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

On Friday 17 February 2006 06:41, you wrote:
"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.

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
-
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

  • [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)
    ... review in preparation for the proposed patch). ... do not understand implicit constraints from requiring orthogobality. ... way is removed from Linux. ... Linux to be used to _develop_ SCSI user space programs. ...
    (Linux-Kernel)
  • RE: *at family of syscalls in FreeBSD
    ... this is certainly a nice API to have even aside from the linux compatibility ... the actuall implementaiton. ... My patch has been ... can someone from Isilon comment their version so we can compare benefits etc.? ...
    (freebsd-arch)
  • 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)