Not that I'm denying it, but how was the devfsd persistance not elegant?
-Shawn
-----Original Message-----
From: Stephen Frost [mailto:sfrost@mail.snowman.net]
Sent: Thursday, October 07, 1999 12:08 PM
To: Shawn Leas
Cc: 'Horst von Brand'; Jakma, Paul; linux-kernel@vger.rutgers.edu
Subject: RE: devfs again, (was RE: USB device allocation)
On Wed, 6 Oct 1999, Shawn Leas wrote:
> Stephen Frost wrote:
> > A thought, that I'm sure has been said before, but...
>
> >/devices -- devfs mountpoint
> >/dev -- symlinks in to /devices
> > devfs then adds option to have /devices just be a crapload of
> >files named 'major,minor' in the old fashion. ;)
>
> That is not the default, and is not quite correct. There is a
configuration
> where /devices (or wherever, maybe somewhere only readable by root) is the
> devfs, and devfsd populates /dev with the correct nodes/links. And, as you
> know, when you chown/chmod a link, the target (or the target of the
target,
> etc) gets the requested action. devfsd then adds persistance to whereever
> the devfs is mounted, thereby carrying it over to /dev which devfsd is
> populating.
The persistance that devfsd adds is, as I recall, less than elegant.
A better solution would be nice, almost like a special kind of symlink,
perhaps even something created by mknod which uses a major,minor assigned to
it that is basically just 'talk to devfs', which will then figure out what
device to talk to in /devices.
Now, how you figure out what device to talk to is something of a
kicker. You don't want it based on file name, nor do you (obviously) want
it based on major,minor (You want to have just ONE major,minor to talk
through, if possible). What this would do, basically, is allow for
persistance
in /dev using these files (For those who want it), and have the permissions
on these files be handled when they're initally opened, as things work now.
My comment above regarding having /devices populated w/ major,minor
as my idea as to the possible solution for those who feel using names is
putting policy into the kernel. So we give the option to not use names, and
at the same time allow those of us who like the devfs naming conventions to
use them. Of course, with the idea of the links I'm talking about, you
could
name things in /dev whatever you felt like, but then, that solution may not
be possible, or may not just be a solution at all.
> > The problem here is, how do you give permissions to symlinks?
> >That's really the kicker, but fix that, and you may have something...
>
> See above.
>
> > I realize this is ugly, but some way to store the permissions in
> >the symlink, or have something in there devfs can read real quick to
> determine
> >if you have permission? I somehow fear a hardlink-type thing wouldn't
work
> >too well either, but this seems like something that should be possible to
> >do, perhaps not, tired, end of day, time ta go home. :)
>
> Again, the only permissions that matter are those kept track of by devfsd
on
> the devfs mount.
That would be the problem, and the devfs mount goes away when you
reboot,
I realize devfsd does something to handle (tarball-like I seem to recall?),
but
that seems less than elegant to me...
Realize, I like devfs as it is personally, but I want to see it in
the
main kernel tree and this is why I'm trying to come up w/ ideas that will
(maybe)
help satisfy others and convince them to let it be put in...
Stephen
-
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/
-
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/