On Tue, 6 February 2007 10:16:17 -0500, Mark Lord wrote:
>
> That interface is driven entirely backwards.
> The funtionality option should always be visible,
You are absolutely correct. The _interface_ is horrible. And changing
the config language won't change that fact one bit.
Make *config
On Tue, 6 Feb 2007, Mark Lord wrote:
I'm with Linus 100% here.
It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.
The reason being, that /proc/acpi/alarm no longer exists,
and the
On Tue, 6 Feb 2007, Mark Lord wrote:
I'm with Linus 100% here.
It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.
The reason being, that /proc/acpi/alarm no longer exists,
and the
On Tue, 6 February 2007 10:16:17 -0500, Mark Lord wrote:
That interface is driven entirely backwards.
The funtionality option should always be visible,
You are absolutely correct. The _interface_ is horrible. And changing
the config language won't change that fact one bit.
Make *config is
On 2/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
And yes, then it's almost always correct to "turn things on as needed to
make everything work out right", while turning things off would be
actively wrong.
I see a scenario (many others may have got this idea):-
Reading H/W config at the
On 2/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
And yes, then it's almost always correct to turn things on as needed to
make everything work out right, while turning things off would be
actively wrong.
I see a scenario (many others may have got this idea):-
Reading H/W config at the time
On Wed, 7 Feb 2007, David Woodhouse wrote:
>
> I think 'make oldconfig_noselect' is the way forward. We can both have
> what we want.
Actually, I think there might be an even more interesting schenario.
The Kconfig language right not is ternary, which is fine as an arithmetic,
but the
On Tue, 2007-02-06 at 16:21 -0800, Linus Torvalds wrote:
>
> On Wed, 7 Feb 2007, David Woodhouse wrote:
> >
> > It isn't that far off, and we could improve it if we wanted to. In
> > _general_ it's quite good already.
>
> I agree that it's close to hierarchical. But it's literally the
Linus Torvalds wrote:
On Wed, 7 Feb 2007, David Woodhouse wrote:
It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that get you.
Let me mention (again)
On Wed, 7 Feb 2007, David Woodhouse wrote:
>
> It isn't that far off, and we could improve it if we wanted to. In
> _general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that get you.
Let me mention (again) USB_STORAGE and ATA.
They
On Tue, 2007-02-06 at 15:55 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, David Woodhouse wrote:
> >
> > Really, if our config is set up in sensible submenus (as in general it
> > _is_), the "see everything" behaviour really isn't bad.
>
> There are two fundamental problems with that
On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> Really, if our config is set up in sensible submenus (as in general it
> _is_), the "see everything" behaviour really isn't bad.
There are two fundamental problems with that statement:
- no, it really isn't always
Quite often, our Kconfig
On Tue, 6 Feb 2007, Randy Dunlap wrote:
> Besides this select business, Bill (or someone :) mentioned a
> feature that I requested about 8 months ago: the ability to disable
> or enable groups of drivers at one swoop.
i vaguely recall that *i* was pushing that idea, and even submitted a
couple
On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> Out of interest, which people would this be? Not me, certainly.
> I _use_ select, for options which don't have questions. There were two
> such instances in the context of Ingo's mail of $subject, even.
>
> And the thing Randy was saying "yes" to,
On Tue, 2007-02-06 at 15:41 -0800, Randy Dunlap wrote:
> It's quite subjective. E.g., I made/submitted a patch maybe 1 year
> ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI,
> etc.) into one localized place in the menu structure.
> OK, perhaps I wasn't persistent enough, but
On Tue, 06 Feb 2007 23:36:23 + David Woodhouse wrote:
> On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
> > (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
> > still want to be able to see the question about NFSv8.1, which only works
> > on top of IPV6. I
On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
> (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
> still want to be able to see the question about NFSv8.1, which only works
> on top of IPV6. I might not even *know* I want IPV6, but I know my company
> uses
On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> The other possibility which comes to mind, and which I _have_ seen
> implemented, is not to hide the disabled option but to _show_ it, and
> represent its dependencies right there next to it somehow.
That would probably work, especially if you
On Tue, 2007-02-06 at 15:11 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, Randy Dunlap wrote:
> > > But it doesn't matter. I'll come up with a hack for the tools which make
> > > them (optionally) treat 'select' of a user-visible option as if it
> > > was just 'depends on'. And that should
On Tue, 6 Feb 2007, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, Randy Dunlap wrote:
> >
> > Yes, that's the solution that I decided on during lunch also:
> > select <==> depends on
>
> I think yuou can certainly enable an "expert mode", which just reads
> "select" as "depends on".
On Tue, 2007-02-06 at 14:53 -0800, Linus Torvalds wrote:
> I don't think you've ever showed any such example.
>
> And if you did, it would all boil down to *exactly* what 'select' does:
> config options that get set automatically based on other choices.
That's one option which I don't think
On Tue, 6 Feb 2007, Randy Dunlap wrote:
>
> Yes, that's the solution that I decided on during lunch also:
> select <==> depends on
I think yuou can certainly enable an "expert mode", which just reads
"select" as "depends on".
You'll probably have to do *more* changes to the tools than
On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> I claim that there are _better_ ways to do it than 'select'.
I don't think you've ever showed any such example.
And if you did, it would all boil down to *exactly* what 'select' does:
config options that get set automatically based on other
On Tue, 6 Feb 2007, Haavard Skinnemoen wrote:
>
> I disagree. I did the exact same thing on AVR32 because !EMBEDDED
> forces on tons of crap that just isn't useful on many embedded
> platforms.
I do agree. EMBEDDED largely means "non-generic/non-standard" these days.
It's also true that
On Tue, 06 Feb 2007 22:38:04 + David Woodhouse wrote:
> On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
> >
> > WE WANT TO BE NICE.
> > - the firewall example was not an example of 'select', but of the "we
> >want to be nice". But you simply DID NOT GET IT.
>
> It's a very
On 2/6/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
A number of current users are indeed bogus. Stuff like:
config SUPERH
bool
default y
select EMBEDDED
Just because you're using a SuperH board doesn't mean you want to turn
off standard features.
I disagree. I did the
On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
>
> WE WANT TO BE NICE.
> - the firewall example was not an example of 'select', but of the "we
>want to be nice". But you simply DID NOT GET IT.
It's a very clever straw man, Linus, but it's still bogus. Not only do I
_agree_ about
Matt Mackall wrote:
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our "depend" keyword. Things which
don't
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
> >There's no reason we shouldn't be able to do exactly that with config
> >symbols in Kconfig-land. The only difference is that we've got
> >slightly different semantics for our "depend" keyword. Things which
> >don't have their
On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> It's a bad example because it's not relevant to the 'select' question,
> and you're trying to use it as a straw man; assigning to me a belief I
> just don't have.
It *is* relevant.
Why are you ignoring the ATA example? Which is exactly the same
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote:
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
And I told you that you could just improve the tools that track
those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that
just uses
Matt Mackall wrote:
On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote:
But Alan makes a reasonable suggestion -- we could work around this in
the tools too.
I wouldn't call it "work around this" in the tools. It's a
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
And I told you that you could just improve the tools that track those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that just
uses curses for most things), hitting ? shows what
David Woodhouse wrote:
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
On Mon, 5 Feb 2007, David Woodhouse wrote:
The netfilter example is totally irrelevant here, since 'select' is
neither necessary nor sufficient for that. Russell and I have both
pointed that out to you already.
Linus Torvalds wrote:
On Mon, 5 Feb 2007, David Woodhouse wrote:
Ten years ago, people used 'depends on' to fix the tools, so that then
you want to enable something like USB_STORAGE, it can automatically turn
SCSI on for you.
Isn't that what you wanted?
Try it. It's not what it does.
If
On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote:
> I'd be happy to turn this into CONFIG_NONSTANDARD or
> CONFIG_EXPERT, which is how I described it in the Kconfig help texts:
>
> menuconfig EMBEDDED
> bool "Configure standard kernel features (for small systems)"
>
I'm with Linus 100% here.
It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.
The reason being, that /proc/acpi/alarm no longer exists,
and the kernel option to configure it has
On Mon, 5 February 2007 15:09:15 -0800, Linus Torvalds wrote:
>
> Why? You could *trivially* have a tool tell you. Make "xconfig" or
> something just pop up a window saying "sorry, you can't disable SCSI,
> because you've got ATA enabled, and ATA wants SCSI".
That would be useful for both
On Mon, 5 Feb 2007, Ingo Oeser wrote:
> On Monday, 5. February 2007, Linus Torvalds wrote:
> > So thank God for the few selects we have, and we should add a whole lot
> > more!
>
> But "select" is not fine grained enough.
>
> I would like to have "require", "recommend", "suggest" for feature
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > The netfilter example is totally irrelevant here, since 'select' is
> > neither necessary nor sufficient for that. Russell and I have both
> > pointed that out to you already.
>
> No,
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
On Mon, 5 Feb 2007, David Woodhouse wrote:
The netfilter example is totally irrelevant here, since 'select' is
neither necessary nor sufficient for that. Russell and I have both
pointed that out to you already.
No, the example
On Mon, 5 Feb 2007, Ingo Oeser wrote:
On Monday, 5. February 2007, Linus Torvalds wrote:
So thank God for the few selects we have, and we should add a whole lot
more!
But select is not fine grained enough.
I would like to have require, recommend, suggest for feature A.
require X
On Mon, 5 February 2007 15:09:15 -0800, Linus Torvalds wrote:
Why? You could *trivially* have a tool tell you. Make xconfig or
something just pop up a window saying sorry, you can't disable SCSI,
because you've got ATA enabled, and ATA wants SCSI.
That would be useful for both select and
I'm with Linus 100% here.
It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.
The reason being, that /proc/acpi/alarm no longer exists,
and the kernel option to configure it has
On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote:
I'd be happy to turn this into CONFIG_NONSTANDARD or
CONFIG_EXPERT, which is how I described it in the Kconfig help texts:
menuconfig EMBEDDED
bool Configure standard kernel features (for small systems)
help
Linus Torvalds wrote:
On Mon, 5 Feb 2007, David Woodhouse wrote:
Ten years ago, people used 'depends on' to fix the tools, so that then
you want to enable something like USB_STORAGE, it can automatically turn
SCSI on for you.
Isn't that what you wanted?
Try it. It's not what it does.
If
David Woodhouse wrote:
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
On Mon, 5 Feb 2007, David Woodhouse wrote:
The netfilter example is totally irrelevant here, since 'select' is
neither necessary nor sufficient for that. Russell and I have both
pointed that out to you already.
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
snip
And I told you that you could just improve the tools that track those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that just
uses curses for most things), hitting ? shows what
Matt Mackall wrote:
On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote:
But Alan makes a reasonable suggestion -- we could work around this in
the tools too.
I wouldn't call it work around this in the tools. It's a
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote:
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
snip
And I told you that you could just improve the tools that track
those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that
just
On Tue, 6 Feb 2007, David Woodhouse wrote:
It's a bad example because it's not relevant to the 'select' question,
and you're trying to use it as a straw man; assigning to me a belief I
just don't have.
It *is* relevant.
Why are you ignoring the ATA example? Which is exactly the same
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our depend keyword. Things which
don't have their depend
Matt Mackall wrote:
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our depend keyword. Things which
don't have
On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
WE WANT TO BE NICE.
- the firewall example was not an example of 'select', but of the we
want to be nice. But you simply DID NOT GET IT.
It's a very clever straw man, Linus, but it's still bogus. Not only do I
_agree_ about the
On 2/6/07, Matt Mackall [EMAIL PROTECTED] wrote:
A number of current users are indeed bogus. Stuff like:
config SUPERH
bool
default y
select EMBEDDED
Just because you're using a SuperH board doesn't mean you want to turn
off standard features.
I disagree. I did the
On Tue, 06 Feb 2007 22:38:04 + David Woodhouse wrote:
On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
WE WANT TO BE NICE.
- the firewall example was not an example of 'select', but of the we
want to be nice. But you simply DID NOT GET IT.
It's a very clever straw
On Tue, 6 Feb 2007, Haavard Skinnemoen wrote:
I disagree. I did the exact same thing on AVR32 because !EMBEDDED
forces on tons of crap that just isn't useful on many embedded
platforms.
I do agree. EMBEDDED largely means non-generic/non-standard these days.
It's also true that EMBEDDED
On Tue, 6 Feb 2007, David Woodhouse wrote:
I claim that there are _better_ ways to do it than 'select'.
I don't think you've ever showed any such example.
And if you did, it would all boil down to *exactly* what 'select' does:
config options that get set automatically based on other
On Tue, 6 Feb 2007, Randy Dunlap wrote:
Yes, that's the solution that I decided on during lunch also:
select == depends on
I think yuou can certainly enable an expert mode, which just reads
select as depends on.
You'll probably have to do *more* changes to the tools than my
On Tue, 2007-02-06 at 14:53 -0800, Linus Torvalds wrote:
I don't think you've ever showed any such example.
And if you did, it would all boil down to *exactly* what 'select' does:
config options that get set automatically based on other choices.
That's one option which I don't think I've
On Tue, 6 Feb 2007, Linus Torvalds wrote:
On Tue, 6 Feb 2007, Randy Dunlap wrote:
Yes, that's the solution that I decided on during lunch also:
select == depends on
I think yuou can certainly enable an expert mode, which just reads
select as depends on.
Actually, it's
On Tue, 2007-02-06 at 15:11 -0800, Linus Torvalds wrote:
On Tue, 6 Feb 2007, Randy Dunlap wrote:
But it doesn't matter. I'll come up with a hack for the tools which make
them (optionally) treat 'select' of a user-visible option as if it
was just 'depends on'. And that should fix the
On Tue, 6 Feb 2007, David Woodhouse wrote:
The other possibility which comes to mind, and which I _have_ seen
implemented, is not to hide the disabled option but to _show_ it, and
represent its dependencies right there next to it somehow.
That would probably work, especially if you had
On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
(Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
still want to be able to see the question about NFSv8.1, which only works
on top of IPV6. I might not even *know* I want IPV6, but I know my company
uses
On Tue, 06 Feb 2007 23:36:23 + David Woodhouse wrote:
On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
(Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
still want to be able to see the question about NFSv8.1, which only works
on top of IPV6. I might
On Tue, 2007-02-06 at 15:41 -0800, Randy Dunlap wrote:
It's quite subjective. E.g., I made/submitted a patch maybe 1 year
ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI,
etc.) into one localized place in the menu structure.
OK, perhaps I wasn't persistent enough, but no
On Tue, 6 Feb 2007, David Woodhouse wrote:
Out of interest, which people would this be? Not me, certainly.
I _use_ select, for options which don't have questions. There were two
such instances in the context of Ingo's mail of $subject, even.
And the thing Randy was saying yes to, which
On Tue, 6 Feb 2007, Randy Dunlap wrote:
Besides this select business, Bill (or someone :) mentioned a
feature that I requested about 8 months ago: the ability to disable
or enable groups of drivers at one swoop.
i vaguely recall that *i* was pushing that idea, and even submitted a
couple
On Tue, 6 Feb 2007, David Woodhouse wrote:
Really, if our config is set up in sensible submenus (as in general it
_is_), the see everything behaviour really isn't bad.
There are two fundamental problems with that statement:
- no, it really isn't always
Quite often, our Kconfig files
On Tue, 2007-02-06 at 15:55 -0800, Linus Torvalds wrote:
On Tue, 6 Feb 2007, David Woodhouse wrote:
Really, if our config is set up in sensible submenus (as in general it
_is_), the see everything behaviour really isn't bad.
There are two fundamental problems with that statement:
-
On Wed, 7 Feb 2007, David Woodhouse wrote:
It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that get you.
Let me mention (again) USB_STORAGE and ATA.
They are
Linus Torvalds wrote:
On Wed, 7 Feb 2007, David Woodhouse wrote:
It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that get you.
Let me mention (again)
On Tue, 2007-02-06 at 16:21 -0800, Linus Torvalds wrote:
On Wed, 7 Feb 2007, David Woodhouse wrote:
It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that
On Wed, 7 Feb 2007, David Woodhouse wrote:
I think 'make oldconfig_noselect' is the way forward. We can both have
what we want.
Actually, I think there might be an even more interesting schenario.
The Kconfig language right not is ternary, which is fine as an arithmetic,
but the problem
On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
> On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote:
> > But Alan makes a reasonable suggestion -- we could work around this in
> > the tools too.
>
> I wouldn't call it "work around this" in the tools. It's a useful
>
On Mon, Feb 05, 2007 at 09:17:52PM +, David Woodhouse wrote:
> On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote:
> > More importantly, some things that *are* visible probably shouldn't be, or
> > should perhaps only be in expert mode (aka "EMBEDDED").
>
> I've heard some fairly stupid
On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote:
> But Alan makes a reasonable suggestion -- we could work around this in
> the tools too.
I wouldn't call it "work around this" in the tools. It's a useful
feature we can add in the tools for developers who aren't men enough
to
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
And I told you that you could just improve the tools that track those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that
just uses curses for most things), hitting ? shows what depends or
selects any
Linus Torvalds wrote:
I also feel that a lot of people are "advanced" in one area, but not
necessarily in another. The Netfilter example I gave was one such personal
gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
knowledge, but I *still* want to be baby-fed with
On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> The netfilter example is totally irrelevant here, since 'select' is
> neither necessary nor sufficient for that. Russell and I have both
> pointed that out to you already.
No, the example IS relevant.
Why?
Because you don't seem to be getting
On Mon, 2007-02-05 at 15:09 -0800, Linus Torvalds wrote:
> I also feel that a lot of people are "advanced" in one area, but not
> necessarily in another. The Netfilter example I gave was one such personal
> gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
> knowledge,
On Mon, 5 Feb 2007, Randy Dunlap wrote:
>
> I think the problem is "who is make *config" for?".
Absolutely.
> Linus wants it to be for (unadvanced) users, but they tend to just
> use distro kernels and distro configs, according to David, and I
> agree with that.
Well, the thing is, according
On Mon, 5 Feb 2007 14:21:41 -0800 (PST) Linus Torvalds wrote:
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > Ten years ago, people used 'depends on' to fix the tools, so that then
> > you want to enable something like USB_STORAGE, it can automatically turn
> > SCSI on for you.
> >
> >
On Mon, 5 Feb 2007, Alan wrote:
>
> It works both ways. If I don't need to know that I must select SCSI then
> it turns on easily. If I want to turn SCSI off then it causes mayhem. Two
> sides of the same coin.
They are not really symmetric, though.
There's two big issues:
- tuning things
On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> Ten years ago, people used 'depends on' to fix the tools, so that then
> you want to enable something like USB_STORAGE, it can automatically turn
> SCSI on for you.
>
> Isn't that what you wanted?
Try it. It's not what it does.
If you have a
> > Really? Including the 'Scanner driver' card which arrived with my
> > scanner?
>
> Can you read? Can you UNDERSTAND?
>
> This is exactly my point.
>
> If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI".
> It should be on its own and "select SCSI".
It works both
On Mon, 2007-02-05 at 13:49 -0800, Linus Torvalds wrote:
> Can you read? Can you UNDERSTAND?
>
> This is exactly my point.
>
> If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI".
> It should be on its own and "select SCSI".
>
> The whole AND ALMOST ONLY point of "depends
On Mon, 5 Feb 2007, David Woodhouse wrote:
> On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote:
> > Right. Because for MOST scsi drivers, it's obvious that they are SCSI to
> > the user.
>
> Really? Including the 'Scanner driver' card which arrived with my
> scanner?
Can you read? Can
On Mon, 2007-02-05 at 21:50 +, Alan wrote:
> > No, you're thinking of something else. The use of 'select' just turns
> > the problem backwards -- if _every_ SCSI hostadapter were to 'select
> > SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> > one of them instead of
On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote:
> Right. Because for MOST scsi drivers, it's obvious that they are SCSI to
> the user.
Really? Including the 'Scanner driver' card which arrived with my
scanner?
Is that like the 'RAID' card which is obviously RAID to the user, and
not at
> No, you're thinking of something else. The use of 'select' just turns
> the problem backwards -- if _every_ SCSI hostadapter were to 'select
> SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> one of them instead of being able to just say 'n' to SCSI as I can at
> the
On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> No, you're thinking of something else. The use of 'select' just turns
> the problem backwards -- if _every_ SCSI hostadapter were to 'select
> SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> one of them instead of being
On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote:
> More importantly, some things that *are* visible probably shouldn't be, or
> should perhaps only be in expert mode (aka "EMBEDDED").
I've heard some fairly stupid abuse of the term 'embedded' in my time,
but rarely have I heard people
On Monday, 5. February 2007, Linus Torvalds wrote:
> So thank God for the few selects we have, and we should add a whole lot
> more!
But "select" is not fine grained enough.
I would like to have "require", "recommend", "suggest" for feature A.
require X
does not work without X, but X
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Me, I'd like to say I want "default firewall built in", and not have
> to see *any* of the crap. And that's exactly why "select" is a good
> thing.
yeah. For a long time i wanted to do something like that for all the
kernel debugging options, to
On Mon, Feb 05, 2007 at 08:58:10AM -0800, Linus Torvalds wrote:
> On Mon, 5 Feb 2007, Ingo Molnar wrote:
> >
> > but this is /only/ practical if all (even disabled) features are visible
> > (and selectable) in the tools. They are not at the moment, so selects
> > are quite useful.
>
> More
On Mon, Feb 05, 2007 at 05:52:33PM +0100, Ingo Molnar wrote:
>
> * Russell King <[EMAIL PROTECTED]> wrote:
>
> > and the rest (ie, except integrator, versatile and ixp4xx) has:
> >
> > config ARCH_SHARK
> > bool "Shark"
> > select PCI
> >
> > IOW, the "PCI support" question
On Mon, 5 Feb 2007, Ingo Molnar wrote:
>
> but this is /only/ practical if all (even disabled) features are visible
> (and selectable) in the tools. They are not at the moment, so selects
> are quite useful.
More importantly, some things that *are* visible probably shouldn't be, or
should
* Russell King <[EMAIL PROTECTED]> wrote:
> and the rest (ie, except integrator, versatile and ixp4xx) has:
>
> config ARCH_SHARK
> bool "Shark"
> select PCI
>
> IOW, the "PCI support" question isn't offered for platforms which
> require PCI to be present, but is offered on
On Mon, 2007-02-05 at 08:32 -0800, Linus Torvalds wrote:
>
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > Secondly, please don't _ever_ use 'select'.
>
> No, David.
>
> I don't know why you keep repeating this mantra, when it's WRONG.
It may not shock you to find that I repeat it
1 - 100 of 154 matches
Mail list logo
