bug-gnupod
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]