Re: cdrtools-2.01a22 ready
On Wed 7 January 2004 11:37, Joerg Schilling wrote:
>
> For all people who have enough background knowledge in software
> engineering, here is a text that I did write for another purpose:
>
> /*---------------------------------------------------------------
>-----------*/
>
> star -tv < /tmp/cdev.tar.bz2
> star: WARNING: Archive is 'bzip2' compressed, trying to
> use the -bz option.
> star: Blocksize = 7 records.
> Release star 1.5a35 (i386-pc-solaris2.9)
> Archtype exustar
> Dumpdate 1073336802.243055000 (Mon Jan 5 22:06:42 2004)
> Volno 1
> Blocksize 20
> 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev
> star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k).
>
> AS you see, this is a tar archive that includes a character
> special with major 255 and minor 7000. You can list the correct
> major/minor numbers on any OS if you use star -tv, as the content
> of the tar archive is kernel interface independent.
>
> If you unpack this on a Linux-2.6 system using a "star" binary
> that has been compiled on Linux-2.4, you will extract a character
> special with minor 88 instead of minor 7000.
>
> This proves that you cannot run binaries from Linux-2.4 on
> Linux-2.6 correctly.
Well, it proves that you cannot run _some_ binaries that were
compiled under linux 2.4 on linux 2.6 correctly.
> If you compile on Linux-2.6, there is a big chance that the
> autoconf run will detect interfaces that are not present on
> Linux-2.4, so trying the other direction will most likely give
> just other problems.
>
>
> I am sorry, but the current work on the Linux kernel is
> overshadowed by severe missunderstandings. Linus and other people
> from LKML seem to be unable to understand how interfaces work.
>
> Let me explain it to you. There are three types of interfaces,
> you can see in libc and /usr/include/*:
>
> 1) Interfaces that are fully created by libc, such as strcpy()
>
> 2) Interfaces that are defined by the kernel but propagated by
> libc. Interfaces of this type are things similar to
> open()/read()/write(),..
>
> 3) Interfaces that libc is not even aware of (like ioctl()
> functions). If major()/minor()/makedev() are CPP macros and not
> functions in libc, then they are part of this group of
> interfaces.
Not necessarily. If the macros only call functions in libc, then
they're in category 1. But I see your point.
> Interfaces of type 1) are independent of the kernel and for this
> reason, the statements from Linus on how (from his belief)
> include files should be treatened apply _only_ to these
> interfaces.
> To allow an application to match the interface, you need an
> include file that is published by the same instance or person who
> does work on libc.
>
> Interfaces of type 2) require that libc and the kernel version
> match. This means, that you need to recompile and in some cases
> even to modify the libc sources in order to get a working
> complete system every time the kernel interface (used by libc)
> changes. This is needed to keep the upper level interface from
> libc stable.
>
> Interfaces of type 3) are independent of libc!
> Any application that likes to use them, _needs_ to use the
> include files from the kernel they are going to be run on. This
> is the only way, to make sure that the user level application
> uses an interface that matches the adjacent interface from the
> kernel. If you use different include files, you are unable to
> even test the kernel interface. For this reason, it is important
> that all include files from the kernel (that define interfaces
> that are visible from user land) are written in a way that allows
> a consistent usage from a user land application (which does never
> #define __KERNEL or similar).
>
> Cdrecord is definitely a user land application that needs to be
> compiled with the include files from the current kernel -
> otherwise it could not e.g. use new features from SCSI drivers
> inside the kernel.
>
>
> Star with respect to device major/minor handling is another one.
>
> There are most likely a lot more user land applications that will
> observe incompatibilities from changes in the Linux kernel
> interfaces.
Ofcourse, but are they a majority? There aren't that many programs
that talk directly to hardware. There aren't that many programs
that create device files. This email program manages some files on
the disk and it makes some network connections and that's it. Other
office software likely doesn't do this either. And audio and video
servers such as MAS or X abstract away from the hardware, so that
client programs don't use the kernel interface directly either.
I could live with "Do not use cdrtools on a different kernel than it
was compiled against" or even "I don't recommend using software
with a different kernel than it was compiled under". Simply stating
that it will never work...well, try this:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
Compile under 2.4, run under 2.6. I'm sure it'll work fine, because
it falls in your category 1 above.
Incidentally, your announcements are still a mess. I keep thinking
that the BerliOS Open Source center is a new feature of cdrtools
each time I read them. Advertisements should be at the bottom.
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Reply to: