Messages in this thread |  | | Date | Wed, 23 May 2001 06:19:25 +0200 | From | Edgar Toernig <> | Subject | Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup) |
| |
Daniel Phillips wrote: > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote: > > On Mon, 21 May 2001, Daniel Phillips wrote: > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > > > What I'd like to see: > > > > > > > > - An interface for registering an array of related devices > > > > (almost always two: raw and ctl) and their legacy device numbers > > > > with a single userspace callout that does whatever /dev/ creation > > > > needs to be done. Thus, naming and permissions live in user > > > > space. No "device node is also a directory" weirdness... > > > > > > Could you be specific about what is weird about it? > > > > *boggle* > > > >[general sense of unease]
I fully agree with Oliver. It's an abomination.
> > I don't think it's likely to be even workable. Just consider the > > directory entry for a moment - is it going to be marked d or [cb]? > > It's going to be marked 'd', it's a directory, not a file.
Aha. So you lose the S_ISCHR/BLK attribute.
> > If it doesn't have the directory bit set, Midnight commander won't > > let me look at it, and I wouldn't blame cd or ls for complaining. If it > > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > > million other programs if they did the wrong thing. They've had 30 > > years to expect that files aren't directories. They're going to act > > weird. > > No problem, it's a directory.
Directories are not allowed to be read from/written to. The VFS may support it, but it's not (current) UNIX.
> > Linus has been kicking this idea around for a couple years now and > > it's still a cute solution looking for a problem. It just doesn't > > belong in UNIX. > > Hmm, ok, do we still have any *technical* reasons?
So with your definition, I have a fs-object that is marked as a directory but opening it opens a device. Pretty nice. How I'm supposed to list it's contents? open+readdir? But the open has nasty side effects. So you have a directory that you are not allowed to list (because of the possible side effects) but is allowed to be read from/written to maybe even issue ioctls to?. And you call that sane???
IMO the whole idea of arguments following the device name is junk (incl a "/ctrl").
Just think about the implications of the original "/dev/ttyS0/19200" suggestion. It sounds nice and tempting. But which programs will benefit. Which gets confused. What will be cleaned up. After some thoughts you'll find out that it's useless ;-)
And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl): This _may_ work for some kind of devices. But serial ports are one example where it simply will _not_. It requires that you know the name of the device. For ttys this is often not the case. Even if you manage to get some name for stdin for example - now I should simply attach a "ctrl" to that name to get a control channel??? At least dangerous. If I'm lucky I only get an EPERM...
Ciao, ET.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |