>> Jean Delvare wrote:
>> Mark, can you provide a patch to your i2c-sis96x driver so that it'll
>> keep quiet when no supported device is found?
>
>Mark M. Hoffman wrote:
>Lots of drivers printk messages when they load - IMO it's useful info.
>E.g. how else could Etienne discover that he accidentally built a kernel
>with dozens of i2c bus drivers (and probably all of the hwmon drivers)
>built-in by accident?
I did not built with all hwmon drivers because I could determine what I
had on my mainboard. For me, because the kernel say it enters the I2C
system by the line:
Mar 13 21:46:48 kernel: [ 47.705445] i2c /dev entries driver
It could print a line when finished probing all those I2C drivers by a
line like:
Mar 13 21:46:48 kernel: [ 50.705445] i2c driver found: aaa-i2c, bbb-i2c.
And then I can have a clue on what to include in my monolitic build.
I do not care about such timeout on _one_ build, as long as I know what
to do for next build. Another possibility is to print a line when an I2C
detection has failed: you know that it has taken quite a lot of time and
it should not have been done in the first place (even for a module
because this module should not have been inserted).
It also protect the I2C group from people like me complainning
because completely unrelated messages like
Mar 13 22:12:54 kernel: [ 61.997032] : Detection failed at step 3
Elsewhere Jean Delvare wrote:
> That being said, the key problem being stuck i2c busses, it's even more
> important to get rid of these. You can use "i2cdetect -l" to list all
> detected i2c bus, so you'll see if you have any unwanted bus left.
I do not have this i2cdetect software installed on my system.
> If all drivers were actually printking messages when they load,
> monolithic kernels would be a mess (not that I much understand the
> point of such monolithic kernels, but...) You wouldn't be able to tell from
> the boot log which drivers are actually used by the system, and which
> aren't.
Maybe it is only me, and I am totally wrong, but it seems that the
resulting _monolitic_ kernel is quicker.
- Maybe it is quicker because a lot of modules try to insert themself
and fails as an autodetection subsystem in some distributions.
- Maybe because fetching a lot of files (kernel modules) at boot
time creates a lot of disk activity - and it is better to load everything
at startup by the bootloader (hint: Gujin).
- Maybe it is quicker because when loading a module there is a lot
of addresses to resolve at run time and that takes time, instead of
doing it once when you are linking the monolitic kernel.
- Maybe it is simply (correct me if I am wrong) because modules
_have_ to be compiled as a relocatable library (because the load
address of code and data segment isn't known) and that is acheived
by the compiler by fixing register %ebx to the base address - and
on i386 removing one of the 4 (or 6) general purpose register
produces code which is a lot slower (up to the point you do not care
for which processor you compile the kernel: the improvement done
by one or two added instruction/features do not compensate for this
kind of loss).
Maybe also managing the tree /lib/modules/* and the initrd take
more time than simply doing once a clean linux/.config and
maintaining this file by saying "No" to most added drivers...
Cheers,
Etienne.
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
-
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]
