Subject: Re: fcntl changes once again.
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 07/13/1999 15:38:30
>>>> 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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B