lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)

On Sat, Jun 19, 1999 at 06:44:11PM -0400, Horst von Brand wrote:
> Nathan Hand <nathanh@chirp.com.au> said:
> > On Thu, Jun 17, 1999 at 12:49:47PM -0400, Horst von Brand wrote:
> > >
> > > By whom/how are permissions handled? Even if it's symlinks, the original
> > > files in /devfs have to carry them (you can't follow symplinks to files you
> > > can't access directly!). And that means the kernel has to know how to set
> > > up permissions for a new device when it appears, and remember the settings
> > > from one boot to the next. Gross. And a kludged initscript that sets them
> > > up on each boot is even worse. As bad as the much-maligned MAKEDEV, but run
> > > _each_ boot, so much more critical.
>
> > I would like a devfs mounted on /dev which does nothing except report node
> > accesses that ENODEV to devfsd.
>
> kmod + modprobe are doing fine, thanks.

These tools do not (and can not) insert modules based on attempts to open
non-existent device nodes, so I fail to see how they do fine. You've just
thrown away one of the best features of the virtual /dev.

> > Then devfsd can implement all the policies
> > and naming schemes. Permissions can be handled with /etc/devfs.conf (which
> > I think is neater than chmod in an ext2 based /dev anyway). The devfsd can
> > be responsible for node creation with mknod(). Module insert/remove events
> > can also report to devfsd, preferably with major/minor numbers, so that we
> > could shove even more policy in devfsd. So perhaps a devfs.conf like
>
> BTW, what do I access to get at the ZIP drive (i.e., today /dev/sda4 on my
> machine)? It can't be /dev/sda4 if that piece of naming is done by devfsd,
> which might decide today it's /dev/scsi/ppa/0/4...

What sort of nonsensical argument is this? In the current setup the names
are derived from major/minor pairs in a script called /dev/MAKEDEV. Would
you argue that "MAKEDEV might decide today it's /dev/scsi/ppa/0/4"?

If you don't modify /etc/devfs.conf then there's no reason why the device
name would change.

Part of the problem here is that we're trying to keep the mapping between
names and major/minors out of the kernel, because that's one of the major
arguments against the current devfs. An /etc/devfs.conf does that.

> which obviously doesn't exist until I tell the kernel to go looking for it?

It doesn't exist until the module is loaded (which makes sense: you don't
have /dev entries which have no corresponding drivers). But if you try to
access a non-existent node it can attempt to create it for you.

If necessary, devfsd can use /etc/devfs.conf to convert the name into the
corresponding major/minor pair and then call modprobe to load modules. So
you access /dev/sda4 and it automatically loads ZIP modules.

> OK, I could look it up
> in a magic place in /proc... but if I don't want to mount proc (perhaps for
> security reasons, or whatever)? Anyway, now I'm dependent on a magic file
> in /proc (with _that_ specific format!) that does not exist anywhere else
> (bye, bye portability) _and_ /dev, and perhaps more stuff. Also, the above
> might give rise to races.

This is all just fantasy conjecture. It's better to argue against what is
being proposed, instead of these idiotic designs that you're inventing to
make devfs look bad. There is no magic /proc file.

> And "Need Zip drive... OK, look how it should be called today...(root
> around in /proc)... OK, it's called /dev/foo today, go access /dev/foo so
> the kernel goes looking for it... nope, not found" sounds harder on the
> user than "Look for /dev/zip (or whatever it is called _always_ in /dev),
> if not found give up".

What?

> Many programs will just go /dev/foo, and introduce subtle bugs.

What bugs?

> [...]
>
> > This makes sense to me, and I think moves all policy that Tso and HPA have
> > been unhappy about completely into a userspace devfsd. I also think it has
> > the least impact on the existing functionality of devfs (you lose creation
> > of nodes which don't have devfs.conf entries which might upset proprietary
> > module developers, but that's about it). It also doesn't meet the proposal
> > by Tso of providing bus/lun/id information, but I'm not sure that's really
> > a /dev issue anyway (sounds more like a /proc/hardware/ issue).
>
> The problem with this is that it adds one more program that _must_ work in
> order for the system to be minimally functional. No devfsd ==> no /usr _at
> all_, you can't even mount it by hand! And not because the filesystem is
> shot.

Yes, you can. You create the nodes with mknod. This is a non-argument.

> I see all these proposals as introducing complexity for the sake of solving
> problems that have already been solved (perhaps not with maximal elegance,
> but with a working solution). Problems that aren't really important in that
> they need to be addressed perhaps a dozen times during the lifetime of a
> typical system.

I think you intentionally try to misunderstand or misrepresent what devfs
does. The nonsense above about "magic /proc entries" and "race conditions
when opening devices" and "changing device names" suggests you have never
even seen devfs, let alone made an informed decision about it.

--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au

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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.283 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site