"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. 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 :-(
> (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.
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. 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 or ultra speed CD-RWs or cannot do other things....
> > If Linux plans to implement incompatible changes, I would expect that
> > "important users" are informed in advance so that it is possible to discuss
> > the problems an to have a planned smooth migration.
>
> While, in the meantime, users can destroy the hardware.
Not true: if only R/W fd would be allowed, no non root program could do that.
>
> <OT>
>
> BTW while talking about destroying hardware: Turning off burnproof so the
> drives that have this feature _for a reason_ will destroy my CD-Rs like
> a outdated CD-recorder would is doubleplusungood, even if it creates
> consistent behaviour across drives. It's like waring no seat belt in
> your car just because curricles didn't have them. ??
>
> </OT>
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.
> There are other uses for write access to devices. Disabeling SCSI commands
> for r/o fds would only be a quickfix. (IMHO it could have been introduced
> as a config option and gone away in 2.6.13.)
The good/bad SCSI commands table that is currently used is a really bad and
ugly (incorrect) hack and much worse than my proposal.
> > P.S.: About 10 days ago, I made an attempt to include a workaround for the
> > interface changes in Linux, check cdrtools-2.01.01a03
>
> The fix is wrong: You're asuming root is capable of everything. This
> doesn't need to be true (missing CAP_SYS_RAWIO) and you'll run into a
> loop in that case.
If you are really true, then there is a design problem in Linux.
BTW: If Linux starts introducing fine grained rights manamement like on Solaris, why
does it miss the apropriate management tools at user level?
On Solaris, I could run cdrecord rootless if I use pfksh as my shell and if
the roles database would include cdrecord with its needed privilleges and me
as a member of the cdwriters role.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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?
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.
On Thursday 26 May 2005 05:31, Kyle Moffett wrote:
> 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.
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?
--
Alexander E. Patrakov
P.S. I know that the proper solution would be to replace the drive. I tried
returning it to the shop, they said "no, it is in order because it works with
Nero in Windows" and fined me for $25 for their "expertize".
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.
On May 26, 2005, at 15:20:32, Bill Davidsen wrote:
>> 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?
Well, yes, and I do all the time, but the dammed deprecation warning
is just plain
stupid. That's not the deprecated method, that's the reasonable method.
> 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.
I don't use the three-number made-up SCSI-over-USB IDs that Joerg was
complaining
about being unavailable. I have mine set up based on the UUID of the
burner. I'm
sorry for being unclear, but my objection is to his desire to expose
the SCSI IDs
to userspace as the primary naming scheme, when said SCSI IDs are
frequently just
made up by the kernel for USB devices, etc.
>>>> (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.
Agreed. My personal gripe is that it screams at me even when I'm
just doing a
quickie burn of a 60MB debian netinst CD for a one-use-only thing.
> There is an option if you would read the manpage. There are
> legitimate complaints, this doesn't seem to be one of them.
Ah, crap. I just realized that some accidental disk corruption took
a chunk out of
the middle of my copy of the manpage. A reinstall of the package
seems to have
fixed the problem. Sorry about the noise.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$
r !y?(-)
------END GEEK CODE BLOCK------
On Thu, 26 May 2005, Kyle Moffett wrote:
> I don't use the three-number made-up SCSI-over-USB IDs that Joerg was
> complaining about being unavailable. I have mine set up based on the
> UUID of the burner. I'm sorry for being unclear, but my objection is
> to his desire to expose the SCSI IDs to userspace as the primary
> naming scheme, when said SCSI IDs are frequently just made up by the
> kernel for USB devices, etc.
Given that I know the SCSI IDs of every single device I install, am not
using SCAM, I don't object to using SCSI IDs, unfortunately, SCSI CD or
DVD writers are rare and costly - I'd prefer them over ATAPI every day
since I take one PCI device to connect like half a dozen narrow SCSI
devices. ATAPI is so wasteful. And I have bought SCSI for as long as
somewhat up-to-date devices were available.
Things get interesting though with ATAPI, ATAPICAM, ide-scsi, ide-cd and
all sorts of interfaces since probing various busses is something that
requires user intervention or trial & error to list _all_ devices in
different buses, and drives have unlogical bus numbers (seen these on
FreeBSD), or more generally, when cdrecord tries to coerce a device
numbering scheme on devices that are not enumerated, or devices that are
hotplug with device numbers changing with every plug-in action, or
whatever.
--
Matthias Andree
Kyle Moffett <[email protected]> wrote:
> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
> > 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_!!!
So if you really believe this, you should immediately remove all
stuff under /proc.
> 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?
Try to start with reading the cdrecord manual page. Your question
is answered in there.....but if you issue a command that is only
halfway correct you will never be able to get the full set of features from
cdrtools. Using UNIX device names for SCSI devices is highly nonportable
and for this reason not supported by a portable program like cdrecord.
Cdrecord includes the needed features to do what you like, but do not
asume that you will be able to force me to make nonportable and Linux
specific interfaces a gauge for the design of a portable program.
If you read the cdrecord man page, you know that you could
happily call cdrecord dev=green_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.
Aha, so you would prefer /dev/ftp.kernel.org also?
Before trying to make inadequate comparisons and before you request
inadequate similarities, it often helps a lot if you first try to look
around and check whether your claims are really a tautology.
>
> > 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
If you read the LKML archives, it would be easy for you to prove that this
is not true :-(
The numbers are obscured _only_ in order to prevent me to implement a workaround
for the fact that Linux does not implement _one_ unique interface for sending
generic SCSI commands to all devices that talk SCSI.
I aked for a non obscured interface in 2002 (note that the fields _are_ present
inside the ioctl parameter structure) in order to hide this drawback from Linux
users, but I have been told that the Linux developers don't like nice
and _unique_ interfaces for their users.
- The fields are in the ioctl structures for user land
communication.
- The kernel knows the numbers that would allow libscg
to detect duplikate drive appearances when trying to
implement a global umbrella for all different SCSI
interfaces in the Linux kernel
- The kernel hides the fact only to make it impossible for
cdrecord to implement a better user interface.
> > 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.
Do you really believe this? It would help a lot if you did a reality check.
> 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
Again, try do do some reallity check.... Cdrecord by default uses the
setup that grant best media quality. I asume you are able to read, so
just read the man page and set up your defaults the way you like them.
> burnproof). Personally, I'd rather have the latter.
So why do you refuse to read the manual and to setup the parameters
you like?
> 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.
Having such a list in inherently wrong. It never could be made correct.
There are a lot of different drives with a lot of overlapping commands
in the vendor unique part of the name space. Cdrecord needs the
vendor unique commands for old writers in order to be able to write at
all, and cdrecord needs the vendor unique commands in order to implement
the nice features people like for their convenience.
Nut even in the non vendor unique part the list in Linux is incomplete.
****
And please note: Cdrecord uses some of the commands that are used for
firmware upgrade in order to do DMA speed metering........ This is
definitely _not_ a security issue with cdrecord.
In special on Linux, users frequelty did complain about insufficient
DMA speed before I did add this feature. Not cdrecord refuses to write
faster than possible after metering the transfer speed from/to the drive.
****
In case you don't understand this correectly, let me explain:
A security problem may only be correctly dealt with by having a
coherent and consistent security strategy. The SCSI op code table
is not part of a security strategy but just a bad hack.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable
> and for this reason not supported by a portable program like cdrecord.
>
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....
Portable programs have specifics to each OS that it can be compiled on. Why
do you think some portatble programs use automake? Not ever OS defines
variables the same way or uses them the same way as others.
You are going to have to realize that accessing devices directly under
different OSes will require different code. I've read all the stuff you've
posted and it is apparent that you want all OSes to use the scsi scheme.
I don't use cdrecord much anymore since 1) I have a DVDRW and 2) I burn
DVDs mostly. It happily uses /dev/<whatever> instead of compilaining that
it's unintentional.
As far as I can see, you can use scsi ioctls on regular devices so why do
you really need to use the 3 numbers? To find the right /dev/sg and use it?
Doesn't make sense. I looked at the eject program one day. The IOCTL used
to eject a cdrom is different than solaris. Gee, I guess eject is not
portable. You should probably write a library that deals specifically with
each OS. I don't ever see something like this being portable. Especially
between a Unix environment and a Windows environment.
P.S. This is the first and will be the last time I post on this thread. I'm
not trying to flame anyone, this is mostly an enduser observation. The
native OS device usage should be used instead of something supposedly
portable.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On 5/27/05, Joerg Schilling <[email protected]> wrote:
> Kyle Moffett <[email protected]> wrote:
> > 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?
>
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable
> and for this reason not supported by a portable program like cdrecord.
>
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....
>
No, that static mapping is not good. I have an external enclosure that
does firewire and USB. I want to be able to use "sony-dvd" to access
it no matter whether it is onnected to USB bus or Firewire and whether
there are other devices (disks) on USB or firewire. It is possible to
do with udev creating a link to /dev/sony-dvd.
--
Dmitry
Dmitry Torokhov <[email protected]> wrote:
> > Cdrecord includes the needed features to do what you like, but do not
> > asume that you will be able to force me to make nonportable and Linux
> > specific interfaces a gauge for the design of a portable program.
> > If you read the cdrecord man page, you know that you could
> > happily call cdrecord dev=green_burner.....
> >
>
> No, that static mapping is not good. I have an external enclosure that
> does firewire and USB. I want to be able to use "sony-dvd" to access
> it no matter whether it is onnected to USB bus or Firewire and whether
> there are other devices (disks) on USB or firewire. It is possible to
> do with udev creating a link to /dev/sony-dvd.
I am not sure what you like to do.....
But what you claim is simply impossible.
As you started to introduce the allegory with the colors, let me make
an assumption based on your claim:
- Buy two identical drives and varnish one in red and the other
in green.
- Connect both drives to your computer to let the OS "learn" the
drives.
- Do any setup you like
- Now disconnect the drives and after that, connect the green one
the way the red one has been connected before.
- Connect the red one too.
- Insert a medium into the green drive
- Let your software try whether it is able to connect you
to the green one.
If this always works as expected, then you are a magician!
So let me sum up: Never rely on things that cannot be made 100%
unique in case you like to run security relevent software like cdrecord.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling <[email protected]> writes:
> Dmitry Torokhov <[email protected]> wrote:
>
>> > Cdrecord includes the needed features to do what you like, but do
>> > not asume that you will be able to force me to make nonportable and
>> > Linux specific interfaces a gauge for the design of a portable
>> > program. If you read the cdrecord man page, you know that you
>> > could happily call cdrecord dev=green_burner.....
>> >
>>
>> No, that static mapping is not good. I have an external enclosure
>> that does firewire and USB. I want to be able to use "sony-dvd" to
>> access it no matter whether it is onnected to USB bus or Firewire and
>> whether there are other devices (disks) on USB or firewire. It is
>> possible to do with udev creating a link to /dev/sony-dvd.
>
> I am not sure what you like to do.....
He wants to be able to access his dvd recorder via dev=/sony-dvd. And it
should not matter how it is connected (USB/firewire).
> But what you claim is simply impossible.
No it is not.
> As you started to introduce the allegory with the colors, let me make
> an assumption based on your claim:
>
> - Buy two identical drives and varnish one in red and the other
> in green.
That is indeed impossible, but as soon as there are two different
drives, it is possible with udev and not possible with a static
assignment.
regards
Markus
On Monday 30 May 2005 04:07, Joerg Schilling wrote:
> Dmitry Torokhov <[email protected]> wrote:
>
> > > Cdrecord includes the needed features to do what you like, but do not
> > > asume that you will be able to force me to make nonportable and Linux
> > > specific interfaces a gauge for the design of a portable program.
> > > If you read the cdrecord man page, you know that you could
> > > happily call cdrecord dev=green_burner.....
> > >
> >
> > No, that static mapping is not good. I have an external enclosure that
> > does firewire and USB. I want to be able to use "sony-dvd" to access
> > it no matter whether it is onnected to USB bus or Firewire and whether
> > there are other devices (disks) on USB or firewire. It is possible to
> > do with udev creating a link to /dev/sony-dvd.
>
> I am not sure what you like to do.....
>
> But what you claim is simply impossible.
>
> As you started to introduce the allegory with the colors, let me make
> an assumption based on your claim:
>
> - Buy two identical drives and varnish one in red and the other
> in green.
>
> - Connect both drives to your computer to let the OS "learn" the
> drives.
>
> - Do any setup you like
>
> - Now disconnect the drives and after that, connect the green one
> the way the red one has been connected before.
>
> - Connect the red one too.
>
> - Insert a medium into the green drive
>
> - Let your software try whether it is able to connect you
> to the green one.
>
> If this always works as expected, then you are a magician!
>
It will not work if drives are absolutely identical, however if there is
something even slightly different about them (serial number, model,
firmware version - anything) you can set up udev to produce "stable" name.
FWIW, my example was about a single drive that can "change" it's X,Y,Z
depending on how and when it was connected.
> So let me sum up: Never rely on things that cannot be made 100%
> unique in case you like to run security relevent software like cdrecord.
Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
Because for the most types of devices out there they don't make any sense
and just provided for compatibility with legacy software.
Also, from a bit different perspective - do you also want users to mount
the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
If not why writing application should use different addressing?
--
Dmitry
This thead has become ultimately boring, Joerg's views are
irreconcilably anti linux and pro Solaris,
there are, fortunately, alternatives to cdrrecord that work,
especially for DVD,
let us just thank Joerg for his work and move on quietly!
--
mit freundlichen Gr??en, Brian.
Dmitry Torokhov <[email protected]> wrote:
> > So let me sum up: Never rely on things that cannot be made 100%
> > unique in case you like to run security relevent software like cdrecord.
>
> Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
> Because for the most types of devices out there they don't make any sense
> and just provided for compatibility with legacy software.
Well, this is the way most OS on the planet deal with SCSI.
And please explain me why the Linux kernel internally uses these numbers
for driver instancing? Is the Linux kernel a piece of legacy software?
> Also, from a bit different perspective - do you also want users to mount
> the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
> If not why writing application should use different addressing?
Using SCSI addresses is just the way that works more universally for
sending SCSI commands. There are several OS that don't support /dev/ names
and all other UNIX like OS do not artificial hide the SCSI addresses
from userland programs.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Brian O'Mahoney" <[email protected]> wrote:
> This thead has become ultimately boring, Joerg's views are
> irreconcilably anti linux and pro Solaris,
If you are anti Linux, just try to stay quiet......
This is the first time that I experienced a non insulting
discussion at LKML.....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily