Date: Fri, 26 Jul 1996 14:03:53 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: wollman@lcs.mit.edu (Garrett Wollman) Cc: current@freebsd.org, imp@village.org, jkh@time.cdrom.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 Message-ID: <199607261903.OAA18686@brasil.moneng.mei.com> In-Reply-To: <9607261843.AA05293@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 96 02:43:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Fri, 26 Jul 1996 13:30:33 -0500 (CDT), Joe Greco <jgreco@brasil.moneng.mei.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607261903.OAA18686>