Re: [Gitorious] Activity: dschanoeh updated merge request for...

[Marc Kleine-Budde <mkl@pengutronix.de>]

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

On 12/04/2011 10:57 AM, Jan-Niklas Meier wrote:
>>> To be able to compile a subset of the tools I checked if the isotp.h and
>>> gw.h are present in the include directory (I don't have them both) and only
>>> compile the corresponding utils if the headers are present. This way it
>>> should still be possible to compile subsets of the tools on machines with
>>> old kernels and not ending up with tools you can not use afterwards.
>>
>> What about the external kernel modules use case?
> 
> Thank you very much for the clarification. Now I understand why you
> did this. Still if your kernel's CAN API is much older than the
> headers included in the current can-utils the programs will compile
> fine but it is possible that some of them will fail at runtime right?

Yes. If the kernel doesn't implement the features your userspace program
needs.

> Method signatures could have changed or some methods are not present
> in the old kernel. For example using a program with some specific
> parameters could lead to strange behavior for the user. Is that true
> or am I missing something?

Yes - you're missing the policy. The Kernel-Userspace interface must not
be changed in an incompatible way, at least once an interface is in the
mainline kernel. This includes not only the API but also the ABI (the
binary interface) to the kernel. This rule is (next to) 100% hard for
system calls, ioctls, etc... modern things like the sysfs tend to change
sometimes.

For example, the isotp programs will fail with "Protocol not supported"
during socket creation.

>>> I tried to rewrite the autoconf.ac because there are macros I'm having

[...]

>> That might be the problem, don't run autoconf, run $(./autogen.sh) instead.
> 
> \o/ Yay! That's the hint I needed. I didn't know that there is a
> different way to generate a ./configure that autoconf.

[...]

> I did the same and it works fine with both HEADs of your master and
> master-squashed branches. Still I get some warnings during autoreconf:
> 
> configure.ac:22: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
> configure.ac:22: You should run autoupdate.
> [...]
> configure.ac:24: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
> configure.ac:24: You should run autoupdate.

These are deprecation warnings from the autotools. IIRC these come from
libtool-2.x, but you need them for pre pre 2.x to work. Debian lenny
(this is old-stable, isn't it?) uses still libtool-1.5. Maybe some old
redhat versions, too.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]