From owner-freebsd-arch Tue Jan 5 09:26:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09402 for freebsd-arch-outgoing; Tue, 5 Jan 1999 09:26:42 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09397 for ; Tue, 5 Jan 1999 09:26:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA18925 for ; Tue, 5 Jan 1999 18:26:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA16093 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 18:26:12 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA08975 for ; Tue, 5 Jan 1999 09:21:24 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id SAA20482 for ; Tue, 5 Jan 1999 18:20:18 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Tue, 05 Jan 1999 23:10:30 +0800." <199901051510.XAA21446@spinner.netplex.com.au> Date: Tue, 05 Jan 1999 18:20:17 +0100 Message-ID: <20480.915556817@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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