a few more "make xconfig" inconsistencies

a few more "make xconfig" inconsistencies

[Robert P. J. Day]

  (if any of these observations are going to the wrong list,
or are based on some fundamental misunderstanding of kernel
configuration, please let me know so i can minimize 
my embarrassment. :-)

  before i post any more observations on what i think are 
inconsistencies, here's another example, so i can be sure
that these are worth pointing out:

  even if, under "Networking options", i deselect IPv6,
i'm still presented with an inactive IPv6 Netfilter Configuration
screen.

  is *that* the sort of thing we're talking about?

rday

Re: a few more "make xconfig" inconsistencies

[Tomas Szepe]

> [rpjday@mindspring.com]
>
>   even if, under "Networking options", i deselect IPv6,
> i'm still presented with an inactive IPv6 Netfilter Configuration
> screen.

This is fixed in both 2.4.20 & 2.5.53 as far as I can see.

Could you have a look at 2.5.53's setup screens, though,
and let me know if you can find any inconsistencies there
(I'm sure you can :D)?

>   is *that* the sort of thing we're talking about?

Jup.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: a few more "make xconfig" inconsistencies

[Robert P. J. Day]

On Wed, 1 Jan 2003, Tomas Szepe wrote:

> > [rpjday@mindspring.com]
> >
> >   even if, under "Networking options", i deselect IPv6,
> > i'm still presented with an inactive IPv6 Netfilter Configuration
> > screen.
> 
> This is fixed in both 2.4.20 & 2.5.53 as far as I can see.

i'm looking at 2.4.20 with the 2.4.21-pre2 patch as we speak,
and, under "make xconfig", after deselecting IPv6, i am still
presented with a (deactivated) IPv6 netfilter configuration
dialog.

granted, it's deactivated (is that what you were referring to?)
but it's still presented to me.  this seems to be inconsistent
with one of your recent patches -- don't show arcnet dialog if
arcnet is deselected.

am i understanding all this correctly?
> 
> Could you have a look at 2.5.53's setup screens, though,
> and let me know if you can find any inconsistencies there
> (I'm sure you can :D)?

i'm downloading it as we speak. :-)  but on a more general note,
here's something i was thinking about -- some of the more general
selections should have their overall select button moved up in 
the hierarchy.

case in point:  under "General setup", there are two (what do
you call those things?) selectable entries for "PCMCIA/CardBus
support" and "PCI Hotplug Support".  why not make them selectable
entries, so i can deselect *all* of PCMCIA/Cardbus support 
immediately right there?

as it is, i have to move on to the actual dialog, in which i
can deselect all of it in one click.  there are other examples:
"Networking options" -> "Appletalk protocol support".  right now,
even though it's deselected, the net line reads "Appletalk devices"
and that dialog *will* come up, albeit deactivated.

anyway, i'll switch over to 2.5.53 and let you know what i find.

rday

Re: a few more "make xconfig" inconsistencies

[John Bradford]

> case in point:  under "General setup", there are two (what do
> you call those things?) selectable entries for "PCMCIA/CardBus
> support" and "PCI Hotplug Support".  why not make them selectable
> entries, so i can deselect *all* of PCMCIA/Cardbus support 
> immediately right there?
> 
> as it is, i have to move on to the actual dialog, in which i
> can deselect all of it in one click.  there are other examples:
> "Networking options" -> "Appletalk protocol support".  right now,
> even though it's deselected, the net line reads "Appletalk devices"
> and that dialog *will* come up, albeit deactivated.

The interfaces for the 2.4 and 2.5 xconfig systems are completely
different.

For 2.4, I think it's a very bad idea to not to show the greyed-out
options, because a switch disabling all of them is set.  Having a
switch to disable, for example, all of the power management options is
useful, because they are amoungst other options, and I can just ignore
them and scroll past quickly and easily.

I think it would be a big waste of time if we have to start toggling
options just to see which options are being hidden.

For 2.5, each subcategory can be 'collapsed', so this problem doesn't
really occur.

John.

Re: a few more "make xconfig" inconsistencies

[Robert P. J. Day]

On Wed, 1 Jan 2003, John Bradford wrote:

> The interfaces for the 2.4 and 2.5 xconfig systems are completely
> different.

yup, so i'll just move on to 2.5 and poke around there, and
not spend any more time on 2.4.  thanks.

rday

Re: a few more "make xconfig" inconsistencies

[Robert P. J. Day]

On Wed, 1 Jan 2003, John Bradford wrote:

> For 2.5, each subcategory can be 'collapsed', so this problem doesn't
> really occur.

there's one point i want to verify.  the design of this hierarchical
structure of kernel options is not going to simply affect
"make xconfig", is it?

i'm assuming that the way this hierarchy is designed will affect
*all* of the possible make ???config variations, right?

rday

Re: a few more "make xconfig" inconsistencies

[Tomas Szepe]

> [rpjday@mindspring.com]
> 
> On Wed, 1 Jan 2003, Tomas Szepe wrote:
> 
> > > [rpjday@mindspring.com]
> > >
> > >   even if, under "Networking options", i deselect IPv6,
> > > i'm still presented with an inactive IPv6 Netfilter Configuration
> > > screen.
> > 
> > This is fixed in both 2.4.20 & 2.5.53 as far as I can see.
> 
> i'm looking at 2.4.20 with the 2.4.21-pre2 patch as we speak,
> and, under "make xconfig", after deselecting IPv6, i am still
> presented with a (deactivated) IPv6 netfilter configuration
> dialog.

Oh, I see what you mean.  This behavior is a "feature" of the old
xconfig (it's been so since the 2.0 times or thereabouts). menuconfig
will hide entirely what xconfig merely grays out.

> granted, it's deactivated (is that what you were referring to?)

Right.

> but it's still presented to me.  this seems to be inconsistent
> with one of your recent patches -- don't show arcnet dialog if
> arcnet is deselected.

That's just my word choice sucking noodles as usual.  I should
probably be referring to these changes with something like "make
the submenu dependent on its parent entry," which wouldn't take
for granted any of the pecularities a certain config frontend
might throw in.  You see, in 2.4, config, menuconfig and xconfig
all have their own mechanics for work with Config.in files.
(Ever noticed how menuconfig and xconfig produce different
.config's while the options chosen are identical?)

> am i understanding all this correctly?

Hope this clarifies.

> i'm downloading it as we speak. :-)  but on a more general note,
> here's something i was thinking about -- some of the more general
> selections should have their overall select button moved up in 
> the hierarchy.

Yes, but no one is really fond of the thought of the options getting
rearranged too much.  There's the old "Yes, it's not ideal, but if
you woke me up totally wasted at 3 a.m., I'd know where to look for
CONFIG_HRM0PS54554."

> anyway, i'll switch over to 2.5.53 and let you know what i find.

Thanks.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: a few more "make xconfig" inconsistencies

[John Bradford]

> Oh, I see what you mean.  This behavior is a "feature" of the old
> xconfig (it's been so since the 2.0 times or thereabouts). menuconfig
> will hide entirely what xconfig merely grays out.

I actually like that feature :-(.

On the other hand, the TCL-based config system has gone completely in
2.5.  I look forward to the 2.7 tree opening when hopefully somebody
will bring it back as an extra choice, just for the sake of it :-).

John.

Re: a few more "make xconfig" inconsistencies

[Tomas Szepe]

> [john@grabjohn.com]
> 
> > Oh, I see what you mean.  This behavior is a "feature" of the old
> > xconfig (it's been so since the 2.0 times or thereabouts). menuconfig
> > will hide entirely what xconfig merely grays out.
> 
> I actually like that feature :-(.
> 
> On the other hand, the TCL-based config system has gone completely in
> 2.5.  I look forward to the 2.7 tree opening when hopefully somebody
> will bring it back as an extra choice, just for the sake of it :-).

The new config system provides a generic library for handling kernel
configuration.  My bet is we can expect lots of kernel config frontends
turning up as soon as 2.6 sees the light of the world (and people find
out how great it is :D).

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: a few more "make xconfig" inconsistencies

[John Bradford]

> > > Oh, I see what you mean.  This behavior is a "feature" of the old
> > > xconfig (it's been so since the 2.0 times or thereabouts). menuconfig
> > > will hide entirely what xconfig merely grays out.
> > 
> > I actually like that feature :-(.
> > 
> > On the other hand, the TCL-based config system has gone completely in
> > 2.5.  I look forward to the 2.7 tree opening when hopefully somebody
> > will bring it back as an extra choice, just for the sake of it :-).
> 
> The new config system provides a generic library for handling kernel
> configuration.  My bet is we can expect lots of kernel config frontends
> turning up as soon as 2.6 sees the light of the world (and people find
> out how great it is :D).

Cool - the big disadvantage of the QT-based kernel configurator is
that it takes ages to load on slow boxes, (even on my MMX-200 it's
slow, and that's not _that_ old).

John.

Re: a few more "make xconfig" inconsistencies

[John Bradford]

Another config problem I noticed a while ago:

In 2.5.53, under Old CD-ROM drivers (not SCSI, not IDE), if you select
"Matsushita/Panasonic/Creative, Longshine, TEAC CDROM support", the
help text says:

"This driver can support up to four CD-ROM controller cards, and each
card can support up to four CD-ROM drives; if you say Y here, you will
be asked how many controller cards you have."

The user is not prompted to specify how many controllers they have in
2.5.53, and in 2.4.20-pre2, there are separate options for the 2nd,
3rd, and 4th controllers.

However, I've looked through the code, and I'm not sure if >1
controller is actually supported anymore - a lot of the code for that
seems to be commented out in 2.4.20-pre2, and completely removed in
2.5.53.

John.

Re: a few more "make xconfig" inconsistencies

[Tomas Szepe]

> [john@grabjohn.com]
> 
> In 2.5.53, under Old CD-ROM drivers (not SCSI, not IDE), if you select
> "Matsushita/Panasonic/Creative, Longshine, TEAC CDROM support", the
> help text says:
> 
> "This driver can support up to four CD-ROM controller cards, and each
> card can support up to four CD-ROM drives; if you say Y here, you will
> be asked how many controller cards you have."
> 
> The user is not prompted to specify how many controllers they have in
> 2.5.53, and in 2.4.20-pre2, there are separate options for the 2nd,
> 3rd, and 4th controllers.
> 
> However, I've looked through the code, and I'm not sure if >1
> controller is actually supported anymore - a lot of the code for that
> seems to be commented out in 2.4.20-pre2, and completely removed in
> 2.5.53.

You'll need to ask the driver's maintainer (if there is one at all,
that is).

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: a few more "make xconfig" inconsistencies

[Bill Davidsen]

On Wed, 1 Jan 2003, Tomas Szepe wrote:

> > [john@grabjohn.com]
> > 
> > In 2.5.53, under Old CD-ROM drivers (not SCSI, not IDE), if you select
> > "Matsushita/Panasonic/Creative, Longshine, TEAC CDROM support", the
> > help text says:
> > 
> > "This driver can support up to four CD-ROM controller cards, and each
> > card can support up to four CD-ROM drives; if you say Y here, you will
> > be asked how many controller cards you have."
> > 
> > The user is not prompted to specify how many controllers they have in
> > 2.5.53, and in 2.4.20-pre2, there are separate options for the 2nd,
> > 3rd, and 4th controllers.
> > 
> > However, I've looked through the code, and I'm not sure if >1
> > controller is actually supported anymore - a lot of the code for that
> > seems to be commented out in 2.4.20-pre2, and completely removed in
> > 2.5.53.
> 
> You'll need to ask the driver's maintainer (if there is one at all,
> that is).

Well, someone seems to have changed the behaviour for 2.5, so perhaps the
problem can be addressed if that person can be identified from the patch
log.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.