On Wed, 30 Jun 1999, Ted Lemon wrote:

> Nitpicking once again, why not just use an fcntl to control this
> behaviour?

On 30 Jun 1999, Chris G. Demetriou wrote:

> Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> > Thoughts?
> 
> Why would extra flags to open()/fcntl(F_[GS]ETFL,...) be the wrong
> thing?

fcntl maybe....

> At least naively, i'd think that they'd be the right place to put the
> information, for a couple of reasons:
> 
> 	* you can still have an application support multiple types of
> 	  access (if concurrent via multiple FDs, if serialized via
> 	  fcntl()).
> 
> 	* for many applications that want the 'alternate' operation,
> 	  it might be unreasonable to recode the application.  e.g.
> 	  for the compressing file system case, i could easily imagine
> 	  a "cat --flags fs_raw file" or something similar.  It seems
> 	  unwieldy to recode all of the I/O calls to cope with this
> 	  obvious case.
> 
> That, at least, seems to be the right way to get the 'alternate
> semantics' information into the kernel.  How to pass it around
> internally is less interesting to me (I'm not really a VFS guy 8-).

Well, since I'd be the one to pass it around, it's interesting to me. ;-)
This interface makes the application programmer do most all of the work.
It's exposing dofilewrite() & dofileread() to the userland application for
them to hang themselves with.

What would work would be to shove a flag or two into f_flags, and then
have the dofile{read,write} routines pass that down.

I'll play with that.

As to why I'd do things this way, I'm much more a kernel hacker and just
like to expose the kernel innards to programs. :-)

Take care,

Bill