Matthew Kirkwood wrote:
> That being the case, I'd rather that O_NONE just went away. I
> am unconvinced of its worth anyway.
Apparently it's used by fdformat and a few other small utils.
> > I don't think there would be many complaints if that were changed to
> > read _or_ write.
>
> The two options are basically orthogonal, though. I don't see
> any gain from combining them, especially when that just means
> an extra fcntl(F_SETFD) in the cases I want deferred open for.
>
> People who want both can specifc O_NONE|O_DEFEROPEN.
>
> Or did I miss something?
Well, nearly all the uses for O_DEFEROPEN seem to be the same as the
uses of O_NONE. Being able to do safe fstat()s without opening the
device, that sort of thing.
The only difference is the current ioctl behaviour for O_NONE, and the
fact that you can actually open an O_DEFEROPEN fd later.
But your deferred open could be made properly generic: Define F_REOPEN
to mean reopen this fd's object with new flags. It needn't be specific
to O_DEFEROPEN, and probably has a few uses. (Like just being able to
dup a file without sharing the file pointer and locks).
For the fstat() and fs-specific ioctl() type of thing, the current ioctl
behaviour for O_NONE isn't really right. For for fdformat it is right.
Your O_DEFEROPEN actually seems like the right thing in many cases, like
when you want to open a device file prior to fstat(), and you don't
really want to open the device.
Neither the current O_NONE nor O_DEFEROPEN implement another useful
case: provide an fd you can use fs-flag-setting ioctls on. E.g. that's
why you can't do chattr +i /dev/*.
It would be nice to provide all the useful facilities in the simplest
possible way. I think making O_NONE not open underlying devices but to
permit fs ioctls which could in principle be filename based anyway, and
F_REOPEN, gets very close to that. fdformat is solved by simply
providing an alternate device to open -- it works for not rewinding
tapes so there is a precedent.
-- Jamie
