2.0.36 and "make menuconfig"

Riley Williams (rhw@bigfoot.com)
Sun, 22 Nov 1998 13:17:47 +0000 (GMT)


Hi Alan.

First, my system setup:

1. Intel P166 with 128M of RAM and 6.4G of HD space, networked with a
PCI bus NE2k clone card and a USR Sportster 33k6/VoiceFax modem.

2. Kernel 2.0.35 source tree downloaded as tarball and patched up to
2.0.36 with the recent patchfile.

3. RedHat 5.0 installed from scratch, since updated via RPM's to RedHat
5.1. In addition, all rpm's referencing libc5 have been updated to
glibc versions, and all update RPM's since have been installed, with
the following exceptions:

procmail-3.11pre7-1.hash2.i386.rpm

This release of procmail is badly broken, as it
appears to need massive configuration changes and
many extra directories, but none of these changes
are documented.

All I know is that whilst I had it installed, ALL
incoming mail was delivered to one file, namely
/var/tmp/dead.letter together with wads of additional
emails informing me that many apparently random
subdirectories of /var/spool/mail didn't exist !!!

I have reverted to procmail-3.10-12.i386.rpm which
works fine.

ImageMagick-4.1.2-1.i386.rpm
rxvt-2.20-6.i386.rpm
vim-5.2-1.i386.rpm
vim-X11-5.1-5.i386.rpm
xscreensaver-3.02-1.i386.rpm

These won't install because of inter-RPM clashes that
I have still to sort out.

Note particularly that the libc5 RPM has been removed from my system,
and it now runs entirely on glibc with the currently installed RPM
being glibc-2.0.7-19.i386.rpm although I understand a later one is
now available.

I have now tried "make menuconfig" out in an xterm under kernel 2.0.36 and
using the 2.0.36 source tree, and I can report that the serious bugs that
existed under earlier kernels do not apply under 2.0.36, and as a result
"make menuconfig" is usable under xterm in X-windows.

However, there are a few niggles that crop up, although they are only
minor ones:

1. When run under the standard Linux console, "make menuconfig" uses
a blue background, and otherwise makes excellent use of the colour
facilities. Running in a xterm session, it reverts to white text on
a black background.

The xterm I run provides full support for colour - indeed, I have
the line "alias ls='ls color=auto -F'" in /etc/bashrc as a default
setting for all my users - so that isn't the reason for this change.

2. Under the version of "make menuconfig" supplied with kernel 2.0.33,
one could press either PgDn or ^V to move down a screenfull of lines,
and PgUp or ^Y to move up by the same amount. Under version 2.0.36,
only the PgDn and PgUp keys work, and these aren't usable in xterm
sessions, making the menus much harder than necessary to navigate.
Would it be possible to reimplement the ^V and ^Y keys as those ARE
usable from xterm.

3. When one moves between menus in "make menuconfig" under an xterm,
the screen that was visible before one typed the "make menuconfig"
flashes up briefly before the new menu appears. To say the least,
this is very disconcerting, and if it can be prevented, that would
be much appreciated.

4. If it finds an error in the configuration script, "make menuconfig"
briefly displays an error message, then clears the screen before
one has time to read it, and just displays a bland message to the
effect of "An error occurred. Please contact that maintainer". It
would be much better in my opinion if the actual error message
remained visible.

Next, I'd like to mention a niggle with "make config" under xterm's that I
discovered as a result of item (4) above. If one uses it, and only wishes
to see/modify an entry near the end of the configuration script, one has a
habit of just holding down the ENTRY key to fast-scroll through the
earlier option.

Doing so under the standard Linux console works fine, but under an xterm
session, the result is that one gets a large group of blank lines followed
by a horrible jumble of options presented nose to tail on a single line.

I would presume that this is due to xterm echoing the input back to the
user before "make config" has a chance to process it, but if there's any
way this can be fixed, it would be a definite advantage in my opinion.

Finally, I'd like to see the enclosed patch applied to the 2.0.36 kernel
to make the filesystems configuration submenu easier to navigate.

===8<=== CUT ===>8===
--- linux/fs/Config.in.orig Mon Jul 13 13:47:34 1998
+++ linux/fs/Config.in Sun Nov 22 11:55:07 1998
@@ -19,6 +19,8 @@
dep_tristate 'MSDOS fs support' CONFIG_MSDOS_FS $CONFIG_FAT_FS
dep_tristate 'umsdos: Unix like fs on top of std MSDOS FAT fs' CONFIG_UMSDOS_FS $CONFIG_MSDOS_FS
dep_tristate 'VFAT (Windows-95) fs support' CONFIG_VFAT_FS $CONFIG_FAT_FS
+ mainmenu_option next_comment
+ comment 'Select available code pages'
dep_tristate 'Codepage 437' CONFIG_NLS_CODEPAGE_437 $CONFIG_NLS
dep_tristate 'Codepage 737' CONFIG_NLS_CODEPAGE_737 $CONFIG_NLS
dep_tristate 'Codepage 775' CONFIG_NLS_CODEPAGE_775 $CONFIG_NLS
@@ -45,6 +47,7 @@
dep_tristate 'NLS ISO 8859-8' CONFIG_NLS_ISO8859_8 $CONFIG_NLS
dep_tristate 'NLS ISO 8859-9' CONFIG_NLS_ISO8859_9 $CONFIG_NLS
dep_tristate 'NLS KOI8-R' CONFIG_NLS_KOI8_R $CONFIG_NLS
+ endmenu
fi

bool '/proc filesystem support' CONFIG_PROC_FS
===8<=== CUT ===>8===

Basically, it moves the codepage selection to a submenu thereof, thus
allowing one to concentrate on the file systems and codepages seperately.
Certainly from a personal point of view, having the available file systems
split either side of selecting the codepages is particularly disconcerting
to use...

I appreciate that this is just a personal wish, and probably runs against
the wishes of the Linux development team, but the suggestion is there
anyway.

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/