Kyle Moffett wrote:
On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
"Bodo Eggert <[email protected]>"
<[email protected]> 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?
You do realize that you can?
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
So having you see the information to set up your udev is a good use and
having Joerg use them is bad? If you want to have names mapped into
"humanspace" why is program use bad? I agree numbers are ugly and
confusing, but if I wanted someone to make those choices for me I'd run
another o/s.
The "support is accidental" message pisses me off, because it isn't
true. Code was added, I'm betting by design.
(I'm running as user, and cdrecord has no need for suid bits.)
Which is fine if you have a system to dedicate to burning CDs. But on a
loaded system Joerg is right, you get a better burn if you don't have
the burnfree used. Like any other minor defect it may or may not bite
you, a lot of them will measurably reduce your CD capacity, which
actually will bite you if you are trying to use every last byte.
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.
See above. It hasn't bitten you, therefore it doesn't bite... it's
generally safe on a fast unloaded system.
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.
Possibly true, didn't work for me.
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.
No argument with that.
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.
There is an option if you would read the manpage. There are legitimate
complaints, this doesn't seem to be one of them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
