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.
pgpk0vtRcEDpA.pgp
Description: PGP signature
