Artem Kachitchkine wrote: > James Carlson wrote: > >> At one point, I started working on a "GSD" (generic serial driver, >> akin to GLD) to implement all of the common POSIX bits with simple >> callbacks for the chip-specific bits. >> > > And that was before I put my GSD in Solaris 9? :) > > http://blogs.sun.com/artem/date/20051118 > > The GSD used for USB serial drivers (/kernel/misc/usbser) has all the POSIX > bits, calling into device-specific code (DSD). There's minimum USB code in > usbser - hotplug events and logging macros. > > > This message posted from opensolaris.org > _______________________________________________ > opensolaris-code mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code >
Aargh. I wish I had known about this a while ago. Well, usbser has some "interesting" things in it, and some short-comings. No doubt I'm polluted after reading asy.c, su_driver.c, and zs_async.c, as well as NetBSD serial drivers. 1) it has notions about USB "disconnect" and "reconnect". Some of these things don't make sense in the same fashion with more "normal" devices. (You don't hot remove a device that is in use, DR always checks to make sure nobody is on the device before detaching it.) 2) It is (obviously) very well suited to USB. In a few areas it uses things like dual taskq's for tx and rx, that might be useful to help stuff. 3) "rx" is a callback in the driver. How does a DSD indicate arrival of data? We want to handle that in interrupt context, I think. And we want to do so quickly. (Normally the bits are moved out of the on-chip fifo into a software fifo for later processing by a soft interrupt.) 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? 5) The notion of separate "start" and "stop" and directions seems weird, at least to me. 6) There is no documentation or clear information in the headers for how to write a driver. I sort of get some of it from the usbser_dsdi.h, but I can't easily see, for example, how I indicate interrupts, etc. 7) There does not appear to be support for timely handling of modem interrupts, which is necessary to get good support for the NTP synchronization via PPS source. (Well, with normal USB latencies, you probably wouldn't want to use a USB serial dongle for PPS synchronization anyway.) 8) There are of course other "hacks" needed to make the framework able to replace asy.c and su_driver.c, etc. For example, support for "motherboard" ports, and special nodes for mouse, keyboard, RSC, and LOM consoles. (And automatic defaults of tty settings for those, as well. E.g., rsc nodes run at 115200 by default.) 9) CPR/Suspend resume? Power management? Why?!? I would have though these would have been handled in the DSD without interaction from GSD. 10) Finally, the whole framework resides in USB specific directories rather than somewhere generic. While this is kind of arbitrary, it seems to me weird to have ISA and PCI devices pulling in USB headers to get common framework. This is of course fixable, if it were the only issue... 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. :-) -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
