loop-AES changes since previous release:
- WBINVD assembler instruction is no longer used on Xen builds.
- Makefile changed to probe .h header files instead of .c source files. (2.4
and 2.6 kernels)
- compat_ioctl code updated to handle all 32bit/64bit loop ioctl conversions
on 2.6 kernels. No longer depends on fs/compat_ioctl.c handling them.
- Semaphores are not used/needed anymore on 2.6 kernels.
- Makefile changed to work around 2.6.16-rc1 build breakage.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.1c.tar.bz2
md5sum 3e54b8e66142fe58282e58075f73e58c
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.1c.tar.bz2.sign
Additional ciphers package changes since previous release:
- Makefile changed to work around 2.6.16-rc1 build breakage.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0c.tar.bz2
md5sum 8770eb519b448ef0d4a0306e015de283
http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0c.tar.bz2.sign
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
On Wed, Jan 18, 2006 at 05:49:24PM +0200, Jari Ruusu wrote:
> - Makefile changed to work around 2.6.16-rc1 build breakage.
Hi Jari.
Care to explain why it is needed to have this in your Makefile:
SR1:=$(shell if grep -q -s \
"^basename_flags.*KBUILD_BASENAME.*KBUILD_STR" \
$(LS)/scripts/Makefile.lib; then echo y; fi)
...
ifeq ($(SR1),y)
EF += -D"KBUILD_STR(s)=\#s"
else
EF += -D"KBUILD_STR(s)=s"
endif
Either something is missing in the support for external modules in the
kernel or you are overdoing some stuff.
If there is something missing in the kernel to support external
modules then please say so, so it can be fixed.
Sam
Sam Ravnborg wrote:
> Either something is missing in the support for external modules in the
> kernel or you are overdoing some stuff. If there is something missing in
> the kernel to support external modules then please say so, so it can be
> fixed.
Missing functionality:
1) "make M=/path/to/dir modules_install" does not run depmod. Pulling
correct depmod info from kernel Makefile needs ugly hacks.
2) Try building external module A that exports some function, and then build
another external module B (separate package, only knows function
prototype) that uses said exported function. And I mean build it cleanly
without puking error messages on me. 2.4 and older kernel got that right,
but 2.6 is still FUBAR. Serious regression here.
Both above cases can be (and need to be) worked around using ugly hacks.
Sam,
Please understand that loop-AES needs to work with 2.0, 2.2, 2.4 and 2.6
kernels. Not just latest mainline, but all of them, including ones that you
cannot retroactively change.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
On Sat, Jan 21, 2006 at 06:27:36PM +0200, Jari Ruusu wrote:
> Sam Ravnborg wrote:
> > Either something is missing in the support for external modules in the
> > kernel or you are overdoing some stuff. If there is something missing in
> > the kernel to support external modules then please say so, so it can be
> > fixed.
>
> Missing functionality:
> 1) "make M=/path/to/dir modules_install" does not run depmod. Pulling
> correct depmod info from kernel Makefile needs ugly hacks.
OK, I will try to take a look at this.
The correct fix though is to upgrade module-utils to no rely on depmod.
Rusty mentioned this long time ago but no-one did it so far.
> 2) Try building external module A that exports some function, and then build
> another external module B (separate package, only knows function
> prototype) that uses said exported function. And I mean build it cleanly
> without puking error messages on me. 2.4 and older kernel got that right,
> but 2.6 is still FUBAR. Serious regression here.
OK, but I have yet to find a clean solution for it.
> Both above cases can be (and need to be) worked around using ugly hacks.
>
> Sam,
> Please understand that loop-AES needs to work with 2.0, 2.2, 2.4 and 2.6
> kernels. Not just latest mainline, but all of them, including ones that you
> cannot retroactively change.
Fully aware ot that - my only issue was that you had to workaround some
2.6 functionality.
The objective is to provide full support for external modules in 2.6.
And you raised two valid points.
Thanks,
Sam
On Sat, Jan 21, 2006 at 06:27:36PM +0200, Jari Ruusu wrote:
> Sam Ravnborg wrote:
> > Either something is missing in the support for external modules in the
> > kernel or you are overdoing some stuff. If there is something missing in
> > the kernel to support external modules then please say so, so it can be
> > fixed.
>
> Missing functionality:
> 1) "make M=/path/to/dir modules_install" does not run depmod. Pulling
> correct depmod info from kernel Makefile needs ugly hacks.
Fixed in latest kbuild.
One day I need to get full grip on the module-init-tools stuff....
> 2) Try building external module A that exports some function, and then build
> another external module B (separate package, only knows function
> prototype) that uses said exported function. And I mean build it cleanly
> without puking error messages on me. 2.4 and older kernel got that right,
> but 2.6 is still FUBAR. Serious regression here.
This was always possible using a kbuild file specifying all relevant
modules. But accepting this is not always doable kbuild now add an
additional method.
build module a
copy Module.symvers from module a to module b.
Voila, module b has full access to symbols from module a. This includes
module versioning support.
Both methods are documented in Documentation/kbuild/modules.txt now.
Both changes are in my kbuild.git tree and I will send out a series of
patches to lkml soon. It will be available for testing in next -mm too.
Thanks for input, and please let me know if you know of more
shortcomings in kbuild that needs to be addressed.
Sam
Sam Ravnborg wrote:
> On Sat, Jan 21, 2006 at 06:27:36PM +0200, Jari Ruusu wrote:
> > 2) Try building external module A that exports some function, and then build
> > another external module B (separate package, only knows function
> > prototype) that uses said exported function. And I mean build it cleanly
> > without puking error messages on me. 2.4 and older kernel got that right,
> > but 2.6 is still FUBAR. Serious regression here.
>
> This was always possible using a kbuild file specifying all relevant
> modules. But accepting this is not always doable kbuild now add an
> additional method. build module a. copy Module.symvers from module a to
> module b. Voila, module b has full access to symbols from module a. This
> includes module versioning support. Both methods are documented in
> Documentation/kbuild/modules.txt now.
But that "copy Module.symvers from module A to module B" does not work in
these situations:
1) Module B does not know where module A source is.
2) Automatic package builder box may remove all traces of module A before
module B is built.
3) Automatic package builder box may build module B before module A.
How about this:
make M=/path/to/dir IGNORE_MISSING_SYMVER_ERRORS=1 modules
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Meaning: If symbol version is available, fine, use that. If some info is not
available, that is fine too. Just make it work without symbol versioning.
Killing those damn error messages should be enough.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD