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

[Matthias Andree <matthias.andree@gmx.de>]

Kyle Moffett wrote:
> On Jan 25, 2006, at 11:31, Joerg Schilling wrote:
>> Albert Cahalan <acahalan@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/