Hi!
I was recently hacking the declance.c driver to support my
DS5000/200. While hanging around I looked over the code to
count the current implementations of Am7990 Lance drivers:
Driver file | Mentioned Chip
----------------------------------------------+--------------------
./drivers/net/declance.c
./xxx/declance.c # as for DS5k/200
./drivers/net/bagetlance.c none mentioned
./drivers/net/sk_g16.c Am7990
./drivers/net/ni65.c ni6510 aka Am7990
./drivers/net/ewk3.c Am7990
./drivers/net/sk_mca.c Am7990
./drivers/net/sunlance.c NCR92c990
`-> Father of declance.c as I think
./drivers/net/sunhme.c none mentioned
`-> *some* cards seem to be compatible?!
./drivers/net/a2065.c Am7990
./drivers/net/ariadne.c Am79c960
./drivers/net/atarilance.c none mentioned
./drivers/net/sunqu.c "looks like LANCE"
./drivers/net/atari_pamsnet.c none mentioned
./drivers/net/lance.c Am7990, Am79c970A
./drivers/net/pcnet32.c none mentioned
./drivers/net/sgiseeq.c Seeq8003 (different buffer
layout for speed)
./drivers/net/am79c961a.c Am79c961A
./drivers/net/sun3lance.c none mentioned, but adopted from sunlance.c
./drivers/net/pcmcia/nmclan_cs.c Am79c90
./drivers/net/ibmlana.c "start of LANCE"
./drivers/net/7990.c *** GENERIC ROUTINES!!! ***
./drivers/net/hplance.c Uses 7990.c!
./drivers/net/mvme147.c Uses 7990.c!
That are *many* drivers for at least *one* chip. For now, I'm
working to get a serial keyboard running. However - having
more than 20 drivers for one kind of device sucks a lot. So
I'd like you to comment on this. There is a generic chip
implementation of an Am7990 driver (7990.c), but I can't
tell about it's quality. I'd *really* like to ask maintainers
and/or authors of those drivers to think about having
theit "own" driver. I think, it will be a 2.5.x thing to
re-unify them again (at lease, write a central implementation
for the chip and let bus specific drivers use it). Just the
same words are to be said for the Zilog8530 serial chip.
Thinking about it, we really have to do a lot on drivers for
a *chip* and those for I/O *busses* to work together. This way,
we could IMHO get rid of many lines of code, not giving up
any functionality. In fact, this would ease maintainance a lot,
wouldn't it?
Gest regards,
Jan-Benedict Glaw
> ./drivers/net/sunlance.c NCR92c990
> `-> Father of declance.c as I think
It handles 79c90, but also includes support for ledma,
lebuffer, and Lance-fixed-with-PAL. Hardly a target for merge.
> ./drivers/net/sunhme.c none mentioned
> `-> *some* cards seem to be compatible?!
Nope, not even close. Make it 23 Lance drivers.
> ./drivers/net/sunqu.c "looks like LANCE"
QE is a quad of some Lance derivatives, plus a bus interface
for DMA which is not compatible with ledma. It is sufficiently
unusual for Solaris to have separate drivers for le and qe.
> ./drivers/net/sun3lance.c none mentioned,
> but adopted from sunlance.c
Yes, they are basically the same. Dunno why sun3 people split it.
> However - having
> more than 20 drivers for one kind of device sucks a lot.
Not really, as long as they are maintained.
> I think, it will be a 2.5.x thing to
> re-unify them again (at lease, write a central implementation
> for the chip and let bus specific drivers use it). Just the
> same words are to be said for the Zilog8530 serial chip.
Large number of them is going to die fromm bitrot naturally,
so I do not see a major problem. For instance, sunle is going
to disappear in 5..10 years, as old machines break down.
-- Pete
Jan-Benedict Glaw
>That are *many* drivers for at least *one* chip. For now, I'm
>working to get a serial keyboard running. However - having
>more than 20 drivers for one kind of device sucks a lot. So
One has to wonder. I was looking at 1.2.13 and there is mention of
splitting a driver, I forget which one, because there are two bits with
reversed sense in later versions of a card.
This raises a question about open source. How do you aknowledge code
removal? Given a system at some level of existing functionality, removing
code is one of the best things you can do for it, but it doesn't get your
name anywhere that sticks. Maybe Linux needs a linux/NO_MAINTENANCE .
Rick Hohensee
http://www.clienux.com
Rick Hohensee <[email protected]> said:
[...]
> This raises a question about open source. How do you aknowledge code
> removal? Given a system at some level of existing functionality, removing
> code is one of the best things you can do for it, but it doesn't get your
> name anywhere that sticks. Maybe Linux needs a linux/NO_MAINTENANCE .
What about TOP-DELETERS sorted by the numbers of lines each one has axed?
--
Dr. Horst H. von Brand Usuario #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513