[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cosmetic JFFS patch.
> Things like version strings etc sound useful, but the fact is that the
> only _real_ problem it has ever solved for anybody is when somebody thinks
> they install a new kernel, and forgets to run "lilo" or something. But
> even that information you really get from a simple "uname -a".
For device drivers it tends to be very useful because people often mix and
match a base kernel and older/newer drivers. But it can certainly be
KERN_VERSION which is KERN_DEBUG type level
> Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care
> that we have quota version "dquot_6.4.0"? No. Do we want to get the
Actually that one matters. Its important to tell people they have broken
quota code and should do something about it ;)
> If people care about version printing, it (a) only makes sense for modules
> and (b) should therefore maybe be done by the module loader. And modules
> already have the MODULE_DESCRIPTION() thing, so they should NOT printk it
> on their own. modprobe can do it if it wants to.
Q: Would it be worth making the module author/version strings survive in
a non modular build but stuffed into their own section so you can pull them
out with some magic that we'd include in 'REPORTING-BUGS'
> Authors willing to start sending me patches?
For the networking credit for the university - nope. Its hard to quantify what
it gained the university but it isnt something to throw away lightly. Its
as real in its nonfinancial way as reiserfs is important financially to
Hans and that he is known to be its author.
I've no idea what the position on vendor copyright printk messgaes is,
certainly if they are copyright strings and count as such I think you need
to discuss the matter with the boards of the companies concerned.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org