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

Groups > linux.kernel > #1421036 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

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.

[toc] | [next] | [standalone]

#1421073

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web