One more thought: I'm planning on changing a few minor bits, and
wondered how much it is likely to cause pain.
First, I'm going to export kstats like su_driver.c, but instead of being
named "serialstat", they will be named "port0", or "port1" , or
somesuch, where the port number reflects the port number on the
_instance_. I.e. for a single devinfo node that represents a multiport
board, it could expose a bunch of kstats, one per port. I could try to
retain the "serialstat" kstat if anyone is using it for anything, but I
can't think of anything. By the way, the "asy" driver doesn't seem to
expose _any_ kstats.
Second, I might change the minor node names a bit. I will retain the
"a" - "z" monikers for motherboard ports, but I'm considering making
minor names of the form "0" or "0,cu" (incrementing "0" to "1".. "16"
etc. to represent the port number. For most serial ports, this will
mean a change in the minor names from "" (empty) and ",cu" to "0" and
"0,cu". It looks like devfsadm will do the right thing with these,
setting up /dev/term/xxx links using monotonically increasing numbers
(irrespective of the minor node name).
Anyone see any problems with either of these? I can't think of
anything, but maybe some folks are using "non-published" information
somewhere I am not aware of.
Oh yes, and for "su", I'll do the handling for keyboard, mouse, lom
console, and rsc console/control nodes. Those will be unchanged.
-- Garrett
Garrett D'Amore wrote:
> Peter Memishian wrote:
>
>>
>>
>> > 1) I'm writing a "common framework" so that pretty much all
>> > 16550-work-alikes could use the common code. This would allow pcser,
>> > asy.c and my new multiport support to all be consolidated. I'm lifting
>> > large portions of asy.c in the process, but I'm gutting some parts of
>> > it. (It is probably also useful to cardbus serial ports and a variety
>> > of modem devices as well...)
>> >
>> > [ ... ]
>> >
>> > 3) Am I insane? Should just try to "hack" support into asy.c rather
>> > than creating a new class? I don't know . But there seems to be a
>> > number of serial port drivers out there with most of the same
>> functionality.
>>
>> You're not insane -- this work would be hero status in my book. Thank you
>> for taking this on. BTW, you've no doubt noticed that su_driver.c is cut
>> and pasted from asy.c :-( There are many others, too.
>>
>>
>>
>
> I started looking at su_driver.c. It should be be consolidated as
> well. But one area that gives me cause for concern is comments and code
> referencing the Intel 82510 chip.
>
> Is this chip found on any UltraSPARC hardware (or any hardware that we
> need to support in OpenSolaris?)
>
> I cannot find Intel's original datasheets for this part, and I'm not
> entirely confident in this part. It looks like it probably had a FIFO,
> but that it was accessed using some method quite different from the
> standard 16550 UARTs.
>
> Should I worry about this? I don't feel that I can support the 82510
> without further knowledge of which platform(s) used it (so I can test),
> and without a datasheet.
>
> FWIW, it looks like once upon a time asy.c also had 82510 support that
> was removed in S10. I want to take it a step further and remove 8250
> and 16450, because I consider fifo-less UARTS to largely be useless in
> the modern era.
>
>
--
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
