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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
