[alsa-devel] [PATCH v4 4/6] core: add API header and driver header files

[Takashi Iwai]

At Tue, 13 Dec 2011 19:21:30 +0530,
Nallasellan, Singaravelan wrote:
> 
> > > > +	size_t buffer_size;
> > > > +	size_t fragment_size;
> > > Can we define buffer_size and fragment_size as unsigned items?
> > 
> > size_t is unsigned.
> > 
> > But, it needs consideration whether size_t is the best choice, since size_t is basically
> > a long, thus its size is different between 32bit and 64bit architectures.  This may lead
> > to mess in many cases when you think of overlapping.
> > 
> Sorry for my mess on size_t.
> I think the assumption here is 32 bits. Should u32 be fine here?

This depends pretty much on the demand and the implementation.
Unless a buffer over 4GB is needed, u32 should be OK for buffer_size,
etc.  (Or, in this case, unsigned int would be fine, too.  It's not
necessarily be limited to 32bit.  u32 or such is used usually for the
type that must be 32bit.)

But, the questions remain for hw_pointer, app_pointer, bytes_*
fields.  Are these supposed to be 32bit or more?  This question is
more important than the buffer size.  The buffer size would be rarely
over 32bit.  But, if hw_pointer or such represents the accumulated
position like ALSA PCM does, you'll face the overlapping problem.
32bit limit can be reached easily in the real use case.

When this changes between 32bit and 64bit, think twice about the 32bit
compat-layer on 64bit arch (and the corresponding user-space
implementation)...


Takashi