Cosmetic JFFS patch.

Linus, Alan - Please apply the following self-explanatory patch.

Index: fs/jffs/inode-v23.c
===================================================================
RCS file: /inst/cvs/linux/fs/jffs/Attic/inode-v23.c,v retrieving revision 1.1.2.11

diff -u -u -r1.1.2.11 inode-v23.c
@@ -1722,6 +1722,12 @@
 	printk("JFFS version "
 	       JFFS_VERSION_STRING
 	       ", (C) 1999, 2000  Axis Communications AB\n");
+	/* LynuxWorks are politely reminded that removing copyright
+	   notices is an offence under the Copyright Design and
+	   Patents Act 1988, and under equivalent non-UK law in
+	   accordance with the Berne Convention. */
+	printk("Portions (C) 2000, 2001 Red Hat, Inc.\n");
+	
 	return register_filesystem(&jffs_fs_type);
 }
 

--
dwmw2

How about we drop the "printk" altogether, and make it all a comment?

I find printk's with copyright notices quite disturbing. You will notice that I don't have any myself. I think the whole thing is very tasteless, and the "polite reminder" is just complete crap.

You're allowed to remove offensive printk's, that's not a copyright notice in Linux, that's just a big ugly bother. The copyright notice is that big comment at the top of the file.

Linus

If someone took all references to your name out of the kernel and put it out as 'Foobaros' by Foobarco you might take a different view.

Intentionally or otherwise in the change thats what the JFFS argument is about.

I don't _have_ any instances of my name being printed out to annoy the user, so that's a very theoretical argument.

This is my current patch in my tree. I refuse to have bickering in printk's. You can edit the comment all you want.

Linus

-----

diff -urN v2.4.5/linux/fs/jffs/inode-v23.c linux/fs/jffs/inode-v23.c
@@ -16,6 +16,7 @@
  * Ported to Linux 2.3.x and MTD:
  * Copyright (C) 2000  Alexander Larsson ([email protected]), Cendio Systems AB
  *
+ * Copyright 2000, 2001  Red Hat, Inc.
  */
 
 /* inode.c -- Contains the code that is called from the VFS.  */

@@ -1719,9 +1720,6 @@
 static int __init
 init_jffs_fs(void)
 {
-	printk("JFFS version "
-	       JFFS_VERSION_STRING
-	       ", (C) 1999, 2000  Axis Communications AB\n");
 	return register_filesystem(&jffs_fs_type);
 }
 

Hello...

Am Donnerstag, 28. Juni 2001 00:16 schrieb Linus Torvalds:

Err.... Just nitpicking...

dreker@wintermute:~> dmesg | grep -C Linus
hub.c: 2 ports detected
uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber

dreker@wintermute:~> uname -a
Linux wintermute 2.4.5-ac15 #1 Son Jun 17 12:44:01 CEST 2001 i686 unknown

Patrick Dreker

Oh, damn.

It wasn't addded by me, though, and if somebody wants to change the name to "Frodo Rabbit", I wouldn't holler loudly.

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.

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

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.

Also consider the question "What was the last thing you see on screen before it reboots?"

--
dwmw2

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

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

Actually that one matters. Its important to tell people they have broken quota code and should do something about it ;)
<runs>

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'

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

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

/proc/drivers maybe. It just needs to be a compact summry for debugging - nothing more.

Bloats the running kernel. Startup messages should be issued by __init code and the messages should be __initdata. There is no point in holding onto those strings after boot.

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

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.

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     |

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.

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:

<one line version>
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     |

Hi!

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.

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

Nifty, I did not know that. Makes all kinds of sense, though. Silly me...

Excellent.

Jeff

Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

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.

<snip>

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

Hacksaw <[email protected]> opined:

Perhaps a boot time option such as:

lilo boot: newkernel debug=xxxxxxx

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 McLean P: 01276 423905
Proactive Technical Analyst M: 07801 459497
Sun Microsystems Proactive Services E: [email protected]

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.

USER: A bunch of words.
TECH: What words?
USER: Dunno, there were a lot though.

;)

-b

:    __o
:   -\<,
:   0/ 0
-----------

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/>

<snip>

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.

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

Please look at the latest 2.4.6-pre tree. This has been changed for a while now.

thanks,

greg k-h

Can we please also drop annoying static informational printk's?

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.

Ditto.

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:

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.
...

There would be no end to the suffering...

There's a difference; someone paid for that Windows code and you paid to get windows and don't care about who did what. But when someone puts down a lot of work to contributes something for free which others find useful and actually use, don't you think it might be prudent to let them at least write who contributed it, if a line is going to be printed anyway to say device that or that has been registred ?

I know it sounds a bit like an "advertisment space" but it's always been so; people have been releasing code for free since noone knows how long and often one major factor has been that their peers will go "wow did you do that". Otherwise why would anyone ever write their name in an About box when they release a freeware program. And dmesg is the Linux kernels About box (someone might argue that the code is the about box but unfortunately most people dont read the headers in every .c file they use).

See the old BSD license - distribution-wise it's more free than the GPL but you still had to give credit where credit is due when getting a free lunch from someone elses work (I think this requirement was dropped in the current BSD license)

The risk is that some people might take it quite personally to get their names removed and might not be as interested to see their code in the kernel in the future. Of course as long as it's GPL nothing would stop it anyway, but I still think it's a good idea to give credit for others hard work.

/Bjorn

tao@tictac$ grep "^N:" CREDITS | sed -e "s/N: //" | wc
    392     863    5916

Add a little for (c) xxxx and other stuff, and you're getting close to the size of the dmesg-buffer. Is it worth it?

Now, I can't claim to be 100% innocent; my name appears in the procinfo for at least one MCA-driver. This will be remedied in due time, I can assure you. I hope others follow my example.

/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Actually it has made a measurable difference both to the computer society and to Swansea University. Yes maybe to an extent it is advertising but its also very important as a motivator.

I don't actually think you can remove the copyrights either. It just isnt clear if a printk is a copyright message or not. If the printk counts as a copyright statement then I don't think it can be casually removed, at least not in the UK

Alan

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...

-Chuck

Chuck Wolber		| steward: "Are you the pilot?"
System Administrator	| pilot: "Yes, why?"
AltaServ Corporation	| steward, handing box to pilot: "Then this is for you."
(425)576-1202		| pilot, looking inside box: "Oh, it's a new altimeter."
ten.vresatla@wkcuhc	| 	--Chris Kennedy

A /proc/credits maybe?

Vipin

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...

Chuck Wolber		| steward: "Are you the pilot?"
System Administrator	| pilot: "Yes, why?"
AltaServ Corporation	| steward, handing box to pilot: "Then this is for you."
(425)576-1202		| pilot, looking inside box: "Oh, it's a new altimeter."
ten.vresatla@wkcuhc	| 	--Chris Kennedy

KERN_BANNER

--
dwmw2

Hi David.

Where would you put that in the sequence?

Best wishes from Riley.

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

I absolutely _abhor_ the fact that most distributions seem to set the default logging level to be "emergency only". That's wrong. The default logging level should be "print out everything but debugging", and we should make sure that normal code _never_ spits stuff out that happens during regular use.

As it is now, when something bad actually _does_ happen, many distributions will simply not print anything at all, because user processes are dead by then.

And why did the distributions do this? Because we tend to be too damn verbose for our own good.

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.

Linus

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

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

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

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

[email protected] (Linus Torvalds) wrote on 28.06.01 in <[email protected]>:

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

Taking that one step further, isn't it a developer's right to "toot their own horn" in their code?

Chuck Wolber		| steward: "Are you the pilot?"
System Administrator	| pilot: "Yes, why?"
AltaServ Corporation	| steward, handing box to pilot: "Then this is for you."
(425)576-1202		| pilot, looking inside box: "Oh, it's a new altimeter."
ten.vresatla@wkcuhc	| 	--Chris Kennedy

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.

Chuck Wolber		| steward: "Are you the pilot?"
System Administrator	| pilot: "Yes, why?"
AltaServ Corporation	| steward, handing box to pilot: "Then this is for you."
(425)576-1202		| pilot, looking inside box: "Oh, it's a new altimeter."
ten.vresatla@wkcuhc	| 	--Chris Kennedy

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

Linus Torvalds <[email protected]> was pleased to say:

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                      |

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.

Christoph Zens
[email protected]
(415)-289-7765

*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!!"

In article <[email protected]>,

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.

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.

How about a new level, say "KERN_CONFIG", with a "show-config"
parameter to enable displaying KERN_CONFIG messages?

Craig Milo Rogers

Is this (printing out versions. etc) really a big deal so we should add stuff like "/proc/xxx", KERN_XXXX 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.

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.

Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Miquel van Smoorenburg proclaimed:

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

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

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/

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

Many new Linux users go through an extended period of dual-booting.

--
Daniel

Hi,

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)

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

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

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.

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/

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.

See all the previous messages in this thread. :)

Isn't that more a "who to blame" than credit?

Paul.

For about 4 seconds before gnome/kde starts up...

point, click, drag, drool...

--cw

cool, what about kbannerd ?

John Lenton ([email protected]) -- Random fortune:
	A longo prazo, estaremos todos mortos.
		-- John Maynard Keynes 

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...

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     |

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

[email protected] wrote on 28.06.01 in <[email protected]>:

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

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.

Chuck Wolber		| steward: "Are you the pilot?"
System Administrator	| pilot: "Yes, why?"
AltaServ Corporation	| steward, handing box to pilot: "Then this is for you."
(425)576-1202		| pilot, looking inside box: "Oh, it's a new altimeter."
ten.vresatla@wkcuhc	| 	--Chris Kennedy

[email protected] (Chuck Wolber) wrote on 29.06.01 in <[email protected]>:

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.

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

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.

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

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: xxxxx
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

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
pty        Devices: 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.