Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1421073

Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs

From "Luis R. Rodriguez" <mcgrof@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs
Date 2016-06-13 19:50 +0200
Message-ID <rJE9P-11j-7@gated-at.bofh.it> (permalink)
References <rIrHH-3il-3@gated-at.bofh.it> <rIrRo-3lN-31@gated-at.bofh.it> <rIvUZ-5O9-17@gated-at.bofh.it> <rJCB3-bq-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Jun 13, 2016 at 09:00:41AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote:
> > Do we not expect the number of argument to grow ? This "cleanup" would
> > do away with such possibilities, and then require adding the API later,
> > and this requiring a full set of collateral evolutions again when this
> > is needed. What was the original motivation for using this instead of
> > the approach you are suggesting ?
> 
> We still got plenty of space for attrs.  If you're worried about running
> out of 32 flags we could do a dma_attrs_t typedef that we could swich
> to a u64.  That would have another advantage in that we could add a
> __bitwise sparse annotation to avoid people passing the wrong kind of
> flags.

History shows only sparse use of extensions of these these attributes so I
think the approach with a typedef is definitely more suitable for this API, and
should last long enough. The added gain of the annotation is a nice bonus.

  Luis

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs Christoph Hellwig <hch@infradead.org> - 2016-06-13 18:10 +0200
  Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-06-13 19:50 +0200

csiph-web