Date: Fri, 22 Mar 1996 20:43:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: scott@statsci.com, terry@lambert.org, bde@zeta.org.au, current@freebsd.org, julian@ref.tfs.com, phk@critter.tfs.com, scrappy@ki.net Subject: Re: PATCH: small, syntax changes for devfs Message-ID: <199603230343.UAA04412@phaeton.artisoft.com> In-Reply-To: <199603230117.MAA00596@godzilla.zeta.org.au> from "Bruce Evans" at Mar 23, 96 12:17:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >This is really irrelevant to flat vs. non-flat name spaces. There is > >no reason why a device file can't be a directory and a file at the > >same time. Device reads and writes don't care about seek offsets > > The semantics aren't clear. wd0s1 would be a container for both > wd0s1[a-h] and the raw bytes on the device. I like ordinary read() > to work on directories. Bletch. How would I mark a file "Bruce can't see this when he iterates the directory" if I let you read the directory data? Or "This file is still here, but it has been marked deleted so that the user can use 'undelete' on it later because he's the kind of silly git who deletes first and thinks second". There's a lot of useful things you can do with directory data if it's considered opaque. Plus your application would need to have all sorts of hooks for each possible directory layout on disk -- that's exactly what getdirentries() is trying to avoid. Even if we bought into your idea, we could still have an ioctl() that means "convert this fd which is a directory reference in the devfs to point to a venode for a devices instead". Since the current utilities all operate on terminal devices instead of intermediate devices anyway, this wouldn't damage backward compatability. 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?199603230343.UAA04412>