| View previous topic :: View next topic |
| Author |
Message |
hazelnusse
n00b
Joined: 22 Nov 2004
Posts: 19
|
 Posted: Fri May 12, 2006 7:53 am Post subject: Module autoloading weirdness |
 |
|
I'm perplexed: All my kernel modules are loading at boot time, totally normal, but I have nothing at all in the files /etc/modules.autoload.d/kernel-2.6 (or kernel-2.4). There is nothing in either of those files, yet all my modules: agpgart, fglrx, ipw_2200, and others are all getting loaded somehow. Is it magic? Where is the configuration file that lets you change them? I have been using Gentoo for over two years now, and in the past, if I wanted a module loaded, it was necessary for it to be in kernel-2.6. Is this information being stored somewhere else?
Thanks,
Dale |
|
| Back to top |
|
 |
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Fri May 12, 2006 9:29 am Post subject: |
|
|
Look into udev/hotplug/coldplug and you should find your answers.
troymc |
|
| Back to top |
|
|
hazelnusse
n00b
Joined: 22 Nov 2004
Posts: 19
|
| Posted: Fri May 12, 2006 6:39 pm Post subject: |
|
|
| troymc wrote: | Look into udev/hotplug/coldplug and you should find your answers.
troymc |
No I wasn't able to find my answers there. Can you be more specific? I've done a text string search in the /etc directory for all the modules that are being loaded at boot, and no files that are found have anything to do with module loading....
Why would this change in the first place? Which file do I need to edit, for instance to prevent my wireless module from being loaded at boot time if I don't want to use wireless?
Thanks,
Dale |
|
| Back to top |
|
|
thepustule
Apprentice
Joined: 22 Feb 2004
Posts: 212
Location: Toronto, Canada
|
| Posted: Fri May 12, 2006 10:14 pm Post subject: |
|
|
For some completely inexplicable reason, the coldplug functionality is being merged into udev. Even though this is clearly NOT what udev is supposed to be doing!
I'm going to have to mask my udev below 0.89 to keep my system from being ruined! |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Fri May 12, 2006 10:41 pm Post subject: |
|
|
| hazelnusse wrote: | | troymc wrote: | Look into udev/hotplug/coldplug and you should find your answers.
troymc |
No I wasn't able to find my answers there. Can you be more specific?
|
Sorry if I wasn't clear. I didn't mean that as a directory path. udev, hotplug and coldplug are userspace applications that autodetect hardware & load the modules for it. In general, they are "good" things.
| thepustule wrote: |
For some completely inexplicable reason, the coldplug functionality is being merged into udev. Even though this is clearly NOT what udev is supposed to be doing!
I'm going to have to mask my udev below 0.89 to keep my system from being ruined!
|
I fully understand your frustration. I don't know who decided that just because you have the hardware that you MUST want the module loaded immediately & constantly. I thought that the whole idea of an autoloading, modular kernel was to only load the modules you need, when you need them. That damned eth1394 module is a particular peeve of mine. Some moron thinks that everyone in the world who has a firewire interface wants to use it as a network device. WTF? 
troymc |
|
| Back to top |
|
|
thepustule
Apprentice
Joined: 22 Feb 2004
Posts: 212
Location: Toronto, Canada
|
| Posted: Fri May 12, 2006 11:36 pm Post subject: |
|
|
Indeed.
Have you ever actually tried to use eth1394 with a cable between 2 computers? It's hard enough to get it working with Linux on the other end, let alone any other OS...
Is there a way to influence these decisions? |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 13, 2006 10:33 am Post subject: |
|
|
| thepustule wrote: | | Is there a way to influence these decisions? |
Violence or cash. 
troymc |
|
| Back to top |
|
|
nephros
Advocate
Joined: 07 Feb 2003
Posts: 2139
Location: Graz, Austria (Europe - no kangaroos.)
|
| Posted: Fri May 19, 2006 5:42 pm Post subject: |
|
|
I completely agree, especially with what troymc said above.
The udev devs deal with that in their FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)
| Quote: | Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: Right, but Linux is supposed to load a module when a device is discovered
not to load a module when it's accessed. |
I couldn't disagree more.
| Quote: | Q: Oh come on, pretty please. It can't be that hard to do.
A: Such a functionality isn't needed on a properly configured system. All
devices present on the system should generate hotplug events, loading
the appropriate driver, and udev will notice and create the
appropriate device node. If you don't want to keep all drivers for your
hardware in memory, then use something else to manage your modules
(scripts, modules.conf, etc.) This is not a task for udev. |
I used to do exactly that. Now I cannot anymore.
Can someone explain how they think this can be done?
udev is among the first things to get started on system bootup, (probably even before / is mounted rw, haven't checked) and will load the whole shebang in /lib/modules long before any script can kick in.
Or am I supposed to keep an empty (minimal) modules.conf for boot time and use some hackish script to replace it sometime after the system is running? Kind of defeats the purpose of modules.conf doesn't it?
_________________
Please put [SOLVED] in your topic if you are a moron.
Last edited by nephros on Fri May 19, 2006 6:20 pm; edited 2 times in total |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Fri May 19, 2006 6:09 pm Post subject: |
|
|
At least it should respect some blacklist!
It is simply ridiculous
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Fri May 19, 2006 6:16 pm Post subject: |
|
|
coldplug will become more configurable soon
remember you are using the testing tree
as for module loading when /dev node is opened, that happens anyway. if you want that functionality, just create the device nodes. you probably want to unmerge udev and install static-dev.
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 20, 2006 8:25 am Post subject: |
|
|
| Gergan Penkov wrote: |
At least it should respect some blacklist!
It is simply ridiculous
|
/etc/hotplug/blacklist completely excludes those modules from autoloading. We want them all autoloaded - just not all loaded at boot.
| dsd wrote: |
as for module loading when /dev node is opened, that happens anyway.
|
Yes, the kernel's autoloading of modules upon first use is the behaviour we know and love.
The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour.
| dsd wrote: |
if you want that functionality, just create the device nodes. you probably want to unmerge udev and install static-dev.
|
C'mon guys, be reasonable. Are you seriously suggesting that we have to go back to the 90s and manually handle our /dev nodes and that the functionality we've enjoyed for the past 6 years is no longer available?
I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually?
Plus, items like eth1394 are firewire devices. They should only be loaded when that device is used/present. I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too?
I guess it is simply a matter of semantics. What does the term autoload mean? Loaded every boot and kept persistently? or loaded when needed and unloaded when not?
In the past, it's always been loaded/unloaded as needed.
| dsd wrote: |
coldplug will become more configurable soon
remember you are using the testing tree
|
Understood. It's just an annoyance to me NOW. 
And, yes, I do need to go read & learn more about this new "feature" that is really messing with my world. I don't seem to understand their mindset.
troymc |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Sat May 20, 2006 10:23 am Post subject: |
|
|
| troymc wrote: | | Gergan Penkov wrote: |
At least it should respect some blacklist!
It is simply ridiculous
|
/etc/hotplug/blacklist completely excludes those modules from autoloading. We want them all autoloaded - just not all loaded at boot.
|
This seems to be only theory.
/var/log/messages
| Code: | ...
May 20 11:55:01 gero Freeing unused kernel memory: 152k freed
May 20 11:55:01 gero ath_hal: module license 'Proprietary' taints kernel.
May 20 11:55:01 gero ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
May 20 11:55:01 gero ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
May 20 11:55:01 gero ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22
May 20 11:55:01 gero ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, high) -> IRQ 177
May 20 11:55:01 gero PCI: Setting latency timer of device 0000:00:02.0 to 64
May 20 11:55:01 gero ohci_hcd 0000:00:02.0: OHCI Host Controller
May 20 11:55:01 gero ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
May 20 11:55:01 gero ohci_hcd 0000:00:02.0: irq 177, io mem 0xdf003000
May 20 11:55:01 gero wlan: 0.8.4.2 (svn 1531)
May 20 11:55:01 gero ath_rate_amrr: 0.1 (svn 1531)
May 20 11:55:01 gero ath_pci: 0.9.4.5 (svn 1531)
May 20 11:55:01 gero Linux agpgart interface v0.101 (c) Dave Jones
May 20 11:55:01 gero usb usb1: configuration #1 chosen from 1 choice
... |
/etc/hotplug/blacklist
| Code: | #
# Listing a module here prevents the hotplug scripts from loading it.
# Usually that'd be so that some other driver will bind it instead,
# no matter which driver happens to get probed first. Sometimes user
# mode tools can also control driver binding.
#
# Syntax: driver name alone (without any spaces) on a line. Other
# lines are ignored.
#
# uhci ... usb-uhci handles the same pci class
usb-uhci
# usbcore ... module is loaded implicitly, ignore it otherwise
usbcore
# tulip ... de4x5, xircom_tulip_cb, dmfe (...) handle same devices
de4x5
# At least 2.4.3 and later xircom_tulip doesn't have that conflict
# xircom_tulip_cb
dmfe
#evbug is a debug tool and should be loaded explicitly
evbug
# Don't hotplug eth1394, bug #128962
eth1394
shpchp
ath_pci
ath_hal
wlan
|
/etc/modules.autoload.d/kernel-2.6
| Code: | # /etc/modules.autoload.d/kernel-2.6: kernel modules to load when system boots.
#
# Note that this file is for 2.6 kernels.
#
# Add the names of modules that you'd like to load when the system
# starts into this file, one per line. Comments begin with # and
# are ignored. Read man modules.autoload for additional details.
# For example:
# 3c59x
#ath_pci
loop
ndiswrapper
squashfs
unionfs
nvidia
ide-cd
svgalib_helper
snd_cmipci
snd_intel8x0 |
Now if this is a working solution, I simply do not want to load the atheros drivers, I use ndiswrapper in the moment.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 20, 2006 10:34 am Post subject: |
|
|
| Gergan Penkov wrote: | | troymc wrote: | | Gergan Penkov wrote: |
At least it should respect some blacklist!
It is simply ridiculous
|
/etc/hotplug/blacklist completely excludes those modules from autoloading. We want them all autoloaded - just not all loaded at boot.
|
This seems to be only theory.
|
So udev even ignores blacklist?! Unbelievable!
troymc |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 12:05 pm Post subject: |
|
|
| troymc wrote: | | The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour. |
seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.
| Quote: | | I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually? |
my advice to you, and every other manual compile kernel user we have, is avoid modules where possible. build floppy support directly into your kernel image, and accept the fact that it uses near zero memory until you actually mount a floppy. this wasnt the case with 2.4, but 2.6 contains a new driver model which means there is almost zero expense for loading modules that you arent using.
if you insist on living any other way without good reason, then you'll have to make some sacrifices, tinker with things, or whatever else.
| Quote: | | I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too? |
usb is hotpluggable, so no (assuming the devices are disconnected). are they being autoloaded even without the devices attached?
even though usb might be more suited for hotplugging and module autoloading like this, i still suggest that you build support for your hardware into the kernel image, unless you have good reason not to. the kernel is much better at autoloading its own components than userspace is at loading modules.
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 12:10 pm Post subject: |
|
|
if it helps your understanding at all, udev's coldplug functionality is a slightly more complicated version of this:
| Code: | for i in /sys/block/*/*/uevent; do echo 1 > $i; done
for i in /sys/class/*/*/uevent; do echo 1 > $i; done
for i in /sys/bus/*/devices/*/uevent; do echo 1 > $i; done |
that is, it generates hotplug events for all devices already present on the system.
hotplug events are usually only generated at the point devices are physically attached.
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Sat May 20, 2006 1:03 pm Post subject: |
|
|
This has nothing to do with udev, at least in my case (or it is even more complicated), somehow earlier kernels, do not load the modules in this way.
Writing some udev rule did not help in my case, as the modules are loaded before udev kicks in, so it does not create the devices with these rules but the modules are loaded, or at least this was after a short debugging, what really helped now, is this file:
| Code: | cat /etc/modules.d/blacklist
blacklist ath_hal
blacklist ath_pci
blacklist ath_rate_amrr
blacklist wlan
blacklist wlan_scan_sta
|
and probably this udev rule (I haven't tested it without them for now and it is probably superfluous)
| Code: | cat /etc/udev/rules.d/01-atheros.rules
SUBSYSTEM=="module", DRIVER=="ath*", OPTIONS="ignore_device,last_rule"
SUBSYSTEM=="module", DRIVER=="wlan*", OPTIONS="ignore_device,last_rule" |
but now at least all works as I want it.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Sat May 20, 2006 1:07 pm Post subject: |
|
|
The problem here is that just not listing sth in modules autoload, with earlier udev and kernels, prevented them from loading, now I must blacklist sth in order not to be loaded automagically.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 20, 2006 1:11 pm Post subject: |
|
|
| dsd wrote: |
| troymc wrote: | | The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour. |
seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.
|
Hmmmm....maybe I have been living under a rock and never noticed, but then I only switched to udev sometime late last year. 
I'm going thru the udev page right now, to try and understand some of these changes.
| dsd wrote: |
| Quote: | | I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually? |
my advice to you, and every other manual compile kernel user we have, is avoid modules where possible. build floppy support directly into your kernel image, and accept the fact that it uses near zero memory until you actually mount a floppy. this wasnt the case with 2.4, but 2.6 contains a new driver model which means there is almost zero expense for loading modules that you arent using.
|
For hardware drivers I've been moving this way for awhile now. If it's built in the box, it's built in the kernel. Only external modular devices (USB, firewire, scsi, etc) are built as modules. I've just been resistant about some devices that rarely ever get used like floppy.o and ftape.o. I have another old workstation with a SCSI card & a bunch of old scsi devices hanging off of it. I left the whole SCSI subsystem modular and used to only load it when I needed to use one those devices. But now I'm finding that the SCSI subsystem loads at boot whether I want it to or not.
| dsd wrote: |
| Quote: | | I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too? |
usb is hotpluggable, so no (assuming the devices are disconnected). are they being autoloaded even without the devices attached?
|
No, but that's my point about the eth1394 module. It IS being autoloaded. This is not a Firewire controller module, this is a module to make your firewire port look like an ethernet NIC. It is a firewire client device and it should not get autoloaded at boot any more than my USB printer modules should.
I have helped several people who had problems because, during the gentoo install, this module gets loaded first and becomes eth0 and net-setup fails, then they configure everything for their onboard NIC as eth1, rebuild their kernel w/o eth1394, reboot, and now their NIC is eth0. So they end up confused twice over. Add a wireless device in there too, and the confusion level rises even more. (This has come up several time in the Installing Gentoo forum - do a quick search for eth1394 in there & look at the network issues.)
And, on a side note: Thank you for spending some of your time helping us out on these forums. It is very important to us, and very much appreciated.
troymc |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 2:09 pm Post subject: |
|
|
yes, i'm aware of those problems, the situation isnt great but it is improving. possible solutions are: use udev to automatically rename your net interfaces to more appropriate names, based on their mac address. e.g. on my home router system, i have "wan" and "lan" rather than eth0 and eth1. another approach is configuring the new baselayout (1.12) to configure network interfaces based on their mac address, rather than their interface name.
a possible improvement for net-setup is to make it print out the details of the interface before the user configures it. you can get this info from sysfs, e.g:
mac address: cat /sys/class/net/eth0/address
device type (pci/usb/etc): readlink /sys/class/net/eth0/device
driver: readlink /sys/class/net/eth0/device/driver
for pci devices, the manufacturer/product name could also be deduced by looking at /sys/class/net/eth0/device/{device,vendor} and then looking up those ID's in the pciutils database.
maybe it would be worth filing a feature request bug for this.
i expect eth1394 will get blacklisted from udev-coldplug when it becomes more configurable. it was blacklisted from hotplug-coldplug due to it being rarely used yet causing a lot of confusion in this area.
your general argument against coldplugging eth1394 isnt complete though:
usb and firewire are both multifunction buses but you cant compare them network-wise. you can network computers through eth1394 just by connecting a standard firewire cable between them (comparable to an ethernet card with Xover ethernet cable) - this is not possible with usb. so, you should view firewire as a multifunction bus *and* network adapter, whereas you can only view usb as a multifunction bus.
now, viewing firewire as a network adapter, compare it to an ethernet adapter. ethernet card modules (8139cp, forcedeth, those kind) are autoloaded on boot regardless of whether they are actually connected to anything. same with eth1394 in this example. makes sense to a certain degree, right?
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 20, 2006 4:00 pm Post subject: |
|
|
| dsd wrote: |
now, viewing firewire as a network adapter, compare it to an ethernet adapter. ethernet card modules (8139cp, forcedeth, those kind) are autoloaded on boot regardless of whether they are actually connected to anything. same with eth1394 in this example. makes sense to a certain degree, right? |
Sorry, I'm having a hard time getting my head around that one.
Just because a device can be configured as a network device doesn't mean it should be by default.
By that logic we should also be autoloading IrLAN, IrNET, PLIP, SLIP and a host of other possible interfaces.
Wouldn't it make more sense to configure the NICs as NICs and leave the other stuff to the user?
troymc |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 4:26 pm Post subject: |
|
|
PLIP and SLIP are not hardware-specific right? they are general upper layers, so they wont be autoloaded with this kind of system.
IR networking modules are (or should be, if hotplug-capable) autoloaded if IR networking hardware is present, exactly the same as eth1394, exactly the same as other networking hardware.
i'm not judging whether or not this makes sense in a distro environment - i'm just saying why it happens. a networking piece of hardware is attached, so the networking driver for that hardware is autoloaded. ethernet, firewire, wireless, IR all fall into this category.
the hotplug architecture is quite simple:
a device is attached, the bus driver (e.g. pci, usb) generates a hotplug event. the hotplug event is passed to the userspace hotplug agent. the agent examines the device, and examines any modular drivers which claim to support it. the new device is a networking-capable firewire adapter, and there is a module on the system which claims to support networking-capable firewire adapters, so it gets loaded.
there is no additional logic involved, nothing like "lets see, this is a firewire adapter, and firewire isn't networking only, and 99% of firewire users dont actually use the networking part, not to mention the number of users who get confused when this module is loaded, so lets not load this one today"
its plain and simple: it sees a device, and finds a driver which claims to support that device, so it loads that driver
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
troymc
Guru
Joined: 22 Mar 2006
Posts: 553
|
| Posted: Sat May 20, 2006 5:55 pm Post subject: |
|
|
| dsd wrote: | | PLIP and SLIP are not hardware-specific right? they are general upper layers, so they wont be autoloaded with this kind of system. |
No, actually I see PLIP as a direct analog of this eth1394 issue. It simply uses the parallel port instead of the firewire port. modprobe plip and I have a ethernet device ready to configure & connect, just need a cable.
| Code: |
# modprobe plip
# ifconfig plip0 192.168.1.1
# ifconfig
...
plip0 Link encap:Ethernet HWaddr FC:FC:C0:A8:01:01
inet addr:192.168.1.1 P-t-P:192.168.1.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:7 Base address:0x378
|
SLIP is the same, it just seems like an upper layer because we generally use modems and need to run some other software to manage the modem and make the initial connection. None of that is needed with a direct cable connection (null modem cable), however a usermode program is necessary to attach the driver to a specific serial port (slattach). So maybe that would exempt this one.
| dsd wrote: | | IR networking modules are (or should be, if hotplug-capable) autoloaded if IR networking hardware is present, exactly the same as eth1394, exactly the same as other networking hardware. |
Again, no. The IR networking modules are not autoloaded. At least not on my system. But all I have to do is modprobe them and I have a working interface. I've tried looking for the rules for this in the udev rules files, but I don't understand the rules files enough yet. I can't even identify the rule which is loading the eth1394 module. 
| Code: |
# modprobe irlan
# ifconfig -a
...
irlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:4
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
|
| dsd wrote: |
a device is attached, the bus driver (e.g. pci, usb) generates a hotplug event. the hotplug event is passed to the userspace hotplug agent. the agent examines the device, and examines any modular drivers which claim to support it. the new device is a networking-capable firewire adapter, and there is a module on the system which claims to support networking-capable firewire adapters, so it gets loaded.
there is no additional logic involved, nothing like "lets see, this is a firewire adapter, and firewire isn't networking only, and 99% of firewire users dont actually use the networking part, not to mention the number of users who get confused when this module is loaded, so lets not load this one today"
its plain and simple: it sees a device, and finds a driver which claims to support that device, so it loads that driver
|
Well, that logic is pretty straight forward and does make sense to me.
But, I guess I just don't see it being applied to any other non-networking specific device except firewire. But, if it has been, since the others generally use non ethx names, I haven't seen anyone confused by extra network interfaces. So maybe the eth1394 interface has just managed to intrude into my daily conciousness by causing confusion.
And I definitely don't recall giving MY approval for this change! 
troymc |
|
| Back to top |
|
|
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Sat May 20, 2006 5:58 pm Post subject: |
|
|
Well this is fine and dandy, but my problem is with drivers, which are not part of the kernel-tree (madfiwi-ng and ndiswrapper), if such drivers are causing for example kernel-panic (this behaviour begins to resemble a little bit the windows one)?
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 6:17 pm Post subject: |
|
|
in some ways, parallel is comparable to firewire. it is a multi-function bus (you can connect all kinds of devices to it), and you can use it as a raw networking device with no extra hardware (plip/eth1394).
however, the parallel subsystem is completely non-hotpluggable, mainly because it is not possible to detect which kind of peripheral device is attached. it is also considered legacy. if it wasnt, the plip module would be automatically coldplugged in the same way.
| Quote: | | I've tried looking for the rules for this in the udev rules files, but I don't understand the rules files enough yet. I can't even identify the rule which is loading the eth1394 module. |
i know that it is expected that the hotplug blacklist is not obeyed during coldplugging, but i can't offer an explanation for that at this point. this is my understanding:
rules are mostly for naming devices, setting device permissions, taking actions when devices are created, things like that.
additionally, they control responses to "uevents" (this is the new form of hotplug event). the default ruleset simply invokes the old hotplug agent when this happens:
| Code: | | ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd $env{SUBSYSTEM}" |
when a device is attached, the kernel generates a hotplug uevent, which causes that rule to execute the userspace hotplug, which in turn loads the module.
udev coldplugging is simply the process of udev asking the kernel to generate uevents for every connected device. the kernel will do so, which will trigger the above rule to run (as if the device had just been plugged in). hotplug will then do the module loading.
i must either be wrong somewhere, or missing something, because the above implies that the hotplug blacklist would come into effect. if i dont get a chance to look into it beforehand, i'll ask the lead udev developer when i meet with him next month 
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
dsd
Developer
Joined: 30 Mar 2003
Posts: 2162
Location: nr London
|
| Posted: Sat May 20, 2006 6:21 pm Post subject: |
|
|
just noticed the section titled "Autoloading modules" in the udev rules file (thats new). that almost certainly has something to do with it.
_________________
http://dev.gentoo.org/~dsd |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
