> But what you claim is simply impossible.
wrong. again.
look up the man page for udev(8), pay particular attention to the part
that can tie devname into device serial number.
take note of the example shown under 'serial'.
> 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.
LOL.
On Mon, May 30, 2005 at 05:19:43PM +0800, Lincoln Dale (ltd) wrote:
> > But what you claim is simply impossible.
>
> wrong. again.
>
> look up the man page for udev(8), pay particular attention to the part
> that can tie devname into device serial number.
> take note of the example shown under 'serial'.
These were my thoughts too.
But I just checked the entries in my sysfs tree for my CDRW drive,
and there is no serial number available...
Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
"Lincoln Dale \(ltd\)" <[email protected]> wrote:
> > But what you claim is simply impossible.
>
> wrong. again.
>
> look up the man page for udev(8), pay particular attention to the part
> that can tie devname into device serial number.
> take note of the example shown under 'serial'.
Let me give up here :-(
If you don't understand that the availability of the device serial number is
not a basic SCSI feature, it makes no sense to continue this discussion.
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
Toon van der Pas <[email protected]> wrote:
> > look up the man page for udev(8), pay particular attention to the part
> > that can tie devname into device serial number.
> > take note of the example shown under 'serial'.
>
> These were my thoughts too.
> But I just checked the entries in my sysfs tree for my CDRW drive,
> and there is no serial number available...
BTW: an implementation that uses something like Solaris does with
/etc/path_to_inst and puts USB serial numbers into the path_to_inst
kernel instance database could come very close to the desired result
and would give stable SCSI addresses too.
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 Mon, May 30, 2005 at 11:34:20AM +0200, Toon van der Pas wrote:
> On Mon, May 30, 2005 at 05:19:43PM +0800, Lincoln Dale (ltd) wrote:
> > > But what you claim is simply impossible.
> >
> > wrong. again.
> >
> > look up the man page for udev(8), pay particular attention to the part
> > that can tie devname into device serial number.
> > take note of the example shown under 'serial'.
>
> These were my thoughts too.
> But I just checked the entries in my sysfs tree for my CDRW drive,
> and there is no serial number available...
Wild thouht - you can attach a camera pointing to device and use udev
callout script, which will grab a picture by v4l and check color.
It *is* possible in Linux.
--
Tomasz Torcz RIP is irrevelant. Spoofing is futile.
[email protected] Your routes will be aggreggated. -- Alex Yuriev
On May 30, 2005, at 08:26:43, Joerg Schilling wrote:
> Toon van der Pas <[email protected]> wrote:
>
>
>>> look up the man page for udev(8), pay particular attention to the
>>> part
>>> that can tie devname into device serial number.
>>> take note of the example shown under 'serial'.
>>>
>>
>> These were my thoughts too.
>> But I just checked the entries in my sysfs tree for my CDRW drive,
>> and there is no serial number available...
>>
>
> BTW: an implementation that uses something like Solaris does with
> /etc/path_to_inst and puts USB serial numbers into the path_to_inst
> kernel instance database could come very close to the desired result
> and would give stable SCSI addresses too.
But why fix what isn't broken? I can tell all my other programs, from
dd to mount, that I want to use the udev-created /dev/green_burner, so
why do you indicate such usage is _deprecated_ in cdrecord? For such
device nodes, a _filesystem_ is the preferred name=>number index, so
why add an extra strange file "just because Solaris does".
And why again do you need stable SCSI addresses for my _USB_ drive?
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------
Kyle Moffett <[email protected]> wrote:
> > BTW: an implementation that uses something like Solaris does with
> > /etc/path_to_inst and puts USB serial numbers into the path_to_inst
> > kernel instance database could come very close to the desired result
> > and would give stable SCSI addresses too.
>
> But why fix what isn't broken? I can tell all my other programs, from
> dd to mount, that I want to use the udev-created /dev/green_burner, so
> why do you indicate such usage is _deprecated_ in cdrecord? For such
> device nodes, a _filesystem_ is the preferred name=>number index, so
> why add an extra strange file "just because Solaris does".
If you use /dev/ entries to directly address SCSI targets, then you
are relying on on assumptions that cannot be granted everywhere.
Cdrecord is portable and this needs to implement a way that is portable
and does not rely on nonportable assumptions like yours.
> And why again do you need stable SCSI addresses for my _USB_ drive?
Well if the udev program was polite to users, it would also support
to edit /etc/default/cdrecord......
... if it _really_ does wat you like with /dev/ links, then it has all
the information that is needed to also maintain /etc/default/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
On Tue, 31 May 2005, Joerg Schilling wrote:
> Kyle Moffett <[email protected]> wrote:
>
>>> BTW: an implementation that uses something like Solaris does with
>>> /etc/path_to_inst and puts USB serial numbers into the path_to_inst
>>> kernel instance database could come very close to the desired result
>>> and would give stable SCSI addresses too.
>>
>> But why fix what isn't broken? I can tell all my other programs, from
>> dd to mount, that I want to use the udev-created /dev/green_burner, so
>> why do you indicate such usage is _deprecated_ in cdrecord? For such
>> device nodes, a _filesystem_ is the preferred name=>number index, so
>> why add an extra strange file "just because Solaris does".
>
> If you use /dev/ entries to directly address SCSI targets, then you
> are relying on on assumptions that cannot be granted everywhere.
>
> Cdrecord is portable and this needs to implement a way that is portable
> and does not rely on nonportable assumptions like yours.
>
Portability is relative. It's normally handled with a wrapper.
If your software is to work on a Unix or Unix-like machine, a
claim to "portability" must mean that its interface on a Unix-
like machine is either through a virtual file in '/dev' or
through a socket. This is because these are the 'standards'
that we all have to live with whether we like then or not.
Your `cdrecord -scanbus` hack to find I,J,K numbers that the
rest of your code was written to use, probably took more
time to write than a Unix wrapper which would provide the
correct (for a Unix environment) interface semantics.
Administrators need to set up symbolic links for /dev/burner
or /dev/cdreader, etc., to help cut down nuisance complaints
from users who fail to write CDs on their CD readers. This
is the de-facto Unix way. We need 'devices' in /dev.
BYW I have used your software from its inception and it
always worked well in my SCSI environment. The best working
software in the universe will not receive due credit if
it doesn't meet user (and customer) expectations. If you
are still interested in improving your generous gift to
the Linux community, you should seriously consider writing
wrappers to address portability issues.
>
>> And why again do you need stable SCSI addresses for my _USB_ drive?
>
> Well if the udev program was polite to users, it would also support
> to edit /etc/default/cdrecord......
>
> ... if it _really_ does wat you like with /dev/ links, then it has all
> the information that is needed to also maintain /etc/default/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
> -
> 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/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
#!/bin/bash
######################################################
## CampFire Song v0.1
##
## by Terry Vernon
##
## This is dedicated to those who like to keeping pouring fuel ##
## on that stack of burning tires which is this thread...
##
######################################################
#######decalre variable#######
drool='This stupid thread lives!'
####loop it forever and ever####
while [ "$drool" == 'This stupid thread lives!' ]; do
echo "This is the thread that never ends!"
echo "It goes on and on my friends!"
echo "One day people starting reading it not knowing what it was!"
echo "They kept on replying to it just because..."
echo ""
if [ "$drool" != 'This stupid thread lives!' ]; then
echo "Finally people have stfu about redundant crap!"
fi
#just for anticipation...
sleep 1
done
echo "It just faded off..."
Joerg Schilling wrote:
>Kyle Moffett <[email protected]> wrote:
>
>
>
>>>BTW: an implementation that uses something like Solaris does with
>>>/etc/path_to_inst and puts USB serial numbers into the path_to_inst
>>>kernel instance database could come very close to the desired result
>>>and would give stable SCSI addresses too.
>>>
>>>
>>But why fix what isn't broken? I can tell all my other programs, from
>>dd to mount, that I want to use the udev-created /dev/green_burner, so
>>why do you indicate such usage is _deprecated_ in cdrecord? For such
>>device nodes, a _filesystem_ is the preferred name=>number index, so
>>why add an extra strange file "just because Solaris does".
>>
>>
>
>If you use /dev/ entries to directly address SCSI targets, then you
>are relying on on assumptions that cannot be granted everywhere.
>
>Cdrecord is portable and this needs to implement a way that is portable
>and does not rely on nonportable assumptions like yours.
>
>
>
>
>>And why again do you need stable SCSI addresses for my _USB_ drive?
>>
>>
>
>Well if the udev program was polite to users, it would also support
>to edit /etc/default/cdrecord......
>
>... if it _really_ does wat you like with /dev/ links, then it has all
>the information that is needed to also maintain /etc/default/cdrecord
>
>
>
>J?rg
>
>
>
Joerg Schilling <[email protected]> writes:
> If you use /dev/ entries to directly address SCSI targets, then you
> are relying on on assumptions that cannot be granted everywhere.
>
> Cdrecord is portable and this needs to implement a way that is portable
> and does not rely on nonportable assumptions like yours.
Not really. Yes, it runs on different operating systems. But to send
the SCSI commands to the device you have OS-specific code in there,
simply because it's handled in different ways on Solaris / Linux /
whatever OS. You could make the device addressing OS-specific as well
instead of expecting everyone in the world follow the Solaris model,
that would make life a bit easier for everyone involved.
Addressing IDE devices (try to get a real SCSI burner these days)
using scsi host+target+lun is sort-of silly IMHO ...
Gerd
On 05/31/05 01:03:31PM +0200, Joerg Schilling wrote:
>
> > And why again do you need stable SCSI addresses for my _USB_ drive?
>
> Well if the udev program was polite to users, it would also support
> to edit /etc/default/cdrecord......
>
> ... if it _really_ does wat you like with /dev/ links, then it has all
> the information that is needed to also maintain /etc/default/cdrecord
The rules and scripts that udev uses to name things can do anything since
it runs in userland, so udev could easily edit /etc/default/cdrecord if
someone took the time to write the script.
Jim.
On Tue, May 31, 2005 at 06:59:01PM +0200, Gerd Knorr wrote:
> Not really. Yes, it runs on different operating systems. But to send
> the SCSI commands to the device you have OS-specific code in there,
> simply because it's handled in different ways on Solaris / Linux /
> whatever OS. You could make the device addressing OS-specific as well
> instead of expecting everyone in the world follow the Solaris model,
> that would make life a bit easier for everyone involved.
>
> Addressing IDE devices (try to get a real SCSI burner these days)
> using scsi host+target+lun is sort-of silly IMHO ...
Well I remember the first time I saw devfs running, I thought "Wow
finally I have a way to find the disc that is scsi id 3 on controller 0
even if I add a device at id 2 after setting up the system", something
most unix systems have always had, but linux made hard (you had to
somehow figure out which id mapped to which /dev/sd* entry, which from a
users perspective wasn't trivial, and of course keeping your fstab in
sync with the mapping was a pain).
I think sysfs can do it too, although I haven't looked to much at sysfs
yet.
For IDE devices the /dev entry always mapped to a specific device
(modulo your ide drivers loading in a consistant order, but scsi host
controller load order has the same issue). Scsi just assigned /dev
entries in the order devices were discovered. In some ways it is handy
to know your first scsi drive is sda if you are doing raid1 or something
and a drive dies, but on the other hand it is annoying that drives move
around if you add drives with a lower id than your existing drives.
Having both would be preferable.
I don't know if the ide or scsi method is currently more sane, but it
sure would be nice to have a consistent behaviour between the two.
Len Sorensen
On 5/31/05, Jim Crilly <[email protected]> wrote:
> On 05/31/05 01:03:31PM +0200, Joerg Schilling wrote:
> >
> > > And why again do you need stable SCSI addresses for my _USB_ drive?
> >
> > Well if the udev program was polite to users, it would also support
> > to edit /etc/default/cdrecord......
> >
> > ... if it _really_ does wat you like with /dev/ links, then it has all
> > the information that is needed to also maintain /etc/default/cdrecord
>
> The rules and scripts that udev uses to name things can do anything since
> it runs in userland, so udev could easily edit /etc/default/cdrecord if
> someone took the time to write the script.
>
Yes it could but why should it? The purpose of udev is to maintain
dynamic /dev. Do you want to have thoustands quirks in udev to cope
with bazillion configuration files for utilities whose authors refuse
to adopt standard naming convention [for the operating system in
question].
I do not understand why Joerg is so fixed on presenting SCSI interface
to userspace. Why when I mount just burned CD I can use /dev/scd0 but
for writing it I should say dev=5,4,0?? I do not really care that
internally X,Y,Z might or might not used, they should not be exposed
to userspace, especially since days when they could be used for static
device identification are long gone.
--
Dmitry
Hi,
> Well I remember the first time I saw devfs running, I thought "Wow
> finally I have a way to find the disc that is scsi id 3 on controller 0
> even if I add a device at id 2 after setting up the system", something
> I think sysfs can do it too, although I haven't looked to much at sysfs
> yet.
Yep, it can.
> I don't know if the ide or scsi method is currently more sane, but it
> sure would be nice to have a consistent behaviour between the two.
On my suse 9.3, out-of-the-box, I find this (implemented via
udev rules):
# find /dev/cd /dev/disk -type l -print | sort
/dev/cd/by-id/HL-DT-ST_DVDRAM_GSA-4040B_K213BDG5213
/dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
/dev/cd/by-path/pci-0000:00:04.1-ide-1:0
/dev/cd/by-path/pci-0000:00:04.1-ide-1:1
/dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751
/dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751p1
[ ... ]
/dev/disk/by-id/SIBM_DCAS-34330_B3GX3681
/dev/disk/by-id/SIBM_DCAS-34330_B3GX3681p1
/dev/disk/by-id/SIBM_DCAS-34330_B3GX3681p2
/dev/disk/by-label/WIN98
/dev/disk/by-label/unknown
/dev/disk/by-path/pci-0000:00:04.1-ide-0:0
/dev/disk/by-path/pci-0000:00:04.1-ide-0:0p1
[ ... ]
/dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0
/dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0-generic
/dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0p1
/dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0p2
/dev/disk/by-uuid/3140-1206
/dev/disk/by-uuid/5fbce796-2a1a-4ea3-bd5f-be35b28b2fb1
/dev/disk/by-uuid/b6a45df7-63bb-4890-b5d2-7bdcbe6c70a5
/dev/disk/by-uuid/cb367983-ac59-42cd-839d-b5cf0735fae5
/dev/disk/by-uuid/unknown
You'll have stable names both by connection path (great for the
raid case) and by device name (useful for the usb burner which
you plug into a different port each time). Guess you'll find
there what you are looking for ;)
Gerd
--
export CDR_DEVICE=/dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
On 05/31/05 02:28:16PM -0500, Dmitry Torokhov wrote:
> Yes it could but why should it? The purpose of udev is to maintain
> dynamic /dev. Do you want to have thoustands quirks in udev to cope
> with bazillion configuration files for utilities whose authors refuse
> to adopt standard naming convention [for the operating system in
> question].
I didn't say it was a good idea, just that it was possible to do what he
wants.
>
> I do not understand why Joerg is so fixed on presenting SCSI interface
> to userspace. Why when I mount just burned CD I can use /dev/scd0 but
> for writing it I should say dev=5,4,0?? I do not really care that
> internally X,Y,Z might or might not used, they should not be exposed
> to userspace, especially since days when they could be used for static
> device identification are long gone.
I totally agree, whenever I use cdrecord I use dev=/dev/whatever and will
continue to do so until it no longer works. But if that ever happens I
would hope another tool would take it's place. And contrary to what he
believes I also burned as a non-root user so it wasn't able to set itself
to rt or mlock itself into memory and I've never burned a coaster that I
could blame on either case even on my slowest machines.
> --
> Dmitry
Jim.