On Sat, Mar 05, 2005 at 11:58:51AM +0000, Linux Kernel Mailing List wrote:
> ChangeSet 1.1982.137.48, 2005/03/05 11:58:51+00:00, [email protected]
>
> [ARM] Group device drivers together under their own menu
Any reason you can't merge ARM's options into the drivers/*/Kconfig (with
appropriate conditionals) and use drivers/Kconfig?
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
On Sat, Mar 26, 2005 at 09:41:41PM +0000, Matthew Wilcox wrote:
> On Sat, Mar 05, 2005 at 11:58:51AM +0000, Linux Kernel Mailing List wrote:
> > ChangeSet 1.1982.137.48, 2005/03/05 11:58:51+00:00, [email protected]
> >
> > [ARM] Group device drivers together under their own menu
>
> Any reason you can't merge ARM's options into the drivers/*/Kconfig (with
> appropriate conditionals) and use drivers/Kconfig?
Dunno. Haven't gotten around to sorting that out yet, and I don't
particularly fancy trying to fight any corners over it.
I think, a while back, it was thought to be better to keep ARM separate
to keep the conditionals out of drivers/Kconfig.
If the general concensus has changed, I might eventually sort it out if
it causes enough trouble, or people think there's sufficient value to it.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sat, Mar 26, 2005 at 10:50:26PM +0000, Russell King wrote:
> On Sat, Mar 26, 2005 at 09:41:41PM +0000, Matthew Wilcox wrote:
> > Any reason you can't merge ARM's options into the drivers/*/Kconfig (with
> > appropriate conditionals) and use drivers/Kconfig?
>
> Dunno. Haven't gotten around to sorting that out yet, and I don't
> particularly fancy trying to fight any corners over it.
>
> I think, a while back, it was thought to be better to keep ARM separate
> to keep the conditionals out of drivers/Kconfig.
>
> If the general concensus has changed, I might eventually sort it out if
> it causes enough trouble, or people think there's sufficient value to it.
As the original author of drivers/Kconfig, I think it's a brilliant
idea that everybody should use ;-) I haven't heard any dissenting
opinions yet. The only complaint I've heard is that net/Kconfig is now
under device drivers. I didn't make that change, and I agree it sucks.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
Matthew Wilcox wrote:
> On Sat, Mar 26, 2005 at 10:50:26PM +0000, Russell King wrote:
>
>>On Sat, Mar 26, 2005 at 09:41:41PM +0000, Matthew Wilcox wrote:
>>
>>>Any reason you can't merge ARM's options into the drivers/*/Kconfig (with
>>>appropriate conditionals) and use drivers/Kconfig?
>>
>>Dunno. Haven't gotten around to sorting that out yet, and I don't
>>particularly fancy trying to fight any corners over it.
>>
>>I think, a while back, it was thought to be better to keep ARM separate
>>to keep the conditionals out of drivers/Kconfig.
>>
>>If the general concensus has changed, I might eventually sort it out if
>>it causes enough trouble, or people think there's sufficient value to it.
>
>
> As the original author of drivers/Kconfig, I think it's a brilliant
> idea that everybody should use ;-) I haven't heard any dissenting
> opinions yet. The only complaint I've heard is that net/Kconfig is now
> under device drivers. I didn't make that change, and I agree it sucks.
This is likely a little OT for this thread, but
I probably made that change (of grouping all networking
options and drivers together). And I still think that they
should all be grouped together -- whether it's under
device drivers or a top-level Networking section.
The real problem AFAICT is that Networking options
includes some protocols and then Network Device Support
includes some other protocols. Maybe if there was a Network Protocol
section things could be clearer. ??
--
~Randy
Hi,
Randy.Dunlap wrote:
> The real problem AFAICT is that Networking options
> includes some protocols and then Network Device Support
> includes some other protocols. Maybe if there was a Network Protocol
> section things could be clearer. ??
I would really welcome that change.
Regards
Ingo Oeser