On Mon, 5 Jan 2015 19:21:35 -0500 Rafael Aquini <aquini@xxxxxxxxxx> wrote: > > > > > > > > > > > > > + seq_printf(m, " kernelpagesize_kB=%lu", vma_kernel_pagesize(vma) >> 10); > > > > > > > > This changes the format of the numa_maps file and can potentially break > > > > existing parsers. Please discuss. > > > > ^^ ?? > > > Sorry I overlooked it. > > Parsers indeed would have to be adjusted to cope with an extra line element > (they already have to do so, similarly, for the conditional 'huge' hint). > Despite I don't think of it as a showstopper (as is), I think we can consider > moving it to EOL, if its actual printout position turns out to be an issue. > > > For instance, with this patch a numa_maps line would look like the following: > > 7ff965200000 default file=/anon_hugepage\040(deleted) huge kernelpagesize_kB=2048 anon=5 dirty=5 N0=5 > > > or it could look like this, if we decide to switch kernelpagesize_kB position to EOL, > for the sake of parsers: > > 7ff965200000 default file=/anon_hugepage\040(deleted) huge anon=5 dirty=5 N0=5 kernelpagesize_kB=2048 hm, OK, numa_maps is actually a pretty complex thing: it's a combination of `name' and `name=value'. Some fields may be absent. Parsers need to fully parse each field and can't make assumptions based on field number. So yes, I agree that any parser which actually works is unlikely to break due to this change. However it's probably a bit safer to put the new field at the end of the line. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>