Re: CD writing in future Linux (stirring up a hornets' nest)



"D. Hazelton" <dhazelton@xxxxxxxxx> 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:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: CD writing in future Linux (stirring up a hornets nest)
    ... careful review of libscg in preparation for the patch I promised you, ... by Albert Cahalan, Linux does provide b,t,l addresses for ATA/ATAPI devices - ... do not understand implicit constraints from requiring orthogobality. ... the way to access SCSI generic via /dev/hd* is deprecated. ...
    (Linux-Kernel)
  • Re: CD writing in future Linux (stirring up a hornets nest)
    ... tries to _plan_ all interfaces in a way that allows to upgrade interfaces ... So my conclusion is that you did not understand portability. ... order to avoid the problems introduced by Linux. ... Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 ...
    (Linux-Kernel)
  • [PATCH] mmu notifiers #v2
    ... In short when the linux VM decides to free a page, ... This patch allows the shadow pagetables to be dropped and the page to ... behavior of the KVM gphysical memory. ...
    (Linux-Kernel)
  • Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
    ... Con Kolivas wrote: ... surprising Ingo made it a separate patch set as Con has repeatedly ... gzip simply doesn't play well with others... ... than the scheduler in linux, and that's how much writes hurt just about ...
    (Linux-Kernel)
  • Re: CD writing in future Linux (stirring up a hornets nest)
    ... that tries to _plan_ all interfaces in a way that allows to upgrade ... So my conclusion is that you did not understand portability. ... Well what I did first was to try to have a discussion with the Linux people ... ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI ...
    (Linux-Kernel)