Modules and DevFS
William Knop
discovered I had a problem with module loading while using DevFS.
Correct me if I'm wrong, but DevFS only makes /dev entries when a device is
present, and the device is not present until the module is loaded. So if I
want to access /dev/hda and the IDE module has not been loaded yet, I will
get a message telling me the device doesn't exist or some such instead of
autoloading the module and being happy. Same goes for hotswap devices,
right? I boot directly into X and have to crash out (otherwise it
continually tries to unsuccessfully load X) so I could enable my USB mouse
and various other devices.
I realize modularizing the entire IDE subsystem is not really good anyway,
because every time it reloads it will rescan the bus... But what about USB?
Suppose I don't have any IDE or USB devices, but want support so I can use
them later. Especially in the case of USB, plugability is a must for desktop
"home" systems.
I also have enabled the "module autoload" feature of DevFS, which
conveniently autoloads my 3c59x driver. :)
Does the kernel only autoload modules through userspace request, or can a
hardware request cause loading? For instance, inserting a USB peripheral
would cause the USB chipset to signal the OS. So therefore the OS can update
its device tables and unload the module again when it becomes inactive. This
goes for all hot-swap devices, IMHO.
I read all the FAQs and stuff and found nothing that really addresses this,
so here I ask if anyone has any idea as to a solution. No doubt I screwed
something up somewhere along the line... If my kernel or XF86 config files
are needed, I can pull 'em up and post 'em. Also, please CC responses to me
because I'm not currently subscribed.
Thanks a bunch,
Will
Box info:
Linux 2.4.1
Abit M/B
P3 550
256MB RAM
AGP Devices:
Nvidia TNT2 AGP display card
PCI Devices:
S3Virge/VX display card
Adaptec 3940UW SCSI card
3Com "Boomerang" ethernet card
ISA Devices:
SB AWE 64 Gold ISA sound card
IDE Drives:
2 CDROM drives
SCSI Drives:
4.5 GB UW drive
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Brian May
William> Correct me if I'm wrong, but DevFS only makes /dev
William> entries when a device is present, and the device is not
William> present until the module is loaded. So if I want to
William> access /dev/hda and the IDE module has not been loaded
William> yet, I will get a message telling me the device doesn't
William> exist or some such instead of autoloading the module and
William> being happy. Same goes for hotswap devices, right? I boot
William> directly into X and have to crash out (otherwise it
William> continually tries to unsuccessfully load X) so I could
William> enable my USB mouse and various other devices.
My /etc/modutils/devfsd has
probeall /dev/discs scsi-hosts sd_mod ide-probe-mod ide-disk DAC960
perhaps it should have something similar for /dev/hd*?
As a work around, put something like this:
alias /dev/hdd ide-cd
or (not tested; just guessing):
alias /dev/hd* /dev/ide
in /etc/modutils/aliases, and run update-modules.
William> I realize modularizing the entire IDE subsystem is not
William> really good anyway, because every time it reloads it will
William> rescan the bus... But what about USB? Suppose I don't
William> have any IDE or USB devices, but want support so I can
William> use them later. Especially in the case of USB,
William> plugability is a must for desktop "home" systems.
I am not really familiar with USB.
--
Brian May <b...@snoopy.apana.org.au>
Michael B. Trausch
>
> Correct me if I'm wrong, but DevFS only makes /dev entries when a device is
> present, and the device is not present until the module is loaded. So if I
> want to access /dev/hda and the IDE module has not been loaded yet, I will
>
One thing that I've noticed with devfs is that all the old-style names are
symlinks. Documentation/filesystems/devfs/README, I think is the file
that describes this. The actual device file for /dev/hda now is:
/dev/ide/hd/c0b0t0u0
OR
/dev/ide/host0/bus0/target0/lun0/disc
I use the shorter one in my fstab, it makes things neater. It's also a
symlink, but I would think that symlink will stay longer than /dev/hda
will, anyway. When I rebuild my system, or get a completely new one,
everything will probably wind up using /dev/ide/host0... etc.
>
> I realize modularizing the entire IDE subsystem is not really good anyway,
> because every time it reloads it will rescan the bus... But what about USB?
> Suppose I don't have any IDE or USB devices, but want support so I can use
> them later. Especially in the case of USB, plugability is a must for desktop
> "home" systems.
>
Everything is modularized here, including ppp and such, and modprobe is
loading everything quite nicely for me. I don't like to run one big
kernel, it wastes too much memory, and so I use pretty much *everything*
that I can in modules (IDE I can't, because I boot from IDE, but I leave
SCSI in a module, becuase I use ide-scsi to burn my CDs and it's not
*reqired*).
[clipped]
>
> I read all the FAQs and stuff and found nothing that really addresses this,
> so here I ask if anyone has any idea as to a solution. No doubt I screwed
> something up somewhere along the line... If my kernel or XF86 config files
> are needed, I can pull 'em up and post 'em. Also, please CC responses to me
> because I'm not currently subscribed.
>
I can't help you much more than what I've already said, but best of wishes
and luck to you. I would advise that you traverse through /dev/ though,
and find out how the new organization is... it's *quite* different from
the old method. The symlinks are only there for backwards compatability
for the time being - however, I'd expect those to be moved out when pretty
much all Linux software is using the new arrangement.
- Mike
===========================================================================
Michael B. Trausch fd0...@crosswinds.net
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
Peter Samuelson
[William Knop]
> How can DevFS know which devices to add to /dev/scsi/... without
> loading the module and scanning the bus first? Or do you manually
> insert the scsi module when you need it?
If you do 'cd /dev/scsi', the kernel looks it up and finds it missing,
which generates a "lookup" event from the kernel to your 'devfsd'
process. (You *do* run devfsd, right?) devfsd then calls 'modprobe
/dev/scsi' (I think that's the default action, you can change it in
/etc/devfsd.conf if you wish). /sbin/modprobe reads /etc/modules.conf
which has an entry like 'alias /dev/scsi sym53c8xx', so when it is
asked to load /dev/scsi it actually loads sym53c8xx. sym53c8xx in turn
triggers the creation of /dev/scsi as it initializes.
So modprobe, having loaded the module, exits. devfsd then replies to
the kernel 'ok, try again, will you please' and the kernel does so, and
this time /dev/scsi/ exists and is accessible.
...And the chdir("/dev/scsi") system call, having waited this whole
time, finally returns successfully. And now you know ... the rest of
the story.
Peter
Helge Hafting
>
> I decided recently to go bleeding-edge on one of my Linux boxes and
> discovered I had a problem with module loading while using DevFS.
> Correct me if I'm wrong, but DevFS only makes /dev entries when a device is
> present, and the device is not present until the module is loaded. So if I
> want to access /dev/hda and the IDE module has not been loaded yet, I will
> get a message telling me the device doesn't exist or some such instead of
> autoloading the module and being happy. Same goes for hotswap devices,
You can have the device autoloaded and be happy, even when using devfs.
All you need is to set up the devfsd daemon right.
I have my sound driver as modules - so /dev/dsp don't exist when it
isn't loaded. I can still have my sound using programs autoload
the driver. I'll show this as an example, as I don't use USB myself.
My /etc/devfsd.conf contains the following, among other things:
LOOKUP dsp MODLOAD
LOOKUP sound MODLOAD
This is a neat one. Whenever someone tries to lookup "/dev/dsp"
devfsd will do a "modprobe /dev/dsp" if the device isn't there.
Appropriate aliases in /etc/modules.conf then ensures the
correct module is loaded.
REGISTER sound/.* MKOLDCOMPAT
UNREGISTER sound/.* RMOLDCOMPAT
This ensures old fashioned names like /dev/dsp works, by creating
links to /dev/sound/dsp. Few programs ask directly
for /dev/sound/dsp yet.
My modules.conf contains this, among other things:
alias /dev/dsp sound-service-0-3
This maps the "/dev/dsp" probe to the sound driver.
Further aliases for sound-service-0-3 follows, but thats
just stuff necessary to load ALSA so I won't detail it here.
This happens when a program tries to open the (non-existing) /dev/dsp:
* app tells kernel to open "/dev/dsp"
* devfs realize it isn't there, and pass the request to devfsd
* devfsd does a "modprobe /dev/dsp" because its configuration says so.
* modprobe looks up the real driver in modules.conf, using my aliases.
The sound driver modules are loaded.
* The sound modules create /dev/sound/dsp among others
* devfs notice this, and notifiex devfsd which creates the /dev/dsp
symlink as devfsd.conf says so.
* devfsd returns to devfs that lets the sound driver continue its
initialization. The sound driver finishes and modprobe returns
and the first invocation of devfsd finishes.
* devfs continue looking up /dev/dsp. It exists now, so the kernel
return a file descriptor to the app in the usual way.
This may seem like a lot - fortunately it is simpler when the driver
is in memory.
> I realize modularizing the entire IDE subsystem is not really good anyway,
> because every time it reloads it will rescan the bus... But what about USB?
> Suppose I don't have any IDE or USB devices, but want support so I can use
> them later. Especially in the case of USB, plugability is a must for desktop
> "home" systems.
Setting up a LOOKUP in devfsd will do the trick. You can run devfsd in
debug mode if you want to know exactly what the kernel tries to look up.
As for what to modularize - I believe the idea is to create modules
for anything that sits unused for long periods of time, and
compile in anything that is used most of the time. So I
compile in network adapters and drivers for disks that is mounted
all the time. Sound, isdn, floppy and cdrom is used occationally, and
goes in modules. Your case might be different.
> I also have enabled the "module autoload" feature of DevFS, which
> conveniently autoloads my 3c59x driver. :)
>
> Does the kernel only autoload modules through userspace request, or can a
> hardware request cause loading? For instance, inserting a USB peripheral
> would cause the USB chipset to signal the OS. So therefore the OS can update
> its device tables and unload the module again when it becomes inactive. This
> goes for all hot-swap devices, IMHO.
>
I believe it is software requests only. The hw can notify the os,
_if_ the os has a driver catching the notification. So you'll probably
need some part of USB loaded or compiled in to catch the notification.
The various devices may the be loaded as the kernel or some userspace
daemon parses the request and ask for the module.
Or you can skip this and load the device when a program want to open it,
instead of when it is plugged in. You'll simply get an error
if the device isn't there.
Helge Hafting
John Jasen
> >One thing that I've noticed with devfs is that all the old-style names are
> >symlinks.
>
> Hmm... I have no symlinks until the module loads. Therefore X sees no
> /dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the
> module, and DevFS doesn't add the /dev entry. There's got to be an easy way
> around this. Perhaps it has already been implimented, but I haven't been
> able to get anything to work well (manual loading for me).
change your XF86Config file to point to /dev/psaux
Georg Nikodym
JJ> On Thu, 1 Feb 2001, William Knop wrote:
>> >One thing that I've noticed with devfs is that all the old-style
>> >names are symlinks.
>>
>> Hmm... I have no symlinks until the module loads. Therefore X sees
>> no /dev/input/mouse, doesn't ask the kernel for it, the kernel
>> doesn't load the module, and DevFS doesn't add the /dev
>> entry. There's got to be an easy way around this. Perhaps it has
>> already been implimented, but I haven't been able to get anything
>> to work well (manual loading for me).
JJ> change your XF86Config file to point to /dev/psaux
Or /dev/input/mice if you use a USB thang.
William Knop
>symlinks.
Hmm... I have no symlinks until the module loads. Therefore X sees no
/dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the
module, and DevFS doesn't add the /dev entry. There's got to be an easy way
around this. Perhaps it has already been implimented, but I haven't been
able to get anything to work well (manual loading for me).
>Everything is modularized here, including ppp and such, and modprobe is
>loading everything quite nicely for me. I don't like to run one big
>kernel, it wastes too much memory, and so I use pretty much *everything*
>that I can in modules (IDE I can't, because I boot from IDE, but I leave
>SCSI in a module, becuase I use ide-scsi to burn my CDs and it's not
>*reqired*).
Really? How can DevFS know which devices to add to /dev/scsi/... without
loading the module and scanning the bus first? Or do you manually insert the
scsi module when you need it?
Do you think if I add symlinks manually perhaps it will force DevFS to look
for a module to add the needed entry? Or maybe module aliases? I think I am
going to spend some time checking out the DevFS code and experimenting with
module entries.
-Will
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
Michael B. Trausch
>
> >symlinks.
>
> Hmm... I have no symlinks until the module loads. Therefore X sees no
> /dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the
> module, and DevFS doesn't add the /dev entry. There's got to be an easy way
> around this. Perhaps it has already been implimented, but I haven't been
> able to get anything to work well (manual loading for me).
>
As I understand it, devfsd, the daemon that you should have installed and
use with devfs (at least until all old-style device names are gone), is
what puts the compatability symlinks in there. DevFS, if you tell it to
mount at kernel boot, (which you should), provides the actual device
inodes, for example: /dev/tts/*, /dev/pty/*, /dev/vc/*, etc.
DevFSd provides symlinks as follows:
/dev/ttyS0 = /dev/tts/0
/dev/tty0 = /dev/vc/0
/dev/pty* = /dev/pty/*
Until programs use the new names (e.g., init should tell getty to use
/dev/vc/0 instead of /dev/tty0), and everything on the system doesn't need
support for the old-style names, you need to use devfsd and
such.
I can't say that other than naming things and installing the daemon, I've
nto had any problems with modules and whatnot. Maybe you'll be forced to
a solution that Documentation/filesystems/devfs/README presents for those
who need a device there - You may have to create a device inode manually
via a startup script at bootup... You should read that file for more
details.
- Mike
===========================================================================
Michael B. Trausch fd0...@crosswinds.net
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
-
Helge Hafting
[...]
> DevFSd provides symlinks as follows:
>
> /dev/ttyS0 = /dev/tts/0
> /dev/tty0 = /dev/vc/0
> /dev/pty* = /dev/pty/*
>
> Until programs use the new names (e.g., init should tell getty to use
> /dev/vc/0 instead of /dev/tty0), and everything on the system doesn't need
> support for the old-style names, you need to use devfsd and
> such.
You don't have to wait for every program to use the new names, if devfs
is
the way you want to go. Do a "rgrep /dev /etc/*" and you'll find
that many device-using programs have their device names stored in
configuration files. Fixing these files is simple, just replace
/dev/device with whatever the symlink points to. [This leaves a few
files like /etc/securetty that use relative pathnames. These are
of course fixable too, they just don't have the /dev to search for.]
This lets you get rid of a lot of symlinks. I still need symlinks for
/dev/tty* (hardcoded in X), isdn stuff and sound stuff. Everything else
is gone from dev, sitting comfortably in subdirectories only.
Getting rid of all "possible" disks helped in particular, "ls /dev"
fits in a standard 80x25 screen now. :-)
Helge Hafting
Michael B. Trausch
> "Michael B. Trausch" wrote:
> [...]
> > DevFSd provides symlinks as follows:
> >
> > /dev/ttyS0 = /dev/tts/0
> > /dev/tty0 = /dev/vc/0
> > /dev/pty* = /dev/pty/*
> >
> > Until programs use the new names (e.g., init should tell getty to use
> > /dev/vc/0 instead of /dev/tty0), and everything on the system doesn't need
> > support for the old-style names, you need to use devfsd and
> > such.
>
> You don't have to wait for every program to use the new names, if
> devfs is the way you want to go. Do a "rgrep /dev /etc/*" and you'll
> find that many device-using programs have their device names stored in
> configuration files. Fixing these files is simple, just replace
> /dev/device with whatever the symlink points to. [This leaves a few
> files like /etc/securetty that use relative pathnames. These are of
> course fixable too, they just don't have the /dev to search for.]
>
Yeah, also mpg123 has /dev/dsp hardcoded. Which reminds me of a problem
that I'm having with DevFS - I have a minor fix for it, but I don't think
that's "correct" due to the way it works. Myabe DevFS was supposed to
have this behavior change: The console owner can't play sound. =(
/dev/sound/dsp and /dev/sound/mixer are owned by root:root, and start with
0600 permissions. I want them to be owned by the console owner, and
retain that 0600 permission. I can't think of a way to do that exactly,
so what I'm doing for now, is make them 0666 so that I can use them in my
programs. (I run from a 33.6 modem, for now, so I'm not worried about
people snooping into my audio, becuase that's a *lot* of data for them to
try to snoop).
Is this fixable the "right" way?
> This lets you get rid of a lot of symlinks. I still need symlinks for
> /dev/tty* (hardcoded in X), isdn stuff and sound stuff. Everything
> else is gone from dev, sitting comfortably in subdirectories only.
> Getting rid of all "possible" disks helped in particular, "ls /dev"
> fits in a standard 80x25 screen now. :-)
>
That's the one thing that I really like, I can look at /dev/ide/hd/* and
see what I *have*, not what I *could* have. That saves me the trouble of
having to do an fdisk -l every time I want to see what partitions I have
on my drives.
I just need to get ide-scsi working and I'll be all set, I still don't
have ide-scsi working in 2.4.x but I haven't tried it yet. When I do, I'm
hoping that I can get it working completely so that I can use my burner.
- Mike
===========================================================================
Michael B. Trausch fd0...@crosswinds.net
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
-
Georg Nikodym
MBT> Is this fixable the "right" way?
On my box, which started its life as a RH7, I've been editing
/etc/security/console.perms as I've discovered problems.
I don't know if this is the right way but thus far I've:
- changed the <console> line to read:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
(just added the vc/... pattern)
- changed the <cdrom> line to read:
<cdrom>=/dev/cdroms/* /dev/cdwriter*
(removed the /dev/cdrom* and added /dev/cdroms/*)
I have not had reason (ie. xmms works) to change the sound settings,
which are:
<sound>=/dev/dsp* /dev/audio* /dev/midi* \
/dev/mixer* /dev/sequencer
Hope that helps.
Helge Hafting
>
> On Fri, 2 Feb 2001, Helge Hafting wrote:
>
> > "Michael B. Trausch" wrote:
> > [...]
> > > DevFSd provides symlinks as follows:
> > >
> > > /dev/ttyS0 = /dev/tts/0
> > > /dev/tty0 = /dev/vc/0
> > > /dev/pty* = /dev/pty/*
> > >
> > > Until programs use the new names (e.g., init should tell getty to use
> > > /dev/vc/0 instead of /dev/tty0), and everything on the system doesn't need
> > > support for the old-style names, you need to use devfsd and
> > > such.
> >
> > You don't have to wait for every program to use the new names, if
> > devfs is the way you want to go. Do a "rgrep /dev /etc/*" and you'll
> /dev/sound/dsp and /dev/sound/mixer are owned by root:root, and start with
> 0600 permissions. I want them to be owned by the console owner, and
> retain that 0600 permission. I can't think of a way to do that exactly,
> so what I'm doing for now, is make them 0666 so that I can use them in my
> programs. (I run from a 33.6 modem, for now, so I'm not worried about
> people snooping into my audio, becuase that's a *lot* of data for them to
> try to snoop).
>
> Is this fixable the "right" way?
Sure. Run devfsd (devfs daemon), and set up a good /etc/devfsd.conf
devfsd.conf can specify ownership and permissions instead of the
default created by the driver. I get /dev/sound/dsp owned
by group "audio", and my non-root user is a member of that group.
devfsd.conf also specify which devices to create compatibility
symlinks for. The default seems to be all, but you may
decide to create symlinks for only those devices that really need it,
such as sound.
Read the docs for devfsd and devfsd.conf.
Helge Hafting