1) it has notions about USB "disconnect" and "reconnect".
Just extra code that will never be used unless device is hotpluggable. Is pcser hotpluggable?
3) "rx" is a callback in the driver. How does a DSD indicate arrival of data?
GSD registers callbacks (tx, rx, status), DSD invokes rx_cb(), GSD calls ds_rx() to retrieve the data.
4) The "tx" spec says "* data transmit: DSD is *required* to accept mblk for transfer". How does one exert backpressure in the stream to prevent loss of data or runaway memory consumption?
Flow control.
5) The notion of separate "start" and "stop" and directions seems weird, at least to me.
Data flows in both directions.
6) There is no documentation or clear information in the headers for how to write a driver.
Yeah, probably because the interfaces are not yet public. As a small contribution, I wrote a 4 part blog about this:
http://blogs.sun.com/artem/entry/usb_serial_drivers_part_1 http://blogs.sun.com/artem/entry/usb_serial_drivers_part_2 http://blogs.sun.com/artem/entry/usb_serial_drivers_part_3 http://blogs.sun.com/artem/entry/usb_serial_drivers_part_4
7) There does not appear to be support for timely handling of modem interrupts
Define timely. DSD can invoke status callback whenever there's a line change.
8) There are of course other "hacks" needed
Sure. They'll be needed for any framework, not just this one.
9) CPR/Suspend resume? Power management? Why?!? I would have though these would have been handled in the DSD without interaction from GSD.
Maybe. Maybe not. It just happens that USB DSD's use usbser_attach() and usbser_detach() as the attach(9E)/detach(9E) entry points, so when the kernel does CPR, it enters GSD code first, which then propagates it down to DSD.
10) Finally, the whole framework resides in USB specific directories
Non-issue. Moving stuff around is easy.
Anyway, at this point, I suspect what you have is fairly ideal for for USB, but doesn't port well to the needs of onboard and PCI devices. I suggest we not try to consolidate this along with my "gser" driver, but instead keep them separate, as they are well optimized to different needs. It does mean I probably need to bother to give much thought to supporting USB devices though -- you seem to have that pretty well under control. :-)
Sure. I wasn't advocating usbser reuse. Just seemed that one of your main motivations was to avoid code duplication ;-)
-Artem. _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
