Cosmetic JFFS patch.

Cosmetic JFFS patch.

[David Woodhouse]

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
--- fs/jffs/inode-v23.c	2001/06/02 16:19:32	1.1.2.11
+++ fs/jffs/inode-v23.c	2001/06/26 12:50:36
@@ -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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Tue, 26 Jun 2001, David Woodhouse wrote:
>
> Linus, Alan - Please apply the following self-explanatory patch.

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

Re: Cosmetic JFFS patch.

[Alan Cox]

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

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.

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Wed, 27 Jun 2001, Alan Cox wrote:

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

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

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

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
--- v2.4.5/linux/fs/jffs/inode-v23.c	Sun May 20 11:35:00 2001
+++ linux/fs/jffs/inode-v23.c	Wed Jun 27 13:51:50 2001
@@ -16,6 +16,7 @@
  * Ported to Linux 2.3.x and MTD:
  * Copyright (C) 2000  Alexander Larsson (alex@cendio.se), 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);
 }

Re: Cosmetic JFFS patch.

[Patrick Dreker]

Hello...

Am Donnerstag, 28. Juni 2001 00:16 schrieb Linus Torvalds:
> I don't _have_ any instances of my name being printed out to annoy the
> user, so that's a very theoretical argument.

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

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

-- 
Patrick Dreker

Re: Cosmetic JFFS patch.

[Greg KH]

On Thu, Jun 28, 2001 at 09:43:21AM +0200, Patrick Dreker wrote:
> Hello...
> 
> Am Donnerstag, 28. Juni 2001 00:16 schrieb Linus Torvalds:
> > I don't _have_ any instances of my name being printed out to annoy the
> > user, so that's a very theoretical argument.
> 
> 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

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

thanks,

greg k-h

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Thu, 28 Jun 2001, Patrick Dreker wrote:
>
> Am Donnerstag, 28. Juni 2001 00:16 schrieb Linus Torvalds:
> > I don't _have_ any instances of my name being printed out to annoy the
> > user, so that's a very theoretical argument.
>
> 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

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

Re: Cosmetic JFFS patch.

[Alan Cox]

> 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 ;)
<runs>

> 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

Re: Cosmetic JFFS patch.

[Craig Milo Rogers]

>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

Re: Cosmetic JFFS patch.

[Alan Cox]

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

Re: Cosmetic JFFS patch.

[Keith Owens]

On Thu, 28 Jun 2001 18:14:15 +0100 (BST), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>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'

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.

Re: Cosmetic JFFS patch.

[David Woodhouse]

torvalds@transmeta.com 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

Re: Cosmetic JFFS patch.

[Alan Cox]

> 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

Re: Cosmetic JFFS patch.

[Pekka Pietikainen]

On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote:
> 
> 
> torvalds@transmeta.com 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

Re: Cosmetic JFFS patch.

[Ben Ford]

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

Re: Cosmetic JFFS patch.

[Troy Benjegerdes]

<snip>

> 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 majordomo@vger.kernel.org
> 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' |  hozer@drgw.net
-----"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

Re: Cosmetic JFFS patch.

[Jeff Garzik]

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     |

Re: Cosmetic JFFS patch.

[Gerhard Mack]

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Cosmetic JFFS patch.

[Jeff Garzik]

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:

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

Re: Cosmetic JFFS patch.

[Pavel Machek]

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.

Re: Cosmetic JFFS patch.

[Linus Torvalds]

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

Re: Cosmetic JFFS patch.

[Jeff Garzik]

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     |

Re: Cosmetic JFFS patch.

[Ian Stirling]

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

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

Re: Cosmetic JFFS patch.

[Juan Quintela]

>>>>> "ian" == Ian Stirling <root@mauve.demon.co.uk> 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

Re: Cosmetic JFFS patch.

[Craig McLean]

Hacksaw <hacksaw@hacksaw.org> 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
> 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

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: craig.mclean@sun.com

Re: Cosmetic JFFS patch.

[Hacksaw]

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

Re: Cosmetic JFFS patch.

[Adam Sampson]

Linus Torvalds <torvalds@transmeta.com> 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 <azz@gnu.org>                  <URL:http://azz.us-lot.org/>

Re: Cosmetic JFFS patch.

[Aaron Lehmann]

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.

RE: Cosmetic JFFS patch.

[Laramie Leavitt]

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

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

RE: Cosmetic JFFS patch.

[Bjorn Wesen]

On Thu, 28 Jun 2001, Laramie Leavitt wrote:
> > 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:

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

Re: Cosmetic JFFS patch.

[David Weinehall]

On Thu, Jun 28, 2001 at 11:19:37AM +0200, Bjorn Wesen wrote:
> On Thu, 28 Jun 2001, Laramie Leavitt wrote:
> > > 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:
> 
> 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.

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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Cosmetic JFFS patch.

[Alan Cox]

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

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

Re: Cosmetic JFFS patch.

[Troy Benjegerdes]

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' |  hozer@drgw.net
-----"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

Re: Cosmetic JFFS patch.

[J . A . Magallon]

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: 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:jamagallon@able.es
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

Re: Cosmetic JFFS patch.

[Hacksaw]

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.

Re: Cosmetic JFFS patch.

[chuckw]

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

-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

Re: Cosmetic JFFS patch.

[Vipin Malik]

A /proc/credits maybe?

Vipin




chuckw@altaserv.net wrote:

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

Re: Cosmetic JFFS patch.

[chuckw]

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

> A /proc/credits maybe?
>
> > 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 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

Re: Cosmetic JFFS patch.

[David Woodhouse]

chuckw@altaserv.net said:
>  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

--
dwmw2

Re: Cosmetic JFFS patch.

[John R Lenton]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
> 
> KERN_BANNER

cool, what about kbannerd ?


-- 
John Lenton (john@grulic.org.ar) -- Random fortune:
	A longo prazo, estaremos todos mortos.
		-- John Maynard Keynes 

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Cosmetic JFFS patch.

[Jeff Garzik]

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.

Re: Cosmetic JFFS patch.

[Olaf Hering]

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

Re: Cosmetic JFFS patch.

[Jeff Garzik]

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     |

Re: Cosmetic JFFS patch.

[Riley Williams]

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.

Re: Cosmetic JFFS patch.

[Alan Cox]

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

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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Thu, 28 Jun 2001, Alan Cox wrote:
>
> > 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...
>
> 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

Re: Cosmetic JFFS patch.

[Alan Cox]

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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

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

Re: Cosmetic JFFS patch.

[David Woodhouse]

torvalds@transmeta.com 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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

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

Re: Cosmetic JFFS patch.

[David Woodhouse]

torvalds@transmeta.com 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

Re: Cosmetic JFFS patch.

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 28.06.01 in <Pine.LNX.4.33.0106281055410.15199-100000@penguin.transmeta.com>:

> 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

Re: Cosmetic JFFS patch.

[chuckw]

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

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

Re: Cosmetic JFFS patch.

[Aaron Lehmann]

On Thu, Jun 28, 2001 at 10:29:11AM -0700, chuckw@altaserv.net 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.

Re: Cosmetic JFFS patch.

[chuckw]

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


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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Thu, 28 Jun 2001 chuckw@altaserv.net 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

Re: Cosmetic JFFS patch.

[Christoph Zens]

> 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 majordomo@axis.com
> 

-- 
Christoph Zens
czens@coactive.com
(415)-289-7765

Re: Cosmetic JFFS patch.

[Daniel Stone]

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 <daniel@sfarc.net>
     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 <daniel@sfarc.net>
     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						     <daniel@sfarc.net>
<Nuke> "can NE1 help me aim nuclear weaponz????? /MSG ME!!"

Re: Cosmetic JFFS patch.

[Tommy Reynolds]

Linus Torvalds <torvalds@transmeta.com> 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:reynolds@redhat.com                   | http://www.redhat-techworld.com
Phone:  +1.256.704.9286                      |
Mobile: +1.919.641.2923                      |

Re: Cosmetic JFFS patch.

[Miquel van Smoorenburg]

In article <20010628131641.5e10ecca.reynolds@redhat.com>,
Tommy Reynolds  <reynolds@redhat.com> wrote:
>Linus Torvalds <torvalds@transmeta.com> 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.

Re: Cosmetic JFFS patch.

[Jeff Garzik]

Miquel van Smoorenburg wrote:
> 
> In article <20010628131641.5e10ecca.reynolds@redhat.com>,
> Tommy Reynolds  <reynolds@redhat.com> wrote:
> >Linus Torvalds <torvalds@transmeta.com> 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     |

Re: Cosmetic JFFS patch.

[Dan Podeanu]

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.

Re: Cosmetic JFFS patch.

[Craig Milo Rogers]

>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

Re: Cosmetic JFFS patch.

[Hua Zhong]

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.

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

Re: Cosmetic JFFS patch.

[Ian Stirling]

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

Re: Cosmetic JFFS patch.

[Holger Lubitz]

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

Re: Cosmetic JFFS patch.

[Jordan Crouse]

> 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

Re: Cosmetic JFFS patch.

[Daniel Phillips]

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

Re: Cosmetic JFFS patch.

[Chris Boot]

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
bootc@worldnet.fr

"use the source, luke." (obi-wan gnuobi)

Re: Cosmetic JFFS patch.

[David Lang]

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 <h.lubitz@internet-factory.de>
> To: linux-kernel@vger.kernel.org
> 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 majordomo@vger.kernel.org
> 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.

[szonyi calin]

--- David Lang <david.lang@digitalinsight.com> 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/

Re: Cosmetic JFFS patch.

[Rob Landley]

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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Thu, 28 Jun 2001 chuckw@altaserv.net 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

Re: Cosmetic JFFS patch.

[Paul Mackerras]

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.

Re: Cosmetic JFFS patch.

[Cort Dougan]

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 majordomo@vger.kernel.org
} 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.

[Paul Mackerras]

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.

Re: Cosmetic JFFS patch.

[Chris Wedgwood]

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

Re: Cosmetic JFFS patch.

[Anuradha Ratnaweera]

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

Re: Cosmetic JFFS patch.

[Kai Henningsen]

chuckw@altaserv.net  wrote on 28.06.01 in <Pine.LNX.4.33.0106280732480.10308-100000@localhost.localdomain>:

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

Re: Cosmetic JFFS patch.

[Chuck Wolber]

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


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

Re: Cosmetic JFFS patch.

[Kai Henningsen]

chuckw@altaserv.net (Chuck Wolber)  wrote on 29.06.01 in <Pine.LNX.4.33.0106290730540.19843-100000@localhost.localdomain>:

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

Re: PATCH 2.4.6.5: fix mtd config

[David Woodhouse]

jgarzik@mandrakesoft.com said:
> Seeing David Woodhouse's name reminds me that this patch, submitted by
> both David and myself, didn't make it into pre5...  It moves
> mtd-related config items inside CONFIG_MTD. 

Jeff, thankyou for finding this and making me aware of it. It's now in the 
2.4.6 branch of my tree and I'll resend it, along with one or two other 
minor fixes, shortly. I'll now need to wait to see whether this partial 
patch appears in -pre6, I suppose.

--
dwmw2

RE: Cosmetic JFFS patch.

[A. Melon]

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");

Re: Cosmetic JFFS patch.

[Martin Knoblauch]

>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:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: Cosmetic JFFS patch.

[Hua Zhong]

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:  Martin.Knoblauch@TeraPort.de
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-> From Martin Knoblauch <Martin.Knoblauch@TeraPort.de> :

Re: Cosmetic JFFS patch.

[Gregory Finch]

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" <huaz@cs.columbia.edu>

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

Re: Cosmetic JFFS patch.

[Stuart Lynne]

In article <993825330.30635@whiskey.enposte.net>,
Chuck Wolber <chuckw@altaserv.net> 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 <sl@fireplug.net>       www.fireplug.net        604-461-7532

Re: Cosmetic JFFS patch.

[Raja R Harinath]

sl@whiskey.fireplug.net (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 ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Cosmetic JFFS patch.

[Craig McLean]

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 McLean				P: 01276 423905
Proactive Technical Analyst		M: 07801 459497
Sun Microsystems Proactive Services	E: craig.mclean@sun.com
My opinions are not necessarily those of Sun Microsystems

RE: Cosmetic JFFS patch.

[Torrey Hoffman]

(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

Re: Cosmetic JFFS patch.

[Kai Henningsen]

torrey.hoffman@myrio.com (Torrey Hoffman)  wrote on 30.06.01 in <D52B19A7284D32459CF20D579C4B0C0211C90F@mail0.myrio.com>:

> 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

RE: Cosmetic JFFS patch.

[Heusden, Folkert van]

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