public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: LANCE ethernet chip - ~24 drivers
@ 2001-07-31 16:58 Rick Hohensee
  2001-07-31 18:14 ` Horst von Brand
  2001-08-01  8:39 ` Maciej W. Rozycki
  0 siblings, 2 replies; 6+ messages in thread
From: Rick Hohensee @ 2001-07-31 16:58 UTC (permalink / raw)
  To: linux-kernel

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
					www.clienux.com


^ permalink raw reply	[flat|nested] 6+ messages in thread
[parent not found: <mailman.996536700.4319.linux-kernel2news@redhat.com>]
* LANCE ethernet chip - ~24 drivers
@ 2001-07-30 23:42 Jan-Benedict Glaw
  2001-08-01 21:55 ` Jeff Garzik
  0 siblings, 1 reply; 6+ messages in thread
From: Jan-Benedict Glaw @ 2001-07-30 23:42 UTC (permalink / raw)
  To: linux-kernel

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-08-01 21:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-31 16:58 LANCE ethernet chip - ~24 drivers Rick Hohensee
2001-07-31 18:14 ` Horst von Brand
2001-08-01  8:39 ` Maciej W. Rozycki
     [not found] <mailman.996536700.4319.linux-kernel2news@redhat.com>
2001-07-31  0:44 ` Pete Zaitcev
  -- strict thread matches above, loose matches on Subject: below --
2001-07-30 23:42 Jan-Benedict Glaw
2001-08-01 21:55 ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox