[alsa-devel] [PATCH] snd-usb-us122l v0.4 for US-122L

[Takashi Iwai]

At Tue, 15 Apr 2008 18:40:48 +0200,
Karsten Wiese wrote:
> 
> Am Dienstag, 15. April 2008 schrieb Takashi Iwai:
> > > > +#endif
> > > > +
> > > > +#define USB_STREAM_NURBS 4
> > > > +struct usb_stream_config {
> > > > +	unsigned version;
> > > > +	unsigned sample_rate;
> > > > +	unsigned period_frames;
> > > > +	unsigned frame_size;
> > > > +};
> > > > 
> > > > The codes below here should be hidden to user-space.
> > > > If it's exported, then prepare more explicit struct.  For example,
> > > > pointers may have different sizes on user-space.
> > > 
> > > Needed in user-space. Currently only 64Bit userspace works on 64Bit kernel.
> > > Also 32bit user-space on 32bit kernel.
> > > 32bit user-space on 64bit kernel returns an error to the caller, please see
> > > the plugin.
> > > IMO 32bit user-space working on 64bit kernel can wait for "INTERFACE_VERSION 2"
> > Exporting this kind of particular internal struct to the user-space is
> > very dangerous.
> 
> Everything exported by that struct can only be mmap()ed "read only".
> Please explain why you think its very dangerous.

It's pretty fragile against ABI breakage, for example.
Imagine that if the kernel changes wait_queue_head_t implementation.
Even if you don't change your code, the struct size may change, too.

But, what I feel uneasy is that this ABI exposes kernel pointers
excessively.  Passing pointers should be avoided if you think of
portability and maintenance in future.
We don't have to be a naked king.  Let's wear something for the thing
that we don't want to show.

And, if you avoid pointers (and long offsets / addresses) in the
shared parameters, it'd be even bi-arch compliant.  One less worry
gratis.


Takashi