Date: Tue, 05 Jan 1999 18:20:17 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <20480.915556817@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 05 Jan 1999 23:10:30 %2B0800." <199901051510.XAA21446@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199901051510.XAA21446@spinner.netplex.com.au>, Peter Wemm writes:
> For devd to be optional, then the kernel needs to help a little so
> that /etc/rc can do enough to result in a sane and workable
> system. Otherwise, devd isn't going to have a clue what a "blurf"
> device is when it gets loaded or appears on a dynamic bus.
Don't you mix things here ?
If you don't have a devd running you may not know what class a device
wants to belong to, but since this is intended only for "otherwise
limited functionality", ie embedded or chroot environments I don't think
that is a big problem.
If you have a devd it needs to be able to figure out which class a
particular device belongs to.
I either case I can't see why the kernel part of devfs should know and
communicate more than the name and the class. All the sysctl stuff
seems superfluous to me. How will you handle the case of chroot
with a different policy with a sysctl anyway ? If anything it would
have to be (per) mount options, but all I can see it would be is
a "devd-lite-in-the-kernel" which is not very useful as I see it...
> Other important classes are that spring to mind: cua (quite
> different to tty), "tape" (different to disk). There are some
> others that are not so clear, the floppy and cdrom being one. Are
> they a "disk" or "console related"?
Which is why I would rather have the classes not even exist in the kernel,
but be expressed by a file in userland. I don't see much benefit for
the kernel knowing...
> Implementing class support in the kernel should be almost trivial
> compared to the devfs task itself.
No, actually not.
> An additional concern.. There are two types of persistence.. The
> first is persistence across reboot (IMHO, this is not needed with a
> decent backing infrastructure).
> The second is persistence across add/remove of nodes during the time
> the machine is up (eg: usb devices, partition/ slices that change on
> removable media or as a result of partitioning). The second would
> be sort-of covered by devd, as long as the config file was edited in
> advance.
Well, I think we should try to keep the two terms "policy" and "persistence"
covering two different concepts:
policy: A stated intent of permissions (and possibly actions) relating
to a well defined (but possibly instance wildcarded) set of nodes.
(your second item)
persistence: "random" changes to the permissions (or
nodes/links/symlinks/directories created/deleted) by an authorized
user which supersede the applicable policy. (your first item)
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20480.915556817>