>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
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
===========================================================================
[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
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
>>>>> "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.
"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
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
===========================================================================
>>>>> "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 <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.
"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