I've started reworking into a GSD.
I can share a header file showing the "public API" if folks are
interested in seeing it. I might appreciate comments from folks who
have ideas about how to make it work better for extendibility (in
particular, if the API I've come up with has any limitations which would
make implementing synchronous serial devices harder.)
If folks want me to post it somewhere, let me know and I'll post a URL.
-- Garrett
James Carlson wrote:
> Garrett D'Amore writes:
>
>> This is very, very useful information. Thanks.
>>
>> Both asy.c and su_driver.c are very, very crufty, and (quite honestly)
>> suffer from some poor design.
>>
>
> Indeed. Actually, all of the serial drivers in Solaris could use a
> serious overhaul.
>
> 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. I ran out of spare cycles
> during the day to think about it, but I suppose I might look at it
> again. (If someone else with time could do it, that'd be even
> better.)
>
> Besides just plain old async serial I/O, there's the big problem of
> synchronous I/O. That's a crime scene. We adopted the architecture
> brought in by the 'zs' driver, and it's alien. It abuses DLPI (!),
> just plain looks nothing like UNIX, and leaves the AT&T sys/termiox.h
> interfaces adrift in the source base.
>
> It'd be nice to see that (zs and se) worked over.
>
>
>> I'm rewriting much of my new uart
>> framework from scratch, but I'm ditching 82510 support, and I might even
>> require a FIFO. (I've not decided on that yet or not. My design is
>> starting to demonstrate behavior that there is no difference between a
>> fifo-less UART and a deep fifo apart from reliability/performance at
>> high baud rates.)
>>
>
> There probably shouldn't be much difference.
>
> One issue to deal with on deep-FIFO parts is that you may want to
> interrupt on "special" characters, such as 7E in PPP or C0 on SLIP, to
> avoid latency on framed protocols, or even just 11/13 on ordinary
> in-band flow control. Doing this likely means some sort of new
> interfaces for those protocols to signal the need for expedited
> handling of certain sequences.
>
>
--
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
