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 [EMAIL PROTECTED] < /dev/null
