[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnupod] mktunes.pl bug
From: |
H. Langos |
Subject: |
Re: [Bug-gnupod] mktunes.pl bug |
Date: |
Mon, 24 Nov 2008 11:59:42 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Hi Matthijs,
On Sat, Nov 08, 2008 at 02:35:29PM +0100, Matthijs Schuurman wrote:
> Hi guys,
>
> I recently upgraded to Slackware current which doesn't seem to include
> udevinfo anymore.
> mktunes.pl reeaaallly seems freaks out on that... seems to fork itself 20
> times etc.
>
> Might be an idea to add a check to see if udevinfo is available?
Sorry, it took me so long to answer.
I looked into the code and as I read the code, it tries to execute "udevinfo"
for every directory entry it finds in /sys/block . So twenty should be
expected (my /sys/block has 31 entries).
I see however that the code could/should be rewritten to
a) check for the presence of udevinfo
b) using '"--path","/sys/block/".$dirent' instead of '"--name",$dirent'
c) execute udevinfo using "system()" instead of "exec()"
a) is obvious,
b) would get the information out of udev even when you rename the device
file in /dev like I do. I use those two udev lines to get my ipod always
assigned to /dev/ipod instead of /dev/sd[a..z] depending on the number of
usb devices I attach before:
SUBSYSTEMS=="scsi" DRIVERS=="sd" ATTRS{model}=="iPod" ATTRS{vendor}=="Apple"
KERNEL=="sd?1", NAME="ipod"
SUBSYSTEMS=="scsi" DRIVERS=="sd" ATTRS{model}=="iPod" ATTRS{vendor}=="Apple"
KERNEL=="sd?", NAME="ipod-wholedisk"
c) would run udevinfo in sequence instead of in parallel.
Also I think we could limit the devices to be tested to entries that
are named "sd*". Firewire and USB storage devices are both handled by
the scsi subsystem.
@Adrian: Thoughts? Comments?
cheers
-henrik