Messages in this thread Patch in this message | | | Date | Sun, 22 Nov 1998 13:17:47 +0000 (GMT) | From | Riley Williams <> | Subject | 2.0.36 and "make menuconfig" |
| |
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/
| |