Date: Sun, 30 Nov 1997 21:14:18 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Terry Lambert <tlambert@primenet.com> Cc: dk+@ua.net, proff@iq.org, freebsd-hackers@freebsd.org Subject: Re: detecting devfs from userland? Message-ID: <Pine.BSF.3.95.971130210818.10375B-100000@current1.whistle.com> In-Reply-To: <199712010404.VAA03532@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971130210818.10375B-100000>