On Mon, 5 Jan 2015 19:21:35 -0500 Rafael Aquini <aqu...@redhat.com> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
