Joerg Schilling <[email protected]> wrote:
> Jan Engelhardt <[email protected]> wrote:
>> It's shorter than /dev/c0t0d0s0? Well, I think it's because people think
>> in terms of connectors (my drive is IDE therefore it must be hdc) rather
>> than protocol (my drive does ATAPI therefore it must be
>> /dev/scsi/c0t0d0s0).
>
> Is there any reason why the people with small PCs should dominate the
> people with big machines?
>
> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.
So you'll create a symlink. (If you're Ingvar Kamprad, it will be named bj?rn.)
> The systematical attempt is easy to remember even with a big amount of
> external hardware.
If you
- add a SCSI controler
- add an USB burner
- connect to an aoe/iscsi-device(?),
it will get a random ID. If you reboot (or just plug out/plug in), it will
be randomly different. The same thing may happen after a system upgrade,
possibly depending on the linker.
In these cases, there is nothing you can remember, and you'll have to run
-scanbus in order to find out if your burner is 0.8.15 or maybe 32.16.8
_each_ time you want to burn a CD. But you _can_ remember (or write into
your config files) that it will be named /udev/cdr/LITE-ON_LTR-48246K.
Having to find out the magic number of the day is usurally worse than
using the very same name you usurally use to identify an object. If you
see an advantage, let the ATAPI bus be -3, translate -3,$n,0.0 to
"/dev/hd".chr(96+$n) and everybody will be happy.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Bodo Eggert <[email protected]> wrote:
> If you
> - add a SCSI controler
> - add an USB burner
> - connect to an aoe/iscsi-device(?),
> it will get a random ID. If you reboot (or just plug out/plug in), it will
> be randomly different. The same thing may happen after a system upgrade,
> possibly depending on the linker.
This is a limitation of the implementation used on Linux and not true for e.g.
Solaris.
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 schrieb am 2006-02-03:
> This is a limitation of the implementation used on Linux and not true for e.g.
> Solaris.
Linux is not Solaris.
Do you want your application to work with Linux,
because it brings customers?
If yes, listen to kernel developers if they say "you don't need that
feature". Note I do not consider myself kernel developer. I'm a
bystander who's trying to help out.
--
Matthias Andree
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-03:
>
> > This is a limitation of the implementation used on Linux and not true for e.g.
> > Solaris.
>
> Linux is not Solaris.
>
> Do you want your application to work with Linux,
> because it brings customers?
>
> If yes, listen to kernel developers if they say "you don't need that
> feature". Note I do not consider myself kernel developer. I'm a
> bystander who's trying to help out.
????
Kernel developers should listen to the right application developers
(in special when they may have more kernel skills) to find out
what's needed.
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
Hi,
On Monday 06 February 2006 15:46, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
>
> > Joerg Schilling schrieb am 2006-02-03:
> >
> > > This is a limitation of the implementation used on Linux and not true for e.g.
> > > Solaris.
> >
> > Linux is not Solaris.
> >
> > Do you want your application to work with Linux,
> > because it brings customers?
> >
> > If yes, listen to kernel developers if they say "you don't need that
> > feature". Note I do not consider myself kernel developer. I'm a
> > bystander who's trying to help out.
>
> ????
>
> Kernel developers should listen to the right application developers
Yes, to the _right_ ones. You are soo right.
> (in special when they may have more kernel skills) to find out
> what's needed.
...
Have a nice day,
--
Ren? Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30 255 897 45
On Mon, 6 Feb 2006, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
> > Joerg Schilling schrieb am 2006-02-03:
> > > This is a limitation of the implementation used on Linux and not true for e.g.
> > > Solaris.
> >
> > Linux is not Solaris.
> >
> > Do you want your application to work with Linux,
> > because it brings customers?
> >
> > If yes, listen to kernel developers if they say "you don't need that
> > feature". Note I do not consider myself kernel developer. I'm a
> > bystander who's trying to help out.
>
> ????
>
> Kernel developers should listen to the right application developers
> (in special when they may have more kernel skills) to find out
> what's needed.
>From what I read, you need a way to map a short ID (possibly formed like
\mathbb{N}^4) to a (devicename, ID')-tupel, where ID' may be ID, a dummy
value or something completely different.
With the old /dev/sg-scheme, you had a hard time assigning
/dev/sg_num_of_the_day to a device, and you had to enqure each for the ID
in order to at least give a stable name. Obviously this was bad, therefore
it was superseded by the current method, making /dev/sg obsolete. It is
still supported, but nobody will enheance it to include IDE.
With the current mechanism, you can assign a user-defined name like
/dev/scsi/host1/bus2/id3/lun4/cd, /dev/scsi/1.2.3.4, /dev/bj?rn or
/dev/cdr/vendor_model. Obviously some are hard to type, and some are
designed to be typed by the user. In the later case, the user should be
allowed to use these names even if it isn't portable, and in the
former cases, having a nice thing.
For systems using /dev/scsi/1.2.3.4 etc., you can enumerate all devices by
walking a list of paths and trying each device in turn, and you can find
the device node using a regular expression.
On systems using /dev/cdr/vendor_model or /dev/bj?rn, you can't list all
devices yourself, but maybe you can exec a user-defined program doing this
work for you. In order to find the device again, you can either make the
list be (device node, ID), or define a reverse switch giving you just the
device node. I'd prefer the later, since that'd let you handle device
names containing spaces.
I'd use a script for both cases, and since many systems will use the
numeric scheme, maybe provide a default script for them. If the user or
the distribution doesn't use numeric IDs, they can create their own
script. (Off cause you'll still need the sg-scanning for 2.4 kernels).
Example for my system, obviously slightly untested:
---/etc/default/cdrecord:---
#aliases
toshiba TOSHIBA_XM-6201TA -1 -1
liteon LITE-ON_LTR-48246K 40 16m
apple MATSHITA_CR-8004 -1 -1
CDR_DEVICE = LITE-ON_LTR-48246K
enumerate_devices_bin = /usr/lib/cdrecord-scandevices.sh
---
---/usr/lib/cdrecord-scandevices.sh---
#!/bin/sh
if [ "$1" == "-r" ]; then # reverse mapping
exec /usr/bin/find /dev/cd{,r} -follow -name "$2"
else
exec /usr/bin/find /dev/cd{,r} -follow -type b -printf "%f\n"
fi
---
---default script---
#!/bin/sh
if [ "$1" == "-r" ]; then # reverse mapping
case "$2" in
-1.* ) a="`echo "$2"|sed -e \
's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\2[^0-9]+\3[^0-9]*,'`"
/usr/bin/find /dev/ide/ -regex "$a" -type b
;;
*) a="`echo "$2"|sed -e \
's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\1[^0-9]+\2[^0-9]+\3[^0-9]+\4[^0-9]*,'`"
/usr/bin/find /dev/scsi/ -regex "$a" -type b
;;
esac
else
/usr/bin/find /dev/ide/ -type b \! -regex '.*part[0-9]+' \
| sed -e \
's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//;s/^/-1./;s/$/.0/'
/usr/bin/find /dev/scsi/ \! -regex '.*part[0-9]+' -type b \
| sed -e 's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//'
fi
---
--
One enemy soldier is never enough, but two is entirely too many.
Joerg Schilling schrieb am 2006-02-06:
> Kernel developers should listen to the right application developers
> (in special when they may have more kernel skills) to find out
> what's needed.
Your skills are misrepresenting facts, ignoring uncomfortable questions,
and shifting the blame you have to take on others. These are skills that
make you belong to the "wrong" application developers that a kernel
developer will not listen to. You demand cooperation, but you only see
it as cooperation if people do as _you_ say. You put up artificial
limits in your applications to "prove" some kernel is wrong.
Is there anyone who does not see this as some kind of campaign of yours?
--
Matthias Andree