Non-intuitive kernel config change
I just upgraded to hamm, and with that I moved from a hand-patched
2.0.30 kernel to kernel-source-2.0.34. I made a kernel package and
installed it, only to discover that the ISO 9660 file system was not
built, because I didn't compile in NLS support.
This is made particularly tricky by "make menuconfig", since the
dialog-based menus don't even show the ISO 9660 file system as an
option UNLESS you ask for NLS support. So it's non-intuitive, from my
perspective. It took me some time to find out the proper menu options
I needed (actually, I was about to post a bug, but then I searched for
bugs against kernel-source-2.0.34 and discovered a rejected patch from
someone who had the same problem with FAT fs support.
I've got a few questions about this:
- Why is NLS required for a kernel that supports FAT and ISO? I ask
this mostly out of ignorance; it's been a long time since I used
DOS, but I never remember having to do anything special
codepage-wise to get CDROMs to work.
- Why does menuconfig work this way? From my perspective, it's
backward. It would seem to me more logical to prompt for the ISO
and/or FAT fs, and then indicate that the NLS was being
included. (This is consistent with other things in the kernel
config; the one that leaps to mind is IP masquerading, where the
config automatically builds module versions of the various
masquerade shims if you enable the masquerading feature.)
- Does the "non-SCSI/IDE/ATAPI CDROM support" logic in the kernel
config force the appropriate options for ISO support? Perhaps there
should be an option under "CD-ROM Drivers" that selects support for
SCSI/IDE/ATAPI drives, and have that one force all the various
support options as well.
- Can someone give a reason why one would want to generate a kernel
with CDROM support that *didn't* have ISO 9660 support? Other than
the fact that the fs code isn't required to play audio CDs?
- Jim
--
Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
Reply to: