From owner-freebsd-hackers Sun Nov 30 21:24:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06003 for hackers-outgoing; Sun, 30 Nov 1997 21:24:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05984 for ; Sun, 30 Nov 1997 21:24:21 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA23995; Sun, 30 Nov 1997 21:16:41 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023993; Sun Nov 30 21:16:35 1997 Date: Sun, 30 Nov 1997 21:14:18 -0800 (PST) From: Julian Elischer To: Terry Lambert cc: dk+@ua.net, proff@iq.org, freebsd-hackers@freebsd.org Subject: Re: detecting devfs from userland? In-Reply-To: <199712010404.VAA03532@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 1 Dec 1997, Terry Lambert wrote: > > > 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. 4034972160 dr-xr-xr-x 4 root wheel 3283 Nov 30 20:52 /dev/. 2 drwxr-xr-x 19 root wheel 1024 Nov 27 00:07 /dev/.. now, for 16 points (and the car), can you tell me why I'd want to run dump/restore on a devfs? > > > > > 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... I think people expect to find their disk listed as: /dev/foobar3 not as /dev/disk/scsi3/unit3/lun2/partion4 > > > 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. heh! I'll show it to you tomorrow.. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >