Re: cdrtools-2.01a22 ready
>From appro@fy.chalmers.se Tue Jan 6 17:38:11 2004
>> You did just prove that there is a difference between an attempt for a test
>> and a real test!
>>
>> Try to unpack and verify this archive:
>Isn't it typical? I've complained about wording of statement attached to
>usage of major macro in cdda2wav and discussion is immediately led to
>other spheres. Yes, these issues (original and the one brought up here)
>are related, but I would like to get answer to original question
>*first*. Do you or do you not agree that original statement was in fact
>"it has always been wrong to compile cdrtools only once for different
>kernel versions" and not "it has always been wrong to compile software
>only once"? I'm ready to proceed with further discussion on the issue
>brought up in this mail (I suggest to continue on
>cdwrite@other.debian.org) only after you clarify the original statement.
Looks typical for you :-(
Sorry, but you just again proved that it is a waste of time trying to
be more versartile in explanations. What you write is completely irrelevant
because you just proved that you are one of the persons that are unable to
decide whether a binary compiled on Linux-2.4 will run correctly on Linux-2.6
As this is the case, it is better to publish general warnings that tell
people not to try this at all, rather than giving a versatile explanation.
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.
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.
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.
begin 644 cdev.tar.bz2
M0EIH.3%!62936=&]\I< &7_@-[4 ,! 8__B3&18)'_OWW" "# !>TE@,IE3
MU/1/331JC)M0T'J ,AIA#0VF@T"-%#(-30]3)B!H&1DTR:,F D4B>@IF2&FG
MJ9-#1ZAH-#31IB:&G ;]>U$"!NL_-,RC6,A0A)3JP((!B0SZA7BP+UJP-W(J
MA>#X>U210@#!7!XU"')%QFF2,FF@N.;!?RTZ.?-V%*P5//=;:3M"H0I74Q@T
MA71B%7E\STX@M&*E,WC2FYE0'*\-ZXN$)B>*ES%EJQ8" &015?]&I/*9N\F\
MS%; 4@?742 0JVQ>*"W798D.5NPT*E)Z&FL"N'?I$"F9)$I@*R4(:L!05B10
M49)%*IZ(QA3'=MUAY.1KJ/E!?T(,Y#2@[4'N%'00-A 0#'XT#I^2/WETMW/^
MPW?^6T3<W?.Y!IG@6?YC>X>F426F>0F:@J?3!IPIN9O4X,.*%SJY<F1"UERG
MA%'T(X(^T"!&(C5=9>'1-1#,A04LF&@Q7R?7(#+$B!#L:U*L;*KSX8!("$P6
/P5VD#B+N2*<*$AHWOE+@
end
/*--------------------------------------------------------------------------*/
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: