>From: [EMAIL PROTECTED] (Bill Davidsen)
>[EMAIL PROTECTED] wrote:
>> And ATAPI _is_ SCSI so what?
> So they gain nothing with CD readers by adding SCSI anything. And Alan
>is giving the default of the simplest setup which will work for most
>people, many of whom wouldn't have a clue why they were getting a SCSI
>message if there was a problem.
The simplest setup would be to use SCSI / IDE integration because
cdrecord and other SW using USER level SCSI would run without changes
and there would be no need to support 2 !!!! SCSI drivers for CD-ROM's
(you know the result: the two drivers do not support the same set of
features and people complain about problems).
>> It seems you meissed the point: I did not say that an old binary _will_
>> cause problems on a new kernel, I sayd that using a new binary
>> on an old kernel definitely will cause problems.
> I did miss the direction of your old and new issues, but it certainly
>is not certainly a problem. If the library matches the kernel, a month
>of updates is unlikely to be an issue. I'm NFS exporting a binary
>toolkit, with a matching library, from a 2.4 machine. It runs fine on
>older kernels, at least back to some 2.3 machines which are still up and
>won't get an upgrade until they have some problem.
Mmmm I don"t know why you don't see the issue: Linux added mmap() recently
to the supported features. If you compile cdrecord to use mmap() for
the FIFO (this is the preferred method) then old kernels (>= 4 months)
will not be able to allow cdrecord to run.
>> Things like this happen every few weeks (only with Linux).
> See? Comments like this are why people think you don't like Linux. If
>you had access to development kernels for other o/s you would probably
>have a similar experience. Upgrades within a stable kernel series are
>less likely to be an issue.
I _have_ access to the equivalent of Solaris kernels.
I am speaking of versions made available to a limited numbber of people
(300 worldwide) about half a year before a new release will come out.
I need to find bugs in order to be listed the next time...
Do you really like me to compare?
> And I've had programs which ran on AIX 4.3.2 which didn't on 4.3.3, so
>it's not only on Linux, just that more people run development kernels on
>Linux, because they can. (Guilty, I've run things like test4pre5ac2).
Nearly all programs compiled on SunOS 4.0 (1987) will run on Solaris 8
even though the executable foemat did change.
The main difference between Solaris and Linux is that Sun thinks about
an interface before it leaves the lab of the developer.
Interfaces are created in a way that allws them to be upgraded in the
future without breaking binary compatibility. And... basic things like
mmap work since 1987.
>> The interesting thing is that I got at least 3 similar reports during
>> the last few weeks (all related to Linux-2.4). There is a problem
>> with the CHECK_CONDITION #define in a Linux system include file.
>> It is just wrong (right shifted by one). When the first USB-SCSI
>> came out, I could not run cdrecord because I did not get
>> SCSI sense data (caused by the fact that the mass storage driver
>> did not set the right bit in the SCSI structures).
> Obviously this should be fixed (how could it get broken in the first
>place??), but that would make a check report as something else, no? Is
>there some other condition being reported as a check?
The problem is IIRC that the SCSI midlevel code for some strange reasons
has two versions of the SCSI status byte. One right sifted and one
in it"s original form. As long as I am not able to reproduce this
problem or get enough information from a person who has the problem
I cannot say more than "it looks to be a problem that is present
for more than a single person".
> And why does this hurt anything, it's going to be wrong in your
>program as well, because you always compile from source and would have
>the same bit, even if it is wrong?
libscg of course uses the official SCSI bits. If I get wrong bits out of the
kernel, it's a kernel problem. However, people may try to run cdrecord -debug
to check what the Linux low level code gets. ... Unfortunately I don"t
know if all needed information is present. But to see what happens, you
need a person who is willing to cooperate and understands enough to cut off
unneeded information before sending it to me.
> I have mentioned static linking several times and you have not
>commented. Was there a reason why your program which only runs with the
>obsolete libc.5 isn't just linked static, so you wouldn't get all these
>question?
If linux is structured the usual way, then I would expect that crecord
cannot be linked statically.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
