Re: Stop the Linux kernel madness

[V13 <v13@priest.com>]

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]

On Tuesday 22 June 2004 10:54, Hannu Savolainen wrote:
> This kind of "breaks" are not so fatal provided that there is some way to
> detect them reliably. Usually it's possible to check LINUX_VERSION_CODE
> and use different approaches depending on the kernel version. However
> this doesn't always work because distribution vendors often back port
> features from the newer kernels into their distribution kernels which
> have older LINUX_VERSION_CODE. A better  approach would be marking them
> with #define HAVE_NEW_something in the header file that implements this
> change.

I believe we are seeing this kind of problems all the time. This is not just a 
kernel 'problem'. Just take a look at the autoconf info page and the tests 
that a portable program has to run.

Of course the makers of (i.e.) glib could just try to find a source tree that 
would compile everywhere but they know that this is impossible so they have 
to run tests like :

(warning: long list)
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
checking for locale.h... yes
checking for LC_MESSAGES... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking for dgettext in libc... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for nl_langinfo... yes
checking for nl_langinfo and CODESET... yes
checking whether we are using the GNU C Library 2.1 or newer... yes
checking for vasprintf... yes
checking for unsetenv... yes
checking for getc_unlocked... yes
checking for C99 vsnprintf... yes
checking for nl_langinfo (CODESET)... yes
checking for OpenBSD strlcpy/strlcat... no
checking for an implementation of va_copy()... yes
checking for an implementation of __va_copy()... yes
checking whether va_lists can be copied by value... yes
checking for RTLD_GLOBAL brokenness... no
checking for preceeding underscore in symbols... no
checking for dlerror... yes
checking size of pthread_t... 4
checking for pthread_attr_setstacksize... yes
checking for minimal/maximal thread priority... 
sched_get_priority_min(SCHED_OTHER)/sched_get_priority_max(SCHED_OTHER)
checking for posix yield function... sched_yield
checking whether to use the PID niceness surrogate for thread priorities... 
yes
checking size of pthread_mutex_t... 24
checking byte contents of PTHREAD_MUTEX_INITIALIZER... 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
checking value of POLLIN... 1
checking value of POLLOUT... 4
checking value of POLLPRI... 2
checking value of POLLERR... 8
checking value of POLLHUP... 16
checking value of POLLNVAL... 32

.. and many more ..

I don't believe that your source code is more complex than theirs. Maybe the 
solution to your problem is as simple as 'info autoconf'. You know that there 
are more than one ways to compile kernel modules so you just have to test 
each one of them and see which one works. We're talking about no more than 30 
minutes work. After that you may add another distro in the supported 
distributions list of your module.

> Hannu
<<V13>>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]