On Wed, 2 Jul 2014, Luiz Capitulino wrote: > > With this patch, the dmesg changes break one of my scripts that we use to > > determine the start and end address of a node (doubly bad because there's > > no sysfs interface to determine this otherwise and we have to do this at > > boot to acquire the system topology). > > > > Specifically, the removal of the > > > > "Initmem setup node X [mem 0xstart-0xend]" > > > > lines that are replaced when each node is onlined to > > > > "Node 0 memory range 0xstart-0xend" > > > > And if I just noticed this breakage when booting the latest -mm kernel, > > I'm assuming I'm not the only person who is going to run into it. Is it > > possible to not change the dmesg output? > > Sure. I can add back the original text. The only detail is that with this > patch that line is now printed a little bit later during boot and the > NODA_DATA lines also changed. Are you OK with that? >
Yes, please. I think it should be incremental on your patch since it's already in -mm with " fix" appended so the title of the patch would be "x86: numa: setup_node_data(): drop dead code and rename function fix" and then Andrew can fold it into the original when sending it to the x86 maintainers. > What's the guidelines on changing what's printed in dmesg? > That's the scary part, there doesn't seem to be any. It's especially crucial for things that only get printed once and aren't available anywhere else at runtime; there was talk of adding a sysfs interface that defines the start and end addresses of nodes but it's complicated because nodes can overlap each other. If that had been available years ago then I don't think anybody would raise their hand about this issue. These lines went under a smaller change a few years ago for s/Bootmem/Initmem/. I don't even have to look at the git history to know that because it broke our scripts back then as well. You just happened to touch lines that I really care about and breaks my topology information :) I wouldn't complain if it was just my userspace, but I have no doubt others have parsed their dmesg in a similar way because people have provided me with data that they retrieved by scraping the kernel log. -- 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/
