Mysteries of /dev/eth?
Mikkel L. Ellertson
mikkel at infinity-ltd.com
Thu Sep 20 17:26:26 UTC 2007
Timothy Murphy wrote:
> I'm puzzled by the device /dev/eth0 , etc,
> chosen by different drivers.
> This isn't a problem for me, just a mystery.
> For example, I just installed Fedora-7 on a laptop
> (an old Sony PictureBook - C1VFK)
> and when I attached it by ethernet to my LAN,
> it immediately worked through /dev/eth0 ,
> despite the fact that /etc/modprobe.conf
> had an incorrect "alias eth0 orinoco_cs",
> while the driver in use is pcnet_cs .
> By contrast, on another laptop
> although I have the correct "alias eth0 orinoco_cs"
> in /etc/modprobe.conf , a strange device -
> /dev/dev1375 , IIRC, was used.
> So my questions are:
> 1) How does the machine decide which driver to use; and
> 2) How does it decide which device to use?
> Has it got something to do with udev ?
In my experience, to a large extent, the driver affects the choice
of name - it determines if it will be eth?, wlan?, or something
else. The kernel then fills in the ? with the next available number
for that name.
The alias in modprobe.conf is to give an easy name to a module - so
that running "modprobe eth0" is the same as "modprobe orinoco_cs".
It also comes into play if you try to access eth0, but only if there
is not already a eth0. If another driver is already claiming eth0,
then the alias is not processed. You are susposed to be able to
prevent this from happening by specifying the default MAC address of
the NIC in config file for the interface, but this does not always
work. It may prevent the interface from coming up, but it does not
prevent a driver from grabbing the interface name.
You can not use udev to directly affect the name used, but you can
create an "alias" for the interface that is consistent, and use that
name instead. (lan0 instead of eth?) There is an example of doing
this in the udev docs, but I have no personal experience in doing this.
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20070920/e3cfd026/attachment-0001.bin
More information about the users