From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 22 08:54:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5816D1065672 for ; Tue, 22 Sep 2009 08:54:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id CAD958FC12 for ; Tue, 22 Sep 2009 08:54:02 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8M8rlpU034431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 11:53:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8M8rleV043585; Tue, 22 Sep 2009 11:53:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8M8rkNX043584; Tue, 22 Sep 2009 11:53:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Sep 2009 11:53:46 +0300 From: Kostik Belousov To: Igor Sysoev Message-ID: <20090922085346.GR47688@deviant.kiev.zoral.com.ua> References: <20090917101526.GF57619@rambler-co.ru> <4AB2B7A1.5000601@delphij.net> <20090918074027.GI47688@deviant.kiev.zoral.com.ua> <20090921111245.GB23958@rambler-co.ru> <20090921112909.GQ47688@deviant.kiev.zoral.com.ua> <20090922072848.GA727@rambler-co.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lxy5y0HlI/3yLyUE" Content-Disposition: inline In-Reply-To: <20090922072848.GA727@rambler-co.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: fcntl(F_RDAHEAD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:54:03 -0000 --Lxy5y0HlI/3yLyUE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > On Mon, Sep 21, 2009 at 03:12:45PM +0400, Igor Sysoev wrote: >=20 > > > > 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. > > >=20 > > > We can change > > > int f_seqcount; > > > to > > > u_int f_seqcount; > > >=20 > > > and can use highest bit instead of O_READAHEAD: anyway f_seqcount is = shifted > > > to 16 bits left. > >=20 > > Or do the same trick as was done for FHASLOCK and override some flag th= at > > is not saved after open, see FMASK. > >=20 > > 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]. >=20 > 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. --Lxy5y0HlI/3yLyUE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq4kJoACgkQC3+MBN1Mb4hNrwCgn7tc4ZYBPMRcItKYiMwgVIlX zw4AoIBPDroFiC50HGpRhvIcljRvmhFB =dfu4 -----END PGP SIGNATURE----- --Lxy5y0HlI/3yLyUE--