Re: SoundScape driver... FIXMEs

[Takashi Iwai <tiwai@suse.de>]

At Sun, 22 Sep 2002 20:09:52 +0100 (BST),
Chris Rankin wrote:
> 
> Hi,
> 
> I saw the SoundScape PnP driver appear in CVS today,
> along with a number of FIXMEs at the top of the file.
> I presume that these FIXMEs are a barrier to fully
> integrating the driver, and that's what you mean by
> "deadlock for alsa-kernel"?

i guess it means "the condition for the driver to be raised to
alsa-kernel (i.e. 2.5 kernel) tree"

> - a non-modular build wasn't a priority because I was
> under the impression that one of the goals for Linux
> 2.5+ was to *remove* all compiled-in drivers?

i don't think so.  more modulalization doesn't mean to remove the
ability of built-in drivers.  (and i heard that Linus still prefers
built-in drivers to modules :)

> However, I could probably provide something, if absolutely
> necessary. 

i don't see any particular part that restricts to module (except that
the driver needs firmware to be loaded via ioctl).
am i missing something?


> - I was not aware that "verify_area()" had been
> deprecated. There were no comments to this effect in
> the <asm/uaccess.h> header, and a grep through the
> 2.4.19 tree shows that it is HEAVILY used. In fact,
> verify_area() appears to be the public interface for
> the same access-checking function invoked by
> copy_from_user() and copy_to_user(). The point about
> calling verify_area() at all is to validate the entire
> DMA upload block at once, so that I can safely copy it
> piecemeal later. It seems to be more efficient to DMA
> directly from userspace rather than copying the block
> into *more* temporary storage and then DMA-ing from
> there. Is there a race condition between the
> verify_area() and the underlying __copy_from_user()?
> If so, then how is this same race resolved by
> copy_from_user()?

no race condition between them.  verify_area() is simply not necessary
if you use copy_from/to_user().
generally it's recommended to check the return value from
copy_from/to_user() at each call and to return -EFAULT, because it can
be faster.


another point:  doesn't the busy-loop in host_read/write_ctrl_unsafe
need udelay() or something to produce a certain delay length?
otherwise the timeout is very dependent on a machine.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf