Hello again,
Having got the hot and fresh patch, I played around with the new kernel
to see what got fixed and what didn't. All in all, great work as always
- but there are some minor annoyances which remain still. As last time,
I'm posting my observations here in case the issues haven't been spotted
yet.
1. 'make *config' fails with missing header files
On my system I have got no symlinks from /usr/src/linux/include to
/usr/include, as it has turned out their number would have to increase
after switching to 2.6 - before only asm and linux symlinks were
required for me, now there were more (eg. asm-generic and some others I
don't remember) and as a result I began seeing lots of compilation
failures. Eventually I've decided to always access current kernel's
header files by adding
CPATH="/lib/modules/`uname -r`/build/include"; export CPATH
to my profile (by the way, maybe this procedure should be described
somewhere in the README - in the old days one was told to create the
asm, linux and scsi symlinks, now there is nothing). That solved
everything... except one thing: trying to configure the kernel after
patching it and changing the version number in the directory name. The
effect can be seen below:
# pwd
/usr/src/linux
# readlink /usr/src/linux
linux-2.6.5
# make oldconfig
HOSTCC scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:126,
from /usr/include/limits.h:144,
from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/limits.h:122,
from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/syslimits.h:7,
from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/limits.h:11,
from scripts/basic/fixdep.c:105:
/usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or
directory
In file included from /usr/include/netinet/in.h:212,
from scripts/basic/fixdep.c:107:
/usr/include/bits/socket.h:305:24: asm/socket.h: No such file or
directory
scripts/basic/fixdep.c: In function `use_config':
scripts/basic/fixdep.c:193: error: `PATH_MAX' undeclared (first use in
this function)
scripts/basic/fixdep.c:193: error: (Each undeclared identifier is
reported only once
scripts/basic/fixdep.c:193: error: for each function it appears in.)
scripts/basic/fixdep.c:193: warning: unused variable `s'
scripts/basic/fixdep.c: In function `parse_dep_file':
scripts/basic/fixdep.c:289: error: `PATH_MAX' undeclared (first use in
this function)
scripts/basic/fixdep.c:289: warning: unused variable `s'
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2
#
While I know putting the version number in the kernel directory name is
frowned upon by Linus, I am not the only person doing it this way.
Besides, a solution for this particular problem seems to be trivial -
adding '-I/path/to/kernel/include' to the primary Makefile will take
care of the problem easily.
2. Platform-specific 'asm' symlink doesn't get created by 'make *config'
I have got no idea how this could have slipped everyone's attention, but
here it is:
# make menuconfig
HOSTCC scripts/basic/fixdep
In file included from /usr/include/netinet/in.h:212,
from scripts/basic/fixdep.c:107:
/usr/include/bits/socket.h:305:24: asm/socket.h: No such file or
directory
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2
The same happens with oldconfig and config. I have to go to include and
execute 'ln -s asm-i386 asm' by hand to be able to continue.
3. 'make clean' seems to remove too much
It seems some people cannot be satisfied... Before I complained about
leftover junk, now I'm complaining about too few leftovers! Anyway, what
goes away with 'clean' which I believe should only go away with
'mrproper':
- the include/asm symlink
- include/linux/autoconf.h
Maybe there are more, but these are the two I have already found to
cause software compilation errors when not present.
4. Floppy LED remains on whenever LILO boots the kernel quickly
I have only got half a second delay between "LILO" and "Loading Linux",
where "Linux" is the name of my primary kernel. My floppy driver is a
module and isn't loaded by any of the startup scripts. Now, if I delay
the boot (e.g. by typing in command-line parameters for LILO or the
kernel) till after the floppy drive's LED has gone off (after the boot
disk search - my boot sequence is A:,C:) everything works fine - but if
I let the 2.6 kernel boot immediately, the LED remains on indefinitely
(i.e. until the floppy module gets loaded or I reboot the system). Under
2.4 with floppy support built as a module as well, the light is allowed
to go off no matter how quickly I boot the kernel).
5. "Default NLS charset" option is ignored for Joliet filesystems
All my consoles are ISO-8859-2, so the NLS part of my .config looks like
this (all the "not set" lines omitted for brevity):
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-2"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_2=m
The above works fine for vfat. However, whenever I try to mount an
iso9660+Joliet filesystem without specifying the charset explicitly, I
get "Unable to load NLS charset iso8859-1" in kernel logs.
Please note this is NOT a 2.6-specific bug: I have no idea how long this
bug has been here, but at least the 2.4.25 kernel exhibits the same
behaviour.
6. (not really a bug) It would be nice if the ieee1394 subsystem got
sysfs'ed soon...
As always, please let me know if you need any further detail about what
I have noticed or about my configuration.
Keep on trucking, guys!
--
MS
On Sun, Apr 04, 2004 at 11:54:11PM +0200, Marek Szuba wrote:
> 1. 'make *config' fails with missing header files
Only people who try to build userspace programs against current
kernel header files experience this problem.
> 2. Platform-specific 'asm' symlink doesn't get created by 'make *config'
This is only a problem for people trying to build userspace programs
against current kernel header files.
> 3. 'make clean' seems to remove too much
See 2.
These three complaints seem to revolve around your attempt to use
the kernels header files for building user space programs against.
This is something which hasn't really been supported by the kernel
for many versions (since before 2.4) as you will find when searching
the LKML archives.
/usr/include/{asm,linux} are supposed to be a copy of the sanitised
kernel headers which were used *when glibc was built* (the words
between the '*' are the important ones here.)
> 4. Floppy LED remains on whenever LILO boots the kernel quickly
This is a lilo bug - lilo is supposed to turn off the floppy motor before
calling the kernel; the kernel has dropped its work-around for this bug
and expects the boot loader to do it.
Alternatively, build a kernel with floppy support built in.
> 6. (not really a bug) It would be nice if the ieee1394 subsystem got
> sysfs'ed soon...
sysfs'ing subsystems is a complex task, one which requires very careful
analysis. Don't expect ieee1394 to change overnight (or if it does,
expect your kernel to be unstable.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> On Sun, Apr 04, 2004 at 11:54:11PM +0200, Marek Szuba wrote:
>
>>1. 'make *config' fails with missing header files
>
>
> Only people who try to build userspace programs against current
> kernel header files experience this problem.
It would solve all these problems if there were a new version of glibc
included, or headers for user mode, or something... but in the real
world at the moment most people are dropping 2.6.x kernels and selected
upgrades to tools onto 2.4 systems. And a lot of user tools don't work
unless you use kernel headers. The most obnoxious example is cdrecord,
which doesn't seem to use the ATAPI interface unless you have a 2.6
kernel in /usr/src/linux, or at least the include files.
I'm not saying that the kernel should program around people who insist
on doing things wrong, but there are programs which don't work right
unless you use some kernel headers when building (right meaning on 2.6).
>
>
>>2. Platform-specific 'asm' symlink doesn't get created by 'make *config'
>
>
> This is only a problem for people trying to build userspace programs
> against current kernel header files.
>
>
>>3. 'make clean' seems to remove too much
>
>
> See 2.
Unfortunately the sanctimonious "we told you not to do that" approach
isn't helpful to the real problem, the 2.6 kernel doesn't exist in a
vacuum, and at the moment some applications are built with kernel
headers to get full functionality.
>
> These three complaints seem to revolve around your attempt to use
> the kernels header files for building user space programs against.
> This is something which hasn't really been supported by the kernel
> for many versions (since before 2.4) as you will find when searching
> the LKML archives.
>
> /usr/include/{asm,linux} are supposed to be a copy of the sanitised
> kernel headers which were used *when glibc was built* (the words
> between the '*' are the important ones here.)
This purity of approach has only one failing, in some cases it doesn't work.
The useful answer is that you need to be *very* careful about which
headers you use and not just use symlinks. There was a set of headers
around which worked better with 2.6 and didn't have all these problems,
I have solved my problems a case at a time, so I don't have the location
handy.
Hope this actually helps, if you're going to bend the rules you have to
understand how to do it. As O.P. found.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me