[Top] [All Lists]

Re: labels resolved (was Re: XFS volume labels)

To: Ed McKenzie <eem12@xxxxxxxxxxx>
Subject: Re: labels resolved (was Re: XFS volume labels)
From: Russel Ingram <ringram@xxxxxxxxxxxxxx>
Date: Thu, 5 Apr 2001 10:28:47 -0600 (MDT)
Cc: <cattelan@xxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>, <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20010405020044.A1273@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Thu, 5 Apr 2001, Ed McKenzie wrote:

> On Wed, Apr 04, 2001 at 11:41:05PM -0500, cattelan@xxxxxxxxxxx wrote:
> > Other than the "/dev/mouse doesn't exist" or "/dev/cdrom doesn't
> > exist" what other problems have you experienced?
> My biggest problem is that devfs completely breaks module
> load-on-open. I have XFree86 set up to run on matroxfb, and with devfs
> enabled, its attempt to open /dev/fb0 returns ENOENT or some such
> instead of modprobing matroxfb_base. fb0 is an "old" name, sure, but
> there's nothing in /dev/fb to link to even if devfsd were that smart.
> Likewise, if I don't load my SCSI driver in initrd, I can't open
> /dev/scd0 and expect it to load initio.o automatically. cdrecord just
> comes back and says it can't find a CD writer.
> > So yes devfs will remain turned on unless significant problems are
> > encountered.
> Well, I like devfs a whole lot more than a vat of mknod spawn, but it
> still has implementation issues that need to be fixed.

Just my $0.02...

There is really not a problem on any of the issues that have been
mentioned here (on the list) with devfs.  The problems are more about
knowing how to configure devfsd and module management properly to handle
those issues.  The one mentioned here can actually be resolved by watching
the /var/log/messages for the name of the resource the kernel is looking
for when it loads that module, then use that resource name as an alias to
the proper module in /etc/modules.conf.  That much will make the module
load properly.  Past that it's just a matter of telling devfsd to make
the correct symbolic link to the device file that your software is looking
for at the same time it makes the new format device file.

The other issue mentioned in an earlier message was with changing
permissions to allow normal users to access a particular device and having
those permissions stay that way across reboots.  There are options for
doing that that you can specify in /etc/devfsd.conf as well.

The problems with devfs are not actually in the implementation of devfs
but in lack of easily understandable documentation and just plain newness
of the system and the consequent lack of configuration knowledge.

I have run into the same problems mentioned here and though its not always
easy to find the answers so far they have always been available.  I
haven't found anything yet that devfs has permanently broken.


"Bill Gates and Microsoft have ruined the computer industry for
 a long time to come by creating a class of ignorant and lazy
 computer users."  --Russel Ingram

"Mommy ... can I go out and ... KILL TONIGHT!?"
                   --Glen  Danzig, The Misfits
Russ Ingram
Gargoyle Computer Consulting

<Prev in Thread] Current Thread [Next in Thread>