Re: [OT] Joerg Schilling flames Linux on his Blog

From: Giuseppe Bilotta
Date: Thu May 26 2005 - 00:08:55 EST


On Thu, 26 May 2005 09:45:01 +0600, Alexander E. Patrakov wrote:

> That list would be device-dependent. See two examples below.
>
> 1) cdrecord uses some Sony proprietary commands instead of standard MMC ones
> if the drive seems to be made by Sony. What is the effect of those Sony
> commands on non-Sony drives?
>
> 2) I have the following DVD-ROM + CD-RW combo drive:
>
> 'PHILIPS ' 'CDD5301 ' 'P1.2'
>
> Originally, I bought it with the 'B1.1' firmware revision. This drive with old
> firmware is a security hole by itself: if one calls cdrecord dev=/dev/hdd
> -dao some-image.iso, the drive will enter some strange mode at the end. In
> particular, it will flash its light randomly, will never give the CD back
> (waited 15 minutes), and will prevent communication with /dev/hdc until I
> power off the computer (pressing Reset is not enough). Burning CDs with -raw
> switch instead of -dao works. With newer firmware, -dao doesn't lock up the
> drive, but still results in damaged CDs.
>
> Also this drive always silently produces CDs with a lot of wrong bits (but a
> useless and broken image can still be read with dd or readcd) when BurnFree
> is off.
>
> So this filter, if it is in the kernel, should forbid commands specific to SAO
> burning for this drive _and_ also return a modified list of capabilities for
> this drive (i.e. say that this drive _cannot_ burn in SAO mode).
>
> Isn't this too much knowledge for the kernel?

Isn't this exactly the knowledge the kernel, not the apps, should
have? What if I wanted to use a different CD burning program? Why
should we have duplicate knowledge about the hardware?

Do you picture every PCI-accessing userland program to have its own
copy of pciids & relative knowledge?

--
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown

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