From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> To: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, "prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org" <prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>, Robin Murphy <Robin.Murphy-5wv7dgnIgG8@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org> Subject: Re: [PATCH 1/4] iommu: introduce generic page table allocation framework Date: Mon, 1 Dec 2014 13:53:37 +0000 [thread overview] Message-ID: <20141201135337.GF18466@arm.com> (raw) In-Reply-To: <12888062.XNeNCOOP61@avalon> On Mon, Dec 01, 2014 at 01:33:09PM +0000, Laurent Pinchart wrote: > On Monday 01 December 2014 12:13:38 Will Deacon wrote: > > On Sun, Nov 30, 2014 at 10:00:21PM +0000, Laurent Pinchart wrote: > > > On Thursday 27 November 2014 11:51:15 Will Deacon wrote: > > > > diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c > > > > new file mode 100644 > > > > index 000000000000..82e39a0db94b > > > > --- /dev/null > > > > +++ b/drivers/iommu/io-pgtable.c > > > > @@ -0,0 +1,71 @@ > > > > +/* > > > > + * Generic page table allocator for IOMMUs. > > > > + * > > > > + * This program is free software; you can redistribute it and/or modify > > > > + * it under the terms of the GNU General Public License version 2 as > > > > + * published by the Free Software Foundation. > > > > + * > > > > + * This program is distributed in the hope that it will be useful, > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > > + * GNU General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU General Public License > > > > + * along with this program; if not, write to the Free Software > > > > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA > > > > 02111-1307, USA. > > By the way you can remove this paragraph, we don't want to update all source > files the day the FSF decides to move to a new address. Yeah, I missed that one (I fixed the lpae file already). > > > > diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h > > > > new file mode 100644 > > > > index 000000000000..5ae75d9cae50 > > > > --- /dev/null > > > > +++ b/drivers/iommu/io-pgtable.h > > > > @@ -0,0 +1,65 @@ > > > > +#ifndef __IO_PGTABLE_H > > > > +#define __IO_PGTABLE_H > > > > + > > > > +struct io_pgtable_ops { > > > > + int (*map)(struct io_pgtable_ops *ops, unsigned long iova, > > > > > > How about passing a struct io_pgtable * instead of the ops pointer ? This > > > would require returning a struct io_pgtable from the alloc function, which > > > I suppose you didn't want to do to ensure the caller will not touch the > > > struct io_pgtable fields directly. Do we really need to go that far, or > > > can we simply document struct io_pgtable as being private to the pg alloc > > > framework core and allocators ? Someone who really wants to get hold of > > > the io_pgtable instance could use container_of on the ops anyway, like > > > the allocators do. > > > > Hmm, currently the struct io_pgtable is private to the page table allocator, > > so I don't like the IOMMU driver having an explicit handle to that. > > I agree with this, but given that struct io_pgtable is defined in a header > used by the IOMMU driver, and given that it directly embeds struct > io_pgtable_ops, there's no big difference between the two structures. Right, but you have to do an explicit container_of and, with the kerneldoc added, it should be clear that it's not a good idea to mess with things like the cookie or the cfg after you've allocated the page tables. > > I also like having the value returned from alloc_io_pgtable_ops being used > > as the handle to pass around -- it keeps things simple for the caller > > because there's one structure that you get back and that's the thing you use > > as a reference. > > I agree with that as well, my proposal was to return a struct io_pgtable from > alloc_io_pgtable_ops. > > > What do we gain by returning the struct io_pgtable pointer instead? > > The ops structure could be made a const pointer. That's a pretty small > optimization, granted. I still think I'd rather keep things like they are. Let's see how it looks in v2, when I've reordered the structures and documented them. Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/4] iommu: introduce generic page table allocation framework Date: Mon, 1 Dec 2014 13:53:37 +0000 [thread overview] Message-ID: <20141201135337.GF18466@arm.com> (raw) In-Reply-To: <12888062.XNeNCOOP61@avalon> On Mon, Dec 01, 2014 at 01:33:09PM +0000, Laurent Pinchart wrote: > On Monday 01 December 2014 12:13:38 Will Deacon wrote: > > On Sun, Nov 30, 2014 at 10:00:21PM +0000, Laurent Pinchart wrote: > > > On Thursday 27 November 2014 11:51:15 Will Deacon wrote: > > > > diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c > > > > new file mode 100644 > > > > index 000000000000..82e39a0db94b > > > > --- /dev/null > > > > +++ b/drivers/iommu/io-pgtable.c > > > > @@ -0,0 +1,71 @@ > > > > +/* > > > > + * Generic page table allocator for IOMMUs. > > > > + * > > > > + * This program is free software; you can redistribute it and/or modify > > > > + * it under the terms of the GNU General Public License version 2 as > > > > + * published by the Free Software Foundation. > > > > + * > > > > + * This program is distributed in the hope that it will be useful, > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > > + * GNU General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU General Public License > > > > + * along with this program; if not, write to the Free Software > > > > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA > > > > 02111-1307, USA. > > By the way you can remove this paragraph, we don't want to update all source > files the day the FSF decides to move to a new address. Yeah, I missed that one (I fixed the lpae file already). > > > > diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h > > > > new file mode 100644 > > > > index 000000000000..5ae75d9cae50 > > > > --- /dev/null > > > > +++ b/drivers/iommu/io-pgtable.h > > > > @@ -0,0 +1,65 @@ > > > > +#ifndef __IO_PGTABLE_H > > > > +#define __IO_PGTABLE_H > > > > + > > > > +struct io_pgtable_ops { > > > > + int (*map)(struct io_pgtable_ops *ops, unsigned long iova, > > > > > > How about passing a struct io_pgtable * instead of the ops pointer ? This > > > would require returning a struct io_pgtable from the alloc function, which > > > I suppose you didn't want to do to ensure the caller will not touch the > > > struct io_pgtable fields directly. Do we really need to go that far, or > > > can we simply document struct io_pgtable as being private to the pg alloc > > > framework core and allocators ? Someone who really wants to get hold of > > > the io_pgtable instance could use container_of on the ops anyway, like > > > the allocators do. > > > > Hmm, currently the struct io_pgtable is private to the page table allocator, > > so I don't like the IOMMU driver having an explicit handle to that. > > I agree with this, but given that struct io_pgtable is defined in a header > used by the IOMMU driver, and given that it directly embeds struct > io_pgtable_ops, there's no big difference between the two structures. Right, but you have to do an explicit container_of and, with the kerneldoc added, it should be clear that it's not a good idea to mess with things like the cookie or the cfg after you've allocated the page tables. > > I also like having the value returned from alloc_io_pgtable_ops being used > > as the handle to pass around -- it keeps things simple for the caller > > because there's one structure that you get back and that's the thing you use > > as a reference. > > I agree with that as well, my proposal was to return a struct io_pgtable from > alloc_io_pgtable_ops. > > > What do we gain by returning the struct io_pgtable pointer instead? > > The ops structure could be made a const pointer. That's a pretty small > optimization, granted. I still think I'd rather keep things like they are. Let's see how it looks in v2, when I've reordered the structures and documented them. Will
next prev parent reply other threads:[~2014-12-01 13:53 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-11-27 11:51 [PATCH 0/4] Generic IOMMU page table framework Will Deacon 2014-11-27 11:51 ` Will Deacon [not found] ` <1417089078-22900-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-11-27 11:51 ` [PATCH 1/4] iommu: introduce generic page table allocation framework Will Deacon 2014-11-27 11:51 ` Will Deacon [not found] ` <1417089078-22900-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-11-30 22:00 ` Laurent Pinchart 2014-11-30 22:00 ` Laurent Pinchart 2014-12-01 12:13 ` Will Deacon 2014-12-01 12:13 ` Will Deacon [not found] ` <20141201121338.GD18466-5wv7dgnIgG8@public.gmane.org> 2014-12-01 13:33 ` Laurent Pinchart 2014-12-01 13:33 ` Laurent Pinchart 2014-12-01 13:53 ` Will Deacon [this message] 2014-12-01 13:53 ` Will Deacon 2014-12-14 23:46 ` Laurent Pinchart 2014-12-14 23:46 ` Laurent Pinchart 2014-12-15 9:45 ` Will Deacon 2014-12-15 9:45 ` Will Deacon 2014-11-27 11:51 ` [PATCH 2/4] iommu: add ARM LPAE page table allocator Will Deacon 2014-11-27 11:51 ` Will Deacon [not found] ` <1417089078-22900-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-11-30 23:29 ` Laurent Pinchart 2014-11-30 23:29 ` Laurent Pinchart 2014-12-01 17:23 ` Will Deacon 2014-12-01 17:23 ` Will Deacon [not found] ` <20141201172315.GI18466-5wv7dgnIgG8@public.gmane.org> 2014-12-01 20:21 ` Laurent Pinchart 2014-12-01 20:21 ` Laurent Pinchart 2014-12-02 9:41 ` Will Deacon 2014-12-02 9:41 ` Will Deacon [not found] ` <20141202094156.GB9917-5wv7dgnIgG8@public.gmane.org> 2014-12-02 11:47 ` Laurent Pinchart 2014-12-02 11:47 ` Laurent Pinchart 2014-12-05 18:48 ` Will Deacon 2014-12-05 18:48 ` Will Deacon 2014-12-02 22:41 ` Mitchel Humpherys 2014-12-02 22:41 ` Mitchel Humpherys [not found] ` <vnkw8uipznbj.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> 2014-12-03 11:11 ` Will Deacon 2014-12-03 11:11 ` Will Deacon 2014-12-05 10:55 ` Varun Sethi 2014-12-05 10:55 ` Varun Sethi [not found] ` <BN3PR0301MB12198CE5D736CDC6A221EDC2EA790-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org> 2014-12-05 18:48 ` Will Deacon 2014-12-05 18:48 ` Will Deacon [not found] ` <20141205184802.GH1203-5wv7dgnIgG8@public.gmane.org> 2014-12-14 17:45 ` Varun Sethi 2014-12-14 17:45 ` Varun Sethi [not found] ` <BN3PR0301MB1219D3161E4E9DB314FDD8FAEA6E0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org> 2014-12-15 13:30 ` Will Deacon 2014-12-15 13:30 ` Will Deacon [not found] ` <20141215133020.GJ20738-5wv7dgnIgG8@public.gmane.org> 2014-12-15 15:43 ` Will Deacon 2014-12-15 15:43 ` Will Deacon 2014-12-15 16:35 ` Varun Sethi 2014-12-15 16:35 ` Varun Sethi [not found] ` <BN3PR0301MB12194A8F5CFF870B7A124623EA6F0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org> 2014-12-15 17:25 ` Will Deacon 2014-12-15 17:25 ` Will Deacon 2014-12-15 16:43 ` Varun Sethi 2014-12-15 16:43 ` Varun Sethi [not found] ` <BN3PR0301MB12199C5CAD33E745CC7E51F4EA6F0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org> 2014-12-15 17:20 ` Will Deacon 2014-12-15 17:20 ` Will Deacon 2014-11-27 11:51 ` [PATCH 3/4] iommu: add self-consistency tests to ARM LPAE IO " Will Deacon 2014-11-27 11:51 ` Will Deacon 2014-11-27 11:51 ` [PATCH 4/4] iommu/arm-smmu: make use of generic LPAE allocator Will Deacon 2014-11-27 11:51 ` Will Deacon 2014-11-30 22:03 ` [PATCH 0/4] Generic IOMMU page table framework Laurent Pinchart 2014-11-30 22:03 ` Laurent Pinchart 2014-12-01 12:05 ` Will Deacon 2014-12-01 12:05 ` Will Deacon [not found] ` <20141201120534.GC18466-5wv7dgnIgG8@public.gmane.org> 2014-12-02 13:47 ` Laurent Pinchart 2014-12-02 13:47 ` Laurent Pinchart 2014-12-02 13:53 ` Will Deacon 2014-12-02 13:53 ` Will Deacon [not found] ` <20141202135356.GF9917-5wv7dgnIgG8@public.gmane.org> 2014-12-02 22:29 ` Laurent Pinchart 2014-12-02 22:29 ` Laurent Pinchart 2014-12-14 23:49 ` Laurent Pinchart 2014-12-14 23:49 ` Laurent Pinchart 2014-12-15 16:10 ` Will Deacon 2014-12-15 16:10 ` Will Deacon [not found] ` <20141215161052.GM20738-5wv7dgnIgG8@public.gmane.org> 2014-12-15 17:33 ` Laurent Pinchart 2014-12-15 17:33 ` Laurent Pinchart 2014-12-15 17:39 ` Will Deacon 2014-12-15 17:39 ` Will Deacon [not found] ` <20141215173911.GT20738-5wv7dgnIgG8@public.gmane.org> 2014-12-15 17:46 ` Laurent Pinchart 2014-12-15 17:46 ` Laurent Pinchart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20141201135337.GF18466@arm.com \ --to=will.deacon-5wv7dgnigg8@public.gmane.org \ --cc=Robin.Murphy-5wv7dgnIgG8@public.gmane.org \ --cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.