From owner-freebsd-hackers Sun Nov 30 20:04:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA00628 for hackers-outgoing; Sun, 30 Nov 1997 20:04:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA00622 for ; Sun, 30 Nov 1997 20:04:53 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id VAA07054; Sun, 30 Nov 1997 21:09:59 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd007037; Sun Nov 30 21:09:57 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id VAA03532; Sun, 30 Nov 1997 21:04:10 -0700 (MST) From: Terry Lambert Message-Id: <199712010404.VAA03532@usr09.primenet.com> Subject: Re: detecting devfs from userland? To: julian@whistle.com (Julian Elischer) Date: Mon, 1 Dec 1997 04:04:10 +0000 (GMT) Cc: tlambert@primenet.com, dk+@ua.net, proff@iq.org, freebsd-hackers@freebsd.org In-Reply-To: from "Julian Elischer" at Nov 28, 97 10:10:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You can do the same thing by doing a stat of /dev and looking > > for an st_ino of 2. > > actually no, as the root ino in devfs is not 2, and the ino for .. > IS 2 regardless of what FS it is.. The ino for the root directory (.) in any FS should be 2. This is part and parcel of making the backup/restore utilities work. > > The devices themselves, especially in the new SLICE stuff that > > he's done, should be self-referrential. I'm still trying to > > talk him into putting them in a hierarchy (with little success... > > you SVR4 device name traditionalists can rest easy: you still get > > you have your long cryptic device names for now...). > > A hierarchy is good but has the following problems > > 1/ violates "Principle of least surprise" (POLS) I disagree (big surprise ;-)). I think /dev/sd1c1d2t0 violates the principle... At least with a hierarchy, you get a hierarchy in /dev that matches the hierarchy on disk. Better to have a valid map with a "you are here.." than an invalid map, IMO... > 2/ if you have /dev/disk/sd0/slice1/partA, then how do you access > /dev/disk/sd0? because htat is a directory. You make a distinction between VOP_READWRITE nad VOP_READDIR. This is a pretty trival distinction to make, since you don't allow directories, per se, in devfs, without them being parent devices. That naming is pretty bad, BTW. ;-). > you need to either: > (A) make devfs allow devices to respond to directory operations.. > and therefore confuse everybody.. Not really... it's pretty obvious that subdirectories = subdevices. Both have "sub" in them... > "hey if /dev/disk/sd0 is a device, how can /dev/disk/sd0/slice1 exist?" The better question is "how can '/dev/disk/sd0' exist". The answer is that each parent is also a device. The devfs is *not* a normal FS; we already knew this, > /dev/disk/sd0/slice1 > /dev/disk/sd0/slice1/all <--device I dislike this distinction. Any time you make aliases, you damage the model (the same reason I'm against links in devfs). > If objection 1 violates POLS, then solution (A) REALLY violates it, > though if we were designing a new OS that's what I would do. > (it's easy to do) I don't think your "if" is true, so your "then" isn't true, either. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.