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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
