On Thu, Aug 28, 2008 at 04:05:55PM -0700, H. Peter Anvin wrote:
quoted text
> Greg KH wrote:
>> Independant of that, I can see a number of uses for the CUSE code.  One
>> would be emulating /dev/pilot for old palm pilot software that things it
>> wants to talk to a serial port, yet really a libusb userspace program
>> can handle all of the data to the USB device instead.
>
> I think that's probably another bad example... I would think serial port 
> emulation would be better handled by ptys, and/or a specific serial port 
> emulation module.

Hm, why?  It's a "fake" serial port as it is just a pass-through to the
USB device.  No flow control or line settings work on the device, so the
kernel driver just silently eats them.  But there is old, closed source
software that wants to talk to a serial port, so the kernel driver
remains.  With this code, we could then use the more modern libusb code
instead.

I guess you could hook it up through a pty, and somehow create
/dev/pilot/ for it as well, that is an idea to consider.

quoted text
> The big problem with using ptys for serial port emulation is that they 
> currently don't handle BREAK at all.

For this type of USB device, that's not an issue :)

thanks,

greg k-h
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/