We are, or at least, I am, investigating this question purely on
technical grounds - name calling is a noop. I'd be happy to find a
real reason why this is a bad idea but so far none has been
presented.
Don't get me wrong, the fact that people I respect have reservations
about the idea does mean something to me, but this still needs to be
investigated properly. Now on to the technical content...
> > > 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.
Readdir fills in a directory type, so ls sees it as a directory and does
the right thing. On the other hand, we know we're on a device
filesystem so we will next open the name as a regular file, and find
ISCHR or ISBLK: good.
The rule for this filesystem is: if you open with O_DIRECTORY then
directory operations are permitted, nothing else. If you open without
O_DIRECTORY then directory operations are forbidden (as
usual) and normal device semantics apply.
If there is weirdness anywhere, it's right here with this rule. The
question is: what if anything breaks?
> > > 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.
Here, we obey this rule: if you open it with O_DIRECTORY then you
can't read from or write to it.
> > > 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..
No, you have to open it without O_DIRECTORY to get your device
fd handle.
> How I'm supposed to list it's contents? open+readdir?
Nothing breaks here, ls works as it always did.
This is what ls does:
open("foobar", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(0x3, 0x2, 0x1, 0x2) = -1 ENOSYS (Function not implemented)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805b000) = 0x805b000
getdents64(0x3, 0x8058270, 0x1000, 0x26) = -1 ENOSYS (Function not implemented)
getdents(3, /* 2 entries */, 2980) = 28
getdents(3, /* 0 entries */, 2980) = 0
close(3) = 0
Note that ls doesn't do anything as inconvenient as opening
foobar as a normal file first, expecting that operation to fail.
> 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?.
No, you would get side effects only if you open as a regular file.
I'd agree that that sucks, but that's not what we're trying to fix
just now.
> And you call that sane???
I would hope it seems saner now, after the clarification.
Please, if you know something that actually breaks, tell me.
-- Daniel - 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/