[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#4764: ELKS should not use /etc/init.d just to load a module

On Sat, 12 Oct 1996, Dominik Kubla wrote:

kubla >> ELKS like dosemu uses this technology to be independent of the kernel
kubla >> version. Otherwise I have to compile ELKS for each kernel
kubla >> version.

kubla >1. Kernel modules are always kernel dependant unless the kernel and the
kubla >   modules are compiled with CONFIG_MODVERSIONS=y.

That is not true. Symbols of kernel modules are resolved at load time like
a linker. The only problem is if the kernel API of the exported procedures
change. There was one change in the 2.0.X series from 2.0.0 to 2.0.1 that
is relevant to ELKS.

Remember 2.0.X is a stable kernel. Changes to the API were avoided as much
as possible. That is why it works. You could not do that with the 1.3.X or
the 2.1.X series.

The CONFIG_MODVERSIONS=y generates symbols that reflect the parameter
structure of the exported procedure so that the INSMOD can verify that the
parameter calling conventions where not changed and thus insure an
unchanged API in terms of the syntax structure of the call but not in
terms of the semantics. Modules still can break with CONFIG_MODVERSIONS=y!

kubla >2. Unconditionally pushing a module into kernel space may have damaging
kubla >   side-effects.

May. But it does not in this case. I am maintaining a kernel driver and
thus follow the kernel development closely.

kubla >Currently the stock Debian kernel is compiled without CONFIG_MODVERSIONS
kubla >(which should be changed ASAP!), meaning that every maintainer suppling
kubla >kernel modules is _REQUIRED_ to recompile his package each time the kernel
kubla >package changes.

CONFIG_MODVERSIONS has lead to strange side effects in the past. Cannot
remember the exact issue though. I would not recommend it for 2.0.X. It is
safer when trying to do kernel version independant modules. If at all do
it when we move to the 2.1.X kernels where there will be high development

There are certain incompatibilities in I/O memory access that will break
a module despite CONFIG_MODVERSIONS when moving to 2.1.X

kubla >Because of that i will reopen the bug. In addition i will file bug-reports
kubla >for the kernel and dosemu as well.
Dont forget IBCS.

{}  Consulting available for Networking / Unix / Crossplatform integration    {}
{}  Snail Mail:   FTS Box 466, 135 N.Oakland Ave, Pasadena, CA 91182          {}
PGP Public Key  =  FB 9B 31 21 04 1E 3A 33  C7 62 2F C0 CD 81 CA B5 

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: