fcntl(F_RDAHEAD)

[Kostik Belousov]

On Tue, Sep 22, 2009 at 11:28:48AM +0400, Igor Sysoev wrote:
> On Mon, Sep 21, 2009 at 02:29:09PM +0300, Kostik Belousov wrote:
> 
> > On Mon, Sep 21, 2009 at 03:12:45PM +0400, Igor Sysoev wrote:
> 
> > > > What I dislike about the patch is the new kernel-private flag that is
> > > > eaten from the open(2) flags namespace. We do already have FHASLOCK,
> > > > so far the only such flag.
> > > 
> > > We can change
> > >   int    f_seqcount;
> > > to
> > >   u_int  f_seqcount;
> > > 
> > > and can use highest bit instead of O_READAHEAD: anyway f_seqcount is shifted
> > > to 16 bits left.
> > 
> > Or do the same trick as was done for FHASLOCK and override some flag that
> > is not saved after open, see FMASK.
> > 
> > Or split f_seqcount into two u_short fields, one for f_seqcount, second for
> > f_kflag, and use the later for FHASLOCK and FREADAHEAD. [We are trying to
> > not grow struct file unless absolutely neccessary].
> 
> I agree that struct file should not grow (at least in this case).
> However, I believe splitting f_seqcount into two fields will break
> kernel ABI. Or not ? I think f_seqcount should be splitted in 9-CURRENT
> and probably, in 8-STABLE, but in 7-STABLE we may use the open(2) flags
> namespace.

The struct file indeed participates in the KBI, in particular, pointer
to it is supplied as an argument to VOP_OPEN() and d_fdopen(). On the
other hand, it is assumed that drivers and fses use it to override
f_ops and possibly f_data. f_seqcount status is internal VFS field that
probably should be not accessed or modified by driver or fs.

Reason to try hard to keep layout of struct file intact even between major
branches is the userspace compatibility, with the code of lsof and fstat.
Might be, fstat will be improved to not require this.

Probably, best temporal solution would be to override some flag used
only for open(2), postponing the task of separating bit- and name-spaces
for other day. Also, it makes merge to 8 and 7 easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090922/d6fd7b5c/attachment.pgp