devfs
[Top] [All Lists]

devfsd link problem and module loading questions

To: <devfs@xxxxxxxxxxx>
Subject: devfsd link problem and module loading questions
From: "Kevin P. Fleming" <kevin@xxxxxxxxxxxxx>
Date: Thu, 26 Apr 2001 12:55:28 -0700
Organization: LSG, Inc.
Sender: owner-devfs@xxxxxxxxxxx
I'm using RH7.1, with kernel 2.4.3 and devfs mounting at boot time, plus
devfsd (the one distributed with RH7.1). I've converted pretty much
everything on my system to use the new names (and will be turning off old
compatibility names soon), and it's all working quite well. There are two
issues I've identified, though:

- I have the Universal TUN/TAP driver compiled as a module for my kernel for
some IP tunneling. This module, in a non-devfs environment, needs a device
inode at /dev/net/tun with major 10/minor 200. With devfs loaded, when the
module loads, a device inode is created at /dev/misc/net/tun with major
10/minor 200, and a link is created at /dev/net/tun. Unfortunately that link
is pointed to "misc/net/tun", not "../misc/net/tun", so it's broken. The
TUN/TAP driver only seems to be asking for the misc/net/tun inode to be
created, so I can't find the code that is creating the link to fix it...
anyone have a clue where the link is coming from?

- I have an IDE (ATAPI) ZIP 250 drive that works just fine with the
ide-floppy driver. When I have this driver compiled as a module, there is no
/dev entry for this drive in /dev/discs if the module has not been loaded.
There is an entry at /dev/ide/host0/bus0/target1/lun0, but it has no entries
below since again the module has not been loaded. Obviously, I can create an
entry in modules.conf to alias "/dev/discs/disc1" to ide-floppy, or even
alias "/dev/ide/host0/bus0/target1/lun0/*" to ide-floppy, but I'd rather not
have to tie this drive down to being "disc1" or at that specific IDE  bus
location. Other than forcibly loading/unloading the ide-floppy module during
the boot process, is there any better solution for this problem?

Ideally, it'd be very cool if the modules that are compiled for the running
kernel were all given the chance to identify their associated devices and
register their entries with devfs, then unload for later (possible) usage.
This would take care of the devices that are internal to the machine,
getting all the /dev entries created. For external devices that may not be
attached this would be no help... but still. Even for things like the
TUN/TAP driver, it seems to make sense to me to not make the end-user have
to put an alias in modules.conf for the driver, when it could easily do a
devfs_register/devfs_unregister to get the proper /dev entries created.


<Prev in Thread] Current Thread [Next in Thread>
  • devfsd link problem and module loading questions, Kevin P. Fleming <=