From: Chris Wedgwood <cw@f00f.org>
To: Donald Becker <becker@scyld.com>
Cc: Francois Romieu <romieu@cogenit.fr>,
Russell King <rmk@arm.linux.org.uk>,
Ivan Passos <lists@cyclades.com>,
linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Date: Thu, 7 Dec 2000 21:44:36 +1300 [thread overview]
Message-ID: <20001207214436.A7974@metastasis.f00f.org> (raw)
In-Reply-To: <20001203075958.A1121@metastasis.f00f.org> <Pine.LNX.4.10.10012021412560.16980-100000@vaio.greennet>
In-Reply-To: <Pine.LNX.4.10.10012021412560.16980-100000@vaio.greennet>; from becker@scyld.com on Sat, Dec 02, 2000 at 02:48:10PM -0500
On Sat, Dec 02, 2000 at 02:48:10PM -0500, Donald Becker wrote:
It's certainly possible to break the driver up, but it will be
even more of a problem to maintain. Some of the complicated
media selection code applies to several generations. Splitting
the driver to have a copy for each generation means a lot of
duplicated code, which quickly leads to version skew.
So how does someone, like me for example, try to cleanly add support
for something like ethtool when the only hardware they have is say
3c920 and they could care less about the rest?
The best thing I can see to do is to restructure the driver as is and
try to get common paths for things like media setting and remove the
module parameter hacks we now have; that way it should be possible to
add ethtool support that works for everything...
... how does that sound?
--cw
P.S. Also, since only _two_ drivers actually support ethtool (hme and
acenic) is everyone 100% happy they want this API? Surely now is
the best time to invite discussion and promote ideas if people
have requirements that ethtool can't satisfy?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-07 9:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-30 19:16 [RFC] Configuring synchronous interfaces in Linux Ivan Passos
2000-12-01 9:01 ` Francois romieu
2000-12-01 10:32 ` Chris Wedgwood
2000-12-01 11:00 ` Christoph Hellwig
2000-12-01 12:30 ` Xavier Bestel
2000-12-01 12:07 ` Russell King
2000-12-01 13:00 ` Francois Romieu
2000-12-02 16:09 ` Donald Becker
2000-12-02 18:59 ` Chris Wedgwood
2000-12-02 19:07 ` Jeff Garzik
2000-12-02 19:46 ` Russell King
2000-12-02 20:02 ` Philip Blundell
2000-12-03 5:47 ` Chris Wedgwood
2000-12-03 11:10 ` Philip Blundell
2000-12-03 11:27 ` Russell King
2000-12-03 0:20 ` Keith Owens
2000-12-03 13:43 ` Jeff Garzik
2000-12-03 20:29 ` Keith Owens
2000-12-03 20:41 ` Keith Owens
2000-12-02 19:48 ` Donald Becker
2000-12-07 8:44 ` Chris Wedgwood [this message]
2000-12-01 13:44 ` Philip Blundell
2000-12-01 12:15 ` Francois Romieu
2000-12-01 13:14 ` Bogdan Costescu
2000-12-01 16:26 ` Francois Desloges
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20001207214436.A7974@metastasis.f00f.org \
--to=cw@f00f.org \
--cc=becker@scyld.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@cyclades.com \
--cc=netdev@oss.sgi.com \
--cc=rmk@arm.linux.org.uk \
--cc=romieu@cogenit.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.