From owner-freebsd-current Fri Jul 26 12:04:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16759 for current-outgoing; Fri, 26 Jul 1996 12:04:28 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA16754 for ; Fri, 26 Jul 1996 12:04:26 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA18686; Fri, 26 Jul 1996 14:03:53 -0500 From: Joe Greco Message-Id: <199607261903.OAA18686@brasil.moneng.mei.com> Subject: Re: cvs commit: src/sys/dev/ccd ccd.c src/sys/dev/vn vn.c src/sys/sys conf.h src/sys/i386/isa fd.c mcd.c scd.c wcd.c wd.c wt.c s To: wollman@lcs.mit.edu (Garrett Wollman) Date: Fri, 26 Jul 1996 14:03:53 -0500 (CDT) Cc: current@freebsd.org, imp@village.org, jkh@time.cdrom.com In-Reply-To: <9607261843.AA05293@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 96 02:43:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > < said: > > > I don't have anything useful to suggest other than to note that Sun took the > > easy way out of this problem by implementing a "devfs-on-ufs", i.e. they use > > UFS and have a procedure for "automatically" creating new instances of > > devices. > > Well, perhaps this is an indication of the correct way to implement > persistence. Uh, no. I should have mentioned, also, that it's done as symlinks into a botched and bizarre /devices hierarchy that causes no end of grief when you switch slots, etc... I was just bi***ing about how NOT to do it. :-) > Filesystems keep device nodes as they currently exist, > but they don't actually do anything---they are just place-holders that > return ENXIO or some such if you try to do anything to them. > However, if a devfs layer is stacked on top of a directory containing > such a node, then the devfs hides any device nodes that are not > available in the running system, and ``adopts'' the permissions of the > underlying nodes for its own local devices. That way, upgrading an > old system to devfs would Just Work. Attempts to change the > permissions of a node would cause a new node to be created in the > underlying filesystem, and the permissions changed on that, as well. > This fixes the persistence problem, leverages our stackable filesystem > infrastructure in a useful way, and makes devices work again over > NFS. (This wouldn't support renaming of devices, but I don't know if > that's at all useful if we have symbolic links instead.) > > Julian, does this sound reasonable to you? So, what you're saying is, sort of a strange union mount where the "devfs" overlays /dev. /dev contains the permissions, symlinks for aliases, owners, etc. "devfs" obscures nonexistent devices.. and also creates devices that do not exist in the underlying layer that do exist.. Wow, I don't see a problem.. that does actually sound workable. Unfortunately I don't have the time or knowledge to code something of this complexity :-( ... JG