From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com ([209.85.214.194]:45612 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387441AbeKFHke (ORCPT ); Tue, 6 Nov 2018 02:40:34 -0500 Received: by mail-pl1-f194.google.com with SMTP id o19-v6so5115986pll.12 for ; Mon, 05 Nov 2018 14:18:41 -0800 (PST) From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B92017BB-76B3-4906-AD6F-13E995BDDE12"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH 08/20] ext4: Remove direct usage of fiemap_extent_info Date: Mon, 5 Nov 2018 15:13:36 -0700 In-Reply-To: <20181030131823.29040-9-cmaiolino@redhat.com> Cc: Linux FS-devel Mailing List , Eric Sandeen , Christoph Hellwig , Dave Chinner , darrick.wong@oracle.com To: Carlos Maiolino References: <20181030131823.29040-1-cmaiolino@redhat.com> <20181030131823.29040-9-cmaiolino@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Apple-Mail=_B92017BB-76B3-4906-AD6F-13E995BDDE12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 30, 2018, at 7:18 AM, Carlos Maiolino = wrote: >=20 > struct fiemap_extent_info will be gone in later patches, remove its = direct usage > from Ext4. >=20 > Signed-off-by: Carlos Maiolino > --- > fs/ext4/ext4.h | 2 +- > fs/ext4/extents.c | 19 ++++++++++--------- > fs/ext4/inline.c | 7 ++++--- > 3 files changed, 15 insertions(+), 13 deletions(-) >=20 > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > index acc1ea0e9f40..c7ad6db930f5 100644 > --- a/fs/ext4/ext4.h > +++ b/fs/ext4/ext4.h > @@ -3023,7 +3023,7 @@ extern struct buffer_head = *ext4_get_first_inline_block(struct inode *inode, > struct ext4_dir_entry_2 = **parent_de, > int *retval); > extern int ext4_inline_data_fiemap(struct inode *inode, > - struct fiemap_extent_info *fieinfo, > + struct fiemap_ctx *f_ctx, > int *has_inline, __u64 start, __u64 = len); >=20 > struct iomap; > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index d52aafc34e25..11ee46aff677 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -2151,7 +2151,7 @@ int ext4_ext_insert_extent(handle_t *handle, = struct inode *inode, >=20 > static int ext4_fill_fiemap_extents(struct inode *inode, > ext4_lblk_t block, ext4_lblk_t num, > - struct fiemap_extent_info *fieinfo) > + struct fiemap_ctx *f_ctx) > { > struct ext4_ext_path *path =3D NULL; > struct ext4_extent *ex; > @@ -2277,7 +2277,8 @@ static int ext4_fill_fiemap_extents(struct inode = *inode, > } >=20 > if (exists) { > - err =3D fiemap_fill_next_extent(fieinfo, > + err =3D fiemap_fill_next_extent( > + (struct fiemap_extent_info = *)f_ctx->fc_data, No need to cast void pointer. This also makes me wonder why you didn't = name fc_data as fc_extent_info instead of making it a void pointer? I didn't = see any users where it isn't a pointer to struct fiemap_extent_info? The same is true of all the other filesystem-specific patches - there is = no need to cast from a void *. Is there a later user where this is used as = a generic data pointer, or is it always going to be a fiemap_extent_info, = and later a fiemap_ctx structure? > @@ -5040,14 +5041,14 @@ static int ext4_xattr_fiemap(struct inode = *inode, > } >=20 > if (physical) > - error =3D fiemap_fill_next_extent(fieinfo, 0, physical, > - length, flags); > + error =3D fiemap_fill_next_extent( > + (struct fiemap_extent_info *)f_ctx->fc_data, Same... > diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c > index 9c4bac18cc6c..7b9b0da60d54 100644 > --- a/fs/ext4/inline.c > +++ b/fs/ext4/inline.c > @@ -1888,8 +1888,9 @@ int ext4_inline_data_fiemap(struct inode *inode, > physical +=3D offsetof(struct ext4_inode, i_block); >=20 > if (physical) > - error =3D fiemap_fill_next_extent(fieinfo, start, = physical, > - inline_len, flags); > + error =3D fiemap_fill_next_extent( > + (struct fiemap_extent_info *)f_ctx->fc_data, Same... Cheers, Andreas --Apple-Mail=_B92017BB-76B3-4906-AD6F-13E995BDDE12 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAlvgwJAACgkQcqXauRfM H+AgFA/9FexZ8ltXSV2QcVxuxrfoagpxB6Ut28PetV0tUXg04Yq+l5WlnV3grpK+ 5Wv17yCVYPp72rNvKGxT38ThcMN37yZpyoOBXiWMqNCWiQrDmdUAf+qa8ODGiWam tp5vsFV6omPpO8dz6+9t5vAGWcWr2euGldqJI7p14cUX8NeafMP35ic25mrW+wWD po9nn74lsgYvXh7LAZ/Xv41dG++cOHkiurUtTE502LEHaUpJkbkWo4IywbRSFrjq 0+THJDvOThFDK3HfwKkvWiIbuBME85jpkcLicVF/McQsJkFVa3zi2MGdHv/0Bf3V uZzTNPpdWc8Op4d9uHN85SH/GwHva3871gDNOjfyrVwpACrQR37kuxScMRvUp93M lwu2USWVcjnog50c4h5FUb0RhI5dmssLGk07Xb3Ub7mWDxrYlU+VmghxDaMobdiI +XDch5hKnxjquR/AlHXiTYc1Fc9oLOIrfs9i83LiTvKNSC4um6qgdbE+g6qFdd/3 EupyQOqHIGsbJ8BfjnZRHm3sO+eDLjJbB0nWNMRyivfP7KYdFYz1gqPmHr3kL53B bkFaJCdjWGWf7q56jBYN/MbDss3oRw5CORw5XxhnX9VSjX1bFcW0WqeKA3dUXJyf cNne2nKj33OuHQy6ixKbi46qJ5zAYIARXxMJaFnQeTEnnifq5CA= =X2Sf -----END PGP SIGNATURE----- --Apple-Mail=_B92017BB-76B3-4906-AD6F-13E995BDDE12--