Re: OT] Joerg Schilling flames Linux on his Blog

From: Kyle Moffett
Date: Wed May 25 2005 - 18:33:27 EST

On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
"Bodo Eggert <harvested.in.lkml@xxxxxxxxxxxxxxxxxxxxxxxxxx>" <7eggert@xxxxxx> wrote:
I just burned a CD on my IDE-burner using mmc_cdr with cdrtools-2.01
(the one without the hack) on a vanilla 2.6.11.10. I can even scan
both my SCSI and IDE devices using -dev=ATAPI, but not without -dev.

The unability to give this kind of convenience to cdrecord users is a result
of the refusal of the Linux kernel crew to include the kernel internal
device instance numbers in the ioctl structures I need to read.

There is a specific reason that the numbers are _kernel_internal_!!! I set up
my udev so that my green CD burner is /dev/green_burner, and my blue CD burner
is /dev/blue_burner. Please tell me again why exactly I can't just give the
option -dev=/dev/green_burner and have it use my green CD burner? That's a lot
easier than messing with random groups of 3 numbers and trying to remember in
which order I plugged in my burners, and which kernel I'm running, so I can
remember the enumeration order, etc.

Note that the fields are there but the information is intentionally obscured
for come of the calls just to make the life of cdrecord useers harder :-(

The information is obscured because userspace shouldn't know or care

(I'm running as user, and cdrecord has no need for suid bits.)

I am frequently reading false claims like this. Usually from people who
do not have the needed SCSI background knowledge to understand that
SCSI is a protocol where commands frequently fail by intention in order to
propagate a state or a implementation level to the application.

What exactly is false about the claim?

If you don't call cdrecord as root, you will not be able to lock in memory
and to raise priority in order to prevent buffer underuns.

I burn CDs fine all the time as a user, and I _don't_ need to lock memory or
raise priority, because I have a good scheduler, plenty of RAM, and dual CPUs.
It would be nice if you could let me leave on the _hardware_ BurnProof
technology designed to prevent that sort of thing, but it doesn't appear to
fit with your ideals of 100% perfect CDs, does it? Besides, by the time we
hit the point where BurnProof would turn on, the disk is either completely
dead and useless (no burnproof), or slightly scarred and still useable (with
burnproof). Personally, I'd rather have the latter.

In addition (with Linux-2.6.8.1 or newer) you will not be able to send some
of the important SCSI commands mainly related to newer CD or DVD drives. As
a result, cdrecord cannot write DVDs

I was not under the impression that the free cdrecord could write DVDs.

or ultra speed CD-RWs or cannot do other things....

Did you try submitting a list of important SCSI commands and their functions?
I suspect that if you provide a clear, concise list of harmless commands,
they would be included in the available command set.

Not true: if only R/W fd would be allowed, no non root program could do that.

Uhh, but I don't run cdrecord as root. My /dev/green_burner device is owned
by root, has group "media", and perms rw-rw-r--. Since this is a somewhat public
machine with lots of users in the "media" group, I don't want anybody to be able
to turn my drives into bricks.

See above, this false claim is a result of the fact that you miss the background
knowledge on CD/DVD writing. Turning burnproof on degrades the quality of the
media and writing without burnproof but with the apropriate privilleges just
works fine.

Why can't you just provide an option to leave it on? My Mac and Windows
computers seem to do just fine with it. In fact, all modern CD-ROM drives
were designed to be able to read such "degraded" media, even "degraded"
media that also has scratches and dents and dings and scars and all sorts
of other glitches in the CD surface.

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