Lennart,

How would this me done?

The userland code expects to open a single /dev/
character device which is attached to the rio.

If I understand the ugen correctly, these devices
assign the minor number to be equal to a combination
of the unit number and the endpoint number.  Since the
rio uses three
end points (control pipe, and two bulk transfer pipes
in/out) we would have to change the userland 
stuff to search all the ugen devices for the rio and
when found open up three devices instead of a single
one.

The rio user land code also calls special ioctls
( which send out special vendor specific requests to 
the default control pipe)
to the rio driver. Would we need to roll these ioctls
out of the driver and back into the userland code?

Is this what you are proposing?  
If so, it sounds like alot of the Linux userland stuff
would be trashed.  It would be
nice if we could just use the Linux tools since
they will continue to make improvements to them.  

However, I do have one concern that might make the use
of the Linux userland tools undesireable.
The speed of the driver/tools is not great. It takes
about a minute to download a song. ~0.5 Mbits/sec.
It is a full speed device however.
Since the current driver is a character device I
suspect the tools do alot
of blocking and context switching passing data down
from userland.  
Is it possible or should we consider 
making the driver into a block device instead?

Regards,
-Alex

--- Martin Husemann <martin@rumolt.teuto.de> wrote:
> > What is people opinion on this?  Should we have
> special kernel
> > drivers or just userland code?  This first is
> quite convenient,
> > but bloats the kernel somewhat.
> 
> Userland as userland can!
> 
> Like the USB GamePad support ;-)
> 
> 
> Martin
> 
> 

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com