Linux is really far too verbose at boot time. I don't think these messages
add anything to either the end user experience or debug ability.
Index: fs/bio.c
===================================================================
RCS file: /var/cvs/linux-2.6/fs/bio.c,v
retrieving revision 1.2
diff -u -p -r1.2 bio.c
--- fs/bio.c 29 Jul 2003 17:25:49 -0000 1.2
+++ fs/bio.c 21 Aug 2003 14:58:40 -0000
@@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
mempool_free_slab, bp->slab);
if (!bp->pool)
panic("biovec: can't init mempool\n");
-
- printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
- i, bp->nr_vecs, pool_entries,
- size);
}
}
@@ -809,8 +805,6 @@ static int __init init_bio(void)
bio_pool = mempool_create(BIO_POOL_SIZE, mempool_alloc_slab, mempool_free_slab, bio_slab);
if (!bio_pool)
panic("bio: can't create mempool\n");
-
- printk("BIO: pool of %d setup, %ZuKb (%Zd bytes/bio)\n", BIO_POOL_SIZE, BIO_POOL_SIZE * sizeof(struct bio) >> 10, sizeof(struct bio));
biovec_init_pools();
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
Matthew Wilcox wrote:
> Linux is really far too verbose at boot time. I don't think these messages
> add anything to either the end user experience or debug ability.
>
> Index: fs/bio.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/fs/bio.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 bio.c
> --- fs/bio.c 29 Jul 2003 17:25:49 -0000 1.2
> +++ fs/bio.c 21 Aug 2003 14:58:40 -0000
> @@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
> mempool_free_slab, bp->slab);
> if (!bp->pool)
> panic("biovec: can't init mempool\n");
> -
> - printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
> - i, bp->nr_vecs, pool_entries,
> - size);
Although I agree with your "too verbose" sentiment above, I think the
removing the messages outright might not serve the best interests the
developer. Since even KERN_DEBUG still spams dmesg, in these situations
I usually change these type of messages to be conditionally printed iff
a debug macro is enabled.
As a tangent, the huge x86 IO-APIC verbosity really bugs me, too, and
often is the direct cause of useful early printk messages being lost
before boot is even complete.
Jeff
Jeff Garzik wrote:
> Matthew Wilcox wrote:
>
>> Linux is really far too verbose at boot time. I don't think these
>> messages
>> add anything to either the end user experience or debug ability.
>>
>> Index: fs/bio.c
>> ===================================================================
>> RCS file: /var/cvs/linux-2.6/fs/bio.c,v
>> retrieving revision 1.2
>> diff -u -p -r1.2 bio.c
>> --- fs/bio.c 29 Jul 2003 17:25:49 -0000 1.2
>> +++ fs/bio.c 21 Aug 2003 14:58:40 -0000
>> @@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
>> mempool_free_slab, bp->slab);
>> if (!bp->pool)
>> panic("biovec: can't init mempool\n");
>> -
>> - printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
>> - i, bp->nr_vecs, pool_entries,
>> - size);
>
>
> . . . removing the messages outright might not serve the best
> interests the developer. Since even KERN_DEBUG still spams dmesg, in
> these situations I usually change these type of messages to be
> conditionally printed iff a debug macro is enabled.
How about using KERN_DEBUG and augmenting the dmesg store so that the
level that is saved is configurable? Even compile time configurable
seems reasonable to start. But axeing out even the possibility of boot
time info seems bad to me.
On Thu, Aug 21, 2003 at 10:51:27AM -0600, Lou Langholtz wrote:
> Jeff Garzik wrote:
> >. . . removing the messages outright might not serve the best
> >interests the developer. Since even KERN_DEBUG still spams dmesg, in
> >these situations I usually change these type of messages to be
> >conditionally printed iff a debug macro is enabled.
>
> How about using KERN_DEBUG and augmenting the dmesg store so that the
> level that is saved is configurable? Even compile time configurable
> seems reasonable to start. But axeing out even the possibility of boot
> time info seems bad to me.
But why is it interesting to have this information at boot time? As a
user, I certainly don't care. As a developer, I don't find it interesting
information. Maybe the maintainer of this particular piece of code finds
it useful (Do you, Jens?), but does it need to be reported at boot time?
Perhaps it would be more useful to add some kind of reporting to
mm/mempool.c along the same lines as /proc/slabinfo so we can get the
dynamic information about pools at runtime rather than knowing their
initial state at boot time.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
On Thu, 21 Aug 2003, Matthew Wilcox wrote:
>
> But why is it interesting to have this information at boot time? As a
> user, I certainly don't care. As a developer, I don't find it interesting
> information.
I do agree. The message may have been useful when the code was young and
people wanted to see that it got executed correctly at all, but there
doesn't seem to be a lot of point to it any more.
But hey, I'll leave it to the maintainer..
Linus
El Thu, 21 Aug 2003 10:51:27 -0600 Lou Langholtz <[email protected]> escribi?:
> How about using KERN_DEBUG and augmenting the dmesg store so that the
> level that is saved is configurable? Even compile time configurable
> seems reasonable to start. But axeing out even the possibility of boot
> time info seems bad to me.
Like this?
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
Available at least in 2.6.0-test3 under "General setup"
Diego Calleja Garc?a wrote:
>El Thu, 21 Aug 2003 10:51:27 -0600 Lou Langholtz <[email protected]> escribi?:
>
>
>>How about using KERN_DEBUG and augmenting the dmesg store so that the
>>level that is saved is configurable? Even compile time configurable
>>seems reasonable to start. But axeing out even the possibility of boot
>>time info seems bad to me.
>>
>>
>Like this?
>(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
>Available at least in 2.6.0-test3 under "General setup"
>
>
Yes, except I was thinking for loglevel rather than size. Is a loglevel
option - as in only save printk's above level X in dmesg - already
available? I've seen other emails fly by on the printk system before so
this could well already be available. I haven't checked but was assuming
from the emails I'd seen so far that this didn't exist and was merely
suggesting this thinking it'd be an easy addition to the dmesg store.
On Thu, 21 Aug 2003, Linus Torvalds wrote:
> On Thu, 21 Aug 2003, Matthew Wilcox wrote:
> >
> > But why is it interesting to have this information at boot time? As a
> > user, I certainly don't care. As a developer, I don't find it interesting
> > information.
>
> I do agree. The message may have been useful when the code was young and
> people wanted to see that it got executed correctly at all, but there
> doesn't seem to be a lot of point to it any more.
>
> But hey, I'll leave it to the maintainer..
>
> Linus
as a user I find a minimal set of messages (loading driver, hardware
found) handy for identifying what hardware is actually in old machines I
am given.
that said there is a lot of distance between that and the current
situation where you print out 3-4 screens worth of info for a single
driver.
David Lang
On Thu, Aug 21 2003, Linus Torvalds wrote:
>
> On Thu, 21 Aug 2003, Matthew Wilcox wrote:
> >
> > But why is it interesting to have this information at boot time? As a
> > user, I certainly don't care. As a developer, I don't find it interesting
> > information.
>
> I do agree. The message may have been useful when the code was young and
> people wanted to see that it got executed correctly at all, but there
> doesn't seem to be a lot of point to it any more.
>
> But hey, I'll leave it to the maintainer..
Willy's patch is fine with me as well. Purpose of the messages is long
gone.
--
Jens Axboe