sean <[email protected]> wrote:
> On Mon, 13 Feb 2006 15:29:02 +0100
> Joerg Schilling <[email protected]> wrote:
>
> > When looking at the current discussion, it seems to me that most people
> > here are still not interested in a fix.
>
> Most people don't see a problem to fix. Your arguments have been roundly
> refuted. On top of which, cdrecord works on Linux just fine already when
> you pass the device node on the command line. There just isn't much
> motivation to pursue a fix for some theoretical problem that doesn't affect
> real users in practice. Since you are the only one who sees this as a huge
> problem you should invest in providing a patch that can be reviewed for
> inclusion.
So you like to prove that it makes not sense to talk to LKML people?
If there is no interest to fox well known bugs in Linux, I would need to warn
people from using Linux.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Mon, 13 Feb 2006 16:36:17 +0100
Joerg Schilling <[email protected]> wrote:
> > Most people don't see a problem to fix. Your arguments have been roundly
> > refuted. On top of which, cdrecord works on Linux just fine already when
> > you pass the device node on the command line. There just isn't much
> > motivation to pursue a fix for some theoretical problem that doesn't affect
> > real users in practice. Since you are the only one who sees this as a huge
> > problem you should invest in providing a patch that can be reviewed for
> > inclusion.
>
> So you like to prove that it makes not sense to talk to LKML people?
This is a non sequitur.
> If there is no interest to fox well known bugs in Linux, I would need to warn
> people from using Linux.
People have a lot of interest to fix well known bugs in Linux, it happens every
day. The point is nobody but you classifies this as a bug. Since you are
alone in classifying this as a bug, you will be alone in submitting patches for
it. Good luck.
Sean
Hello!
> If there is no interest to fox well known bugs in Linux, I would need to warn
> people from using Linux.
Except for mentioning some DMA related problems at the beginning of this
monstrous thread, you haven't shown anything which even remotely qualifies
as a bug.
You are only endlessly complaining about Linux not following the same
model of SCSI access as you love, which might be a little incovenient
for you, but that certainly doesn't make it a bug.
You tried to juggle with dubious POSIX references, but so far nobody has
found any place in POSIX or SuS saying that anything has to be stable
across mounts/umounts.
So what damned bugs are you speaking about?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"One single semicolon. A perfect drop of perliness. The rest is padding." -- S. Manandhar
Joerg Schilling schrieb am 2006-02-13:
> So you like to prove that it makes not sense to talk to LKML people?
Wrong. It does not make sense to keep talking about issues that were
refused, such as providing stable b,t,l device mapping, or violating
layering requirements that you are so fond of.
Such a violation might be making libscg the core and arranging the
kernel around it.
--
Matthias Andree
Martin Mares <[email protected]> wrote:
> Hello!
>
> > If there is no interest to fox well known bugs in Linux, I would need to warn
> > people from using Linux.
>
> Except for mentioning some DMA related problems at the beginning of this
> monstrous thread, you haven't shown anything which even remotely qualifies
> as a bug.
If you forget these things, then please forget about this thread.
I mentioned:
- ide-scsi does not do DMA correctly
- SCSI commands are bastardized on ATAPI
If you like, I can give you many other Linux related bugs but it does
not make sense unless the two bugs above are fixed.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-13:
> Martin Mares <[email protected]> wrote:
>
> > Hello!
> >
> > > If there is no interest to fox well known bugs in Linux, I would need to warn
> > > people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely qualifies
> > as a bug.
>
> If you forget these things, then please forget about this thread.
>
> I mentioned:
>
> - ide-scsi does not do DMA correctly
Apparently no-one bothers to fix this with ide-cd supporting SG_IO, and
nobody produced any use case for other ide-*.c devices.
You'll either have to fix this yourself or wait until the day the cows
coime home.
> - SCSI commands are bastardized on ATAPI
You were asked for a proof but didn't provide one. If you think
otherwise, post URL or Message-ID. We're all sooooooooooooooo terrible
forgetful we don't recall your reports from 2001.
--
Matthias Andree
Hello!
> - SCSI commands are bastardized on ATAPI
One more question before this thread hopefully dies out:
What do you mean by "bastardized"?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Don't take life too seriously -- you'll never get out of it alive.
Martin Mares <[email protected]> wrote:
> Hello!
>
> > - SCSI commands are bastardized on ATAPI
>
> One more question before this thread hopefully dies out:
>
> What do you mean by "bastardized"?
I did describe this in detail before:
some drives complain about "illegal field in cdb"
with "read full toc" and "blank" while the same HW booted
with Solaris or SCO UnixWare has no problems.
Let me write a final remark:
cdrecord currently has no known Linux specific bug.
Let us comtinue to talk after the Linux kernel bugs that
prevent cdrecord from working have been fixed.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> Let me write a final remark:
>
> cdrecord currently has no known Linux specific bug.
>
> Let us comtinue to talk after the Linux kernel bugs that
> prevent cdrecord from working have been fixed.
OK. And in the meantime you can remove the silly warnings about
device names being unsupported.
MM
On Monday 13 February 2006 16:26, Joerg Schilling wrote:
> Martin Mares <[email protected]> wrote:
> > > If there is no interest to fox well known bugs in Linux, I would need
> > > to warn people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely
> > qualifies as a bug.
>
> If you forget these things, then please forget about this thread.
>
> I mentioned:
>
> - ide-scsi does not do DMA correctly
IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note
that ide-scsi is known to be broken in more ways than just this-- for
example, unloading the module causes a kernel panic.
> - SCSI commands are bastardized on ATAPI
I'm not a kernel developer, but my understanding is that they're basically
passed through the ATAPI layer.
Martin Mares <[email protected]> wrote:
> Hello!
>
> > Let me write a final remark:
> >
> > cdrecord currently has no known Linux specific bug.
> >
> > Let us comtinue to talk after the Linux kernel bugs that
> > prevent cdrecord from working have been fixed.
>
> OK. And in the meantime you can remove the silly warnings about
> device names being unsupported.
The warnings are not silly. They could have been removed long ago
if the icd-scsi DMA bug was fixed.
So take it as it is: Linux first fixes the icd-scsi DMA bug and
then it makes sense to remove the related warning.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> The warnings are not silly. They could have been removed long ago
> if the icd-scsi DMA bug was fixed.
This doesn't make sense, the usual case when the warning is printed,
that is referring to /dev/hd* directly, doesn't use ide-scsi at all.
Hence the only logical warning would be exactly the opposite: warn the
user if he uses ide-scsi, because you know it's broken.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The number of UNIX installations has grown to 10, with more expected. (6/72)
Luke-Jr <[email protected]> wrote:
> > I mentioned:
> >
> > - ide-scsi does not do DMA correctly
>
> IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note
> that ide-scsi is known to be broken in more ways than just this-- for
> example, unloading the module causes a kernel panic.
A last word on that:
- this bug is known for more than 2 years.
- time to fix: less than 3 hours for the right person
- I therefore expect a fix in less than a month or
I must asume that Linux is not longer actively maintained.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling a ecrit le 13.02.2006 18:40 :
> - I therefore expect a fix in less than a month or
> I must asume that Linux is not longer actively maintained.
so is your brain, obviously
On Monday 13 February 2006 17:40, Joerg Schilling wrote:
> Luke-Jr <[email protected]> wrote:
> > > I mentioned:
> > >
> > > - ide-scsi does not do DMA correctly
> >
> > IIRC, ide-scsi is deprecated and would be removed as a fix for this bug.
> > Note that ide-scsi is known to be broken in more ways than just this--
> > for example, unloading the module causes a kernel panic.
>
> A last word on that:
>
> - this bug is known for more than 2 years.
>
> - time to fix: less than 3 hours for the right person
>
> - I therefore expect a fix in less than a month or
> I must asume that Linux is not longer actively maintained.
What does it do "wrong" anyway? IIRC, DMA in general works...
Also note that since SCSI does not support DMA, I wouldn't consider lack of
DMA for ide-scsi a bug. Just because the underlying device is IDE and has DMA
support doesn't mean that the SCSI layer (which has no reason for DMA) should
use it.
Joerg Schilling schrieb am 2006-02-13:
> - this bug is known for more than 2 years.
>
> - time to fix: less than 3 hours for the right person
>
> - I therefore expect a fix in less than a month or
> I must asume that Linux is not longer actively maintained.
The kernel jumps at J?rg's command. Film at eleven.
Where's my popcorn?
You were told that ide-scsi fixes are not a priority item,
you were shown that ide-cd works,
you were shown that /dev/hd* and /dev/sg* can share the same namespace
(see my proof-of-concept patch), so there's nothing left for you to
want.
Either fix ide-scsi yourself, or fork a few 50 ? bills and contract
somebody to do it.
--
Matthias Andree
Joerg Schilling schrieb am 2006-02-13:
> The warnings are not silly. They could have been removed long ago
> if the icd-scsi DMA bug was fixed.
The warnings are way off track, because
1. /dev/hd* means ide-cd which has never had the incriminated bugs,
no matter if badly designed or not
2. you can't tell from looking at /dev/sg* or the b,t,l if the device
node is operated by the ide-scsi or sg drivers. Both use the unified
/dev/sg* namespace.
In fact, it makes sense to suppress the warning for /dev/hd* and ATA:
which are known good.
--
Matthias Andree
On Monday 13 February 2006 11:26, Joerg Schilling wrote:
> Martin Mares <[email protected]> wrote:
> > Hello!
> >
> > > If there is no interest to fox well known bugs in Linux, I would need
> > > to warn people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely
> > qualifies as a bug.
>
> If you forget these things, then please forget about this thread.
>
> I mentioned:
>
> - ide-scsi does not do DMA correctly
ide-scsi is deprecated and will be removed at a later date. Any program
relying on ide-scsi will have to be rewritten.
> - SCSI commands are bastardized on ATAPI
identify the problem - provide a test case or two and I'll get off my lazy ass
and see if I can't figure out what's causing the problem.
> If you like, I can give you many other Linux related bugs but it does
> not make sense unless the two bugs above are fixed.
Only one bug needs fixed. ide-scsi is not going to be in the kernel much
longer. Although someone might find the time to fix the bugs for those people
dependant on older kernels.
DRH
>
>The warnings are not silly. They could have been removed long ago
>if the icd-scsi DMA bug was fixed.
>
...if someone cared to fix it. This is the opensource world, and if
someone's out for a fix, they either have to write it themselves or pay
someone to do so.
Jan Engelhardt
--
>
>> - SCSI commands are bastardized on ATAPI
>
>identify the problem - provide a test case or two and I'll get off my lazy ass
>and see if I can't figure out what's causing the problem.
>
Maybe we can put a testsuite together that sends all sorts of commands to a
cd drive and then see with 1. which Linuxes 2. which models it happens.
Jan Engelhardt
--
On Tuesday 14 February 2006 03:04, Jan Engelhardt wrote:
> >> - SCSI commands are bastardized on ATAPI
> >
> >identify the problem - provide a test case or two and I'll get off my lazy
> > ass and see if I can't figure out what's causing the problem.
>
> Maybe we can put a testsuite together that sends all sorts of commands to a
> cd drive and then see with 1. which Linuxes 2. which models it happens.
>
>
> Jan Engelhardt
Excellent idea, but since Joerg probably has all the information already I
don't see why he can't provide it. At least that way there is some time saved
and I won't wind up seeing my aging CDRW drive get any excessive wear.
DRH
Luke-Jr <[email protected]> wrote:
> What does it do "wrong" anyway? IIRC, DMA in general works...
If you really believe that it is good practice to implement DMA in
a way so it works at some places as expected but on others not....
... then you like the Linux kernel be a junk yard :-(
Good practice is to fix _all_ related code in a project in case a bug
is identified and fixed at some place. Unfortunately this is not true
for Linux and for this reason, Linux cannot yet be called mature.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Tuesday 14 February 2006 06:13, Joerg Schilling wrote:
> Luke-Jr <[email protected]> wrote:
> > What does it do "wrong" anyway? IIRC, DMA in general works...
>
> If you really believe that it is good practice to implement DMA in
> a way so it works at some places as expected but on others not....
>
> ... then you like the Linux kernel be a junk yard :-(
>
> Good practice is to fix _all_ related code in a project in case a bug
> is identified and fixed at some place. Unfortunately this is not true
> for Linux and for this reason, Linux cannot yet be called mature.
Joerg, I think you misunderstand the problem here. The block layer itself
supports DMA unilaterally. Some of the extended drivers that provide support
for older hardware or, in the case of the (need I remind you) deprecated
ide-scsi system, for an abstraction layer do not for various reasons. Whether
that is because the device itself doesn't support DMA or if it's because the
added complexity (in the ide-scsi case) of providing DMA for an abstraction
layer made it nearly impossible. As the problems with ide-scsi are soon to be
gone from main-line up-to-date kernels, I have trouble seeing why you still
harp on this problem.
As I'm sure you know, Linux is an Open Source operating system. If you need it
to support DMA in the ide-scsi system, then you are free to add said support.
If you do not have the time or the skill to do so, you are also free to pay
someone to do it for you. But as the kernel progresses through 2.6 you will
find that most of your "bugs" are being dealt with. As a matter of fact I
have offered to attempt to fix the problems you have with the ATAPI layer
munging packets. As I said before, if you can provide me with the details of
which hardware is affected and what exactly is occurring I can probably work
on this. (And from the contents of a recent post, you can be certain I am not
the only one interested in fixing this problem of yours)
However, if the problem is non-existant with a _modern_ kernel, then may I
make one suggestion: remove your constant reporting of the problem.
Furthermore I have been quiet until now regarding the comments you have made
in the source to cdrecord and libscg regarding Linux. While I appreciate that
your software has been functional for twenty years now, I would suggest that
you question your own motives, as it appears that your problems with Linux
are more of a personal nature and not a technical one. Moreover I find that
you make constant reference to "how things should have been done" but in
looking through the Linux sources, I can find no hint that you ever touched
the portions of the OS in question. Therefore I have to wonder if your
abrasive manner and repeated personal attacks were not occurring even as the
block device layer was undergoing it's last sets of rewrites and managed to
alienate the entire crew of people working on it.
Up to this point I have attempted to be calm and civil, if not polite. However
you preach about "good practice" and claim you will accept patches, yet in
your stated policy you reserve the right to reject any patch on non-technical
grounds. What's more is that you _have_ shown this to be your most common
mode of operation, to the point of refusing to actually look at patches that
meet the rest of the standards you provide.
I have no wish for this discussion to devolve any further, and have been
attempting to turn it around and make it productive. Patience is something
that I do not have in infinite quantities, however. My offers to attempt to
fix the second of the two "major" bugs you reported stands, as does my offer
to patch cdrecord so that it uniformly uses the b,t,l addressing scheme
internally while allowing users to select a device node. I will let them
stand for one week. If, at the end of that week, you have either 1) not
provided me with the documentation I need to attempt to fix the bugs in the
linux kernel or 2) not provided me with a written standards document on how
code should be formatted for cdrecord patches either or both of the offers
will be withdrawn and I will neither read nor respond to further mail from
you.
Did I make myself clear, or should I attempt to restate that in my very rusty
and beleagured german?
DRH
Jan Engelhardt <[email protected]> wrote:
> >
> >> - SCSI commands are bastardized on ATAPI
> >
> >identify the problem - provide a test case or two and I'll get off my lazy ass
> >and see if I can't figure out what's causing the problem.
> >
>
> Maybe we can put a testsuite together that sends all sorts of commands to a
> cd drive and then see with 1. which Linuxes 2. which models it happens.
You need to ask around for people with problems....
Debian had some relevent data but removed it the day I was referring to it :-(
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> As I'm sure you know, Linux is an Open Source operating system. If you need it
> to support DMA in the ide-scsi system, then you are free to add said support.
It seems that you did missunderstand Linux:
I did send a fix for an important bug in 1997 and it was NOT integraded by
the Linux kernel people.
As long as the Linux project proves that Linux is not yet mature enough for
being able to _really_ do what you propose, it makes no sense to waste time
on LKML.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-14:
> "D. Hazelton" <[email protected]> wrote:
>
>
> > As I'm sure you know, Linux is an Open Source operating system. If you need it
> > to support DMA in the ide-scsi system, then you are free to add said support.
>
> It seems that you did missunderstand Linux:
>
> I did send a fix for an important bug in 1997 and it was NOT integraded by
> the Linux kernel people.
Wow, 9 years ago. Was it for 2.0 already or still 1.2?
Does the bug persist in 2.6.16-rc3? If so, resend your fix.
> As long as the Linux project proves that Linux is not yet mature enough for
> being able to _really_ do what you propose, it makes no sense to waste time
> on LKML.
An action speaks louder than 1000 words. When are you leaving?
--
Matthias Andree
Joerg Schilling schrieb am 2006-02-14:
> Jan Engelhardt <[email protected]> wrote:
>
> > >
> > >> - SCSI commands are bastardized on ATAPI
> > >
> > >identify the problem - provide a test case or two and I'll get off my lazy ass
> > >and see if I can't figure out what's causing the problem.
> > >
> >
> > Maybe we can put a testsuite together that sends all sorts of commands to a
> > cd drive and then see with 1. which Linuxes 2. which models it happens.
>
> You need to ask around for people with problems....
> Debian had some relevent data but removed it the day I was referring to it :-(
In other words: you cannot provide details or even prove the asserted
bug, and you are trying to shift the blame on Debian. If they no longer
have the reports, chances are the bugs have been fixed since through
Debian patches, that's their workflow.
And if you want Debian bugs, look here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=cdrecord&archive=no&version=&dist=unstable&pend-exc=fixed&pend-exc=done&sev-exc=wishlist&sev-exc=fixed
But keep in mind only the "forwarded" or "upstream" bugs are your
business.
Besides that, I wouldn't exactly call it quality standard if you lose
important bug reports about the environment.
--
Matthias Andree
El Tue, 14 Feb 2006 17:35:32 +0100,
Joerg Schilling <[email protected]> escribi?:
> I did send a fix for an important bug in 1997 and it was NOT integraded by
> the Linux kernel people.
Many patches are rejected. Looking at the way you handle cross-platform design
for libscg is not something that surprises me....
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-14:
>
> > Jan Engelhardt <[email protected]> wrote:
> >
> > > >
> > > >> - SCSI commands are bastardized on ATAPI
> > > >
> > > >identify the problem - provide a test case or two and I'll get off my lazy ass
> > > >and see if I can't figure out what's causing the problem.
> > > >
> > >
> > > Maybe we can put a testsuite together that sends all sorts of commands to a
> > > cd drive and then see with 1. which Linuxes 2. which models it happens.
> >
> > You need to ask around for people with problems....
> > Debian had some relevent data but removed it the day I was referring to it :-(
>
> In other words: you cannot provide details or even prove the asserted
> bug, and you are trying to shift the blame on Debian. If they no longer
> have the reports, chances are the bugs have been fixed since through
> Debian patches, that's their workflow.
In other words, you are still only trying to create voilence but
unable/unwilling to cooperate?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>
>I did send a fix for an important bug in 1997 and it was NOT integraded by
>the Linux kernel people.
>
Resend it. I also see that some of my patches/compilefixes don't make it
into the main tree at first time.
Jan Engelhardt
--
Joerg Schilling schrieb am 2006-02-14:
> Matthias Andree <[email protected]> wrote:
>
> In other words, you are still only trying to create voilence but
> unable/unwilling to cooperate?
Amusing question, isn't it you who dropped the patch (= quit
cooperation) without looking at it?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you
never insinuated Debian deleted bugs.
Quote "This seems to be a general problem with QSI-drives, see e.g.
http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html
which shows testimonials about failed blanking of cd-rws for QSI
CD-RW/DVD-ROM SBW-241, cdrdao succeeds."
"If you are unwilling to remove a non cdrecord related bug from the list
or if you unable to understand the background, you should ask for help
or leave the cdrecord project."
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84
Uncle J?rg the Dictator, commander in charge of earth motion.
Fails to mention libscg code paths for Solaris and Linux differ.
I've filed a 186099 amendment to prevent fallacies there...
--
Matthias Andree
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-14:
>
> > Matthias Andree <[email protected]> wrote:
> >
> > In other words, you are still only trying to create voilence but
> > unable/unwilling to cooperate?
>
> Amusing question, isn't it you who dropped the patch (= quit
> cooperation) without looking at it?
>
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
>
> So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you
> never insinuated Debian deleted bugs.
>
> Quote "This seems to be a general problem with QSI-drives, see e.g.
> http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html
> which shows testimonials about failed blanking of cd-rws for QSI
> CD-RW/DVD-ROM SBW-241, cdrdao succeeds."
>
> "If you are unwilling to remove a non cdrecord related bug from the list
> or if you unable to understand the background, you should ask for help
> or leave the cdrecord project."
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84
If you don't know the background, stay quiet!
This bug has been moved away from Linux kernel bugs several times.
I was requesting to put the bug where it belongs....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-14:
> Matthias Andree <[email protected]> wrote:
> > "If you are unwilling to remove a non cdrecord related bug from the list
> > or if you unable to understand the background, you should ask for help
> > or leave the cdrecord project."
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84
>
> If you don't know the background, stay quiet!
Right, hello everyone, jump at J?rg's command. One, two, ...
> This bug has been moved away from Linux kernel bugs several times.
False. It had never been assigned to the kernel.
> I was requesting to put the bug where it belongs....
I can read, thank you, and the bugreport lacks any evidence as to the
nature of the bug. "where it belongs" are typical fallacies, unless
someone invokes "in dubio pro reo", concludes it's a firmware bug and
closes it.
--
Matthias Andree
On Tuesday 14 February 2006 10:04, Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> wrote:
> > >> - SCSI commands are bastardized on ATAPI
> > >
> > >identify the problem - provide a test case or two and I'll get off my
> > > lazy ass and see if I can't figure out what's causing the problem.
> >
> > Maybe we can put a testsuite together that sends all sorts of commands to
> > a cd drive and then see with 1. which Linuxes 2. which models it happens.
>
> You need to ask around for people with problems....
> Debian had some relevent data but removed it the day I was referring to it
> :-(
As the maintainer of the cdrtools package and the author of both libscg and
cdrecord I find it hard to believe that you do not have a log of these
somewhere. If Debian had relevant data and removed it, then it is quite
probable that they fixed the problem already. If that is the case, then all
it should take to find out is making an enquiry or searching among their
distribution specific kernel patches.
However, in the spirit of making this discussion bear useful fruit, I will
take it upon myself to search the Debian archived bugs and see if I can find
out the relevant data myself.
DRH
"D. Hazelton" <[email protected]> wrote:
> As the maintainer of the cdrtools package and the author of both libscg and
> cdrecord I find it hard to believe that you do not have a log of these
> somewhere. If Debian had relevant data and removed it, then it is quite
> probable that they fixed the problem already. If that is the case, then all
> it should take to find out is making an enquiry or searching among their
> distribution specific kernel patches.
I usually fix real bugs immediately after I know them.
I don't see that it makes sense to archive Linux bugs as long ad the Linux
kernel folks are obviously not willing to fix them.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-16:
> "D. Hazelton" <[email protected]> wrote:
>
> > As the maintainer of the cdrtools package and the author of both libscg and
> > cdrecord I find it hard to believe that you do not have a log of these
> > somewhere. If Debian had relevant data and removed it, then it is quite
> > probable that they fixed the problem already. If that is the case, then all
> > it should take to find out is making an enquiry or searching among their
> > distribution specific kernel patches.
>
> I usually fix real bugs immediately after I know them.
"Usually" is the key here. Sometimes, you refuse to fix real bugs
forever even if you're made aware of them, and rather shift the blame
on somebody else.
> I don't see that it makes sense to archive Linux bugs as long ad the Linux
> kernel folks are obviously not willing to fix them.
Then the bugs can't have been important to you.
--
Matthias Andree
Matthias Andree <[email protected]> wrote:
> > I usually fix real bugs immediately after I know them.
>
> "Usually" is the key here. Sometimes, you refuse to fix real bugs
> forever even if you're made aware of them, and rather shift the blame
> on somebody else.
Show me a single real bug that I did not fix.
> > I don't see that it makes sense to archive Linux bugs as long ad the Linux
> > kernel folks are obviously not willing to fix them.
>
> Then the bugs can't have been important to you.
??? Id the Linux kernel is not fixed, the importance is irrelevent
unfortunately.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-16:
> Matthias Andree <[email protected]> wrote:
>
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
>
> Show me a single real bug that I did not fix.
Namespace split ATA/SCSI is unfixed in 2.01.01a06.
Bogus warnings about Linux are unfixed in said version.
Bogus warnings about /dev/* are unfixed in said version.
Linux uname() detection code is broken since 2.6.10 because it assumes
fixed-width fields.
That makes four.
--
Matthias Andree
Joerg Schilling wrote:
>
> Matthias Andree <[email protected]> wrote:
>
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
>
> Show me a single real bug that I did not fix.
Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
reboots when run as root.
Ciao, ET.
On Thursday 16 February 2006 13:06, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
>
> Show me a single real bug that I did not fix.
At this point I, personally, am not aware of any. However, after a careful
review of libscg in preparation for the patch I promised you, I can see that
it would be possible for the code to be rewritten so that just the linux
section contains the various workarounds that might be needed.
With your refusal to even consider doing that I can see where some people get
this idea (I myself was under this exact same belief until I began my code
review in preparation for the proposed patch).
I am unsure if you refused to provide OS specific workarounds for known bugs
in order to keep the code orthogonal, or if you had another reason. But with
the division of the various operating system specific pieces of libscg into
seperate source files it doesn't make sense.
> > > I don't see that it makes sense to archive Linux bugs as long ad the
> > > Linux kernel folks are obviously not willing to fix them.
> >
> > Then the bugs can't have been important to you.
>
> ??? Id the Linux kernel is not fixed, the importance is irrelevent
> unfortunately.
Of the two bugs you've reported, one only exists in a deprecated and soon to
be removed module. I will try to fix the other one as soon as you can provide
me with enough data that I can see exactly what is getting messed up where.
As to you wanting to be able to read the SCSI status byte and the actual size
of the completed DMA... Those parts of the kernel are as close to a blackbox
to me as any code gets. Perhaps you could provide information or ideas on how
it could be managed?
DRH
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-16:
>
> > Matthias Andree <[email protected]> wrote:
> >
> > > > I usually fix real bugs immediately after I know them.
> > >
> > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > forever even if you're made aware of them, and rather shift the blame
> > > on somebody else.
> >
> > Show me a single real bug that I did not fix.
>
> Namespace split ATA/SCSI is unfixed in 2.01.01a06.
The namne space split is a Linux kernel bug
> Bogus warnings about Linux are unfixed in said version.
Warnings related to Linux kernel bugs
> Bogus warnings about /dev/* are unfixed in said version.
Warnings related to Linux kernel bugs
> Linux uname() detection code is broken since 2.6.10 because it assumes
> fixed-width fields.
Warnings related to Linux kernel bugs
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
>
> The namne space split is a Linux kernel bug
You are getting ridiculous. A bug against what? Against your wishes?
> > Bogus warnings about /dev/* are unfixed in said version.
>
> Warnings related to Linux kernel bugs
Rubbish. The Linux bugs you have pointed to are in ide-scsi and opening
/dev/hd* directly is guaranteed to avoid them. The only warning which would
make sense would be if somebody USES ide-scsi, not if he avoids it.
> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
>
> Warnings related to Linux kernel bugs
Stop parroting and read what you are replying to.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
My Wife Says I Never Listen, Or Something Like That...
Edgar Toernig <[email protected]> wrote:
> Joerg Schilling wrote:
> >
> > Matthias Andree <[email protected]> wrote:
> >
> > > > I usually fix real bugs immediately after I know them.
> > >
> > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > forever even if you're made aware of them, and rather shift the blame
> > > on somebody else.
> >
> > Show me a single real bug that I did not fix.
>
> Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
> reboots when run as root.
Isn't this unfair?
Heiko did not work on cdda2wav since ~ 2.5 years.
You may have luck in the future as I received the SCCS history for cdda2wav
3 days ago, but there are other more important things to do first......
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> At this point I, personally, am not aware of any. However, after a careful
> review of libscg in preparation for the patch I promised you, I can see that
> it would be possible for the code to be rewritten so that just the linux
> section contains the various workarounds that might be needed.
>
> With your refusal to even consider doing that I can see where some people get
> this idea (I myself was under this exact same belief until I began my code
> review in preparation for the proposed patch).
I am not refusing useful changes but I of course refuse to apply changes that
will or even may cause problems in the future.
cdrtools and libscg are a serious project and are maintained in a way that tries
to _plan_ all interfaces in a way that allows to upgrade interfaces for at
least 10 years without a need for incompatible changes.
> I am unsure if you refused to provide OS specific workarounds for known bugs
> in order to keep the code orthogonal, or if you had another reason. But with
> the division of the various operating system specific pieces of libscg into
> seperate source files it doesn't make sense.
I like to have things orthogonal, but it seems that most people in LKML
do not understand implicit constraints from requiring orthogobality.
> Of the two bugs you've reported, one only exists in a deprecated and soon to
> be removed module. I will try to fix the other one as soon as you can provide
> me with enough data that I can see exactly what is getting messed up where.
Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
ir removed, then a clean and orthogonal way of accessing SCSI in a generic
way is removed from Linux. If Linux does nto care about orthogonality of
interfaces, this is a problem of the people who are responbile for the related
interfaces.
> As to you wanting to be able to read the SCSI status byte and the actual size
> of the completed DMA... Those parts of the kernel are as close to a blackbox
> to me as any code gets. Perhaps you could provide information or ideas on how
> it could be managed?
This is another construction side in Linux.
In 1997, I did cleanly write dowen what exact features are missing to allow
Linux to be used to _develop_ SCSI user space programs. I did even send a patch
for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface
in a source AND binary, up AND downwards compatible way.
This patch has been rejected for unknown reasons and the fact that the source
code fond in official Linux release has been changed in an incompatible way, it
is impossible to apply it now.
My patch did enable sg.c to return more error/status information back to the
user (e.g. the SCSI status byte) _and_ it defined a way to return DMA residual
counts to the user. If Linux still does not even have the DMA residual count
internally available, this is a proof that nobody with sufficient SCSI know how
is willing to work on the Linux SCSI layer.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> Sorry, the way to access SCSI generic via /dev/hd* is deprecated.
By whom?
> ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> way is removed from Linux. If Linux does nto care about orthogonality of
> interfaces, this is a problem of the people who are responbile for the related
> interfaces.
You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that?
Yes, I agree with you that it's hard to do device discovery, but discovering
devices is completely orthogonal to doing I/O in them and it's also not
a problem specific to SCSI devices at all. Hence we want to find a general
solution suitable for *all* devices and that's what sysfs, udev and HAL are
for. They might have some rough edges yet, but they definitely solve the
right problem.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"In theory, practice and theory are the same, but in practice they are different." -- Larry McVoy
Joerg Schilling schrieb am 2006-02-17:
> Matthias Andree <[email protected]> wrote:
>
> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
>
> The namne space split is a Linux kernel bug
Define: name space := cdrecord/libscg device identifier,
specified as [transport:]bus,target,lun
It is a libscg bug, as proven before in
<http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>
(Just so you don't get the last word.)
> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
>
> Warnings related to Linux kernel bugs
OK. Since the bug is actually beneficial to Linux >= 2.6.10 users, I'm
not detailing. You don't need to fix it.
--
Matthias Andree
Joerg Schilling schrieb am 2006-02-17:
> > Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
> > reboots when run as root.
>
> Isn't this unfair?
No. You asked for bugs, you got bugs.
You ship cdda2wav, you take the blame.
> Heiko did not work on cdda2wav since ~ 2.5 years.
Does that alleviate the bug? No.
--
Matthias Andree
Martin Mares <[email protected]> wrote:
> > ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> > way is removed from Linux. If Linux does nto care about orthogonality of
> > interfaces, this is a problem of the people who are responbile for the related
> > interfaces.
>
> You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that?
I encourage you to read the previous mails, this has been explained for more
than ten times now.....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Fri, 17 Feb 2006 12:41:58 +0100
Joerg Schilling <[email protected]> wrote:
> In 1997, I did cleanly write dowen what exact features are missing to allow
> Linux to be used to _develop_ SCSI user space programs. I did even send a patch
> for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface
> in a source AND binary, up AND downwards compatible way.
>
> This patch has been rejected for unknown reasons and the fact that the source
> code fond in official Linux release has been changed in an incompatible way, it
> is impossible to apply it now.
Shock! 1997 patch no longer applies cleanly in 2006! Alert the media!
Seriously though, this is exactly why I think Linux should start accepting
patches from crazy people without question or review. It's much easier to
deal with whatever cruft is applied by the patch than it is to endure the
multi year manic tirades of such individuals who have their egos bruised as
a result of rejection.
Sean
Hello!
> I encourage you to read the previous mails, this has been explained for more
> than ten times now.....
Maybe the problem lies in nobody except you considering it an explanation.
E.g., your theory about Linux breaking POSIX has been disproved pretty quickly.
Feel free to consider the Linux interface silly or badly designed, that's
everybody's right, but please keep in mind that as long as you are unable to point
to any *real* problems with it, it's just your opinion not shared by most of
the other people, including the maintainers of the said subsystems, so it's
hardly a reason for changing the interface.
Sorry, but although I value your experience with CD writing very much,
I don't think you are the right person to decide on what the naming of devices
in Linux will look like, exactly because it's a problem with much broader
context than just SCSI devices.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice." -- Albert Einstein
>> Of the two bugs you've reported, one only exists in a deprecated and soon to
>> be removed module. I will try to fix the other one as soon as you can provide
>> me with enough data that I can see exactly what is getting messed up where.
>
>Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
>ir removed, then a clean and orthogonal way of accessing SCSI in a generic
>way is removed from Linux. If Linux does nto care about orthogonality of
>interfaces, this is a problem of the people who are responbile for the related
>interfaces.
>
So what you want is to be able to use write() on a <sg-compatible> device
rather than doing SG_IO ioctl() on <any> device?
Jan Engelhardt
--
On Friday 17 February 2006 06:41, you wrote:
> "D. Hazelton" <[email protected]> wrote:
> > At this point I, personally, am not aware of any. However, after a
> > careful review of libscg in preparation for the patch I promised you, I
> > can see that it would be possible for the code to be rewritten so that
> > just the linux section contains the various workarounds that might be
> > needed.
> >
> > With your refusal to even consider doing that I can see where some people
> > get this idea (I myself was under this exact same belief until I began my
> > code review in preparation for the proposed patch).
>
> I am not refusing useful changes but I of course refuse to apply changes
> that will or even may cause problems in the future.
sysfs is in the kernel and I doubt the contents of /sys/block will change any.
By reading that directory you can find _all_ existing ATA/ATAPI devices as
well as all existing SCSI devices.
As a useful change I could patch your ATA/ATAPI scanning code in libscg to do
that - it would certainly clean up the code. Furthermore, as was pointed out
by Albert Cahalan, Linux does provide b,t,l addresses for ATA/ATAPI devices -
available from a simple stat of the device node.
With him having checked a quick hack of code I tossed together to check the
idea I can even provide code to you that proves this point.
If you are amenable to a patch that does nothing more than fix the ATA/ATAPI
scanning code on Linux so it functions properly then I will go ahead and
create such.
> cdrtools and libscg are a serious project and are maintained in a way that
> tries to _plan_ all interfaces in a way that allows to upgrade interfaces
> for at least 10 years without a need for incompatible changes.
Noted. However even if I do create said patch, I'm more than 90% certain you
won't even take a look at it.
And if you are worried about the future of your code...
Why do you use the autoconf system in such a nonstandard way? It's scripts are
portable to all POSIX compliant systems. From what I have seen they would
remove most of the problems you have and would allow for the code to be
ported to other operating systems even faster.
(Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant
systems, didn't I? Most packages provide prebuilt stuff for compiling for
DOS/Windows anyway.)
> > I am unsure if you refused to provide OS specific workarounds for known
> > bugs in order to keep the code orthogonal, or if you had another reason.
> > But with the division of the various operating system specific pieces of
> > libscg into seperate source files it doesn't make sense.
>
> I like to have things orthogonal, but it seems that most people in LKML
> do not understand implicit constraints from requiring orthogobality.
This is why I'm asking why you don't include such workarounds. As far as I can
see all you do in your code is complain about things with somewhat pointless
warnings and do minimal work to get around the flaws you complain about.
> > Of the two bugs you've reported, one only exists in a deprecated and soon
> > to be removed module. I will try to fix the other one as soon as you can
> > provide me with enough data that I can see exactly what is getting messed
> > up where.
>
> Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a
> generic way is removed from Linux. If Linux does nto care about
> orthogonality of interfaces, this is a problem of the people who are
> responbile for the related interfaces.
Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5
series kernel - at the same time ide-scsi was deprecated access via SG_IO
on /dev/hd* is the new method and not deprecated.
I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport
layer into the SCSI bus code for generic SCSI access, but in Linux there is a
clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on
the system entirely without the SCSI system even being built.
The reason for this, at least to me, is to allow people building Linux kernels
for embedded devices to turn off everything that isn't needed.
> > As to you wanting to be able to read the SCSI status byte and the actual
> > size of the completed DMA... Those parts of the kernel are as close to a
> > blackbox to me as any code gets. Perhaps you could provide information or
> > ideas on how it could be managed?
>
> This is another construction side in Linux.
>
> In 1997, I did cleanly write dowen what exact features are missing to allow
> Linux to be used to _develop_ SCSI user space programs. I did even send a
> patch for sg.c to the Linux folks. This patch extends the sg SCSI Generic
> interface in a source AND binary, up AND downwards compatible way.
Okay. I haven't gone through the mailing list archives to look at this patch.
There are any number of reasons for it being rejected. One of them is that it
got lost in the traffic on LKML.
>
> My patch did enable sg.c to return more error/status information back to
> the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA
> residual counts to the user. If Linux still does not even have the DMA
> residual count internally available, this is a proof that nobody with
> sufficient SCSI know how is willing to work on the Linux SCSI layer.
I can see how the residual DMA count information might be impossible to get at
- the Linux memory allocator has been changed quite a bit over the course of
the past nine years.
However reading the SCSI status byte should still be possible. I have
absolutely _no_ familiarity with that section of the kernel so I wont even
attempt to create such a patch but you should be familiar enough with whats
going on to create said patch.
So, in the end, I have to ask - why don't you create that patch?
DRH
On Fri, 17 Feb 2006, D. Hazelton wrote:
> Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5
> series kernel - at the same time ide-scsi was deprecated access via SG_IO
> on /dev/hd* is the new method and not deprecated.
This is all information that libscg does not need to know. There are
only two models:
1. the old sg2 model before SG_IO was available, was to use write() and
read() on a /dev/sg* node.
2. the new sg3 model is do SG_IO on any device node no matter if /dev/hd,
/dev/sg or perhaps /dev/foobaz42 next year. /dev/sg* happened to be the
first to implement this, others followed suit, and more to come.
--
Matthias Andree
On Friday 17 February 2006 05:29, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
> > Joerg Schilling schrieb am 2006-02-16:
> > > Matthias Andree <[email protected]> wrote:
> > > > > I usually fix real bugs immediately after I know them.
> > > >
> > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > > forever even if you're made aware of them, and rather shift the blame
> > > > on somebody else.
> > >
> > > Show me a single real bug that I did not fix.
> >
> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
>
> The namne space split is a Linux kernel bug
Then why have I been talking about a unification with you?
I would quote your comments on it, but since that was a private mail I will
not do so.
> > Bogus warnings about Linux are unfixed in said version.
>
> Warnings related to Linux kernel bugs
>From what I can tell a lot of the warnings are bogus. You even go to great
lengths to "scare" people into only using "official" versions of cdrtools.
As to that, you have sections in the code marked "Do Not Change" and "Do Not
Remove" - I checked the GPLv2 today (the one shipped with all versions of
cdrecord I can find) and there is nothing in that which gives you the right
to restrict what someone else does to your code.
Call it people being polite that nobody has removed that stuff from the
existing primary port of cdrtools.
> > Bogus warnings about /dev/* are unfixed in said version.
>
> Warnings related to Linux kernel bugs
No. There is no Kernel bug in the SG_IO via /dev/hd* implementation.
While I can gloss over most other warnings, the following seem to be scare
tactics to me:
cdrecord: Warning: Running on Linux-2.6.12-gentoo-r6
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
Warning: Using badly designed ATAPI via /dev/hd* interface.
> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
>
> Warnings related to Linux kernel bugs
Since when is a function that doesn't handle a value returned not the source
of a bug?
Show me the POSIX rules that say all fields returned by uname() have to have a
certain fixed size.
DRH
Jan Engelhardt <[email protected]> wrote:
> >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
> >ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> >way is removed from Linux. If Linux does nto care about orthogonality of
> >interfaces, this is a problem of the people who are responbile for the related
> >interfaces.
> >
>
> So what you want is to be able to use write() on a <sg-compatible> device
> rather than doing SG_IO ioctl() on <any> device?
This kind of disinformation is what constantly puts fuel into the fire....
Are you a victim of the firebugs in this list?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Friday 17 February 2006 16:52, Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> wrote:
> > >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI
> > > in a generic way is removed from Linux. If Linux does nto care about
> > > orthogonality of interfaces, this is a problem of the people who are
> > > responbile for the related interfaces.
> >
> > So what you want is to be able to use write() on a <sg-compatible> device
> > rather than doing SG_IO ioctl() on <any> device?
>
> This kind of disinformation is what constantly puts fuel into the fire....
>
> Are you a victim of the firebugs in this list?
Joerg, it may not be perfect, but it does work. If you're still worried about
how a few of the currently unmaintained devices still don't support SG_IO
then I suggest you find someone to take maintainership.
I have neither the skill nor the want to do it or I would, just to see if it
quieted you down any.
BTW, make it more than a couple of weeks for the patch I mentioned for libscg
- I still need a response about my suggestion to use the BTL addresses Linux
provides as the addresses passed around from libscg to cdrecord.
DRH
"D. Hazelton" <[email protected]> wrote:
> > cdrtools and libscg are a serious project and are maintained in a way that
> > tries to _plan_ all interfaces in a way that allows to upgrade interfaces
> > for at least 10 years without a need for incompatible changes.
>
> Noted. However even if I do create said patch, I'm more than 90% certain you
> won't even take a look at it.
If your code will have similar relevence than the code from Matthias, you are
obviously true.
> Why do you use the autoconf system in such a nonstandard way? It's scripts are
> portable to all POSIX compliant systems. From what I have seen they would
> remove most of the problems you have and would allow for the code to be
> ported to other operating systems even faster.
I do use autoconf in the only senseful way.
And if you did have a look at the schily makefile system you would know that
it provides protability to more plaforms than you get from using an GNU
autoconf the way the GNU people tell you.
If you like best portability, you need to use my version of autoconf inside the
schily makefile system and you need to use my smake instead of GNU make.
So my conclusion is that you did not understand portability. All my software is
using layered portability and if you did take a closer look at the few FSF people
who know what they are talking about, you would find that e.g. Paul Eggert
recently started to silently imitate my portability methods.....
> (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant
> systems, didn't I? Most packages provide prebuilt stuff for compiling for
> DOS/Windows anyway.)
???? There are many problems with portability.
One problem is that GNU make is not working in a useful way on many patforms
that are listed to be working. GNU make is unmaintained since many years and
a serious bug I reported in 1999 still has not been fixed.
So for portability, I was forced to make my smake more portable than any other
open source make program. The automake features (don't confuse this with the
ill designed and wrongly named "automake" program from the FSF) of smake
allow to compile my software on nearly any unknown platform.
> > I like to have things orthogonal, but it seems that most people in LKML
> > do not understand implicit constraints from requiring orthogobality.
>
> This is why I'm asking why you don't include such workarounds. As far as I can
> see all you do in your code is complain about things with somewhat pointless
> warnings and do minimal work to get around the flaws you complain about.
Well what I did first was to try to have a discussion with the Linux people in
order to avoid the problems introduced by Linux.
When it turned out that the related people are not interested, all I could do
was to print warnings.
> > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a
> > generic way is removed from Linux. If Linux does nto care about
> > orthogonality of interfaces, this is a problem of the people who are
> > responbile for the related interfaces.
>
> Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5
> series kernel - at the same time ide-scsi was deprecated access via SG_IO
> on /dev/hd* is the new method and not deprecated.
Any system that is worse than another one is deprecated.
If people on LKML believe it is OK not to abide promises and if they don't have
the vision that /dev/hd* only serves some limited applications but not the need
of generic applications like libscg, this is a LKML problem.
> I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport
> layer into the SCSI bus code for generic SCSI access, but in Linux there is a
> clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on
> the system entirely without the SCSI system even being built.
The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once
that a uniquely layered system could save a lot of code by avoiding to
implement things more than once.
> The reason for this, at least to me, is to allow people building Linux kernels
> for embedded devices to turn off everything that isn't needed.
Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
A SCSI disk driver would be sufficient.
> > My patch did enable sg.c to return more error/status information back to
> > the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA
> > residual counts to the user. If Linux still does not even have the DMA
> > residual count internally available, this is a proof that nobody with
> > sufficient SCSI know how is willing to work on the Linux SCSI layer.
>
> I can see how the residual DMA count information might be impossible to get at
> - the Linux memory allocator has been changed quite a bit over the course of
> the past nine years.
Most other OS provide this information.
Is Linux really that underdeveloped for not being able to provide DMA residual
counts?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> > The namne space split is a Linux kernel bug
>
> Then why have I been talking about a unification with you?
>
> I would quote your comments on it, but since that was a private mail I will
> not do so.
????
I did not get any proposal for working on making ide-scsi work nor did
I get a useful proposal that would explain how it might be done without
ide-scsi.
> > > Bogus warnings about Linux are unfixed in said version.
> >
> > Warnings related to Linux kernel bugs
>
> From what I can tell a lot of the warnings are bogus. You even go to great
> lengths to "scare" people into only using "official" versions of cdrtools.
They are related to serious problems.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once
> that a uniquely layered system could save a lot of code by avoiding to
> implement things more than once.
Could you please stop parrotting this again and again, at least as long as you
are unable to point to any duplicated code?
> Is Linux really that underdeveloped for not being able to provide DMA residual
> counts?
How is it related to the discussion about interfaces?
So far, whenever you were asked to support your assertions (dynamic device
naming violating POSIX, duplicated code, your warning which is printed when
not using ide-scsi while the bugs you were speaking about occur only _with_
ide-scsi and so on), you have ignored the request and started either repeating
the same or diverting the attention to completely unrelated problems (like
above).
Unless you wish to stop spreading your demagogy and write facts instead,
I recommend you to shut up and this is my last mail in this discussion.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"This quote has been selected randomly. Really." -- M. Ulrichs
Joerg Schilling schrieb am 2006-02-20:
> > Noted. However even if I do create said patch, I'm more than 90% certain you
> > won't even take a look at it.
>
> If your code will have similar relevence than the code from Matthias, you are
> obviously true.
Well, it is irrelevant to _you_ because it proves you're wrong. At
least, not a single objective argument WRT bugs in side the code have
surfaced.
> One problem is that GNU make is not working in a useful way on many patforms
> that are listed to be working. GNU make is unmaintained since many years and
> a serious bug I reported in 1999 still has not been fixed.
The so-called "serious" bug is a purely cosmetic complaint about
non-existant .d files.
> > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5
> > series kernel - at the same time ide-scsi was deprecated access via SG_IO
> > on /dev/hd* is the new method and not deprecated.
>
> Any system that is worse than another one is deprecated.
Hm. Schilling's applications are worse than others by printing
meaningless warnings...
> If people on LKML believe it is OK not to abide promises and if they don't have
Your delusions about who "promise"d something to you...
> Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> A SCSI disk driver would be sufficient.
Not your business.
--
Matthias Andree
On Monday 20 February 2006 09:51, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > > cdrtools and libscg are a serious project and are maintained in a way
> > > that tries to _plan_ all interfaces in a way that allows to upgrade
> > > interfaces for at least 10 years without a need for incompatible
> > > changes.
> >
> > Noted. However even if I do create said patch, I'm more than 90% certain
> > you won't even take a look at it.
>
> If your code will have similar relevence than the code from Matthias, you
> are obviously true.
>
> > Why do you use the autoconf system in such a nonstandard way? It's
> > scripts are portable to all POSIX compliant systems. From what I have
> > seen they would remove most of the problems you have and would allow for
> > the code to be ported to other operating systems even faster.
>
> I do use autoconf in the only senseful way.
>
> And if you did have a look at the schily makefile system you would know
> that it provides protability to more plaforms than you get from using an
> GNU autoconf the way the GNU people tell you.
>
> If you like best portability, you need to use my version of autoconf inside
> the schily makefile system and you need to use my smake instead of GNU
> make.
>
> So my conclusion is that you did not understand portability. All my
> software is using layered portability and if you did take a closer look at
> the few FSF people who know what they are talking about, you would find
> that e.g. Paul Eggert recently started to silently imitate my portability
> methods.....
I have taken a second look and it does appear that you are correct. But I
still have some doubts (none that I can quantify) - would it not make sense
to also use automake?
> > (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX
> > compliant systems, didn't I? Most packages provide prebuilt stuff for
> > compiling for DOS/Windows anyway.)
>
> ???? There are many problems with portability.
>
> One problem is that GNU make is not working in a useful way on many
> patforms that are listed to be working. GNU make is unmaintained since many
> years and a serious bug I reported in 1999 still has not been fixed.
Apparently true - the version of gmake I use is four years old. Too bad almost
everything on my system relies on the quirks and features of gmake...
<snip>
> > > I like to have things orthogonal, but it seems that most people in LKML
> > > do not understand implicit constraints from requiring orthogobality.
> >
> > This is why I'm asking why you don't include such workarounds. As far as
> > I can see all you do in your code is complain about things with somewhat
> > pointless warnings and do minimal work to get around the flaws you
> > complain about.
>
> Well what I did first was to try to have a discussion with the Linux people
> in order to avoid the problems introduced by Linux.
>
> When it turned out that the related people are not interested, all I could
> do was to print warnings.
Dodged the question there, didn't you? My question here goes unanswered.
Rather than putting workarounds in your code for the bugs you complain about
you've just put warnings in the code. Seems that that breaks orthagonality in
favor of complaining.
> > > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI
> > > in a generic way is removed from Linux. If Linux does nto care about
> > > orthogonality of interfaces, this is a problem of the people who are
> > > responbile for the related interfaces.
> >
> > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the
> > 2.5 series kernel - at the same time ide-scsi was deprecated access via
> > SG_IO on /dev/hd* is the new method and not deprecated.
>
> Any system that is worse than another one is deprecated.
It seems we have different definitions of deprecated. The definition you are
using is incompatable with the definition of the word as used in software
development. In software development the word means "Old and in the process
of being removed from use".
<snip>
> > I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI
> > transport layer into the SCSI bus code for generic SCSI access, but in
> > Linux there is a clear distinction that exists because the IDE/ATA/ATAPI
> > drivers can exist on the system entirely without the SCSI system even
> > being built.
>
> The SCSI glue layer on Solaris is less than 50 kB. I did mention more than
> once that a uniquely layered system could save a lot of code by avoiding to
> implement things more than once.
Does that glue code comprise the proposed SATL system? Recently I've come
across those whitepapers and opened a discussion about it on LKML.
> > The reason for this, at least to me, is to allow people building Linux
> > kernels for embedded devices to turn off everything that isn't needed.
>
> Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> A SCSI disk driver would be sufficient.
and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI
transport code and the specific SCSI driver for a device.
> > > My patch did enable sg.c to return more error/status information back
> > > to the user (e.g. the SCSI status byte) _and_ it defined a way to
> > > return DMA residual counts to the user. If Linux still does not even
> > > have the DMA residual count internally available, this is a proof that
> > > nobody with sufficient SCSI know how is willing to work on the Linux
> > > SCSI layer.
> >
> > I can see how the residual DMA count information might be impossible to
> > get at - the Linux memory allocator has been changed quite a bit over the
> > course of the past nine years.
>
> Most other OS provide this information.
>
> Is Linux really that underdeveloped for not being able to provide DMA
> residual counts?
No idea. All I said was that with the changes to how the memory allocator
works I can see where it might be impossible to get such information. I don't
think it is, though. What I think is that the developers of the allocator and
the DMA systems just forgot to include such a capability.
DRH
On Monday 20 February 2006 09:59, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > > The namne space split is a Linux kernel bug
> >
> > Then why have I been talking about a unification with you?
> >
> > I would quote your comments on it, but since that was a private mail I
> > will not do so.
>
> ????
>
> I did not get any proposal for working on making ide-scsi work nor did
> I get a useful proposal that would explain how it might be done without
> ide-scsi.
Don't even start. In a private exchange you stated that you had been thinking
of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for
the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the
ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems.
I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and
you said it was wrong and not useful. I've since asked you in another private
mail if you have another solution I could code into the patch and don't
expect a reply until tomorrow.
For the record, I am trying to work with you to resolve these problems, but at
the moment the problem of unifying the scannign of the SCSI and ATA/ATAPI
busses inside libscg in order to workaround the Kernel not providing access
to ATA/ATAPI devices via /dev/sg* is stopped because of the problem of how to
uniquely identify said devices and the problem with the kernel munging SCSI
CDB's for certain devices is stopped because I don't have access to the
hardware to see exactly what gets munged.
And since you've stated that the machine on which you could reproduce the
problem died 3 years ago, I have to assume that the problem may have been
fixed in the ensuing time period.
> > > > Bogus warnings about Linux are unfixed in said version.
> > >
> > > Warnings related to Linux kernel bugs
> >
> > From what I can tell a lot of the warnings are bogus. You even go to
> > great lengths to "scare" people into only using "official" versions of
> > cdrtools.
>
> They are related to serious problems.
Really? From what I've seen you mark sections "You cannot change this" to stop
people from removing those warnings. In fact, there is code in cdrecord that
relates to "bugs" in distribution patched versions that most likely do not
exist anymore. "Serious problems", though? Seems you just love SCSI, fell in
love with ide-scsi and can't let it go. I've been using cdrecord for more
than six years now, the last two on a system without _ide-scsi_ and have yet
to have a problem - so either the problems you call serious are not serious
enough or I was lucky to build a system from spare parts that managed to
dodge all those problems. By applying Occams razor, I find that the first is
likely true.
DRH
Joerg Schilling schrieb am 2006-02-20:
> I did not get any proposal for working on making ide-scsi work
The suggestion was not to insist on it.
> nor did I get a useful proposal that would explain how it might be
> done without ide-scsi.
The existing code works good enough for the cdrecord "consumer" of your
libscg library when the scary warnings are dropped.
Problems with new hardware can be fixed as use cases and hardware appear
and real problems show up. Given that the Linux device layering is
documented as passing unknown ioctls to lower layers to see if they can
deal with them, there shouldn't be many issues.
If you're unware of problems with new hardware or inventions, nobody can
seriously blame you, just stuff "last found working with Linux 2.6.y"
into some readme file and that's it.
> > From what I can tell a lot of the warnings are bogus. You even go to great
> > lengths to "scare" people into only using "official" versions of cdrtools.
>
> They are related to serious problems.
They are related to problems that you encountered with a SUSE version
ages ago, else your commentary in the code is insufficient.
You ought to check once a year or once every two years if the problems
you are so heftily complain about persist in supported versions; for
instance, any SUSE warnings related to 8.X versions can be removed and
replaced by a note that you don't intend to support operating systems
that are no longer supported by their respective vendor. You don't have
support contracts with distributors, so they aren't obliged to tell you
"hey we fixed that bug" -- and if you asked, you'd probably get a useful
answers.
I'm applying the same policy to my software (no support on unsupported
distributions) and it hasn't caused a single complaint yet, the only
comments I received were apologies for having to use obsolete systems
for some reasons, with people being rather modest and cooperative, like
offering testing, accounts on those systems and so on. Pretty reasonable
all in all IMO.
--
Matthias Andree
"D. Hazelton" <[email protected]> wrote:
> > I do use autoconf in the only senseful way.
> >
> > And if you did have a look at the schily makefile system you would know
> > that it provides protability to more plaforms than you get from using an
> > GNU autoconf the way the GNU people tell you.
> >
> > If you like best portability, you need to use my version of autoconf inside
> > the schily makefile system and you need to use my smake instead of GNU
> > make.
> >
> > So my conclusion is that you did not understand portability. All my
> > software is using layered portability and if you did take a closer look at
> > the few FSF people who know what they are talking about, you would find
> > that e.g. Paul Eggert recently started to silently imitate my portability
> > methods.....
>
> I have taken a second look and it does appear that you are correct. But I
> still have some doubts (none that I can quantify) - would it not make sense
> to also use automake?
The way autoconf should be used acording to the autoconf manual is already
wrong and the creation of just another makefile generator, that even is
incorrectly called "automake", is definitely a step into the wrong direction.
David Korn recently discovered that my makefile system basically does the same
as his system. But while he need to write a "make successor" "nmake", I was able
to do the same using "make".
The ideas that I am sucessfully using since more than 12 years is what researchers
did start around 1985.
GNU autoconf (used the documented way) or "automake" is trying to do things in
a way that did look apropriate in the 1970s.
People should look at better solutions (like my makefile system) that do not
need to modify makefiles in place but rather implement object oriented design
that depend on a "table like" master makefile and for this reason allow to
concurrently compile on _all_ supported platforms on the same source tree
in case that the tree is mounted via NFS.
> > One problem is that GNU make is not working in a useful way on many
> > patforms that are listed to be working. GNU make is unmaintained since many
> > years and a serious bug I reported in 1999 still has not been fixed.
>
> Apparently true - the version of gmake I use is four years old. Too bad almost
> everything on my system relies on the quirks and features of gmake...
Try to use my smake to find out whether you use non-portable constructs.
Smake warns you about the most common problems in makefiles.
> > When it turned out that the related people are not interested, all I could
> > do was to print warnings.
>
> Dodged the question there, didn't you? My question here goes unanswered.
> Rather than putting workarounds in your code for the bugs you complain about
> you've just put warnings in the code. Seems that that breaks orthagonality in
> favor of complaining.
The more rotten Linux interfaces become, the harder it is to implement work
arounds.
> > The SCSI glue layer on Solaris is less than 50 kB. I did mention more than
> > once that a uniquely layered system could save a lot of code by avoiding to
> > implement things more than once.
>
> Does that glue code comprise the proposed SATL system? Recently I've come
> across those whitepapers and opened a discussion about it on LKML.
??? Solaris supports SAS decives, is this your question?
> > Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> > A SCSI disk driver would be sufficient.
>
> and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI
> transport code and the specific SCSI driver for a device.
This is an unproven statement.
> > > I can see how the residual DMA count information might be impossible to
> > > get at - the Linux memory allocator has been changed quite a bit over the
> > > course of the past nine years.
> >
> > Most other OS provide this information.
> >
> > Is Linux really that underdeveloped for not being able to provide DMA
> > residual counts?
>
> No idea. All I said was that with the changes to how the memory allocator
> works I can see where it might be impossible to get such information. I don't
> think it is, though. What I think is that the developers of the allocator and
> the DMA systems just forgot to include such a capability.
It seems that Linux is not used for developing SCSI applications, otherwise
I would not be the only person complaining about this missing feature.
I am using SunOS/Solaris for my SCSI programs since 1985, so I don't have
problem. It seems that Linux users don't like to know if their software fails.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
>
> Don't even start. In a private exchange you stated that you had been thinking
> of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for
> the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the
> ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems.
>
> I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and
> you said it was wrong and not useful. I've since asked you in another private
> mail if you have another solution I could code into the patch and don't
> expect a reply until tomorrow.
And I explained you why this is inapropriate. So what is your peoblem?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-21:
> Try to use my smake to find out whether you use non-portable constructs.
> Smake warns you about the most common problems in makefiles.
To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
portable make (just bootstrap http://www.pkgsrc.org to obtain "bmake" on Linux)
is probably a much better approach since it tests real-world make
implementations rather than an artificial and not widely available local
flavor.
> > and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI
> > transport code and the specific SCSI driver for a device.
>
> This is an unproven statement.
Proof sketch: Compile Linux without SCSI subsystem and see if
cdrecord dev=/dev/hdc still works.
> It seems that Linux is not used for developing SCSI applications, otherwise
> I would not be the only person complaining about this missing feature.
The other scenario is that nobody but you has problems
developing/porting SCSI applications to Linux, or nobody but you has
problems formulating useful bug reports. Holding on to 1999 bug reports
that you cannot dig up doesn't work without paid support contract,
as you've seen.
--
Matthias Andree
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-21:
>
> > Try to use my smake to find out whether you use non-portable constructs.
> > Smake warns you about the most common problems in makefiles.
>
> To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
> portable make (just bootstrap http://www.pkgsrc.org to obtain "bmake" on Linux)
> is probably a much better approach since it tests real-world make
> implementations rather than an artificial and not widely available local
> flavor.
Thank you for proving that you are completely uninformed!
Smake is able to compile a _lot_ more real world applications than BSD make.
This is because smake is POSIX compliant while BSD make is not.
Smake is even able to compile more free software that depends on non-portable
GNU make extensions than Sun make does.
And smake warns about makefiles that only work because they depend on Bugs
found in Sun make or GNU make (e.g. because they try to expand '$*' or '$<'
in explicit target rules).
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-21:
> Matthias Andree <[email protected]> wrote:
>
> > Joerg Schilling schrieb am 2006-02-21:
> >
> > > Try to use my smake to find out whether you use non-portable constructs.
> > > Smake warns you about the most common problems in makefiles.
> >
> > To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
> > portable make (just bootstrap http://www.pkgsrc.org to obtain "bmake" on Linux)
> > is probably a much better approach since it tests real-world make
> > implementations rather than an artificial and not widely available local
> > flavor.
>
> Thank you for proving that you are completely uninformed!
You just proved your incapability to extract the meaning of five simple
lines. If you're incapable to understand simple statements like these,
shut your head.
The meaning is, just especially for you so you can excuse yourself, and
in PowerPoint style to be easy on your time:
- run Solaris' /usr/{ccs,xpg4}/bin/make
to find out if your Makefile is portable
- run BSD's portable make (that's a proper name)
to find out if your Makefile is portable
- testing real-world make programs with Makefiles will find out much
more reliably if non-portable constructs are used.
Examples: smake -W -posix (version 1.2a34, the newest available) doesn't
warn of include foo.d (works with said make tools, but isn't POSIX
compliant), and doesn't warn of -include foo.d (works with smake, GNU
make, BSD make, but not SUN make).
This is pretty strong evidence that smake is insufficient as
Makefile portability validator, which substantiates my recommendation to
test real-world make(1) programs rather than smake to find out the
portability characteristics.
And now repeat your insult I were uninformed again,
that's your quickest way to criminal prosecution.
You said good-bye to factual discussion long ago.
--
Matthias Andree
On Tuesday 21 February 2006 04:44, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > > I do use autoconf in the only senseful way.
> > >
<snip>
> > > The SCSI glue layer on Solaris is less than 50 kB. I did mention more
> > > than once that a uniquely layered system could save a lot of code by
> > > avoiding to implement things more than once.
> >
> > Does that glue code comprise the proposed SATL system? Recently I've come
> > across those whitepapers and opened a discussion about it on LKML.
>
> ??? Solaris supports SAS decives, is this your question?
SAS? No. To quote you quite frequently - RTFM. SATL is an entire system,
similar to the old ide-scsi module, that sits on top of the SCSI and ATA
interfaces and provides the capacity to access any disk device on the system
using SCSI commands.
DRH
On Tuesday 21 February 2006 04:55, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > Don't even start. In a private exchange you stated that you had been
> > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove
> > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg
> > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux
> > systems.
> >
> > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0
> > - and you said it was wrong and not useful. I've since asked you in
> > another private mail if you have another solution I could code into the
> > patch and don't expect a reply until tomorrow.
>
> And I explained you why this is inapropriate. So what is your peoblem?
And I asked if _you_ had a solution that I could then implement. Apparently
you are no intelligent enough, or have your head too far up your ass, to
understand a simple question. Goodbye, Joerg - you are now in my killfile.
DRH
Matthias Andree <[email protected]> wrote:
> > Thank you for proving that you are completely uninformed!
>
> You just proved your incapability to extract the meaning of five simple
> lines. If you're incapable to understand simple statements like these,
> shut your head.
You just did strengthen the impression you gave with your mail before....
although - after a long time - you at least did again make yourself busy
with the topic in a mail....
> The meaning is, just especially for you so you can excuse yourself, and
> in PowerPoint style to be easy on your time:
>
> - run Solaris' /usr/{ccs,xpg4}/bin/make
> to find out if your Makefile is portable
Solaris make does not write useful error messages in case of non-portable
makefiles.
> - run BSD's portable make (that's a proper name)
> to find out if your Makefile is portable
BSD make may be portable (although I am sure that smake comppiles/runs
on much more platforms) but it is not POSIX compliant. The fact that a
makefile does not work with BSD make does not prove anything as only simpile
makefiles are handeled the same way as POSIX based make programs do.
After we fixed the bug with pattern macro expansions in FreeBSDs make,
it turned out that cc -o some/dir/to/file.o file.c is handled completely
different from UNIX make programs. This makes it impossible to use FreeBSD
make for e.g. the Schily makefilesystem.
> - testing real-world make programs with Makefiles will find out much
> more reliably if non-portable constructs are used.
??? smake _is_ a real world make program and if you rate POSIX compliance
and portability, it will outstrip all other known make programs.
> Examples: smake -W -posix (version 1.2a34, the newest available) doesn't
> warn of include foo.d (works with said make tools, but isn't POSIX
> compliant), and doesn't warn of -include foo.d (works with smake, GNU
> make, BSD make, but not SUN make).
While smake is much closer to POSIX than e.g. GNU make (proof by looking at
#ifdefs related to DOS like OS <CR/NL> instead of just <NL> in the source code
and find that smake has no single exception for DOS in the parser while GNU
make still does not work correctly with all makefiles). But in a single point,
the GNU make maintainers are correct:
A POSIX make is not able to compile portable applications, so we
need to make the make program portable and add features.
Smake does exactly this. It adds the needed features (see "man makefiles" &
"man makerules") from Sun ideas in 1986 and implements them in a portable way.
The needed features are pattern matching expansion and "include".
> This is pretty strong evidence that smake is insufficient as
> Makefile portability validator, which substantiates my recommendation to
> test real-world make(1) programs rather than smake to find out the
> portability characteristics.
The other make programs I know are worse then smake and they are usually not
portable themself. Note that I don't like to use the technology from the 1970s
as GNU "automake" does.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-22:
> > - run Solaris' /usr/{ccs,xpg4}/bin/make
> > to find out if your Makefile is portable
>
> Solaris make does not write useful error messages in case of non-portable
> makefiles.
Sun Microsystems do not advertise their make tool as Makefile
portability validator. Note the difference: each tool is held to its
own standards.
> > - run BSD's portable make (that's a proper name)
> > to find out if your Makefile is portable
>
> BSD make may be portable (although I am sure that smake comppiles/runs
> on much more platforms) but it is not POSIX compliant.
Please look up the term "proper name" before continuing. BSD make does
not mention "POSIX" a single time in its documentation.
> After we fixed the bug with pattern macro expansions in FreeBSDs make,
> it turned out that cc -o some/dir/to/file.o file.c is handled completely
> different from UNIX make programs. This makes it impossible to use FreeBSD
> make for e.g. the Schily makefilesystem.
If BSD make is not UNIX make, then what is?
That FreeBSD's /usr/bin/make doesn't like your Makefiles doesn't matter,
GNU and Schily make are available in the ports collection, either is fine.
> > - testing real-world make programs with Makefiles will find out much
> > more reliably if non-portable constructs are used.
>
> ??? smake _is_ a real world make program and if you rate POSIX compliance
> and portability, it will outstrip all other known make programs.
You still haven't got my point. Last attempt to explain:
smake isn't sufficient to judge if a "Makefile" is portable to all
widespread make programs, particularly does it not warn about non-POSIX
syntax that SUN make or BSD make reject, as shown in my previous message.
> > This is pretty strong evidence that smake is insufficient as
> > Makefile portability validator, which substantiates my recommendation to
> > test real-world make(1) programs rather than smake to find out the
> > portability characteristics.
>
> The other make programs I know are worse then smake and they are usually not
> portable themself. Note that I don't like to use the technology from the 1970s
> as GNU "automake" does.
Your dislike for GNU make is widely documented, yet only based on
cosmetic bugs. Try if the "remake" guys fix the concerns you have had
about GNU make. remake is a GNU make spinoff with usability
improvements, getting rid of meaningless "Makefile:5: foo.d: No such
file or directory" should be well within reach. Dig through your
sent-mail folder for the explanation you sent me a year or two ago.
See <http://bashdb.sourceforge.net/remake/>
I'm redirecting answers off-list.
This isn't linux-kernel stuff any more.
BTW, your Message-ID is nonconformant (it doesn't use a qualified domain
name, "burner" isn't appropriate), please fix your mailer.
--
Matthias Andree
"D. Hazelton" <[email protected]> wrote:
> > > Does that glue code comprise the proposed SATL system? Recently I've come
> > > across those whitepapers and opened a discussion about it on LKML.
> >
> > ??? Solaris supports SAS decives, is this your question?
>
> SAS? No. To quote you quite frequently - RTFM. SATL is an entire system,
Please read again your text I was responding to..... It was Solaris related
and you did not mention Linux here.
> similar to the old ide-scsi module, that sits on top of the SCSI and ATA
> interfaces and provides the capacity to access any disk device on the system
> using SCSI commands.
If this is a ide-scsi replacement, everything would be fine.
When is it available?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-22:
> "D. Hazelton" <[email protected]> wrote:
> > similar to the old ide-scsi module, that sits on top of the SCSI and ATA
> > interfaces and provides the capacity to access any disk device on the system
> > using SCSI commands.
>
> If this is a ide-scsi replacement, everything would be fine.
That doesn't matter: your policy is to support older kernels, and by the
time it will become available there will still be 2.6.13, .14, .15
kernels around that don't have SAT, so you will need to have code that
works well with 2.6.15 anyhow if you are to comply with your own
intentions.
--
Matthias Andree
"D. Hazelton" <[email protected]> wrote:
> On Tuesday 21 February 2006 04:55, Joerg Schilling wrote:
> > "D. Hazelton" <[email protected]> wrote:
> > > Don't even start. In a private exchange you stated that you had been
> > > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove
> > > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg
> > > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux
> > > systems.
> > >
> > > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0
> > > - and you said it was wrong and not useful. I've since asked you in
> > > another private mail if you have another solution I could code into the
> > > patch and don't expect a reply until tomorrow.
> >
> > And I explained you why this is inapropriate. So what is your peoblem?
>
> And I asked if _you_ had a solution that I could then implement. Apparently
And I did tell you what I was thinking off, so where is your problem?
Don't you remember anymore that I did reply on 30th January to a mail
from Albert Cahalan that the dirty cheap mapping is not useful?
> you are no intelligent enough, or have your head too far up your ass, to
> understand a simple question. Goodbye, Joerg - you are now in my killfile.
So even you are just one of these trolls that are unable to have a tachical
based discussion and at some time start with personal infrimngements?
Tell me why I did spend so much time replying to your mail if you are not able
to to what you did promise before?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
> ??? smake _is_ a real world make program and if you rate POSIX compliance
> and portability, it will outstrip all other known make programs.
does anybody (except for the author, of course) use
smake for building their stuff? just curious ..
best,
Herbert
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-22:
>
> > > - run Solaris' /usr/{ccs,xpg4}/bin/make
> > > to find out if your Makefile is portable
> >
> > Solaris make does not write useful error messages in case of non-portable
> > makefiles.
>
> Sun Microsystems do not advertise their make tool as Makefile
> portability validator. Note the difference: each tool is held to its
> own standards.
I do not advertize smake as makefile validator either.
It would help a lot, if people on LKML would not repeatedly impute me things I
never said....
Smake helps to find non-portable code, this is something completely different!
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, 23 Feb 2006, Herbert Poetzl wrote:
> On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
>> ??? smake _is_ a real world make program and if you rate POSIX compliance
>> and portability, it will outstrip all other known make programs.
>
> does anybody (except for the author, of course) use
> smake for building their stuff? just curious ..
>
> best,
> Herbert
The author wrote it so he is likely to use it. It claims to
have compatible make-files so the source-code tree should
be just fine.
I don't know who would waste their time making another 'make'
program, but I guess the author of smake has lots of time
on his hands!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Joerg Schilling schrieb am 2006-02-23:
> I do not advertize smake as makefile validator either.
In your message from Monday 10:44 Central European Time you advertise
smake as warning about most non-portable constructs...
--
Matthias Andree
On Thursday 23 February 2006 07:15, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
> > Joerg Schilling schrieb am 2006-02-22:
> > > > - run Solaris' /usr/{ccs,xpg4}/bin/make
> > > > to find out if your Makefile is portable
> > >
> > > Solaris make does not write useful error messages in case of
> > > non-portable makefiles.
> >
> > Sun Microsystems do not advertise their make tool as Makefile
> > portability validator. Note the difference: each tool is held to its
> > own standards.
>
> I do not advertize smake as makefile validator either.
>
> It would help a lot, if people on LKML would not repeatedly impute me
> things I never said....
>
>
> Smake helps to find non-portable code, this is something completely
> different!
Umm - Joerg, you just stepped on your own toes there. A makefile validator
does exactly that - helps people find non-portable code. You're fighting a
losing battle when you claim one thing then say something that proves it
false.
DRH
Herbert Poetzl <[email protected]> wrote:
> On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
> > ??? smake _is_ a real world make program and if you rate POSIX compliance
> > and portability, it will outstrip all other known make programs.
>
> does anybody (except for the author, of course) use
> smake for building their stuff? just curious ..
Many people use smake on platforms where there is no other
sufficiently compliant make program.
As GNU make incorrectly states to run on many plaforms, there are
a lot of people who suffer from the fact that GNU make is not maintained
since > 6 years.
Note that I did make bug reports against GNU make that have been accepted as
bugs but never fixed!
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 02/23/2006 16:48 +0100, Joerg Schilling wrote:
>> Herbert Poetzl <[email protected]> wrote:
>>
>> > On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
>> > > ??? smake _is_ a real world make program and if you rate POSIX compliance
>> > > and portability, it will outstrip all other known make programs.
>> >
>> > does anybody (except for the author, of course) use
>> > smake for building their stuff? just curious ..
>>
>> Many people use smake on platforms where there is no other
>> sufficiently compliant make program.
>>
>> As GNU make incorrectly states to run on many plaforms, there are
>> a lot of people who suffer from the fact that GNU make is not maintained
>> since > 6 years.
>>
Hmmm... from the GNU Make web page:
Version 3.80 (stable) released on 2002-10-04 00:00:00.000
Seems to me that's slightly less than 6 years, but then I was never
that great at math... Maybe I missed something....
--
[email protected]
"linux-os \(Dick Johnson\)" <[email protected]> wrote:
>
> I don't know who would waste their time making another 'make'
> program, but I guess the author of smake has lots of time
> on his hands!
Who would waste his time with something like GNU make that is unmaintained
since more than 6 years?
If I need a bugfix in smake, I can do this in a few hours.
This is impossible with GNU make....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, Feb 23, 2006 at 05:35:07PM +0100, Joerg Schilling wrote:
> "linux-os \(Dick Johnson\)" <[email protected]> wrote:
>
> >
> > I don't know who would waste their time making another 'make'
> > program, but I guess the author of smake has lots of time
> > on his hands!
>
> Who would waste his time with something like GNU make that is
> unmaintained since more than 6 years?
>
> If I need a bugfix in smake, I can do this in a few hours.
> This is impossible with GNU make....
just tried with GNU make, did work here within minutes :)
best,
Herbert
> J?rg
>
> --
> EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (work) Blog: http://schily.blogspot.com/
> URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-23:
>
> > I do not advertize smake as makefile validator either.
>
> In your message from Monday 10:44 Central European Time you advertise
> smake as warning about most non-portable constructs...
So you read the correct text and still try to reverse it?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> > Smake helps to find non-portable code, this is something completely
> > different!
>
> Umm - Joerg, you just stepped on your own toes there. A makefile validator
> does exactly that - helps people find non-portable code. You're fighting a
> losing battle when you claim one thing then say something that proves it
> false.
Wrong: a CD box with Suse or Redhat Linux may act as a door stop.
Does this make it a doorstop?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Tim Walberg <[email protected]> wrote:
>
> Hmmm... from the GNU Make web page:
>
> Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>
> Seems to me that's slightly less than 6 years, but then I was never
> that great at math... Maybe I missed something....
And why are the accepted bugs from 1999 not yet fixed?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Herbert Poetzl <[email protected]> wrote:
> > Who would waste his time with something like GNU make that is
> > unmaintained since more than 6 years?
> >
> > If I need a bugfix in smake, I can do this in a few hours.
> > This is impossible with GNU make....
>
> just tried with GNU make, did work here within minutes :)
If you can fix things in GNU make within minutes, please fix the
bug that causes GNU make to complain about missing include files.
This is a self non-compliance as GNU make applies all so far known rules
on any other object before trying to use them (e.g. try to check out Makefile
from SCCS before complaining that Makefiles is missing).
If you need the correct algorithm, look into the smake source...
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-23:
> So you read the correct text and still try to reverse it?
No. You advertised smake in spite of my recommendation to test Makefiles
with real-world make implementations, and now you're ranting about a
particular make implementation.
1. Stick to the topic please.
2. Stop Cc:ing me on this topic, I'm not interested in discussing make
programs beyond showing that smake isn't up to its own standards, and
that I already did.
--
Matthias Andree
On 02/23/2006 17:57 +0100, Joerg Schilling wrote:
>> Tim Walberg <[email protected]> wrote:
>>
>> >
>> > Hmmm... from the GNU Make web page:
>> >
>> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>> >
>> > Seems to me that's slightly less than 6 years, but then I was never
>> > that great at math... Maybe I missed something....
>>
>> And why are the accepted bugs from 1999 not yet fixed?
>>
'accepted "bugs" not being fixed' is not equivalent to 'package is
not being maintained'... at least not in my admittedly meager grasp
of logic...
--
[email protected]
Tim Walberg <[email protected]> wrote:
> >> > Hmmm... from the GNU Make web page:
> >> >
> >> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000
> >> >
> >> > Seems to me that's slightly less than 6 years, but then I was never
> >> > that great at math... Maybe I missed something....
> >>
> >> And why are the accepted bugs from 1999 not yet fixed?
> >>
>
> 'accepted "bugs" not being fixed' is not equivalent to 'package is
> not being maintained'... at least not in my admittedly meager grasp
> of logic...
They told me that fixing would take "a while". If you believe that
"a while" is 20 years, then you seem to live in a different universe then I do.
A
On 02/23/2006 18:32 +0100, Joerg Schilling wrote:
>> Tim Walberg <[email protected]> wrote:
>>
>> > >> > Hmmm... from the GNU Make web page:
>> > >> >
>> > >> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>> > >> >
>> > >> > Seems to me that's slightly less than 6 years, but then I was never
>> > >> > that great at math... Maybe I missed something....
>> > >>
>> > >> And why are the accepted bugs from 1999 not yet fixed?
>> > >>
>> >
>> > 'accepted "bugs" not being fixed' is not equivalent to 'package is
>> > not being maintained'... at least not in my admittedly meager grasp
>> > of logic...
>>
>> They told me that fixing would take "a while". If you believe that
>> "a while" is 20 years, then you seem to live in a different universe then I do.
>>
Indeed... I had already concluded that. It now seems that in
your universe, the time span between 1999 and 2006 is on
the order of 20 years, which seems to be a factor of nearly
3 over what it is in my universe (either that, or it's not
2006 where you are, but rather 2019...).
--
[email protected]
On Thursday 23 February 2006 11:56, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > > Smake helps to find non-portable code, this is something completely
> > > different!
> >
> > Umm - Joerg, you just stepped on your own toes there. A makefile
> > validator does exactly that - helps people find non-portable code. You're
> > fighting a losing battle when you claim one thing then say something that
> > proves it false.
>
> Wrong: a CD box with Suse or Redhat Linux may act as a door stop.
>
> Does this make it a doorstop?
If you decide to use it as such, yes. I have actually done such in the past,
since I needed to find some use for the box once the media was removed.
And anyway, you did state, as pointed out by someone else, that "smake may be
used as a Makefile validator" Since you advertise such a fact - that it works
as a Makefile validator - does that not make it such?
I realize you'll just deny it and don't know why I bother even looking in the
folder your mails get sorted into. Maybe I just have a masochistic streak...
DRH
>>> They told me that fixing would take "a while". If you believe that
>>> "a while" is 20 years, then you seem to live in a different universe then I do.
>
>Indeed... I had already concluded that. It now seems that in
>your universe, the time span between 1999 and 2006 is on
>the order of 20 years, which seems to be a factor of nearly
>3 over what it is in my universe (either that, or it's not
>2006 where you are, but rather 2019...).
>
<sarcasm>That explains why Solaris is so much better.</sarcasm>
But when Linux gets to 2019, it will rule compared to the current
Solaris 2019.
Jan Engelhardt
--
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-23:
>
> > So you read the correct text and still try to reverse it?
>
> No. You advertised smake in spite of my recommendation to test Makefiles
> with real-world make implementations, and now you're ranting about a
> particular make implementation.
So you still read the correct text and try to reverse it?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Tim Walberg <[email protected]> wrote:
> >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is
> >> > not being maintained'... at least not in my admittedly meager grasp
> >> > of logic...
> >>
> >> They told me that fixing would take "a while". If you believe that
> >> "a while" is 20 years, then you seem to live in a different universe then I do.
> >>
>
> Indeed... I had already concluded that. It now seems that in
> your universe, the time span between 1999 and 2006 is on
> the order of 20 years, which seems to be a factor of nearly
> 3 over what it is in my universe (either that, or it's not
> 2006 where you are, but rather 2019...).
I don't know in which universe you live, but in my universe software that does
not fix severe bugs after 7 years or does not publish a new version at least every
2-3 years is called deas and unmaintained. Both applies to GNU make.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote:
> Tim Walberg <[email protected]> wrote:
>
> > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is
> > >> > not being maintained'... at least not in my admittedly meager grasp
> > >> > of logic...
> > >>
> > >> They told me that fixing would take "a while". If you believe that
> > >> "a while" is 20 years, then you seem to live in a different universe then I do.
> > >>
> >
> > Indeed... I had already concluded that. It now seems that in
> > your universe, the time span between 1999 and 2006 is on
> > the order of 20 years, which seems to be a factor of nearly
> > 3 over what it is in my universe (either that, or it's not
> > 2006 where you are, but rather 2019...).
>
> I don't know in which universe you live, but in my universe software
> that does not fix severe bugs after 7 years or does not publish a new
> version at least every 2-3 years is called deas and unmaintained. Both
> applies to GNU make.
Uhm, the version of GNU make in Debian (3.81beta4) was released
12 December 2005; I wouldn't call that dead (or unmaintained).
Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
On Sat, Feb 25, 2006 at 06:44:10PM +0100, David Weinehall wrote:
> On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote:
> > Tim Walberg <[email protected]> wrote:
> >
> > > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is
> > > >> > not being maintained'... at least not in my admittedly meager grasp
> > > >> > of logic...
> > > >>
> > > >> They told me that fixing would take "a while". If you believe that
> > > >> "a while" is 20 years, then you seem to live in a different universe then I do.
> > > >>
> > >
> > > Indeed... I had already concluded that. It now seems that in
> > > your universe, the time span between 1999 and 2006 is on
> > > the order of 20 years, which seems to be a factor of nearly
> > > 3 over what it is in my universe (either that, or it's not
> > > 2006 where you are, but rather 2019...).
> >
> > I don't know in which universe you live, but in my universe software
> > that does not fix severe bugs after 7 years or does not publish a new
> > version at least every 2-3 years is called deas and unmaintained. Both
> > applies to GNU make.
>
> Uhm, the version of GNU make in Debian (3.81beta4) was released
> 12 December 2005; I wouldn't call that dead (or unmaintained).
Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
Yeah, very unmaintained and dead upstream...
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
David Weinehall <[email protected]> wrote:
> > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > 12 December 2005; I wouldn't call that dead (or unmaintained).
>
> Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>
> Yeah, very unmaintained and dead upstream...
None of the bugs I did report has been fixed.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
>>>Uhm, the version of GNU make in Debian (3.81beta4) was released
>>>12 December 2005; I wouldn't call that dead (or unmaintained).
>>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>>Yeah, very unmaintained and dead upstream...
> None of the bugs I did report has been fixed.
Just because a project doesn't fix every bug does not mean it is dead.
That aside, are your bugs listed on
http://savannah.gnu.org/bugs/?group=make
?
Sam.
On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote:
> David Weinehall <[email protected]> wrote:
>
> > > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > > 12 December 2005; I wouldn't call that dead (or unmaintained).
> >
> > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
> >
> > Yeah, very unmaintained and dead upstream...
>
> None of the bugs I did report has been fixed.
Well, the bug you complain most about is about spewing of some
warnings for something completely harmless. I know of another
certain set of software that spews unnecessary and annoying
warnings. Those haven't been removed for despite complaints for
several years either. Does this mean that cdrecord is an unmaintained
piece of software that's dead upstream?
Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
David Weinehall wrote:
>>>>12 December 2005; I wouldn't call that dead (or unmaintained).
>>>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>>>Yeah, very unmaintained and dead upstream...
>>None of the bugs I did report has been fixed.
> Well, the bug you complain most about is about spewing of some
> warnings for something completely harmless. I know of another
> certain set of software that spews unnecessary and annoying
> warnings. Those haven't been removed for despite complaints for
> several years either. Does this mean that cdrecord is an unmaintained
> piece of software that's dead upstream?
This "cdrecord" package doesn't even support recording DVDs! DVD
writers have been around for so long, and the technology is so similar
you would think that the author would implement the feature. The users
sure must be asking for it.
However it still seems to be being updated but not co-operating with the
community or releasing new important features ... looks like we've got a
piece of software that's UNdead upstream.
Sam.
David Weinehall <[email protected]> wrote:
> On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote:
> > David Weinehall <[email protected]> wrote:
> >
> > > > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > > > 12 December 2005; I wouldn't call that dead (or unmaintained).
> > >
> > > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
> > >
> > > Yeah, very unmaintained and dead upstream...
> >
> > None of the bugs I did report has been fixed.
>
> Well, the bug you complain most about is about spewing of some
> warnings for something completely harmless. I know of another
> certain set of software that spews unnecessary and annoying
> warnings. Those haven't been removed for despite complaints for
> several years either. Does this mean that cdrecord is an unmaintained
> piece of software that's dead upstream?
If you do not understand the diffeence between a useful warning (as with
cdrecord) and a warning that is a result of a severe bug caused by incorrect
make file handling (as in GNU make) you are obviously wrong here.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-03-01:
> If you do not understand the diffeence between a useful warning (as with
> cdrecord) and a warning that is a result of a severe bug caused by incorrect
> make file handling (as in GNU make) you are obviously wrong here.
Continued offenses, rather than substantiating your claims.
This cosmetic GNU make bug that you've been ranting about for years,
which isn't a warning, has not, to my knowledge, caused any code to be
miscompiled. If you think otherwise, then you'll need to provide the GNU
make maintainers with such information so they are aware of the
severity.
However, until you can substantiate your claims, it's just Schilling's
usually offensive ranting and not a make "bug". Besides that, you can
just use "-include" to suppress the message. It even works in smake and
BSD make ...
--
Matthias Andree