Migrating ISA/PCI drivers
peterjeremy at acm.org
Thu Nov 18 22:21:04 UTC 2010
I'm (belatedly) looking at porting digi(4) to the MPSAFE TTY system
and have some architectural questions.
The digi(4) driver appears to support 5 different Digi card variants,
at least two of which exist in both ISA and PCI variants. Looking at
the Digi website, it appears that both PCI and ISA cards are still
available (as well as a PCIe card which is unlikely to work with the
current driver). I only have access to PCI/Xem cards and so can't
test my changes on any other card types. I presume Digi cards are not
that popular because noone else has shown any interest in the driver
since the MPSAFE TTY changes were announced about 2.5 years ago.
How much effort should I invest in adapting code for other card types?
In particular, the ISA cards use windowed memory accesses and IO ports
where the PCI cards have a single flat memory aperture. Removing
support for ISA cards would simplify the code (and remove the need to
make decisions about whether I need to do window switches in new
code), as well as potentially allowing finer grained locks.
My options would seem to be:
1) Rip out the ISA support - this is the cleanest for me but maximises
effort for a future person wanting to support ISA Digi cards.
2) Carry forward the ISA code as best I can and ensure new code includes
appropriate window switches etc. This maximises my effort but
hopefully makes it easier for someone to get ISA cards working.
3) Ignore the ISA code. This is fairly easy but probably requires
similar effort to (1) to get it going on ISA since all the code
would need to be reviewed to add necessary ISA-specific locking/
My preference is 1 since it leaves the least cruft (from my point of
view) in the code and doesn't give users the false impression that
ISA cards work.
I would appreciate some advice on the best way forward. In the
absence of any input, I will probably stick with option 3 for now but
may move to option 1 if the ISA code starts getting in the way. Keep
in mind that digi(4) does not currently compile on FreeBSD-8 or later,
so any of the above options are an improvement over the status quo,
though all are a regression from FreeBSD-7.
Of course, if someone has access to other Digi card types and wants
to assist with porting and testing, I would be happy to work with them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101118/6eae5e9c/attachment.pgp
More information about the freebsd-arch