2.6 kernel features

[rezn]

I'm sure theres much more than this, but a few things that I know about
that are new in 2.6 might cause problems and are worth considering. At
the top of the list CONFIG_REGPARM, which causes the kernel to use
registers for passing up to 3 arguments to functions (instead of using
the stack). I mention this one because I think a lot of distributions
are starting to turn this on in their default kernels. I haven't tried
it with linice yet myself. Another one is CONFIG_PREEMPT, which allows
the kernel to be preempted on non-smp systems.

I think options like this could also be the cause of prcoder's problems
getting the current Makefile to build, since the linice_kernel.o module
is not currently being built by the proper 2.6 Kbuild. There is a
chance that some config option (maybe -mregparm=3 or something similar)
which would normally be used by kbuild to compile an object with gcc is
being left out. This may mean that using nasm is going to continue to
break things in the future, since its command line compile time options
will not likely ever be supported by the kernel directly, and many
user-settable kernel config options effect the way things should be
compiled.

[Goran Devic]

I got another report of failure on FC3 with that file (i386.o). It
seems like we will move to Oleg's port to GASM sooner than I thought :)
We just need to verify it's a one-to-one binary match.

[dima]

On my FC3 ld crashes when linking linice.o because of i386.o too.
I have fixed this as follows:

--- i386.asm.GENERIC 2004-12-24 13:30:14.590636699 +0300
+++ i386.asm 2004-12-23 13:10:10.000000000 +0300
@@ -1142,7 +1142,8 @@
mov ax, word [0C0106E41h]
cmp ax, 0F4FBh ; FB sti
jnz @skip ; F4 halt
- call 0C0106E41h
+ mov eax, 0C0106E41h
+ call eax
@skip:
pop eax
ret

But anyway I still can't load linice via linsym -i as prcoder.

Distro: FC3
Shipped kernel: 2.6.9-1.667smp (but system has only one processor)
vermagic for linice.ko: 2.6.9-1.667smp SMP 686 REGPARM 4KSTACKS gcc-3.4

[prcoder]

Ouch... i386.s have some mistakes, I fixing it now...

[prcoder]

But don't care the same i386 files can be not identical because
identical instructions can have different codes.
Like "sub esp, dword 4" (81EC04000000 or 83EC04).

[prcoder]

Another example mov eax,[ebx] and mov eax, [ebx+00]. GNU asm uses the
last when accessing function parameters, but NASM uses the first.

[prcoder]

And one strange thing... NASM silently skips 'halt' instruction in the
begining of 'InterruptPoll' function.
Is that instruction must give 'hlt' opcode or something else ?

[prcoder]

I think my module-loading problem in this function:

InterruptPoll:
halt

; This is for SuSe running under VmWare - makes it less CPU
intensive
; since VmWare yields CPU on kernel HALT, not our HALT
push eax

mov ax, word [0C0106E41h]
cmp ax, 0F4FBh ; FB sti
jnz @skip ; F4 halt

call 0C0106E41h
@skip:
pop eax
ret

NASM for some reason silently skips 'halt' instruction. And other SuSe
specific code leads to that loading problem. If I comment code from
'halt' to 'ret' than the module is loaded and started, otherwise insmod
write 'Verify ELF error [sec 2 rel 367]'.

Maybe we need to comment out this code and place 'htl' instruction
instead of it ?

[Goran Devic]

Interesting observation about NASM and HALT! Never noticed that. Why it
does not complain if the instruction should be coded as HLT instead??
We can remove that VmWare optimizations since it worked only on one
older version. It is not needed any more.

[Goran Devic]

I posted these changes into a developers release at
linice.com->download->dev release.

Change:
In the InterruptPoll(), removing VmWare-specific test code and
changing HALT instruction into HLT. NASM somehow ignores HALT keyword.
Affected files ...

//depot/linice/linice/i386.asm#41 edit