Why not filename and line number? [LWN.net]

Why not filename and line number?

Posted Sep 30, 2010 13:39 UTC (Thu) by felixfix (subscriber, #242)
In reply to: Why not filename and line number? by epa
Parent article: Organizing kernel messages

Because the source line number may well change from time to time? That won't help if you want consistent ids for automated handling, or to send in an email.

I have often used source file and line number in my own messages in my own programs, but always for temporary use, not for any kind of long term identification.

to post comments

Why not filename and line number?

Posted Sep 30, 2010 15:36 UTC (Thu) by epa (subscriber, #39769) [Link] (8 responses)

Because the source line number may well change from time to time?

And so will the exact format string, whose CRC32 has to match exactly for the tool to work. In either case you depend on the exact kernel version. A tiny change to the format string would produce a totally different CRC32.

Why not filename and line number?

Posted Sep 30, 2010 16:05 UTC (Thu) by adamgundy (subscriber, #5418) [Link] (4 responses)

that's not hard to fix. just add a new (optional) version of printk() that lets you specify the ID. if you tweak the format string for some reason (spelling, etc), but the meaning is the same, then just specify the ID so it stays the same..

Why not filename and line number?

Posted Oct 1, 2010 9:53 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

just add a new (optional) version of printk() that lets you specify the ID.

In that case why not short-circuit the whole process - add a unique id to every kernel printk() right now (which can hardly be a controversial patch, even for linux-kernel, since it changes no functionality whatsoever) and be done with it. No need to go through the transitional stage of making up ids from CRC32s.

Why not filename and line number?

Posted Oct 1, 2010 10:44 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

> add a unique id to every kernel printk() right now (which can hardly be a
> controversial patch, even for linux-kernel, since it changes no
> functionality whatsoever)

Such "flag day" patches that require all developers to make the transition at the same time, only work for features with few users. This is because writing patches and merging them is an asynchronous task, trying to coordinate one change to happen on a particular "flag day" synchronizes the process and thus limits the throughput.

And even if you don't expect everyone to transition at the same time, a change that touches practically _every_ file in the source tree would still cause merge conflicts with a large portion of other patches that do real work, and that means lots of work for all maintainers. So in order to have numbered printk's, all other work will have to suffer. It's just not worth the cost for this feature.

It could only work if the conversion is done bit by bit, slowly enough that it has little measurable impact on the process -- but that would take a long time. So even if using CRC32 is a bit of a hack, it's a worthwhile tradeoff because we get similar functionality in no time and no impact.

(Disclaimer: I'm not a Linux kernel hacker, that's just my understanding of the process)

Why not filename and line number?

Posted Oct 1, 2010 15:12 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

If adding a number to a format string - which does not change the line number of any other piece of code, does not move any code around, and does not add or remove files - causes a merge conflict, then your merge algorithm needs fixing. I don't think git's merging is that bad. On the contrary, a single patch to change some strings should be easy for everyone to merge and doesn't require any manual attention or conflict resolution (which would, however, be needed if the patch changed any actual code).

Why not filename and line number?

Posted Oct 1, 2010 16:32 UTC (Fri) by intgr (subscriber, #39733) [Link]

> a single patch to change some strings should be easy for everyone to merge

A _single_ patch is not merged in isolation. That doesn't even make sense. A merge, by definition, can only happen when two patches change the tree from a common ancestor state in different ways. A merge conflict occurs when these two changesets touch the same area of code in different ways.

And git merge doesn't try to be clever. It doesn't understand C. It looks at which lines changed and which didn't, and does a 3-way merge. Resolving merge conflicts requires knowledge of what the code actually does.

So, the printk patch will conflict with every _other_ patch that touches printk lines -- or lines adjacent to a printk -- it's as simple as that.

git merge also obviously cannot assign numbers to printk messages for printk's that were _added_ by other merged patches, so that's another source of headaches.

And can you imagine how many changesets touch printk lines in each kernel release?

Why not filename and line number?

Posted Sep 30, 2010 16:22 UTC (Thu) by felixfix (subscriber, #242) [Link] (2 responses)

You have direct control over the format. You don't have direct control over the line number. It is even arguable that changing the format does change the message. New content needs a new external description. It may indicate circumstances which caused the message have changed.

Why not filename and line number?

Posted Oct 1, 2010 9:50 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

It wouldn't be a good situation, however, for all kernel messages to become set in stone because people are relying on the CRC32 of the format string, so that even spelling mistakes and typos can never be corrected. If you think that line number is something unpredictable, perhaps show "foo.c:N" for the Nth occurrence of printk() in file foo.c. Then it would be fairly robust against code jiggling; only a real change to the code's functionality would cause the number to change.

Why not filename and line number?

Posted Oct 7, 2010 19:47 UTC (Thu) by gvy (guest, #11981) [Link]

Seems you haven't actually read the history part of the article, all of that was discussed already (and outlined there).