>>>> For the flag changes, I'd add O_ALT_IO and O_OTHER [...]
>>> I see no well-defined meaning for what these flags do.  [...]
>> The ALT_IO case, at least, specifies that "file-system-specific
>> alternate semantics" are to be used.  Since these are file-system
>> specific, defining them specifically in a generic header file
>> doesn't even make sense.
> That's precisely the point.  It looks to me like you're trying to
> create some `generic' interface where it simply isn't appropriate.
> FS-specific ioctl(2)s could easily handle this operation, without
> needing to `infect' the VFS interface at all.

I can't see how.  Based on the discussion I saw (didn't you see it too?
you may want to check the archives), the need this interface is
designed to meet is to have a way to mark a file descriptor (not the
object it references) such that the read() and write() family of calls
behave differently, such as by accessing the underlying object on a
compressing or encrypting filesystem.

The bits could be set via ioctl instead of fcntl/open, true, but since
by the nature of the need, they have to "infect" the VOP_* calls, this
doesn't buy anything significant that I can see - and costs another
syscall in what I suspect would be a common case (where it's known at
open() time that alternative semantics are desired).

I'd still rather have at least a char (preferably an int) of
information, not just two or three bits, but shrug.

If you wish to argue that this need shouldn't be met in-tree, or if you
have another way of meeting it you believe would be cleaner, fine.  But
that's not what I see you as saying.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B