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 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
* 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-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

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).