public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: kaih@khms.westfalen.de (Kai Henningsen)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Endian-ness bugs in yellowfin.c
Date: 14 Sep 2001 10:07:00 +0200	[thread overview]
Message-ID: <88q7QEGHw-B@khms.westfalen.de> (raw)
In-Reply-To: <Pine.LNX.3.96.1010914014353.8683A-100000@mandrakesoft.mandrakesoft.com>
In-Reply-To: <20010914001540.B2951@boardwalk> <Pine.LNX.3.96.1010914014353.8683A-100000@mandrakesoft.mandrakesoft.com>

jgarzik@mandrakesoft.com (Jeff Garzik)  wrote on 14.09.01 in <Pine.LNX.3.96.1010914014353.8683A-100000@mandrakesoft.mandrakesoft.com>:

> On Fri, 14 Sep 2001, Val Henson wrote:
> > You misunderstood what I meant.  This is the first case of one driver
> > supporting two different cards, one 10/100 and one 10/100/1000.  All
> > the gigabit cards are 10/100/1000 as far as I know.  I still think the
> > driver should be listed in both the 100 Mbit and 1000 Mbit Ethernet
> > menu sections, unless someone comes up with a better idea.
>
> Please do not add duplicate items...  put drivers that can do gigabit
> under gigabit.  Eventually as we get more of them we can come up
> with better Config.in categories.  Besides being an ugly solution,
> duplicating items has the potential to push edge cases in the various
> Config.in parsers.

Actually, I'd say that practically *all* the categories used for ethernet  
cards are confusing. I certainly often end up backtracking several times  
when configuring a new machine.

Just throwing the lot out and using a flat list would be better than the  
current state.

Bad category strategies:

* Brand name. Drivers serve different brands.
* Bus type. Drivers serve cards on different bus types.
* Speed. Drivers serve cards capable of different speeds.

I really don't know what's left.

Unless, of course, mentioning one driver several places becomes possible.  
Then all these arguments become irrelevant.

MfG Kai

  reply	other threads:[~2001-09-14 14:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-14  1:51 [PATCH] Endian-ness bugs in yellowfin.c Val Henson
2001-09-14  2:39 ` Tom Rini
2001-09-14  2:55   ` Val Henson
2001-09-14  3:02     ` Tom Rini
2001-09-14  5:01       ` Matthew Dharm
2001-09-14  6:12         ` Val Henson
2001-09-14  9:12         ` Alan Cox
2001-09-14  6:15       ` Val Henson
2001-09-14  6:47         ` Jeff Garzik
2001-09-14  8:07           ` Kai Henningsen [this message]
2001-09-14 20:20             ` Val Henson
2001-09-14  6:49 ` Jeff Garzik
2001-09-14 18:50   ` Cort Dougan
2001-09-14 20:20     ` Val Henson

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=88q7QEGHw-B@khms.westfalen.de \
    --to=kaih@khms.westfalen.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox