On 7/27/06, gmu 2k6 <[email protected]> wrote:
On 7/27/06, Dmitry Torokhov <[email protected]> wrote:
> On 7/26/06, Jeff Garzik <[email protected]> wrote:
> > Arjan van de Ven wrote:
> > > On Wed, 2006-07-26 at 00:43 +0200, Jesper Juhl wrote:
> > >> On 26/07/06, Bjorn Helgaas <[email protected]> wrote:
> > >>> If we don't find any devices, we shouldn't print anything.
> > >>>
> > >> I disagree.
> > >> I find it quite nice to be able to see that the driver loaded even if
> > >> it finds nothing. At least then when there's a problem, I can quickly
> > >> see that at least it is not because I didn't forget to load the
> > >> driver, it's something else. Saves time since I can start looking for
> > >> reasons why the driver didn't find anything without first spending
> > >> additional time checking if I failed to cause it to load for some
> > >> reason.
> > >
> > > I'll add a second reason: it is a REALLY nice property to be able to see
> > > which driver is started last in case of a crash/hang, so that the guilty
> > > party is more obvious..
> >
> > OTOH, it is not a property that scales well at all.
> >
> > When you build extra drivers into the kernel, or distros load drivers
> > you don't need (_every_ distro does this), you wind up with a bunch of
> > version strings for drivers for hardware you don't have.
> >
>
> Given that boot tracing is best done with initcall_debug and
> drivers that care about their version string can report it through
> /sys/modules/<driver>/version why should version string be printed at
> load time at all?
not every driver provides that file (btw, I guess you mean
/sys/module, don't you?) there anyway so it's still inconsistent.
Yes, you are right, we drop version string when !MODULE. We need to
keep it if we want to have consistent sysfs data.
what if you can see up until loading of the driver and it halts there
without /sys being mounted yet. I don't think you can rely on sysfs
being mounted or modules being loaded.
Right, so you boot with debug_initcall to see what was the last thing
that we tried to initialize. Hmm, we might need to add debug_modcall
to print names of modules being loaded as well.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
