Re: Modules and DevFS
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
> "MBT" == Michael B Trausch <[EMAIL PROTECTED]> 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 line to read: =tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] (just added the vc/... pattern) - changed the line to read: =/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: =/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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
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[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fw: Modules and DevFS
I just edited my rc.local file to add symlinks of the old names to the files of the new names. Works great for my purposes. -- Dan Egli - Original Message - From: "Michael B. Trausch" <[EMAIL PROTECTED]> To: "William Knop" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 31, 2001 3:56 PM Subject: Re: Modules and DevFS > 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
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[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
> "JJ" == John Jasen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
[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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
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. REGISTERsound/.*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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
> "William" == William Knop <[EMAIL PROTECTED]> 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/discsscsi-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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Modules and DevFS
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
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[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/