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.
> The big problem with using ptys for serial port emulation is that they

quoted text
> 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/