Re: CD writing in future Linux (stirring up a hornets' nest)
From: Matthias Andree
Date: Wed Jan 25 2006 - 12:06:27 EST
Kyle Moffett wrote:
> On Jan 25, 2006, at 11:31, Joerg Schilling wrote:
>> Albert Cahalan <acahalan@xxxxxxxxx> wrote:
>>> We Linux users will forever patch your software to work the
>>
>> Looks like you are not a native English speaker. "We" is incorrect
>> here, as you only speak for yourself.
>
> I agree completely with his statements, therefore he speaks for at
> least two people and "we" is proper usage. I suspect given the posts
> on this list the last time this flamewar came up that there are more as
> well, but 2 is enough.
>
>> libscg includes...
>
> Irrelevant to the discussion at hand, we are talking only about linux
> and what should be done on linux.
Well, cdrecord relies on libscg, so in effect most of the portability code
that is affected is in libscg; some of the real-time code however is
specific to cdrecord.
>> - Only 5 of them allow a /dev/hd* device name related access.
>
> No, you have this wrong:
>
> - One of them (IE: Linux) requires a /dev/[hs]d* device-name related
> access
/dev/sd* for CD writing? I think you're off track here. AFAICS cdrecord uses
/dev/sg* to access the writer.
> - Only 4 others allow /dev/hd*
>
> However, the later is _completely_ _irrelevant_ to the discussion, as
> we are talking about Linux *only*.
This, and if the code can then be used on other platforms, then there is
little point in calling the Linux /dev/hd* device "badly designed", unless
there were problems with it that prevented cdrecord (or libscg, for pxupdate
or something like that) from working properly.
So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.
The numbers we get from ide-scsi for ATAPI writers are skewed anyhow, I'm
getting 1,0,0 for a SATA hard disk, 2,0,0 for secondary master
DVD-RAM/±R[W], 3,0,0 for secondary slave CD-RW... I wonder why these could
be desirable, and if they are really as static as they pretend to be. I
doubt that, their numbers depend on the order of driver loading.
-
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/