From owner-freebsd-hackers Wed Apr 2 10:32:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA14895 for hackers-outgoing; Wed, 2 Apr 1997 10:32:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA14881 for ; Wed, 2 Apr 1997 10:32:06 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13944; Wed, 2 Apr 1997 11:13:45 -0700 From: Terry Lambert Message-Id: <199704021813.LAA13944@phaeton.artisoft.com> Subject: Re: devfs To: avalon@coombs.anu.edu.au (Darren Reed) Date: Wed, 2 Apr 1997 11:13:45 -0700 (MST) Cc: jkh@time.cdrom.com, proff@suburbia.net, hackers@FreeBSD.org In-Reply-To: <199704021415.GAA01403@freefall.freebsd.org> from "Darren Reed" at Apr 3, 97 00:10:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > if only name & permission persistance is sought, why can't devfs inherit > permissions from /dev and just change major/minor #'s (or is persistance > required there too) ? 1) What do you do with a "persistance" record for a pluggable (PCMCIA, etc.) device that is not currently present? 2) This requires that you maintain specfs for normal FS's. One of the main benefits of a devfs is that I can mount my root NFS from a system which does not support FreeBSD's bizarre idea of the number of bits in a major and minor number. Like, oh, all of them but FreeBSD. 3) This requires that the root FS be writeable. This is unsuitable for embedded applications, POS systems, and NC systems, among other applications. > maybe mounting devfs needs to be a boot "procedure" where name->permissions > ownership is transfered from /dev to /devices. Hmmm, what if /dev was a > sym. link to /dev.old (or was reset to that at boot time), then after > the devfs block was mounted under /devices and attributes transfered, > changed to point to /devices ? This persistance crap is just crap. If people cared about it, it should be possible to simply add an ioctl() that would return the location in KVM of the entry which created the devfs entry you are interested in changing, and then mung the real kernel image at that offset for the struct entries mode_t, uid_t, and gid_t to implement "persistance" as a permanent change to boot image data instead of something that's stored seperately from the kernel, for no good reason. The problem is that the people who care about persistance aren't the people writing the code -- the same problem FreeBSD has always had with IDE device, floppy tape devices, and anything else that works fine in another free OS but not in FreeBSD. If FreeBSD is to act historically consistent, then it would integrate devfs, and let the people who cared about persistance of permissions other than the default, either submit patches for the default values set on device registration (losing the need for persistance) or they can implement persistance and submit it on their own. If this doesn't seem to be a good idea, then getting rid of netiso was probably a bad idea with exactly the same character. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.