Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Why not filename and line number?
Posted Oct 1, 2010 9:53 UTC (Fri) by epa (subscriber, #39769)
just add a new (optional) version of printk() that lets you specify the ID.
Posted Oct 1, 2010 10:44 UTC (Fri) by intgr (subscriber, #39733)
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)
Posted Oct 1, 2010 15:12 UTC (Fri) by epa (subscriber, #39769)
Posted Oct 1, 2010 16:32 UTC (Fri) by intgr (subscriber, #39733)
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?
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds