fcntl(F_RDAHEAD)

[Igor Sysoev]

On Tue, Sep 22, 2009 at 11:53:46AM +0300, Kostik Belousov wrote:

> 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.

Well, I think O_CREAT or O_TRUNC are good candidate to be an alias
for O_READAHEAD.


-- 
Igor Sysoev
http://sysoev.ru/en/