On Fri, 25 Apr 2008, Takashi Iwai wrote:
> > > > I see. In this case, I would propose to add a 32-bit "magic" at the
> > > > start of 'void *' data. How about this modification:
> > >
> > > The magic number sounds OK, but funky cast to integer pointer is bad.
> > > If you have a long or a pointer after int, you can have an alignment
> > > problem on 64bit archs, for example.
> >
> > Not really. First 32-bit word has offset 0 and next 64-bit word has offset
> > 8 on x86-64. So alignment is OK.
>
> No, suppose the data like
>
> int magic;
> void *ptr;
>
> and the code to retrive the magic is
>
> magic = *(int*)device_data;
>
> and thus the next data pointer is (int*)device_data + 1.
> This doesn't work.
+ 1 does not work, but driver can define own private structure and it will
work. The point is that 32-bit magic must be always at offset 0.
> > Anyway, I agree that with a struct, code is more readable without hidden
> > things. Also, drivers can define own struct with magic member as first.
> >
> > Here is corrected patch:
>
> Hm, but this allows you pass only one value and has an ugly union.
As I mentioned, this structure can be redefined. I can imagine, that
drivers won't use predefined structure and create own like:
struct mydata {
unsigned int magic; /* required */
unsigned long value1;
char *name;
int somevalue;
};
The only required thing is to have 32-bit magic value at offset 0.
Jaroslav
-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
