driver core patches for 3.5-rc1 - try 2
A message that is not in the archive (sent off-list or not yet received): 1337723927.9270.15.camel@joe2Laptop
Quoted 11 lines · Joe Perches
While there are several things I like about the printk modifications, (binary header, delta time, slightly better partial message deinterleaving, global
msg_id, kmsg is ok too), I am concerned about the utility and expectations for the new [v]printk_emit functions.I think it is not really ready to be merged at this time.
The commit sequencing was unclean.
Yes, but the build was never broken, the system always worked, and the end result was agreed apon by everyone as a nice addition.
Quoted 6 lines
The original commit originally required
KERN_CONTand it was modified by another commit to return to the current behavior.What really are the expectations and true use-cases for [v]printk_emit?
What's wrong with the existing use case? Since when do we write use-cases for kernel functions?
Quoted 5 lines
How is it really better that what is available now?
Perhaps it would be better to respin all the printk modifications without adding [v]printk_emit and have the [v]printk_emit bits debated a bit more.
I'm always glad to review patches, but to just propose something that works to be reverted without a patch to replace the functionality, isn't ok.
thanks,
greg k-h
A message that is not in the archive (sent off-list or not yet received): [email protected]
(adding lkml and not editing Greg's reply)
Quoted 20 lines · Greg KH
Quoted 11 lines · Joe Perches
While there are several things I like about the printk modifications, (binary header, delta time, slightly better partial message deinterleaving, global
msg_id, kmsg is ok too), I am concerned about the utility and expectations for the new [v]printk_emit functions.I think it is not really ready to be merged at this time.
The commit sequencing was unclean.
Yes, but the build was never broken, the system always worked, and the end result was agreed apon by everyone as a nice addition.
Quoted 4 lines
The original commit originally required
KERN_CONTand it was modified by another commit to return to the current behavior.
Quoted 5 lines
Quoted 2 lines
What really are the expectations and true use-cases for [v]printk_emit?
What's wrong with the existing use case? Since when do we write use-cases for kernel functions?
When it's a generic function that appears to be used to attach additional data to message logging, and it takes up buffer space and currently reduces the number of dev_<foo> messages in dmesg without adding value.
What's it for and who's going to use it and more importantly, why?
I do not want to link human readable messaging with machine parsing of binary data. I'm not sure it's useful and possibly sets expectations for immutability.
Quoted 9 lines
Quoted 5 lines
How is it really better that what is available now?
Perhaps it would be better to respin all the printk modifications without adding [v]printk_emit and have the [v]printk_emit bits debated a bit more.
I'm always glad to review patches, but to just propose something that works to be reverted without a patch to replace the functionality, isn't ok.
It hasn't been committed yet in anything other than -next.
Lots of stuff gets committed there and later removed and hits Linus' mainline tree.
Quoted 12 lines · Joe Perches
Quoted 10 lines · Greg KH
Quoted 5 lines · Joe Perches
How is it really better that what is available now?
Perhaps it would be better to respin all the printk modifications without adding [v]printk_emit and have the [v]printk_emit bits debated a bit more.
I'm always glad to review patches, but to just propose something that works to be reverted without a patch to replace the functionality, isn't ok.
Quoted 5 lines
It hasn't been committed yet in anything other than -next.
Lots of stuff gets committed there and later removed and hits Linus' mainline tree.
Sorry, but as people are "downstream" for me, I do not rebase my trees, unless something really bad happened (i.e. I messed up the tree). So this will not happen, sorry.
Also, the patches are all in Linus's tree now, so the point is moot.
thanks,
greg k-h