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",
Hi!
FWIW I find usb and parport messages exceptionally verbose, but some of
USB was bad, but should get better in 2.4.6. I hate that ugly verbosity,
and will try to kill it in USB case.
Pavel
--
Philips Velo 1: 1x4x8, 300gram,
> 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>
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
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
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
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..
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..
[EMAIL PROTECTED] (Torrey Hoffman) wrote on 30.06.01 in
<[EMAIL PROTECTED]>:
> So they compile it into the linux_logo.h image. It's now under the
> GPL, of course... what does that do to the legal status of the logo?
Copyright: you named it.
Any other right: unchanged. (The GPL doesn't
[EMAIL PROTECTED] (Chuck Wolber) wrote on 29.06.01 in
<[EMAIL PROTECTED]>:
> > Does sed tell you who programmed it on startup?
> >
> > Awk?
> >
> > Perl?
> >
> > Groff?
> >
> > Gcc?
> >
> > See a pattern here?
>
> Yeah, the output of these programms are usually parsed by other programs.
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
>
>
> Is this (printing out versions. etc) really a big deal so we should add stuff
> like "/proc/xxx", KERN_ to make things more complicated? It sounds to me
> like to make the kernel "smaller" we'd actually end up with adding more code
> and complexity to it. And quite frankly, if
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
> --
>
Is this (printing out versions. etc) really a big deal so we should add stuff
like "/proc/xxx", KERN_ to make things more complicated? It sounds to me
like to make the kernel "smaller" we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't
Is this (printing out versions. etc) really a big deal so we should add stuff
like /proc/xxx, KERN_ to make things more complicated? It sounds to me
like to make the kernel smaller we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't read
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
--
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
Is this (printing out versions. etc) really a big deal so we should add stuff
like /proc/xxx, KERN_ to make things more complicated? It sounds to me
like to make the kernel smaller we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't
[EMAIL PROTECTED] (Torrey Hoffman) wrote on 30.06.01 in
[EMAIL PROTECTED]:
So they compile it into the linux_logo.h image. It's now under the
GPL, of course... what does that do to the legal status of the logo?
Copyright: you named it.
Any other right: unchanged. (The GPL doesn't demand
[EMAIL PROTECTED] (Chuck Wolber) wrote on 29.06.01 in
[EMAIL PROTECTED]:
Does sed tell you who programmed it on startup?
Awk?
Perl?
Groff?
Gcc?
See a pattern here?
Yeah, the output of these programms are usually parsed by other programs.
s/usually/sometimes/
Most of
Linus Torvalds <[EMAIL PROTECTED]> writes:
> So let's simply disallow versions, author information, and "good status"
> messages, ok?
I'd be quite happy with this, if only for consistency's sake -- at the
moment we've got some kernel subsystems which print "yup, I've started
up" messages, and
[EMAIL PROTECTED] (Stuart Lynne) writes:
[snip]
> A counter example that does both, bc does tell us who wrote it
> every time we run it (most annoying) and is smart enough to know
> when it is not talking to a tty.
>
> % bc
> bc 1.05
> Copyright 1991, 1992, 1993, 1994, 1997, 1998
(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
David Woodhouse wrote:
>
>Also consider the question "What was the last thing you see on screen
>before it reboots?"
>
USER: A bunch of words.
TECH: What words?
USER: Dunno, there were a lot though.
;)
-b
--
:__o
: -\<,
: 0/ 0
---
-
To unsubscribe from this list: send
--- David Lang <[EMAIL PROTECTED]> wrote:
> back when I was doing PC repair (1.x kernel days) I
> started useing linux
> becouse the boot messages gave me so much info about
> the system (I started
> to keep a Slackware boot/root disk set on hand so
> when faced with a
> customer machine I could
--- David Lang [EMAIL PROTECTED] wrote:
back when I was doing PC repair (1.x kernel days) I
started useing linux
becouse the boot messages gave me so much info about
the system (I started
to keep a Slackware boot/root disk set on hand so
when faced with a
customer machine I could boot and
(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
[EMAIL PROTECTED] (Stuart Lynne) writes:
[snip]
A counter example that does both, bc does tell us who wrote it
every time we run it (most annoying) and is smart enough to know
when it is not talking to a tty.
% bc
bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free
Linus Torvalds [EMAIL PROTECTED] writes:
So let's simply disallow versions, author information, and good status
messages, ok?
I'd be quite happy with this, if only for consistency's sake -- at the
moment we've got some kernel subsystems which print yup, I've started
up messages, and some
David Woodhouse wrote:
Also consider the question What was the last thing you see on screen
before it reboots?
USER: A bunch of words.
TECH: What words?
USER: Dunno, there were a lot though.
;)
-b
--
:__o
: -\,
: 0/ 0
---
-
To unsubscribe from this list: send the line
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
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,
In article <[EMAIL PROTECTED]>,
Chuck Wolber <[EMAIL PROTECTED]> wrote:
>> Does sed tell you who programmed it on startup?
>>
>> Awk?
>>
>> Perl?
>>
>> Groff?
>>
>> Gcc?
>>
>> See a pattern here?
>
>Yeah, the output of these programms are usually parsed by other programs.
>If they barked version
>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,
Hi David.
>> Perhaps even a boot flag of some sort to de-activate the
>> printing of the /proc/credits during the kernel boot sequence.
>> Or would the community rather an opt-in scenario...
> KERN_BANNER
Where would you put that in the sequence?
Best wishes from Riley.
-
To
rnel
> 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
Hi,
> Many new Linux users go through an extended period of dual-booting.
And many users also have to sleep in the same room as their computers (still
live w/ parents or are in college) and the fans bother them, so they turn
them off every night.
Just my 2 eurocents.
--
Chris Boot
[EMAIL
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
> 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
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
Hacksaw <[EMAIL PROTECTED]> opined:
> Given that seeing as much as possible on a potentially
> small screen would be good, maybe tighter would be
> nice. In example:
>
> kswapd:v1.8
> ptyDevices: 256 Unix98 ptys configured
> serial:v5.05b (2001-05-03) with
>Options:
> "ian" == Ian Stirling <[EMAIL PROTECTED]> writes:
Hi
ian> It would be nice to show driver version for every single non-stock
ian> driver we load though.
ian> Perhaps a list of versions in the stock kernel build, stored somewhere,
ian> that shouldn't be patched by anyone, but only change
>Olaf Hering wrote:
>> kde.o. 2.5?
>
>Good idea! Graphics needs to be in the kernel to be fast. Windows
>proved that.
thought SGI proved that :-)
Martin
--
--
Martin Knoblauch |email: [EMAIL PROTECTED]
TeraPort
On Thu, Jun 28, 2001 at 06:18:28PM +0100, Alan Cox wrote:
> Managers at places like Cisco see boot messages and it gets into
> their brains. They certainly don't all read the source code.
For about 4 seconds before gnome/kde starts up...
point, click, drag, drool...
--cw
-
To unsubscribe
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
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
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
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
Olaf Hering wrote:
kde.o. 2.5?
Good idea! Graphics needs to be in the kernel to be fast. Windows
proved that.
thought SGI proved that :-)
Martin
--
--
Martin Knoblauch |email: [EMAIL PROTECTED]
TeraPort GmbH
ian == Ian Stirling [EMAIL PROTECTED] writes:
Hi
ian It would be nice to show driver version for every single non-stock
ian driver we load though.
ian Perhaps a list of versions in the stock kernel build, stored somewhere,
ian that shouldn't be patched by anyone, but only change with official
Hacksaw [EMAIL PROTECTED] opined:
Given that seeing as much as possible on a potentially
small screen would be good, maybe tighter would be
nice. In example:
kswapd:v1.8
ptyDevices: 256 Unix98 ptys configured
serial:v5.05b (2001-05-03) with
Options:
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
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
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
Hi,
Many new Linux users go through an extended period of dual-booting.
And many users also have to sleep in the same room as their computers (still
live w/ parents or are in college) and the fans bother them, so they turn
them off every night.
Just my 2 eurocents.
--
Chris Boot
[EMAIL
: 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
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,
In article [EMAIL PROTECTED],
Chuck Wolber [EMAIL PROTECTED] wrote:
Does sed tell you who programmed it on startup?
Awk?
Perl?
Groff?
Gcc?
See a pattern here?
Yeah, the output of these programms are usually parsed by other programs.
If they barked version info, that'd be extra code
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
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
On Thu, Jun 28, 2001 at 06:18:28PM +0100, Alan Cox wrote:
Managers at places like Cisco see boot messages and it gets into
their brains. They certainly don't all read the source code.
For about 4 seconds before gnome/kde starts up...
point, click, drag, drool...
--cw
-
To unsubscribe
Hi David.
Perhaps even a boot flag of some sort to de-activate the
printing of the /proc/credits during the kernel boot sequence.
Or would the community rather an opt-in scenario...
KERN_BANNER
Where would you put that in the sequence?
Best wishes from Riley.
-
To unsubscribe from
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
>
> 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
Given that seeing as much as possible on a potentially small screen would be
good, maybe tighter would be nice. In example:
kswapd:v1.8
ptyDevices: 256 Unix98 ptys configured
serial:v5.05b (2001-05-03) with
Options: MANY_PORTS SHARE_IRQ SERIAL_PCI
Devices:
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
[EMAIL PROTECTED] wrote on 28.06.01 in
<[EMAIL PROTECTED]>:
> > > Linux NET4.0 for Linux 2.4
> > > Based upon Swansea University Computer Society NET3.039
> >
> > The later line is not something of interest to most people, and if it
> > happens to be they can research it rather than being
[EMAIL PROTECTED] (Linus Torvalds) wrote on 28.06.01 in
<[EMAIL PROTECTED]>:
> On Thu, 28 Jun 2001, David Woodhouse wrote:
> >
> > I agree the messages can be ugly. But they don't do any harm either, and
> > sometimes they're useful.
>
> I consider them harmful when I start getting annoying
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"
>> >
Olaf Hering wrote:
> kde.o. 2.5?
Good idea! Graphics needs to be in the kernel to be fast. Windows
proved that.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
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.
John R Lenton wrote:
>
> On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
> >
> > KERN_BANNER
>
> cool, what about kbannerd ?
I'm still pushing for a Perl interpreter in the kernel, let's not forget
that too.
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
>
> KERN_BANNER
cool, what about kbannerd ?
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
A longo prazo, estaremos todos mortos.
-- John Maynard Keynes
PGP signature
>Print all copyright, config, etc. as KERN_DEBUG.
How about a new level, say "KERN_CONFIG", with a "show-config"
parameter to enable displaying KERN_CONFIG messages?
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe
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
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
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.
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
> >
Ok, my two cents.
Print all copyright, config, etc. as KERN_DEBUG. Then use a 'verbose' or
similar parameter to lilo/kernel to enable console printing of KERN_DEBUG,
to be used when the system fails to boot, etc.
Dan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
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
Miquel van Smoorenburg wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tommy Reynolds <[EMAIL PROTECTED]> wrote:
> >Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
> >
> >> If they are shut off, then where's the drumming? Because if people start
> >> making copyright printk's normal, I will
In article <[EMAIL PROTECTED]>,
Tommy Reynolds <[EMAIL PROTECTED]> wrote:
>Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
>
>> If they are shut off, then where's the drumming? Because if people start
>> making copyright printk's normal, I will make "quiet" the default.
>
>Amen. This is
On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote:
>
>
> [EMAIL PROTECTED] said:
> > Things like version strings etc sound useful, but the fact is that the
> > only _real_ problem it has ever solved for anybody is when somebody
> > thinks they install a new kernel, and forgets to
> 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
Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
> If they are shut off, then where's the drumming? Because if people start
> making copyright printk's normal, I will make "quiet" the default.
Amen. This is like editing a program to remove the "harmless" compiler warning
messages. If I
[EMAIL PROTECTED] said:
> I consider them harmful when I start getting annoying patches that
> start adding more and more of them.
> Which is how this whole thread started.
Sort of. The point of the patch which started this thread was as a wake-up
call to a company who had taken the code,
> >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
On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > > Taking that one step further, isn't it a developer's right to "toot their
> > > own horn" in their code?
> >
> > Right. In the code. Not in the Linux boot diagnostic information.
>
> Which is why I proposed earlier that we make it easy to shut
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.
On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote:
>
> Taking that one step further, isn't it a developer's right to "toot their
> own horn" in their code?
You can do whatever you want in your own code.
But if it makes the code behave badly, others have the right to change it.
That's what the GPL is
>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"?
> 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
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
[EMAIL PROTECTED] said:
> On Thu, 28 Jun 2001, Alan Cox wrote:
> > Managers at places like Cisco see boot messages and it gets into
> > their brains. They certainly don't all read the source code.
> Quote frankly, I doubt "managers" read the boot messages.
This is consistent with what Alan
On Thu, Jun 28, 2001 at 10:29:11AM -0700, [EMAIL PROTECTED] wrote:
> Taking that one step further, isn't it a developer's right to "toot their
> own horn" in their code?
Right. In the code. Not in the Linux boot diagnostic information.
-
To unsubscribe from this list: send the line "unsubscribe
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
> Also consider the question "What was the last thing you see on screen
> before it reboots?"
You need that info in case it doesn't. Its much like the watchdog tells you
it fired in case someone didn't wire it right. So in a sense its an error
message
-
To unsubscribe from this list: send the
> 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
> 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
[EMAIL PROTECTED] said:
> Things like version strings etc sound useful, but the fact is that the
> only _real_ problem it has ever solved for anybody is when somebody
> thinks they install a new kernel, and forgets to run "lilo" or
> something.
I can give counter-examples of times when it's
1 - 100 of 167 matches
Mail list logo
