http://bugzilla.kernel.org/show_bug.cgi?id=2819
Make oldconfig silently disabled support for my CONFIG_TIGON3 NIC.
It seems that it depends on CONFIG_NET_GIGE which in turn depends on
CONFIG_NET_ETHERNET which was not required in 2.6.6 kernel.
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Growing old is mandatory... growing up is optional.
On Wednesday 02 June 2004 17:37, Thomas Zehetbauer wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=2819
>
> Make oldconfig silently disabled support for my CONFIG_TIGON3 NIC.
>
> It seems that it depends on CONFIG_NET_GIGE which in turn depends on
> CONFIG_NET_ETHERNET which was not required in 2.6.6 kernel.
>
> Tom
Many days ago I read on lkml that separating 10,100 and 1000 Mbit
ethernet is not really justified. There are devices which have
100 and 1000 variants.
Just keeping all ethernet devices in one menu sounds sane to me.
--
vda
Denis Vlasenko wrote:
> On Wednesday 02 June 2004 17:37, Thomas Zehetbauer wrote:
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=2819
>>
>>Make oldconfig silently disabled support for my CONFIG_TIGON3 NIC.
>>
>>It seems that it depends on CONFIG_NET_GIGE which in turn depends on
>>CONFIG_NET_ETHERNET which was not required in 2.6.6 kernel.
>>
>>Tom
>
>
> Many days ago I read on lkml that separating 10,100 and 1000 Mbit
> ethernet is not really justified. There are devices which have
> 100 and 1000 variants.
>
> Just keeping all ethernet devices in one menu sounds sane to me.
There are other issues with the build process, when a driver supports a
chipset used in several products there's no reasonable way to find out
which driver should be used, and as you say the split of speed makes
less and less sense, and will just get worse when 10Ge is more common.
The solution may be an external table, program, or whatever, since the
situation changes as drivers are modified to support new models,
chipsets move to new vendors, etc. But it would be *really nice* to find
the 3c940 with 3COM drivers, instead of grepping driver source and
looking at spec sheets to find out that the driver is called something
like sk98lin, it's in an unobvious place and has a name unrelated to 3COM.
Here's a suggestion if someone wants to do something about this, like
LDP. Produce a CSV list of vendor name, like 3c940, name used for config
in the menu, module name and symbol in the .config file. Would let users
find things a lot faster, and could be used with grep as well as some
spreadsheet tool.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
It would also help if there was a preliminary auto-detect option/feature
in the main window that could get a quick idea of what can/should be
enabled.
David
Bill Davidsen wrote:
> Denis Vlasenko wrote:
>
>> On Wednesday 02 June 2004 17:37, Thomas Zehetbauer wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=2819
>>>
>>> Make oldconfig silently disabled support for my CONFIG_TIGON3 NIC.
>>>
>>> It seems that it depends on CONFIG_NET_GIGE which in turn depends on
>>> CONFIG_NET_ETHERNET which was not required in 2.6.6 kernel.
>>>
>>> Tom
>>
>>
>>
>> Many days ago I read on lkml that separating 10,100 and 1000 Mbit
>> ethernet is not really justified. There are devices which have
>> 100 and 1000 variants.
>>
>> Just keeping all ethernet devices in one menu sounds sane to me.
>
>
> There are other issues with the build process, when a driver supports
> a chipset used in several products there's no reasonable way to find
> out which driver should be used, and as you say the split of speed
> makes less and less sense, and will just get worse when 10Ge is more
> common.
>
> The solution may be an external table, program, or whatever, since the
> situation changes as drivers are modified to support new models,
> chipsets move to new vendors, etc. But it would be *really nice* to
> find the 3c940 with 3COM drivers, instead of grepping driver source
> and looking at spec sheets to find out that the driver is called
> something like sk98lin, it's in an unobvious place and has a name
> unrelated to 3COM.
>
> Here's a suggestion if someone wants to do something about this, like
> LDP. Produce a CSV list of vendor name, like 3c940, name used for
> config in the menu, module name and symbol in the .config file. Would
> let users find things a lot faster, and could be used with grep as
> well as some spreadsheet tool.
>
On Tue, 8 Jun 2004, Bill Davidsen wrote:
> The solution may be an external table, program, or whatever, since the
> situation changes as drivers are modified to support new models,
> chipsets move to new vendors, etc. But it would be *really nice* to find
> the 3c940 with 3COM drivers, instead of grepping driver source and
> looking at spec sheets to find out that the driver is called something
> like sk98lin, it's in an unobvious place and has a name unrelated to 3COM.
Another problem with the sk98lin driver is that it hasn't yet been converted to
the new driver model. Even when booting Knoppix, you have to manually modprobe
sk98lin to use the 3c940. Took me a while to find out...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds