| |||||||||||||
Why not filename and line number?Why not filename and line number?Posted Oct 1, 2010 9:53 UTC (Fri) by epa (subscriber, #39769)In reply to: Why not filename and line number? by adamgundy Parent article: Organizing kernel messages
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.
(Log in to post comments)
Why not filename and line number? Posted Oct 1, 2010 10:44 UTC (Fri) by intgr (subscriber, #39733) [Link]
> 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]
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?
|
|||||||||||||