Re: Modules and DevFS

Re: Modules and DevFS

[William Knop]

>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).

>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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Michael B. Trausch]

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).
> 

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                                    fd0man@crosswinds.net
Avid Linux User since April, '96!                           AIM:  ML100Smkr

              Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Helge Hafting]

"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.]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Michael B. Trausch]

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
> 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                                    fd0man@crosswinds.net
Avid Linux User since April, '96!                           AIM:  ML100Smkr

              Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Helge Hafting]

"Michael B. Trausch" wrote:
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Georg Nikodym]

>>>>> "MBT" == Michael B Trausch <fd0man@crosswinds.net> writes:

 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[John Jasen]

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).

change your XF86Config file to point to /dev/psaux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Georg Nikodym]

>>>>> "JJ" == John Jasen <jjasen@datafoundation.com> writes:

 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Modules and DevFS

[William Knop]

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, 
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Michael B. Trausch]

On Wed, 31 Jan 2001, William Knop wrote:
> 
> 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                                    fd0man@crosswinds.net
Avid Linux User since April, '96!                           AIM:  ML100Smkr

              Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Brian May]

>>>>> "William" == William Knop <w_knop@hotmail.com> writes:

    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 <bam@snoopy.apana.org.au>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Modules and DevFS

[Helge Hafting]

William Knop wrote:
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/