Re: Cosmetic JFFS patch.
Hi! > FWIW I find usb and parport messages exceptionally verbose, but some of USB was bad, but should get better in 2.4.6. I hate that ugly verbosity, and will try to kill it in USB case. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi! FWIW I find usb and parport messages exceptionally verbose, but some of USB was bad, but should get better in 2.4.6. I hate that ugly verbosity, and will try to kill it in USB case. Pavel -- Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
> Leave the copyright messages alone is all I can say. And as to your flag, > well we've got one. Try the 'quiet' boot option YOU> Leaving copyright messages also saves the purpose of motivating - not all but YOU> many - developers. People who _see_ the printk copyright messages is a _very_ YOU> large superset of people who _look_ at source code, or ChangeLog / CREDITS / YOU> MAINTAINERS files. YOU> After all many copyright messages are not that annoying. Suggestion: make the buffer-size for these messages configurable at make config -time. So; people can define wether they want the message or not. If size=0, the printk-thing could be replaced with #define printk(x) /*nothing*/ Nice for the embedded linux-system people. Greetings, Folkert van Heusden [ www.vanheusden.com ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 05:26:53PM +0100, Alan Cox wrote: > > Leave the copyright messages alone is all I can say. And as to your flag, > well we've got one. Try the 'quiet' boot option Leaving copyright messages also saves the purpose of motivating - not all but many - developers. People who _see_ the printk copyright messages is a _very_ large superset of people who _look_ at source code, or ChangeLog / CREDITS / MAINTAINERS files. After all many copyright messages are not that annoying. Anuradha -- Debian GNU/Linux (kernel 2.4.6-pre6) Large increases in cost with questionable increases in performance can be tolerated only in race horses and women. -- Lord Kalvin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 05:26:53PM +0100, Alan Cox wrote: Leave the copyright messages alone is all I can say. And as to your flag, well we've got one. Try the 'quiet' boot option Leaving copyright messages also saves the purpose of motivating - not all but many - developers. People who _see_ the printk copyright messages is a _very_ large superset of people who _look_ at source code, or ChangeLog / CREDITS / MAINTAINERS files. After all many copyright messages are not that annoying. Anuradha -- Debian GNU/Linux (kernel 2.4.6-pre6) Large increases in cost with questionable increases in performance can be tolerated only in race horses and women. -- Lord Kalvin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
Leave the copyright messages alone is all I can say. And as to your flag, well we've got one. Try the 'quiet' boot option YOU Leaving copyright messages also saves the purpose of motivating - not all but YOU many - developers. People who _see_ the printk copyright messages is a _very_ YOU large superset of people who _look_ at source code, or ChangeLog / CREDITS / YOU MAINTAINERS files. YOU After all many copyright messages are not that annoying. Suggestion: make the buffer-size for these messages configurable at make config -time. So; people can define wether they want the message or not. If size=0, the printk-thing could be replaced with #define printk(x) /*nothing*/ Nice for the embedded linux-system people. Greetings, Folkert van Heusden [ www.vanheusden.com ] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Stuart Lynne wrote: > I think listing driver versions on boot with perhaps some diagnostic info > if appropriate is useful. Names and copyrights should be in the source. Yup, if you go out and buy a book, the copyright business is in small print inside, not under the title on the dust-cover.. Now, I'll just have to pretend they don't put the authors name on the front in huge letters, and my analogy will be complete. Hmmm. Craig. -- Craig McLeanP: 01276 423905 Proactive Technical Analyst M: 07801 459497 Sun Microsystems Proactive Services E: [EMAIL PROTECTED] My opinions are not necessarily those of Sun Microsystems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Stuart Lynne wrote: I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. Yup, if you go out and buy a book, the copyright business is in small print inside, not under the title on the dust-cover.. Now, I'll just have to pretend they don't put the authors name on the front in huge letters, and my analogy will be complete. Hmmm. Craig. -- Craig McLeanP: 01276 423905 Proactive Technical Analyst M: 07801 459497 Sun Microsystems Proactive Services E: [EMAIL PROTECTED] My opinions are not necessarily those of Sun Microsystems - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Torrey Hoffman) wrote on 30.06.01 in
<[EMAIL PROTECTED]>:
> So they compile it into the linux_logo.h image. It's now under the
> GPL, of course... what does that do to the legal status of the logo?
Copyright: you named it.
Any other right: unchanged. (The GPL doesn't demand any change, so how
could it possibly change?)
However, for rights you want to keep, I'd suggest pointing them out in
some sort of readme in the sources. ("The XXX Logo is a registered
trademark of XXX Websites, Inc.".)
Frankly, in the context of (say) a registered trademark, the GPL for the
logo becomes fairly meaningless ... sure, you can get "the source", but
you can't *use* it except in those cases where you'd get "the source" for
a proprietary logo anyway, unless it's a really weird case.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Chuck Wolber) wrote on 29.06.01 in <[EMAIL PROTECTED]>: > > Does sed tell you who programmed it on startup? > > > > Awk? > > > > Perl? > > > > Groff? > > > > Gcc? > > > > See a pattern here? > > Yeah, the output of these programms are usually parsed by other programs. s/usually/sometimes/ Most of the time, it's only parsed by humans, with the possible exception of awk. But feel free to look for other common Unix programs that behave differently. df, du, ps, ls, bash ... there *are* programs that announce the copyright at the start, but there are damned few of them. It's not in the culture. > If they barked version info, that'd be extra code that has to go into > *EVERY* script that uses them. You're not using the kernel in the same > capacity. OTOH, kernel output typically *always* goes into another program (dmesg, klog, syslog) ... though admittedly parsing it is not common. Well, except for the oops part (klogd, ksymoops). MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
GDI.EXE was moved into the kernel in winNT 4.0 and has been there ever since. M$ released a white paper about this claiming the "performance boost". worked great for me, but was one more thing to go wrong in kernel space, although they touched on that as well. it'd take me a bit to find a refernce or link for you, but i remember it well.. ;) -greg - Original Message - From: "Hua Zhong" <[EMAIL PROTECTED]> Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode. > >Olaf Hering wrote: > >> kde.o. 2.5? > > > >Good idea! Graphics needs to be in the kernel to be fast. Windows > >proved that. > > thought SGI proved that :-) > > Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> > > Is this (printing out versions. etc) really a big deal so we should add stuff > like "/proc/xxx", KERN_ to make things more complicated? It sounds to me > like to make the kernel "smaller" we'd actually end up with adding more code > and complexity to it. And quite frankly, if people don't read MAINTAINERS, > they won't read /proc/maintainers either. That was why I had the thought of doing it at compile time, based on a magic list of versions only updated by Linus. As I've been told that this won't work very well due to some people having the temerity to disagree with him on driver versions shipped :), something more flexible is needed. I can't think of a neat way to do this, without knowing the source tree the kernel came from though. I think at least knowing what drivers are not stock might be useful. Perhaps make distversion xxx would add another string to KERNELRELEASE, setting a major releases "stock" drivers, and letting anything that changes thereafter have a higher default display level. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode. > >Olaf Hering wrote: > >> kde.o. 2.5? > > > >Good idea! Graphics needs to be in the kernel to be fast. Windows > >proved that. > > thought SGI proved that :-) > > Martin > -- > -- > Martin Knoblauch |email: [EMAIL PROTECTED] > TeraPort GmbH|Phone: +49-89-510857-309 > C+ITS|Fax:+49-89-510857-111 > http://www.teraport.de |Mobile: +49-170-4904759 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -> From Martin Knoblauch <[EMAIL PROTECTED]> : - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Is this (printing out versions. etc) really a big deal so we should add stuff like "/proc/xxx", KERN_ to make things more complicated? It sounds to me like to make the kernel "smaller" we'd actually end up with adding more code and complexity to it. And quite frankly, if people don't read MAINTAINERS, they won't read /proc/maintainers either. > >Print all copyright, config, etc. as KERN_DEBUG. > > How about a new level, say "KERN_CONFIG", with a "show-config" > parameter to enable displaying KERN_CONFIG messages? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Is this (printing out versions. etc) really a big deal so we should add stuff like /proc/xxx, KERN_ to make things more complicated? It sounds to me like to make the kernel smaller we'd actually end up with adding more code and complexity to it. And quite frankly, if people don't read MAINTAINERS, they won't read /proc/maintainers either. Print all copyright, config, etc. as KERN_DEBUG. How about a new level, say KERN_CONFIG, with a show-config parameter to enable displaying KERN_CONFIG messages? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode. Olaf Hering wrote: kde.o. 2.5? Good idea! Graphics needs to be in the kernel to be fast. Windows proved that. thought SGI proved that :-) Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - From Martin Knoblauch [EMAIL PROTECTED] : - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
GDI.EXE was moved into the kernel in winNT 4.0 and has been there ever since. M$ released a white paper about this claiming the performance boost. worked great for me, but was one more thing to go wrong in kernel space, although they touched on that as well. it'd take me a bit to find a refernce or link for you, but i remember it well.. ;) -greg - Original Message - From: Hua Zhong [EMAIL PROTECTED] Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode. Olaf Hering wrote: kde.o. 2.5? Good idea! Graphics needs to be in the kernel to be fast. Windows proved that. thought SGI proved that :-) Martin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Is this (printing out versions. etc) really a big deal so we should add stuff like /proc/xxx, KERN_ to make things more complicated? It sounds to me like to make the kernel smaller we'd actually end up with adding more code and complexity to it. And quite frankly, if people don't read MAINTAINERS, they won't read /proc/maintainers either. That was why I had the thought of doing it at compile time, based on a magic list of versions only updated by Linus. As I've been told that this won't work very well due to some people having the temerity to disagree with him on driver versions shipped :), something more flexible is needed. I can't think of a neat way to do this, without knowing the source tree the kernel came from though. I think at least knowing what drivers are not stock might be useful. Perhaps make distversion xxx would add another string to KERNELRELEASE, setting a major releases stock drivers, and letting anything that changes thereafter have a higher default display level. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Torrey Hoffman) wrote on 30.06.01 in [EMAIL PROTECTED]: So they compile it into the linux_logo.h image. It's now under the GPL, of course... what does that do to the legal status of the logo? Copyright: you named it. Any other right: unchanged. (The GPL doesn't demand any change, so how could it possibly change?) However, for rights you want to keep, I'd suggest pointing them out in some sort of readme in the sources. (The XXX Logo is a registered trademark of XXX Websites, Inc..) Frankly, in the context of (say) a registered trademark, the GPL for the logo becomes fairly meaningless ... sure, you can get the source, but you can't *use* it except in those cases where you'd get the source for a proprietary logo anyway, unless it's a really weird case. MfG Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Chuck Wolber) wrote on 29.06.01 in [EMAIL PROTECTED]: Does sed tell you who programmed it on startup? Awk? Perl? Groff? Gcc? See a pattern here? Yeah, the output of these programms are usually parsed by other programs. s/usually/sometimes/ Most of the time, it's only parsed by humans, with the possible exception of awk. But feel free to look for other common Unix programs that behave differently. df, du, ps, ls, bash ... there *are* programs that announce the copyright at the start, but there are damned few of them. It's not in the culture. If they barked version info, that'd be extra code that has to go into *EVERY* script that uses them. You're not using the kernel in the same capacity. OTOH, kernel output typically *always* goes into another program (dmesg, klog, syslog) ... though admittedly parsing it is not common. Well, except for the oops part (klogd, ksymoops). MfG Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds <[EMAIL PROTECTED]> writes:
> So let's simply disallow versions, author information, and "good status"
> messages, ok?
I'd be quite happy with this, if only for consistency's sake -- at the
moment we've got some kernel subsystems which print "yup, I've started
up" messages, and some which don't; it's mildly annoying when you're
trying to track down a problem that's stopping the kernel from
starting up correctly, because there's no guarantee that the last
message had anything to do with what was actually happening.
Being a geekish sort of person, I'd prefer it if on my system I could
make everything print a line saying what it is and what hardware it
found; perhaps it could be a kernel argument ("messages=full"; the
messages option would control which log prefixes printk would actually
print to the screen, and module startup messages would use a
predefined prefix). Might be handy for debugging.
--
Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Stuart Lynne) writes: [snip] > A counter example that does both, bc does tell us who wrote it > every time we run it (most annoying) and is smart enough to know > when it is not talking to a tty. > > % bc > bc 1.05 > Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > 1+2 > 3 > % bc > test > 1+2 > % cat test > 3 > % That may be because of clause (2.c) of the GPL version 2. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
(cc's trimmed a little.) As someone who actually has created an embedded Linux distribution for a set top box, I can say that the boot output has never been a problem for me. I like verbose output, it's useful. Developers probably know that once you have the system booting nicely and you've quit messing with the kernel, you can put APPEND = "console=/dev/tty2 CONSOLE=/dev/tty2" in lilo.conf. With framebuffer support and a custom, full screen boot logo, the graphics appear immediately after the kernel starts, and no text ever appears on screen. After init gets going, you can continue to dump text output to tty2 while you display pretty pictures in the framebuffer or start X. So, I can't see verbose text output being a problem for anyone developing for embedded systems... that memory is all freed after boot anyway. So here's a real copyright / trademark / GPL question: Suppose some embedded Linux system developer wants to put their trademarked, copyrighted logo on the screen during the boot. So they compile it into the linux_logo.h image. It's now under the GPL, of course... what does that do to the legal status of the logo? Incidentally, the copyright and other messages have never bothered me. I figure if some company is going to do me the favor of sponsoring development of software I can use for free, I really don't mind being reminded of it. MP3.com definitely scores karma points with me for sponsoring Reiser, for instance. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
David Woodhouse wrote: > >Also consider the question "What was the last thing you see on screen >before it reboots?" > USER: A bunch of words. TECH: What words? USER: Dunno, there were a lot though. ;) -b -- :__o : -\<, : 0/ 0 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
--- David Lang <[EMAIL PROTECTED]> wrote: > back when I was doing PC repair (1.x kernel days) I > started useing linux > becouse the boot messages gave me so much info about > the system (I started > to keep a Slackware boot/root disk set on hand so > when faced with a > customer machine I could boot and see what hardware > was actually > installed) > > make a boot option to turn on the verbose mode if > you want, but don't > eliminate it completely. > I like to see boot messages which give me info about my pc: cpu -- type, speed, cache; motherboard -- type, cache; busses; cards information (not copyright). when I want too see what has a computer inside without opening it i boot a linux kernel, and if i have linux on it a 'cat /proc/pci' is sufficient for an average computer. This is one thing you don't see on windblows. I wouldn't like a UN*X which wouldn't tell me what is he doing.(I don't like fancy GUI's which hide the sistem from the user and then screw up everything). __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
--- David Lang [EMAIL PROTECTED] wrote: back when I was doing PC repair (1.x kernel days) I started useing linux becouse the boot messages gave me so much info about the system (I started to keep a Slackware boot/root disk set on hand so when faced with a customer machine I could boot and see what hardware was actually installed) make a boot option to turn on the verbose mode if you want, but don't eliminate it completely. I like to see boot messages which give me info about my pc: cpu -- type, speed, cache; motherboard -- type, cache; busses; cards information (not copyright). when I want too see what has a computer inside without opening it i boot a linux kernel, and if i have linux on it a 'cat /proc/pci' is sufficient for an average computer. This is one thing you don't see on windblows. I wouldn't like a UN*X which wouldn't tell me what is he doing.(I don't like fancy GUI's which hide the sistem from the user and then screw up everything). __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
(cc's trimmed a little.) As someone who actually has created an embedded Linux distribution for a set top box, I can say that the boot output has never been a problem for me. I like verbose output, it's useful. Developers probably know that once you have the system booting nicely and you've quit messing with the kernel, you can put APPEND = console=/dev/tty2 CONSOLE=/dev/tty2 in lilo.conf. With framebuffer support and a custom, full screen boot logo, the graphics appear immediately after the kernel starts, and no text ever appears on screen. After init gets going, you can continue to dump text output to tty2 while you display pretty pictures in the framebuffer or start X. So, I can't see verbose text output being a problem for anyone developing for embedded systems... that memory is all freed after boot anyway. So here's a real copyright / trademark / GPL question: Suppose some embedded Linux system developer wants to put their trademarked, copyrighted logo on the screen during the boot. So they compile it into the linux_logo.h image. It's now under the GPL, of course... what does that do to the legal status of the logo? Incidentally, the copyright and other messages have never bothered me. I figure if some company is going to do me the favor of sponsoring development of software I can use for free, I really don't mind being reminded of it. MP3.com definitely scores karma points with me for sponsoring Reiser, for instance. Torrey Hoffman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Stuart Lynne) writes: [snip] A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc test 1+2 % cat test 3 % That may be because of clause (2.c) of the GPL version 2. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds [EMAIL PROTECTED] writes: So let's simply disallow versions, author information, and good status messages, ok? I'd be quite happy with this, if only for consistency's sake -- at the moment we've got some kernel subsystems which print yup, I've started up messages, and some which don't; it's mildly annoying when you're trying to track down a problem that's stopping the kernel from starting up correctly, because there's no guarantee that the last message had anything to do with what was actually happening. Being a geekish sort of person, I'd prefer it if on my system I could make everything print a line saying what it is and what hardware it found; perhaps it could be a kernel argument (messages=full; the messages option would control which log prefixes printk would actually print to the screen, and module startup messages would use a predefined prefix). Might be handy for debugging. -- Adam Sampson [EMAIL PROTECTED] URL:http://azz.us-lot.org/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
David Woodhouse wrote: Also consider the question What was the last thing you see on screen before it reboots? USER: A bunch of words. TECH: What words? USER: Dunno, there were a lot though. ;) -b -- :__o : -\, : 0/ 0 --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 11:17:15AM -0700, Christoph Zens wrote: > > > Also, in printk's, you waste run-time memory, and you bloat up the need > > for the log size. Both of which are _technical_ reasons not to do it. > > > > Small is beuatiful. > > I totally agree. If you want to use Linux for a small and low cost > embedded system, you can't afford loads of RAM and FLASH space. > Small is the _key_ for those systems. *For* *those* *systems*. Until 99% of the Linux machines are Agendas, or whatever, and 1% PC's, as opposed to the other way around, we should default to displaying basic[1] info about the driver, unless told to with a "verbose" option or somesuch, which would make it spew verbose stuff[2]. And then a "debug" option which would make it spew lots and lots of stuff[3]. All of this specifiable on the commandline. (Can you currently change the default loglevel on the kernel commandline?). I honestly feel that this is the best idea. Just because we do this by default doesn't mean that the people who make embedded systems can't modify the kernel, or hell, even just the bootflags, to do what they want. :) d [1]: : , e.g.: eth0: Intel EtherExpress PRO/100, IRQ10, etc [2]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> eth0: Intel EtherExpress PRO/100, IRQ10, etc [3]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> Loaded with no options, scanning all PCI bus by default. eth0: Intel EtherExpress PRO/100, IRQ10, etc Intel i82559 OEM card, with bug. Enabling lock-up workaround bug, but you should get a Tulip. -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thursday 28 June 2001 14:36, Miquel van Smoorenburg wrote: > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc We've got a couple of VA rackmount servers with adaptec scsi controllers that print out several SCREENS worth of information as they probe all the busses and joyfully announce that yes, there are still hard drives plugged into some of them, and even gives me a list of the ones that DON'T have hard drives plugged into them. Interestingly, the bios also goes through a very similar ritual earlier in the boot. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
In article <[EMAIL PROTECTED]>, Chuck Wolber <[EMAIL PROTECTED]> wrote: >> Does sed tell you who programmed it on startup? >> >> Awk? >> >> Perl? >> >> Groff? >> >> Gcc? >> >> See a pattern here? > >Yeah, the output of these programms are usually parsed by other programs. >If they barked version info, that'd be extra code that has to go into >*EVERY* script that uses them. You're not using the kernel in the same >capacity. A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc > test 1+2 % cat test 3 % I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
>No 'debug=' could then simply cause the kernel to kprint any info from >drivers/modules that failed to load, else keep schtum. My idea is that the driver announces itself, and then what it has found/initialized, in the minimum number of screen lines possible. I'd want that to be the default, because it gives you a decent idea of where it was if it failed. I am envisioning an algorithm like this: 1. Printk name and version 2. initialize self 3. Hunt for devices, printk when you find one 4. Initialize this device 5. Go back to 3 until you don't detect any more devices 6. Do whatever final thing needs doing Note that I only advocate the two printk's mentioned explicitly. I think this provides just enough of a clue to give one an idea of what might have gone wrong, so you might be able to make a quick fix even before needing to enter a "tell me everything you are doing" mode for debugging. More might be nice, but balance is good. I agree with some folks that this is way too much from some drivers. The giant per CPU tables are an example. That's a useful thing if you are a kernel developer, or are trying to debug something weird, but it too much information for someone like me, who knows the code works most of the time. If I see an error, I'm going to replace the CPU, not write new code. On the other hand, I do like the v for version, etc thing, but I think I would have it like this: v for version i for initiation progress (devices and options) d for debugging (or tell me every major step you take) q for quiet (Just the kernel version and the word "Loading" and a spinner of some sort) s for "shut up shuttin' up!" (Nothing, or maybe some custom module for the embedded installations) Obviously, the last two are exclusive with the first three. I'd make it so including them after the other cancels them, so you could add something temporarily without losing your default. I would default to "vi", no pun intended. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi David. >> Perhaps even a boot flag of some sort to de-activate the >> printing of the /proc/credits during the kernel boot sequence. >> Or would the community rather an opt-in scenario... > KERN_BANNER Where would you put that in the sequence? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
back when I was doing PC repair (1.x kernel days) I started useing linux becouse the boot messages gave me so much info about the system (I started to keep a Slackware boot/root disk set on hand so when faced with a customer machine I could boot and see what hardware was actually installed) make a boot option to turn on the verbose mode if you want, but don't eliminate it completely. David Lang On Fri, 29 Jun 2001, Holger Lubitz wrote: > Date: Fri, 29 Jun 2001 15:43:25 +0200 > From: Holger Lubitz <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Newsgroups: lists.linux.kernel > Subject: Re: Cosmetic JFFS patch. > > Miquel van Smoorenburg proclaimed: > > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc > > Well, I _like_ the fact that my machine tells me all that when booting > (ok, maybe the APIC tables are a little bit much). Believe it or not - > the detailed boot messages were one of the reasons I chose Linux over > BSD back in 1993 when I started. I think it gives a valuable feeling for > what the OS is up to - even to the unexperienced. > > A boot parameter for the verbosity would be ok, though. But I'd still > vote for the default to be pretty verbose. Leave it to the distributors > to disable it, if they want. > > After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. > > Holger > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi, > Many new Linux users go through an extended period of dual-booting. And many users also have to sleep in the same room as their computers (still live w/ parents or are in college) and the fans bother them, so they turn them off every night. Just my 2 eurocents. -- Chris Boot [EMAIL PROTECTED] "use the source, luke." (obi-wan gnuobi) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Friday 29 June 2001 15:43, Holger Lubitz wrote: > A boot parameter for the verbosity would be ok, though. But I'd still > vote for the default to be pretty verbose. Leave it to the distributors > to disable it, if they want. > > After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. Many new Linux users go through an extended period of dual-booting. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. Don't forget that embedded devices boot much more often than their desktop counterparts, and they are most often used by people who definitely fall into the non-linux savvy demographic (like my grandmother). We use the Linux Progress Patch (http://lpp.FreeLords.org/) for our solutions. Despite the size that it adds to the kernel (a 240 x 320 image is a pretty big linux_logo.h file), I feel that it makes the kernel booting procedure more painless for the average user (and the hackers can always use dmesg to find out what happened). Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Miquel van Smoorenburg proclaimed: > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc Well, I _like_ the fact that my machine tells me all that when booting (ok, maybe the APIC tables are a little bit much). Believe it or not - the detailed boot messages were one of the reasons I chose Linux over BSD back in 1993 when I started. I think it gives a valuable feeling for what the OS is up to - even to the unexperienced. A boot parameter for the verbosity would be ok, though. But I'd still vote for the default to be pretty verbose. Leave it to the distributors to disable it, if they want. After all - how often does the average linux machine boot? Once a day at most. Mine usually run until the next kernel upgrade. But then again, I'm not a kernel hacker, so this is to be taken more as a users point of view. Holger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hacksaw <[EMAIL PROTECTED]> opined: > Given that seeing as much as possible on a potentially > small screen would be good, maybe tighter would be > nice. In example: > > kswapd:v1.8 > ptyDevices: 256 Unix98 ptys configured > serial:v5.05b (2001-05-03) with >Options: MANY_PORTS SHARE_IRQ SERIAL_PCI >Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > rtclock: v1.10d > ide: v6.31 Perhaps a boot time option such as: lilo boot: newkernel debug=xxx Where each 'x' is an option given to each driver and modules as they're loaded, say 'v' for 'show version', 'o' for 'show options', 'd' for 'show devices managed' and so on. You could even have a 'p' for 'give mad props' if you wanted :-). No 'debug=' could then simply cause the kernel to kprint any info from drivers/modules that failed to load, else keep schtum. Just my ยฃ0.02. Craig. -- Craig McLeanP: 01276 423905 Proactive Technical Analyst M: 07801 459497 Sun Microsystems Proactive Services E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> "ian" == Ian Stirling <[EMAIL PROTECTED]> writes: Hi ian> It would be nice to show driver version for every single non-stock ian> driver we load though. ian> Perhaps a list of versions in the stock kernel build, stored somewhere, ian> that shouldn't be patched by anyone, but only change with official releases. ian> At compile time, if the driver version string is different from the ian> 'blessed' version, it prints it's version, and possibly more. Don't work, because the kernels in distributions are heavily patched, and for the distribution the driver that counts is the one that is in in the distribution, not the one in standard kernel. I think that this is overengenering and not too useful :( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
>Olaf Hering wrote: >> kde.o. 2.5? > >Good idea! Graphics needs to be in the kernel to be fast. Windows >proved that. thought SGI proved that :-) Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 06:18:28PM +0100, Alan Cox wrote: > Managers at places like Cisco see boot messages and it gets into > their brains. They certainly don't all read the source code. For about 4 seconds before gnome/kde starts up... point, click, drag, drool... --cw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Cort Dougan writes: > Can we then expect to see all mention of authors in drivers disappear from > the boot? I think we'll either see a lot more or a lot less. In my example I would have had no particular problem with a message saying "PPP driver copyright Al Longyear and Michael Callahan" or whatever. What annoyed me was the noisy copyright message about something that was only 20 or 30 lines of code, and not especially clever code at that. If copyright messages on boot are the way we get credit for the work we've done, then I have a few to add myself. :) My personal preference is for a quieter boot, with basically no copyright messages. It's Linus' call though. > Same with url's, version #'s and the like? See all the previous messages in this thread. :) > The built by > user@host message is a good bit of "drumming ones own drum" while > contributing very little (running 'make' vs. writing the system). Isn't that more a "who to blame" than credit? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Can we then expect to see all mention of authors in drivers disappear from the boot? Same with url's, version #'s and the like? The built by user@host message is a good bit of "drumming ones own drum" while contributing very little (running 'make' vs. writing the system). Is the kernel boot screen so sacred that it requires us to make it the arid wasteland that the HP-UX boot is? This verbosity is useful in many cases and certainly harmless. } > There's another side to "drumming your own drum": it is often seen as } > actively offensive to some people who don't want to do the same thing. } } I agree. What usually seems to end up happening is that someone } writes 95% and gets no credit, someone else does 5% and puts in a } printk announcing their contribution loudly every time the system } boots. I recall that the old PPP driver used to print "PPP Dynamic } channel allocation code copyright 1995 Caldera, Inc." which always } annoyed me because it was a completely trivial piece of code that the } notice was referring to. } } Paul. } - } To unsubscribe from this list: send the line "unsubscribe linux-kernel" in } the body of a message to [EMAIL PROTECTED] } More majordomo info at http://vger.kernel.org/majordomo-info.html } Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Can we then expect to see all mention of authors in drivers disappear from the boot? Same with url's, version #'s and the like? The built by user@host message is a good bit of drumming ones own drum while contributing very little (running 'make' vs. writing the system). Is the kernel boot screen so sacred that it requires us to make it the arid wasteland that the HP-UX boot is? This verbosity is useful in many cases and certainly harmless. } There's another side to drumming your own drum: it is often seen as } actively offensive to some people who don't want to do the same thing. } } I agree. What usually seems to end up happening is that someone } writes 95% and gets no credit, someone else does 5% and puts in a } printk announcing their contribution loudly every time the system } boots. I recall that the old PPP driver used to print PPP Dynamic } channel allocation code copyright 1995 Caldera, Inc. which always } annoyed me because it was a completely trivial piece of code that the } notice was referring to. } } Paul. } - } To unsubscribe from this list: send the line unsubscribe linux-kernel in } the body of a message to [EMAIL PROTECTED] } More majordomo info at http://vger.kernel.org/majordomo-info.html } Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Cort Dougan writes: Can we then expect to see all mention of authors in drivers disappear from the boot? I think we'll either see a lot more or a lot less. In my example I would have had no particular problem with a message saying PPP driver copyright Al Longyear and Michael Callahan or whatever. What annoyed me was the noisy copyright message about something that was only 20 or 30 lines of code, and not especially clever code at that. If copyright messages on boot are the way we get credit for the work we've done, then I have a few to add myself. :) My personal preference is for a quieter boot, with basically no copyright messages. It's Linus' call though. Same with url's, version #'s and the like? See all the previous messages in this thread. :) The built by user@host message is a good bit of drumming ones own drum while contributing very little (running 'make' vs. writing the system). Isn't that more a who to blame than credit? Paul. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Olaf Hering wrote: kde.o. 2.5? Good idea! Graphics needs to be in the kernel to be fast. Windows proved that. thought SGI proved that :-) Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
ian == Ian Stirling [EMAIL PROTECTED] writes: Hi ian It would be nice to show driver version for every single non-stock ian driver we load though. ian Perhaps a list of versions in the stock kernel build, stored somewhere, ian that shouldn't be patched by anyone, but only change with official releases. ian At compile time, if the driver version string is different from the ian 'blessed' version, it prints it's version, and possibly more. Don't work, because the kernels in distributions are heavily patched, and for the distribution the driver that counts is the one that is in in the distribution, not the one in standard kernel. I think that this is overengenering and not too useful :( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hacksaw [EMAIL PROTECTED] opined: Given that seeing as much as possible on a potentially small screen would be good, maybe tighter would be nice. In example: kswapd:v1.8 ptyDevices: 256 Unix98 ptys configured serial:v5.05b (2001-05-03) with Options: MANY_PORTS SHARE_IRQ SERIAL_PCI Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtclock: v1.10d ide: v6.31 Perhaps a boot time option such as: lilo boot: newkernel debug=xxx Where each 'x' is an option given to each driver and modules as they're loaded, say 'v' for 'show version', 'o' for 'show options', 'd' for 'show devices managed' and so on. You could even have a 'p' for 'give mad props' if you wanted :-). No 'debug=' could then simply cause the kernel to kprint any info from drivers/modules that failed to load, else keep schtum. Just my ยฃ0.02. Craig. -- Craig McLeanP: 01276 423905 Proactive Technical Analyst M: 07801 459497 Sun Microsystems Proactive Services E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Miquel van Smoorenburg proclaimed: You know what I hate? Debugging stuff like BIOS-e820, zone messages, dentry|buffer|page-cache hash table entries, CPU: Before vendor init, CPU: After vendor init, etc etc, PCI: Probing PCI hardware, ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc Well, I _like_ the fact that my machine tells me all that when booting (ok, maybe the APIC tables are a little bit much). Believe it or not - the detailed boot messages were one of the reasons I chose Linux over BSD back in 1993 when I started. I think it gives a valuable feeling for what the OS is up to - even to the unexperienced. A boot parameter for the verbosity would be ok, though. But I'd still vote for the default to be pretty verbose. Leave it to the distributors to disable it, if they want. After all - how often does the average linux machine boot? Once a day at most. Mine usually run until the next kernel upgrade. But then again, I'm not a kernel hacker, so this is to be taken more as a users point of view. Holger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
After all - how often does the average linux machine boot? Once a day at most. Mine usually run until the next kernel upgrade. But then again, I'm not a kernel hacker, so this is to be taken more as a users point of view. Don't forget that embedded devices boot much more often than their desktop counterparts, and they are most often used by people who definitely fall into the non-linux savvy demographic (like my grandmother). We use the Linux Progress Patch (http://lpp.FreeLords.org/) for our solutions. Despite the size that it adds to the kernel (a 240 x 320 image is a pretty big linux_logo.h file), I feel that it makes the kernel booting procedure more painless for the average user (and the hackers can always use dmesg to find out what happened). Jordan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Friday 29 June 2001 15:43, Holger Lubitz wrote: A boot parameter for the verbosity would be ok, though. But I'd still vote for the default to be pretty verbose. Leave it to the distributors to disable it, if they want. After all - how often does the average linux machine boot? Once a day at most. Mine usually run until the next kernel upgrade. But then again, I'm not a kernel hacker, so this is to be taken more as a users point of view. Many new Linux users go through an extended period of dual-booting. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi, Many new Linux users go through an extended period of dual-booting. And many users also have to sleep in the same room as their computers (still live w/ parents or are in college) and the fans bother them, so they turn them off every night. Just my 2 eurocents. -- Chris Boot [EMAIL PROTECTED] use the source, luke. (obi-wan gnuobi) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
back when I was doing PC repair (1.x kernel days) I started useing linux becouse the boot messages gave me so much info about the system (I started to keep a Slackware boot/root disk set on hand so when faced with a customer machine I could boot and see what hardware was actually installed) make a boot option to turn on the verbose mode if you want, but don't eliminate it completely. David Lang On Fri, 29 Jun 2001, Holger Lubitz wrote: Date: Fri, 29 Jun 2001 15:43:25 +0200 From: Holger Lubitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Newsgroups: lists.linux.kernel Subject: Re: Cosmetic JFFS patch. Miquel van Smoorenburg proclaimed: You know what I hate? Debugging stuff like BIOS-e820, zone messages, dentry|buffer|page-cache hash table entries, CPU: Before vendor init, CPU: After vendor init, etc etc, PCI: Probing PCI hardware, ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc Well, I _like_ the fact that my machine tells me all that when booting (ok, maybe the APIC tables are a little bit much). Believe it or not - the detailed boot messages were one of the reasons I chose Linux over BSD back in 1993 when I started. I think it gives a valuable feeling for what the OS is up to - even to the unexperienced. A boot parameter for the verbosity would be ok, though. But I'd still vote for the default to be pretty verbose. Leave it to the distributors to disable it, if they want. After all - how often does the average linux machine boot? Once a day at most. Mine usually run until the next kernel upgrade. But then again, I'm not a kernel hacker, so this is to be taken more as a users point of view. Holger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
No 'debug=' could then simply cause the kernel to kprint any info from drivers/modules that failed to load, else keep schtum. My idea is that the driver announces itself, and then what it has found/initialized, in the minimum number of screen lines possible. I'd want that to be the default, because it gives you a decent idea of where it was if it failed. I am envisioning an algorithm like this: 1. Printk name and version 2. initialize self 3. Hunt for devices, printk when you find one 4. Initialize this device 5. Go back to 3 until you don't detect any more devices 6. Do whatever final thing needs doing Note that I only advocate the two printk's mentioned explicitly. I think this provides just enough of a clue to give one an idea of what might have gone wrong, so you might be able to make a quick fix even before needing to enter a tell me everything you are doing mode for debugging. More might be nice, but balance is good. I agree with some folks that this is way too much from some drivers. The giant per CPU tables are an example. That's a useful thing if you are a kernel developer, or are trying to debug something weird, but it too much information for someone like me, who knows the code works most of the time. If I see an error, I'm going to replace the CPU, not write new code. On the other hand, I do like the v for version, etc thing, but I think I would have it like this: v for version i for initiation progress (devices and options) d for debugging (or tell me every major step you take) q for quiet (Just the kernel version and the word Loading and a spinner of some sort) s for shut up shuttin' up! (Nothing, or maybe some custom module for the embedded installations) Obviously, the last two are exclusive with the first three. I'd make it so including them after the other cancels them, so you could add something temporarily without losing your default. I would default to vi, no pun intended. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
In article [EMAIL PROTECTED], Chuck Wolber [EMAIL PROTECTED] wrote: Does sed tell you who programmed it on startup? Awk? Perl? Groff? Gcc? See a pattern here? Yeah, the output of these programms are usually parsed by other programs. If they barked version info, that'd be extra code that has to go into *EVERY* script that uses them. You're not using the kernel in the same capacity. A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc test 1+2 % cat test 3 % I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thursday 28 June 2001 14:36, Miquel van Smoorenburg wrote: You know what I hate? Debugging stuff like BIOS-e820, zone messages, dentry|buffer|page-cache hash table entries, CPU: Before vendor init, CPU: After vendor init, etc etc, PCI: Probing PCI hardware, ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc We've got a couple of VA rackmount servers with adaptec scsi controllers that print out several SCREENS worth of information as they probe all the busses and joyfully announce that yes, there are still hard drives plugged into some of them, and even gives me a list of the ones that DON'T have hard drives plugged into them. Interestingly, the bios also goes through a very similar ritual earlier in the boot. Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 11:17:15AM -0700, Christoph Zens wrote: Also, in printk's, you waste run-time memory, and you bloat up the need for the log size. Both of which are _technical_ reasons not to do it. Small is beuatiful. I totally agree. If you want to use Linux for a small and low cost embedded system, you can't afford loads of RAM and FLASH space. Small is the _key_ for those systems. *For* *those* *systems*. Until 99% of the Linux machines are Agendas, or whatever, and 1% PC's, as opposed to the other way around, we should default to displaying basic[1] info about the driver, unless told to with a verbose option or somesuch, which would make it spew verbose stuff[2]. And then a debug option which would make it spew lots and lots of stuff[3]. All of this specifiable on the commandline. (Can you currently change the default loglevel on the kernel commandline?). I honestly feel that this is the best idea. Just because we do this by default doesn't mean that the people who make embedded systems can't modify the kernel, or hell, even just the bootflags, to do what they want. :) d [1]: device name: hardware type irq, etc, e.g.: eth0: Intel EtherExpress PRO/100, IRQ10, etc [2]: driver name: version maintainer device name: hardware type irq, etc, e.g.: eepro100.c: v0.1, Daniel Stone [EMAIL PROTECTED] eth0: Intel EtherExpress PRO/100, IRQ10, etc [3]: driver name: version maintainer other random init crap device name: hardware type irq, etc other random crap, e.g.: eepro100.c: v0.1, Daniel Stone [EMAIL PROTECTED] Loaded with no options, scanning all PCI bus by default. eth0: Intel EtherExpress PRO/100, IRQ10, etc Intel i82559 OEM card, with x bug. Enabling lock-up workaround bug, but you should get a Tulip. -- Daniel Stone [EMAIL PROTECTED] Nuke can NE1 help me aim nuclear weaponz? /MSG ME!! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 06:18:28PM +0100, Alan Cox wrote: Managers at places like Cisco see boot messages and it gets into their brains. They certainly don't all read the source code. For about 4 seconds before gnome/kde starts up... point, click, drag, drool... --cw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi David. Perhaps even a boot flag of some sort to de-activate the printing of the /proc/credits during the kernel boot sequence. Or would the community rather an opt-in scenario... KERN_BANNER Where would you put that in the sequence? Best wishes from Riley. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds writes: > There's another side to "drumming your own drum": it is often seen as > actively offensive to some people who don't want to do the same thing. I agree. What usually seems to end up happening is that someone writes 95% and gets no credit, someone else does 5% and puts in a printk announcing their contribution loudly every time the system boots. I recall that the old PPP driver used to print "PPP Dynamic channel allocation code copyright 1995 Caldera, Inc." which always annoyed me because it was a completely trivial piece of code that the notice was referring to. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> > Linus Torvalds wrote: > > 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". > > > > 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 > > version printed for every single driver we load? No. It would be nice to show driver version for every single non-stock driver we load though. Perhaps a list of versions in the stock kernel build, stored somewhere, that shouldn't be patched by anyone, but only change with official releases. At compile time, if the driver version string is different from the 'blessed' version, it prints it's version, and possibly more. > As Alan said, driver versions are incredibly useful. People use update > their drivers over top of kernel drivers all the time. Vendors do it > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > end users. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Given that seeing as much as possible on a potentially small screen would be good, maybe tighter would be nice. In example: kswapd:v1.8 ptyDevices: 256 Unix98 ptys configured serial:v5.05b (2001-05-03) with Options: MANY_PORTS SHARE_IRQ SERIAL_PCI Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtclock: v1.10d ide: v6.31 net: v4.0 for Linux 2.2, from Swansea University Computer Society NET3.039 Unix domain sockets 1.0 for NET4.0. TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 524288 bhash 65536) IPv4 over IPv4 tunneling driver early initialization of device tunl0 is deferred AppleTalk 0.18 for NET4.0 My hope would be that the name at the extreme left column would be the name of the module that would be loaded if it were a module, and the name of the main code file of the driver in question. That way, those trying to debug stuff could go right to the appropriate file, and start reading the code or nearby documentation. Of course, the spacing I have above is optimistic, but just making sure that a new driver prints it's version line against the left margin, and everything else a few spaces out would help readability. You might note that I eliminated the word Linux in 5 or 6 places. We know the driver works with Linux if it is booting. On the other hand "vX.X for Linux 2.X" is useful, since it's part of the version number. Your opinion may vary. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
Linus Torvalds hath spoken:
> I don't _have_ any instances of my name being printed out to annoy the
> user, so that's a very theoretical argument.
There is, of course, only one way to be fair about this.
And that is to apply this patch to init/main.c:
518a519
> printk("Linux is a registered trademark of Linus Torvalds.\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] wrote on 28.06.01 in <[EMAIL PROTECTED]>: > > > Linux NET4.0 for Linux 2.4 > > > Based upon Swansea University Computer Society NET3.039 > > > > The later line is not something of interest to most people, and if it > > happens to be they can research it rather than being force-fed history > > on bootup. > > I've never met a single person who shared that opinion. In fact, quite the > contrary. It's the main source of currency in this space. If you can't > toot your own horn and/or share credit what's all of this open source > stuff worth? We aren't all Mother Theresa now... Does sed tell you who programmed it on startup? Awk? Perl? Groff? Gcc? See a pattern here? I might add that the most-used program I was one of several authors of *never* mentioned a single author in the program messages, with the single exception that the initials of the author actually compiling the source were part of the version string (in an attempt to control "just which patch to 7.53 are you talking about?" syndrome). I can't say this ever bothered me. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] (Linus Torvalds) wrote on 28.06.01 in <[EMAIL PROTECTED]>: > On Thu, 28 Jun 2001, David Woodhouse wrote: > > > > I agree the messages can be ugly. But they don't do any harm either, and > > sometimes they're useful. > > I consider them harmful when I start getting annoying patches that start > adding more and more of them. Or when there are enough boot messages that the dmesg buffer overflows. My current (2.2.19pre1 or so) system has that problem. That *is* harm caused by these messages. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On 20010628 Troy Benjegerdes wrote: >> > >> > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, >> > Roman Weissgaerber >> > > usb-uhci.c: USB Universal Host Controller Interface driver >> > >> > How about "usb-uhci.c: USB Universal Host Controller Interface >> > driver v1.251" >> > instead? >> > Sorry if this has appeared before in the thread... I like the boot messages (as everyone running linus, I suppose) because you know what is it doing really. But boot is now a real mesh. If toy want to find something you have to read all. Would't it be nice to give a template or a try to standarise the init or module insertion messages ? Someone that can have a global view of what kind of info a subsystem or a driver can print (name of driver, version, devices detected Say you can change: Starting kswapd v1.8 pty: 256 Unix98 ptys configured Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10d block: queued sectors max/low 169645kB/56548kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later To: kswapd: Version: 1.8 pty: Version: x Devices: 256 Unix98 ptys configured serial: Version: 5.05b (2001-05-03) with Options: MANY_PORTS SHARE_IRQ SERIAL_PCI Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtclock: Version: 1.10d ide: Version: 6.31 .. Just an idea -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Mandrake Linux release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac19 #2 SMP Thu Jun 28 00:12:01 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Olaf Hering wrote: > kde.o. 2.5? Good idea! Graphics needs to be in the kernel to be fast. Windows proved that. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, Jeff Garzik wrote: > John R Lenton wrote: > > > > On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote: > > > > > > KERN_BANNER > > > > cool, what about kbannerd ? > > > I'm still pushing for a Perl interpreter in the kernel, let's not forget > that too. kde.o. 2.5? Gruss Olaf -- $ man clone BUGS Main feature not yet implemented... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
John R Lenton wrote: > > On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote: > > > > KERN_BANNER > > cool, what about kbannerd ? I'm still pushing for a Perl interpreter in the kernel, let's not forget that too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote: > > KERN_BANNER cool, what about kbannerd ? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: A longo prazo, estaremos todos mortos. -- John Maynard Keynes PGP signature
Re: Cosmetic JFFS patch.
>Print all copyright, config, etc. as KERN_DEBUG. How about a new level, say "KERN_CONFIG", with a "show-config" parameter to enable displaying KERN_CONFIG messages? Craig Milo Rogers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds wrote: > Especially as "dmesg" will output even the debugging messages > that do not actually end up being printed on the screen unless explicitly > asked for. Nifty, I did not know that. Makes all kinds of sense, though. Silly me... > I'd also like to acknowledge the fact that at bootup it's usually very > nice to see "what was the last message it printed before it hung", and > that there's a fair reason for drivers to print out a single line of "I > just registered myself" for that reason. If that line happens to contain a > version string, all the better. Excellent. Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Gerhard Mack wrote: > > On Thu, 28 Jun 2001, Jeff Garzik wrote: > > > Linus Torvalds wrote: > > > 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". > > > > > > 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 > > > version printed for every single driver we load? No. > > > > > > 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. > > > > As Alan said, driver versions are incredibly useful. People use update > > their drivers over top of kernel drivers all the time. Vendors do it > > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > > end users. > > Why not a generic way to query the drivers for version info from > userspace? For NICs at least, there's already a generic way... :) Sigh, in my technically correct heart I know putting driver versions in dmesg is probably not the best thing, but it makes support -so- -much- easier that I am not inclined to change the existing code. FWIW, all the NIC drivers I mess with (most originated from Becker) should print out: eth0: short product name, base addr, MAC addr, irq eth1: ... eth2: ... I grant you there are tons of exceptions even in NIC drivers, but that is the goal I am striving for. One line version, plus one line per registered netif. FWIW I find usb and parport messages exceptionally verbose, but some of that is probably related to KERN_DEBUG being set in the bootloader or kernel/printk.c or somewhere... Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, Jeff Garzik wrote: > > As Alan said, driver versions are incredibly useful. People use update > their drivers over top of kernel drivers all the time. Vendors do it > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > end users. Fair enough. Especially as "dmesg" will output even the debugging messages that do not actually end up being printed on the screen unless explicitly asked for. I'd also like to acknowledge the fact that at bootup it's usually very nice to see "what was the last message it printed before it hung", and that there's a fair reason for drivers to print out a single line of "I just registered myself" for that reason. If that line happens to contain a version string, all the better. And if the user has to boot with "debug" to see all the information when the machine hangs at bootup (when you can't just mail dmesg), that's probably acceptable. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, Jeff Garzik wrote: > Linus Torvalds wrote: > > 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". > > > > 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 > > version printed for every single driver we load? No. > > > > 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. > > As Alan said, driver versions are incredibly useful. People use update > their drivers over top of kernel drivers all the time. Vendors do it > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > end users. Why not a generic way to query the drivers for version info from userspace? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Ok, my two cents. Print all copyright, config, etc. as KERN_DEBUG. Then use a 'verbose' or similar parameter to lilo/kernel to enable console printing of KERN_DEBUG, to be used when the system fails to boot, etc. Dan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds wrote: > 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". > > 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 > version printed for every single driver we load? No. > > 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. As Alan said, driver versions are incredibly useful. People use update their drivers over top of kernel drivers all the time. Vendors do it too. "Run dmesg and e-mail me the output" is 1000 times more simple for end users. > So let's simply disallow versions, author information, and "good status" > messages, ok? For stuff that is useful for debugging (but that the driver > doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end > up printed on the screen normally. Note that KERN_DEBUG appears in dmesg by default in 2.4, AFAICS. This may be a big source of complaints, right there... Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Miquel van Smoorenburg wrote: > > In article <[EMAIL PROTECTED]>, > Tommy Reynolds <[EMAIL PROTECTED]> wrote: > >Linus Torvalds <[EMAIL PROTECTED]> was pleased to say: > > > >> If they are shut off, then where's the drumming? Because if people start > >> making copyright printk's normal, I will make "quiet" the default. > > > >Amen. This is like editing a program to remove the "harmless" compiler warning > >messages. If I don't get a useless message, I don't have to decide to ignore > >it. Describing what's happening is OK; don't gush. > > Yep - a driver should print out that it loaded and what hardware it > found. Nothing else. > > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc > > That's stuff that noone cares about. If the system fails to boot > boot it with a debug flag. If it does boot, _fine_. Actually this [IMHO] a bug that should be fixed in 2.4: The default logging level for the production 2.4 kernel includes KERN_DEBUG, which is why you see a lot of this crap. > arch/i386/kernel/setup.c: printk(KERN_DEBUG "CPU: Common caps: >%08x %08x %08x %08x\n", -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
In article <[EMAIL PROTECTED]>, Tommy Reynolds <[EMAIL PROTECTED]> wrote: >Linus Torvalds <[EMAIL PROTECTED]> was pleased to say: > >> If they are shut off, then where's the drumming? Because if people start >> making copyright printk's normal, I will make "quiet" the default. > >Amen. This is like editing a program to remove the "harmless" compiler warning >messages. If I don't get a useless message, I don't have to decide to ignore >it. Describing what's happening is OK; don't gush. Yep - a driver should print out that it loaded and what hardware it found. Nothing else. You know what I hate? Debugging stuff like BIOS-e820, zone messages, dentry|buffer|page-cache hash table entries, CPU: Before vendor init, CPU: After vendor init, etc etc, PCI: Probing PCI hardware, ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc That's stuff that noone cares about. If the system fails to boot boot it with a debug flag. If it does boot, _fine_. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote: > > > [EMAIL PROTECTED] said: > > 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. > > I can give counter-examples of times when it's been extremely useful to > know exactly what version the user is running, and the info messages > included in their first bug report have told me exactly what I needed to > know. > > Only for code which is always distributed as part of the kernel, and where > there are never any more up to date versions in the maintainer's tree, even > temporarily. Indeed, and even if you're talking about kernel x.y.z the user might in fact be running a vendor-patched kernel with a newer version of the driver (and the author would still have to find out what version of the driver was included). For other things the version string is pretty useless as it isn't ever updated (e.g. networking), and there the kernel version is enough information. What I'd propose is a recommendation that modules in addition to the "useful" information a module should print a maximum of one line (80 chars), and the author gets to choose what they want in there, version information, driver homepage, copyright, sponsor, whatever. I just hope we never get to the point of having a "Memory leak removal sponsored by Tampax" boot message ;) -- Pekka Pietikainen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> Also, in printk's, you waste run-time memory, and you bloat up the need > for the log size. Both of which are _technical_ reasons not to do it. > > Small is beuatiful. I totally agree. If you want to use Linux for a small and low cost embedded system, you can't afford loads of RAM and FLASH space. Small is the _key_ for those systems. > > Linus > > > To unsubscribe from this list: send the line "unsubscribe jffs-dev" in > the body of a message to [EMAIL PROTECTED] > -- Christoph Zens [EMAIL PROTECTED] (415)-289-7765 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds <[EMAIL PROTECTED]> was pleased to say: > If they are shut off, then where's the drumming? Because if people start > making copyright printk's normal, I will make "quiet" the default. Amen. This is like editing a program to remove the "harmless" compiler warning messages. If I don't get a useless message, I don't have to decide to ignore it. Describing what's happening is OK; don't gush. -- Tommy Reynolds | Red Hat, Inc. (Embedded Development) | Join my presentation at: 307 Wynn Drive NW, Huntsville, AL 35805 USA | Red Hat TechWorld Brussels mailto:[EMAIL PROTECTED] | http://www.redhat-techworld.com Phone: +1.256.704.9286 | Mobile: +1.919.641.2923 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] said: > I consider them harmful when I start getting annoying patches that > start adding more and more of them. > Which is how this whole thread started. Sort of. The point of the patch which started this thread was as a wake-up call to a company who had taken the code, renamed it to appear as their own, commented out the version and copyright printk, and shipped it to their customers in an RPM which claimed it was proprietary code. That wake-up call served its primary purpose quite effectively. The new line was added simply to ensure that if such a thing happens again, the newly-named copyright holder will be in a position to do something about it. Take them all out if you must. I stand by my prediction. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> >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'
>
> In a /proc file, maybe? A single file ("/proc/authors"?
> "/proc/versions"? "/proc/brags"? "/proc/kvell"?) could present the
/proc/drivers maybe. It just needs to be a compact summry for debugging -
nothing more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote: > > > > Taking that one step further, isn't it a developer's right to "toot their > > > own horn" in their code? > > > > Right. In the code. Not in the Linux boot diagnostic information. > > Which is why I proposed earlier that we make it easy to shut them off. > Alan piped in with the "quiet" boot option. If they are shut off, then where's the drumming? Because if people start making copyright printk's normal, I will make "quiet" the default. Also, in printk's, you waste run-time memory, and you bloat up the need for the log size. Both of which are _technical_ reasons not to do it. Small is beuatiful. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, David Woodhouse wrote: > > I agree the messages can be ugly. But they don't do any harm either, and > sometimes they're useful. I consider them harmful when I start getting annoying patches that start adding more and more of them. Which is how this whole thread started. My solution was to just move it into a comment, at which point I don't mind adding more copyright notices, because I know it cannot annoy a real user. And "real users" are what matters, after all. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote: > > Taking that one step further, isn't it a developer's right to "toot their > own horn" in their code? You can do whatever you want in your own code. But if it makes the code behave badly, others have the right to change it. That's what the GPL is all about (you have the right to change it even if it _doesn't_ "behave badly", of course ;) You mustn't remove copyright messages, but you can certainly move them (as long as they are prominently displayed in the source - see ยง1 in the GPL about "conspicuously and appropriately publish"). But that certainly doesn't preclude moving it into a comment, for example. So that it doesn't end up disturbing users who have nothing to do with it. (Note: the "conspicuously and appropriately publish" thing is obviously a matter of taste, especially the "appropriately". So it would easily be considered non-appropriate to move _one_ copyright holder into a comment, while printing out the names of the others. But if you make it a policy to do it across the board, that's clearly "appripriately publishing"). The GPL requires that you "keep intact all the notices that refer to this License and to the absence of any warranty" in the verbatim copy of the programs source code. It doesn't require that you print it out on use (it has that silly "interactive program that is already verbose about the copyright" thing in 2c, but happily that doesn't cover the kernel anyway). There's another side to "drumming your own drum": it is often seen as actively offensive to some people who don't want to do the same thing. Copyright messages often disturb developers even when they are only in the code. Which is why they should be at the top, and ONLY at the top. That's where they are most visible for people who search for them (remember: the copyright message is not primarily for tooting your own horn, it's primarily there to inform people who _wonder_ about whom to contact about the copyright status of the file). And that's also where they aren't in the way for development, and for making changes (what should you do if you change some piece of code, and the comment above it has somebody elses copyright in it - while you've now change the code to make the comment meaningless?) And note that this is not actually a hypothetical example. There have been real-world cases where major developers have complained about other developers copyright notices being disturbingly "in the way". So there's "drumming your own drum", but there's also "being a loudmouth". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
>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'
In a /proc file, maybe? A single file ("/proc/authors"?
"/proc/versions"? "/proc/brags"? "/proc/kvell"?) could present the
whole section. Alternatively, you could have one /proc file per
attributed source file; I suspect that would be messier to code. In a
modular system, would it be feasible to dynamically link/unlink
attribution strings from a global list as modules are loaded/unloaded,
and display linked attributions along with static ones in the /proc
file?
Extrapolating from past behavior into the future: someone will
submit code with a multi-page attribution string. It is likely that
we'd need a formal policy on the length, content, and maybe even format
of attribution strings.
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> Let's make it policy that we _never_ print out annoying messages that have > no useful purpose for debugging or running the system, ok? > > "Informational" messages aren't informational, they're just annoying, and > they hide the _real_ stuff. Sometimes, but I've run into WAY too many occasions where all I know about why this sytem died was "what was the last annoying informational boot message". This gets really usefull when you have either old crufty hardware that's questionable OR fresh alpha silicon for some new whizz-bang processor. > 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". > > 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 > version printed for every single driver we load? No. > > 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. > > So let's simply disallow versions, author information, and "good status" > messages, ok? For stuff that is useful for debugging (but that the driver > doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end > up printed on the screen normally. > > Authors willing to start sending me patches? > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 09:39:15AM +0100, Laramie Leavitt wrote: > > On Wed, Jun 27, 2001 at 01:50:28PM -0700, Linus Torvalds wrote: > > > How about we drop the "printk" altogether, and make it all a comment? > > > > Can we please also drop annoying static informational printk's? > > > > > Linux NET4.0 for Linux 2.4 > > > Based upon Swansea University Computer Society NET3.039 > > > > The later line is not something of interest to most people, and if it > > happens to be they can research it rather than being force-fed history > > on bootup. > > > > > POSIX conformance testing by UNIFIX > > > > Ditto. > > > > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, > > Roman Weissgaerber > > > usb-uhci.c: USB Universal Host Controller Interface driver > > > > How about "usb-uhci.c: USB Universal Host Controller Interface > > driver v1.251" > > instead? > > > > dmesg buffer space is rather limited and IMHO there isn't space to > > waste on credit-giving in boot logs. > > Here here. You don't see annoying log-eating copyright messages > printed out in the Windows boot. Just imagine: Whoaa, back the truck up you just threw all those log messages in. One of the reasons I absolutely HATED windoze was that it didn't tell you ANYTHING about what it was doing when booting. If it died during bootup you had no idea what driver was loading. Yes, *some* of the boot messageses are excessive, but I don't know how many times I've been able to diagnose a hardware problem or been helped by verbose boot messages on some strange hardware I was trying to bring up, and the 'what was the last message printed out' has been invaluable. > Initializing VGA Display. VGA Display by John Smith, John Smith, Jr. > Bill T. Gates, Paul G. Allen, Janet K. Reno. Copyright(c) 1985 Microsoft. > Loading Microsoft ATAPI. Microsoft ATAPI Copyright (c) 1983-2001 Microsoft. > Scanning Microsoft SCSI Layer. Portions Copyright (c) 1992 Harold Potter. > Microsoft SCSI Layer developed in part by Seagate Corporation. > Starting Microsoft Display Device. Display based on Microsoft VESA > Extensions. > Display layer Copyright(c) 1983-2001 Microsoft. > Loading Creative Diamond Viper V770 Display Driver. > Diamond Viper V770 Display driver Copyright(c) 1999 Diamond Multimedia. > Diamond Viper V770 Display driver based on NVIDIA TNT2 Display Driver. > NVIDIA TNT2 Copyright(c) 1998-1999 NVIDIA Corporation. > Scanning Network Devices... > WinSock 2000. Copyright(c) 1990-2001 Microsoft. > WinSock 2000 Contributors include: John Doe, Jane Doe, Ed Smith, Herman > Melville. > Starting WinsockDirect. Winsock Direct Copyright(c) 1999 Microsoft. > WinsockDirect supported by 3COM Corporation, Intel Corporation. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] said: > On Thu, 28 Jun 2001, Alan Cox wrote: > > Managers at places like Cisco see boot messages and it gets into > > their brains. They certainly don't all read the source code. > Quote frankly, I doubt "managers" read the boot messages. This is consistent with what Alan said. "read" != "see". I agree the messages can be ugly. But they don't do any harm either, and sometimes they're useful. Furthermore, I believe that if you enforce a policy of removing them, the direct result of that will be that GPL'd code is released back into the community far slower than it is at the moment. It's your choice, though. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 10:29:11AM -0700, [EMAIL PROTECTED] wrote: > Taking that one step further, isn't it a developer's right to "toot their > own horn" in their code? Right. In the code. Not in the Linux boot diagnostic information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, Alan Cox wrote: > > > As to the credit argument: put your copyright at the top of the source > > file. The people who care and matter will see it. And do NOT hide the > > copyright with reams of changelog information. Put that in a separate file > > if you must. > > Managers at places like Cisco see boot messages and it gets into > their brains. They certainly don't all read the source code. I agree that they won't read the sources. HOWEVER, it's also clearly unworkable to have everybody list their name, This is what we have MAINTAINERS and CREDITS for. Quote frankly, I doubt "managers" read the boot messages. They tend to ask engineers who is responsible. I know I look in the MAINTAINERS file first, then in the actual source code (some people don't want to be listed as maintainers), and I don't think I've ever looked at a boot message on who to worry about. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> Also consider the question "What was the last thing you see on screen > before it reboots?" You need that info in case it doesn't. Its much like the watchdog tells you it fired in case someone didn't wire it right. So in a sense its an error message - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> As to the credit argument: put your copyright at the top of the source > file. The people who care and matter will see it. And do NOT hide the > copyright with reams of changelog information. Put that in a separate file > if you must. Managers at places like Cisco see boot messages and it gets into their brains. They certainly don't all read the source code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
[EMAIL PROTECTED] said: > 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. I can give counter-examples of times when it's been extremely useful to know exactly what version the user is running, and the info messages included in their first bug report have told me exactly what I needed to know. > But even that information you really get from a simple "uname -a". Only for code which is always distributed as part of the kernel, and where there are never any more up to date versions in the maintainer's tree, even temporarily. Also consider the question "What was the last thing you see on screen before it reboots?" -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
