Ieee1394 doen't go under /dev

Ken Moffat zarniwhoop at ntlworld.com
Thu Jan 17 06:03:10 PST 2008


On Thu, Jan 17, 2008 at 10:50:11AM +0100, Thierry Nuttens wrote:
> Hello hello everybody.
> 
> Long time I didn't post anything. But today I'm facing a little prob. Everybody has heard about KINO. Those apps are expecting the firewire connection (ieee1394) directly under dev. Unfortunatly the udev rules puts it under a another one /dev/raw1394/raw whatever. How can I make it that it populate it directly under the /dev at the boot time or when it detect it without messing up the LFS udev rules.
> 
> Tanks a lot for your answer
> 
> Thierry 

 One of the benefits of using udev is that you can create symlinks
with a name of your choosing.  Some people think this is so you can
create names like /dev/mono-printer /dev/photo-printer, but it is
generally useful.

 I used to use a nikon 5700 camera, until it stopped working.  I
still have the following in my buildscripts, to create a symlink
from /dev/nikon5700 to whichever sda device it appears as (probably
sda1 with a PATA disk, or sdb1 with SATA, but it could move if I've
also got another usb storage device connected).  This then lets me
refer to /dev/nikon5700 in the fstab so that a user can mount it:

echo "BUS==\"usb\", SYSFS{product}==\"Nikon Digital Camera E5700\", KERNEL==\"sd?1\", NAME=\"%k\" SYMLINK=\"nikon5700\", MODE=\"0660\", GROUP=\"users\", OPTIONS=\"last_rule\"" >/etc/udev/rules.d/22-nikon5700.rules

 One very long line.  I'm not sure if positioning it as rule 22 is
appropriate for recent versions of udev.  You'll need to consider the
group and permissions, and change whatever identifies the device you
connect (use 'udevinfo') - point your browser to the udev directory
in /usr/share/doc/ .

 But, looking at the machine I'm on at the moment (udev-118), the
appropriate rules seem to be:

# Firewire
KERNEL=="dv1394*",              SYMLINK+="dv1394/%n"
KERNEL=="video1394*",           NAME="video1394/%n"

 So perhaps you can just edit the rule to match what kino expects.
Commenting out the existing rule, so that you can see what changed,
and if necessary revert it, is probably a good idea.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list