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