linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* some kernel config menu suggested tweaks
@ 2003-07-24 17:05 Robert P. J. Day
  2003-07-26 12:14 ` Tomas Szepe
  0 siblings, 1 reply; 13+ messages in thread
From: Robert P. J. Day @ 2003-07-24 17:05 UTC (permalink / raw)
  To: Linux kernel mailing list


  from my experimenting with 2.6.0-test1-bk2:


1) i mentioned this before, i think, but after one deselects
   Power management, should ACPI Support and CPU Frequency
   scaling still be available?

   the "make xconfig" menu display suggests a submenu 
   structure there, which clearly isn't the case.


2) can all of the low-level SCSI drivers be made deselectable
   in one swell foop?  folks might want SCSI support just for
   generic support and SCSI (ide-scsi) emulation, but have no
   interest in low level SCSI drivers.

   so it would be convenient to be able to select the generic
   support, and yet not have to deselect low-level drivers
   and PCMCIA SCSI adapter support painfully, one at a time.

3) can all of ATM support be deselected with a single click?
   in the same way "PCMCIA network device support" is done just
   above it under "Networking options"?

rday

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-24 17:05 some kernel config menu suggested tweaks Robert P. J. Day
@ 2003-07-26 12:14 ` Tomas Szepe
  2003-07-26 12:30   ` Robert P. J. Day
  0 siblings, 1 reply; 13+ messages in thread
From: Tomas Szepe @ 2003-07-26 12:14 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux kernel mailing list

> [rpjday@mindspring.com]
> 
> 1) i mentioned this before, i think, but after one deselects
>    Power management, should ACPI Support and CPU Frequency
>    scaling still be available?
> 
>    the "make xconfig" menu display suggests a submenu 
>    structure there, which clearly isn't the case.

Why don't you go ahead and send a patch?

> 2) can all of the low-level SCSI drivers be made deselectable
>    in one swell foop?  folks might want SCSI support just for
>    generic support and SCSI (ide-scsi) emulation, but have no
>    interest in low level SCSI drivers.

Add a SCSI lowlevel drivers submenu (~4 lines of Kconfig).

> 3) can all of ATM support be deselected with a single click?
>    in the same way "PCMCIA network device support" is done just
>    above it under "Networking options"?

Send a patch.

-- 
Tomas Szepe <szepe@pinerecords.com>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-26 12:14 ` Tomas Szepe
@ 2003-07-26 12:30   ` Robert P. J. Day
  2003-07-26 13:01     ` Tomas Szepe
  2003-07-26 13:45     ` Randy.Dunlap
  0 siblings, 2 replies; 13+ messages in thread
From: Robert P. J. Day @ 2003-07-26 12:30 UTC (permalink / raw)
  To: Tomas Szepe; +Cc: Linux kernel mailing list

On Sat, 26 Jul 2003, Tomas Szepe wrote:

> > [rpjday@mindspring.com]
> > 
> > 1) i mentioned this before, i think, but after one deselects
> >    Power management, should ACPI Support and CPU Frequency
> >    scaling still be available?
> > 
> >    the "make xconfig" menu display suggests a submenu 
> >    structure there, which clearly isn't the case.
> 
> Why don't you go ahead and send a patch?
> 
> > 2) can all of the low-level SCSI drivers be made deselectable
> >    in one swell foop?  folks might want SCSI support just for
> >    generic support and SCSI (ide-scsi) emulation, but have no
> >    interest in low level SCSI drivers.
> 
> Add a SCSI lowlevel drivers submenu (~4 lines of Kconfig).
> 
> > 3) can all of ATM support be deselected with a single click?
> >    in the same way "PCMCIA network device support" is done just
> >    above it under "Networking options"?
> 
> Send a patch.

i'd be happy to, but based on my previous experience sending
in a few patches, it's just not worth the aggravation any more.

just one of my patches that got adopted took, literally, several
weeks of being dropped on the floor with no reason why.  and i
had to resubmit it, slightly updated, for every BK rev of the
kernel since the previous patch wouldn't apply cleanly --
it might be a line or two off, which would require remaking
the patch and resubmitting it *again*.  at which point, it
would be dropped on the floor *again*.

don't get me wrong -- i understand that there has to be some
form of QA in accepting kernel patches, and after a while, 
regular submitters can build up a reputation.

but, at this point, it's not terribly useful to encourage people
to submit patches if those patches are just tossed.

it's like the classic catch-22:

  "we can't hire you.  you don't have enough experience doing
    this job."
  "ok, so how do i get experience?"
  "well, you have to do this job for a while."

uh, right.  so, while there's not much point in my submitting
patches, i can still toss suggestions from the sidelines, unless
you have some ideas.  i'm certainly open to advice.

rday

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-26 12:30   ` Robert P. J. Day
@ 2003-07-26 13:01     ` Tomas Szepe
  2003-07-26 13:45     ` Randy.Dunlap
  1 sibling, 0 replies; 13+ messages in thread
From: Tomas Szepe @ 2003-07-26 13:01 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux kernel mailing list

> > Send a patch.
> 
> i'd be happy to, but based on my previous experience sending
> in a few patches, it's just not worth the aggravation any more.

Well, you know the Gandhi routine: Whatever you do will be
insignificant, but it is very important that you do it.

> just one of my patches that got adopted took, literally, several
> weeks of being dropped on the floor with no reason why.

Trivial patches need to go to people like AC who tend to focus
on aggregating fixes and are in a much better position to push
upstream.

>   "we can't hire you.  you don't have enough experience doing
>     this job."
>   "ok, so how do i get experience?"
>   "well, you have to do this job for a while."

At which point you must get yossarian-ish enough to start a company.

-- 
Tomas Szepe <szepe@pinerecords.com>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-26 12:30   ` Robert P. J. Day
  2003-07-26 13:01     ` Tomas Szepe
@ 2003-07-26 13:45     ` Randy.Dunlap
  1 sibling, 0 replies; 13+ messages in thread
From: Randy.Dunlap @ 2003-07-26 13:45 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: szepe, linux-kernel

On Sat, 26 Jul 2003 08:30:59 -0400 (EDT) "Robert P. J. Day" <rpjday@mindspring.com> wrote:

| On Sat, 26 Jul 2003, Tomas Szepe wrote:
| 
| > > [rpjday@mindspring.com]
| > > 
| > > 1) i mentioned this before, i think, but after one deselects
| > >    Power management, should ACPI Support and CPU Frequency
| > >    scaling still be available?
| > > 
| > >    the "make xconfig" menu display suggests a submenu 
| > >    structure there, which clearly isn't the case.
| > 
| > Why don't you go ahead and send a patch?

Ditto.  the right response.

| i'd be happy to, but based on my previous experience sending
| in a few patches, it's just not worth the aggravation any more.
| 
| just one of my patches that got adopted took, literally, several
| weeks of being dropped on the floor with no reason why.  and i
| had to resubmit it, slightly updated, for every BK rev of the
| kernel since the previous patch wouldn't apply cleanly --
| it might be a line or two off, which would require remaking
| the patch and resubmitting it *again*.  at which point, it
| would be dropped on the floor *again*.
| 
| don't get me wrong -- i understand that there has to be some
| form of QA in accepting kernel patches, and after a while, 
| regular submitters can build up a reputation.

and the QA is on patches, not (so much) on dialog.

| but, at this point, it's not terribly useful to encourage people
| to submit patches if those patches are just tossed.
| 
| it's like the classic catch-22:
| 
|   "we can't hire you.  you don't have enough experience doing
|     this job."
|   "ok, so how do i get experience?"
|   "well, you have to do this job for a while."
| 
| uh, right.  so, while there's not much point in my submitting
| patches, i can still toss suggestions from the sidelines, unless
| you have some ideas.  i'm certainly open to advice.

But suggestions from the sidelines are just too close to whinging
(Brit. spelling :) and moaning.  Not very helpful.

--
~Randy

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
@ 2003-07-26 15:20 John Bradford
  0 siblings, 0 replies; 13+ messages in thread
From: John Bradford @ 2003-07-26 15:20 UTC (permalink / raw)
  To: rpjday, szepe; +Cc: john, linux-kernel

> I'm merely thinking of turning your submenus into sub-entries
> in the main fs menu, because as John has pointed out, the submenus
> are rather annoying.

Having them as sub-entries would be an improvement all-round, (in my
opinion).

As well as improving the usability of make menuconfig, it's also
better for the make config configurator, because that decends in to
submenus automatically, whereas it prompts for sub-entries.

John.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-26 13:07   ` Robert P. J. Day
@ 2003-07-26 14:33     ` Tomas Szepe
  0 siblings, 0 replies; 13+ messages in thread
From: Tomas Szepe @ 2003-07-26 14:33 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: John Bradford, linux-kernel

> [rpjday@mindspring.com]
> 
> i give up.  you encourage me to send in patches, then an hour
> later announce that you're submitting a patch to, as i read it,
> undo my previous "horrid" submission?

A bit on the black-or-white side, aren't we today?

I'm merely thinking of turning your submenus into sub-entries
in the main fs menu, because as John has pointed out, the submenus
are rather annoying.

> are you schizophrenic, or just simply a jerk?  really, enquiring
> minds would like to know.

Damn, you really do need to take a break.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-26 12:52 ` Tomas Szepe
@ 2003-07-26 13:07   ` Robert P. J. Day
  2003-07-26 14:33     ` Tomas Szepe
  0 siblings, 1 reply; 13+ messages in thread
From: Robert P. J. Day @ 2003-07-26 13:07 UTC (permalink / raw)
  To: Tomas Szepe; +Cc: John Bradford, linux-kernel

On Sat, 26 Jul 2003, Tomas Szepe wrote:

> > [john@grabjohn.com]
> > 
> > The filesystem menu, for example, I could previously just skip down in
> > make menuconfig, selecting and deselecting what I wanted.  Now, I have
> > to go in and out, and in and out, just to see what's selected and
> > what's not.  Sure, it might look nice to a new user who doesn't like
> > to see a lot of options they don't necessarily understand, but it
> > wastes the time of more experienced users.
> 
> I'll be sending a patch to fix up this horrid thing shortly.

i give up.  you encourage me to send in patches, then an hour
later announce that you're submitting a patch to, as i read it,
undo my previous "horrid" submission?

are you schizophrenic, or just simply a jerk?  really, enquiring
minds would like to know.

time to take a break and go to the gym.  i can't take much more
of this idiocy.

rday



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-24 19:10 John Bradford
  2003-07-24 19:53 ` Petr Vandrovec
@ 2003-07-26 12:52 ` Tomas Szepe
  2003-07-26 13:07   ` Robert P. J. Day
  1 sibling, 1 reply; 13+ messages in thread
From: Tomas Szepe @ 2003-07-26 12:52 UTC (permalink / raw)
  To: John Bradford; +Cc: rpjday, linux-kernel

> [john@grabjohn.com]
> 
> The filesystem menu, for example, I could previously just skip down in
> make menuconfig, selecting and deselecting what I wanted.  Now, I have
> to go in and out, and in and out, just to see what's selected and
> what's not.  Sure, it might look nice to a new user who doesn't like
> to see a lot of options they don't necessarily understand, but it
> wastes the time of more experienced users.

I'll be sending a patch to fix up this horrid thing shortly.

-- 
Tomas Szepe <szepe@pinerecords.com>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-24 19:10 John Bradford
@ 2003-07-24 19:53 ` Petr Vandrovec
  2003-07-26 12:52 ` Tomas Szepe
  1 sibling, 0 replies; 13+ messages in thread
From: Petr Vandrovec @ 2003-07-24 19:53 UTC (permalink / raw)
  To: John Bradford; +Cc: rpjday, linux-kernel

On Thu, Jul 24, 2003 at 08:10:32PM +0100, John Bradford wrote:
> 
> The filesystem menu, for example, I could previously just skip down in
> make menuconfig, selecting and deselecting what I wanted.  Now, I have
> to go in and out, and in and out, just to see what's selected and
> what's not.  Sure, it might look nice to a new user who doesn't like
> to see a lot of options they don't necessarily understand, but it
> wastes the time of more experienced users.

I think we should use "[X] OptionMenu -->" variant USB Gadgets use
where possible. Currently for example IDE code is

ATA/ATAPI/MFM/RLL support -->
    <*> ATA/ATAPI/MFM/RLL support
    IDE, ATA and ATAPI Block devices -->
        <*> Enhandced IDE/MFM/RLL disk/cdrom/...

One level can be completely removed by doing

<*> ATA/ATAPI/MFF/RLL support -->

directly in toplevel menu. Then you do not have to open most of
the menus, as if there is no checkmark before submenu entry, there is
definitely nothing selected below. 

And after all, there is also "make menuconfig MENUCONFIG_MODE=single_menu".
Unfortunately it starts with all nodes closed, and '*' (which I'm used
to use for unrolling complete subtree) does nothing. And
second problem is that "<*> XXX -->" does not work as expected in
single_menu mode, it still creates its own submenu, which kinda complicates
things.
						Best regards,
							Petr Vandrovec



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
@ 2003-07-24 19:10 John Bradford
  2003-07-24 19:53 ` Petr Vandrovec
  2003-07-26 12:52 ` Tomas Szepe
  0 siblings, 2 replies; 13+ messages in thread
From: John Bradford @ 2003-07-24 19:10 UTC (permalink / raw)
  To: john, rpjday; +Cc: linux-kernel

> > > 1) i mentioned this before, i think, but after one deselects
> > >    Power management, should ACPI Support and CPU Frequency
> > >    scaling still be available?
> > >
> > >    the "make xconfig" menu display suggests a submenu 
> > >    structure there, which clearly isn't the case.
> > >
> > >
> > > 2) can all of the low-level SCSI drivers be made deselectable
> > >    in one swell foop?  folks might want SCSI support just for
> > >    generic support and SCSI (ide-scsi) emulation, but have no
> > >    interest in low level SCSI drivers.
> > >
> > >    so it would be convenient to be able to select the generic
> > >    support, and yet not have to deselect low-level drivers
> > >    and PCMCIA SCSI adapter support painfully, one at a time.
> > >
> > > 3) can all of ATM support be deselected with a single click?
> > >    in the same way "PCMCIA network device support" is done just
> > >    above it under "Networking options"?
> > 
> > A lot of these add extra complications for anybody not wanting a
> > 'simple' kernel config.  _Please_ don't re-design everything the same
> > way as the once-simple filesystems menu.
> > 
> > Too much prompting is irritating for advanced users, and they are the
> > people who are likely to compiling the most kernels, rather than
> > sticking with the kernel that came with their distribution.
>
> ok, this one i *am* going to take a stand on -- you're making no
> sense whatsoever, so just put down the keyboard and step back.
>
> all of the above three suggestions are for the purpose of either
> simplifying the current menu structure or making it more consistent
> with the way the rest of the menus are presented.  none of them
> increase the complexity of *anything*.
>
> how the heck can you refer to "A lot of these" in the context
> of three suggestions?  get a grip, dude.
>
> and as the complete rookie who took it upon himself to learn
> the Kconfig structure so i could bring some order to the filesystems
> menu, well, frankly, i *like* that structure, and i haven't heard
> any complaints.  you seriously think the original structure was
> *clearer*?
>
> since i don't have the ability to actually hack down at the code
> level, i figured i could still contribute by making it easier for
> newbies like myself with simpler and more consistent menus.
> apparently, this might not be worth the effort after all.
>
> thanks ever so much for the encouragement.

It's not personal, please accept my apologies if it seemed that way,
it's just a co-incidence that the couple of things I don't like were
done by you :-).

The point I'm trying to make is that if you've been using Linux for
years, all these 'clean-ups', that might seem to make things easier
and more organised for new users, really just add extra levels of
indirection for experienced users.

The filesystem menu, for example, I could previously just skip down in
make menuconfig, selecting and deselecting what I wanted.  Now, I have
to go in and out, and in and out, just to see what's selected and
what's not.  Sure, it might look nice to a new user who doesn't like
to see a lot of options they don't necessarily understand, but it
wastes the time of more experienced users.

Oh well, I'll just go back to the:

vi .config
make oldconfig

kernel configurator.

:-(.

John.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
  2003-07-24 18:45 John Bradford
@ 2003-07-24 18:49 ` Robert P. J. Day
  0 siblings, 0 replies; 13+ messages in thread
From: Robert P. J. Day @ 2003-07-24 18:49 UTC (permalink / raw)
  To: John Bradford; +Cc: linux-kernel

On Thu, 24 Jul 2003, John Bradford wrote:

> > 1) i mentioned this before, i think, but after one deselects
> >    Power management, should ACPI Support and CPU Frequency
> >    scaling still be available?
> >
> >    the "make xconfig" menu display suggests a submenu 
> >    structure there, which clearly isn't the case.
> >
> >
> > 2) can all of the low-level SCSI drivers be made deselectable
> >    in one swell foop?  folks might want SCSI support just for
> >    generic support and SCSI (ide-scsi) emulation, but have no
> >    interest in low level SCSI drivers.
> >
> >    so it would be convenient to be able to select the generic
> >    support, and yet not have to deselect low-level drivers
> >    and PCMCIA SCSI adapter support painfully, one at a time.
> >
> > 3) can all of ATM support be deselected with a single click?
> >    in the same way "PCMCIA network device support" is done just
> >    above it under "Networking options"?
> 
> A lot of these add extra complications for anybody not wanting a
> 'simple' kernel config.  _Please_ don't re-design everything the same
> way as the once-simple filesystems menu.
> 
> Too much prompting is irritating for advanced users, and they are the
> people who are likely to compiling the most kernels, rather than
> sticking with the kernel that came with their distribution.

ok, this one i *am* going to take a stand on -- you're making no
sense whatsoever, so just put down the keyboard and step back.

all of the above three suggestions are for the purpose of either
simplifying the current menu structure or making it more consistent
with the way the rest of the menus are presented.  none of them
increase the complexity of *anything*.

how the heck can you refer to "A lot of these" in the context
of three suggestions?  get a grip, dude.

and as the complete rookie who took it upon himself to learn
the Kconfig structure so i could bring some order to the filesystems
menu, well, frankly, i *like* that structure, and i haven't heard
any complaints.  you seriously think the original structure was
*clearer*?

since i don't have the ability to actually hack down at the code
level, i figured i could still contribute by making it easier for
newbies like myself with simpler and more consistent menus.
apparently, this might not be worth the effort after all.

thanks ever so much for the encouragement.

rday



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: some kernel config menu suggested tweaks
@ 2003-07-24 18:45 John Bradford
  2003-07-24 18:49 ` Robert P. J. Day
  0 siblings, 1 reply; 13+ messages in thread
From: John Bradford @ 2003-07-24 18:45 UTC (permalink / raw)
  To: linux-kernel, rpjday

> 1) i mentioned this before, i think, but after one deselects
>    Power management, should ACPI Support and CPU Frequency
>    scaling still be available?
>
>    the "make xconfig" menu display suggests a submenu 
>    structure there, which clearly isn't the case.
>
>
> 2) can all of the low-level SCSI drivers be made deselectable
>    in one swell foop?  folks might want SCSI support just for
>    generic support and SCSI (ide-scsi) emulation, but have no
>    interest in low level SCSI drivers.
>
>    so it would be convenient to be able to select the generic
>    support, and yet not have to deselect low-level drivers
>    and PCMCIA SCSI adapter support painfully, one at a time.
>
> 3) can all of ATM support be deselected with a single click?
>    in the same way "PCMCIA network device support" is done just
>    above it under "Networking options"?

A lot of these add extra complications for anybody not wanting a
'simple' kernel config.  _Please_ don't re-design everything the same
way as the once-simple filesystems menu.

Too much prompting is irritating for advanced users, and they are the
people who are likely to compiling the most kernels, rather than
sticking with the kernel that came with their distribution.

John.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2003-07-26 14:58 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-24 17:05 some kernel config menu suggested tweaks Robert P. J. Day
2003-07-26 12:14 ` Tomas Szepe
2003-07-26 12:30   ` Robert P. J. Day
2003-07-26 13:01     ` Tomas Szepe
2003-07-26 13:45     ` Randy.Dunlap
2003-07-24 18:45 John Bradford
2003-07-24 18:49 ` Robert P. J. Day
2003-07-24 19:10 John Bradford
2003-07-24 19:53 ` Petr Vandrovec
2003-07-26 12:52 ` Tomas Szepe
2003-07-26 13:07   ` Robert P. J. Day
2003-07-26 14:33     ` Tomas Szepe
2003-07-26 15:20 John Bradford

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).