From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arioch Date: Tue, 16 Aug 2005 10:52:00 +0000 Subject: Re: +rule: query device inode by Major and Minor - am i inventing Message-Id: List-Id: References: <4300318B.8040505@nm.ru> In-Reply-To: <4300318B.8040505@nm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.org Kay Sievers пишет: > On Mon, Aug 15, 2005 at 10:09:15AM +0400, Arioch wrote: > >>I made (and attached) a tiny rule, and hope it will be interesting to >>some of you. >>See attach. > > >>I made it with two thought in background: >> >>1) Some drivers with incomplete SYSFS support (namely, wbsd on my box) >>publiches major and minor, but not the device inode name :-( >>If i wantr to find it from script - how ? ls -lR | grep ? BRR! :-) Hate >>RegExp's :-) > > > You mean the device 'node', the file in /dev, right? exactly. > What does publish major/minor mean? That mean by crawling through /sys i can learn what is major and minor for some dev-file. Yet the very name of the file is not the thing i can find in /SYS - since SYSFS is not the layer that creates such devices, and there seems to be no method, UDEV will tell device file name, and SYSFS would hear it and represent under /sys. >That the driver does not create an > entry in /sys/block/*? > AS: eraly drivers is only one example, where i want to find file under /dev, knowing only its major and minor. There can be more situations. wbsd is driver for SD/MMC flash cards reader. When i insert MMC card, it (or mmc-core.ko, or mmc-block.ko ) creates block devices /dev/mmcblk0 and /dev/mmcblk0p1 - for 1st (and only) partition. The very controller is not block device yet. There are SDIO cards, which, like CardBus ones, are devices, rather than disks. zsh 4 % ls /sys/module/wbsd parameters refcnt sections zsh 5 % ls /sys/bus/pnp/drivers/wbsd -l @00:07 -> ../../../../devices/pnp0/00:07 zsh 6 % ls /sys/bus/pnp/drivers/wbsd/00:07 bus driver id options power resources This is without MMC card. With card there is added folder mmc0:0001 Yahoo! yesterday i updated kernel to 2.6.12 and driver seems to got updated too. But ... zsh/2 17 % pwd /sys/bus/pnp/drivers/wbsd/00:07/mmc0:0001/block zsh/2 18 % ls dev device mmcblk0p1 queue range removable size stat zsh/2 20 % cat removable 0 # - WOW !!!! zsh/2 19 % cat dev 253:0 That's all. Since UDEV can move and rename device inodes wherever and however it is configured - how should i find it ? At my box, for example, those devices are /dev/mmcblk0* - they are not moved into /dev/disks subfoolder to my HDD, nor to /dev/cdroms. I have not ZIP drive now and cannot check which device node it would be mapped to. IMHO old FDD, ZIP and alike devices, memory cards (CF, MMC, USB flash drives) and even CD-RW in packet burning mode - they are same kind of devices: block and removable. I wonder where they are to be grouped :-) >>2) On my box pktsetup (packet-mode CD-RW burning helper, part of >>udfhelper) creates two block device per drive! I wanted to catch this. >>After all it seems that it creates second inode by mknod, not kernel >>call and UDEV. But surprisingly i saw a number of other duplicate inodes >>with the identical major-minor > > What nodes exactly have the same major/minor? That setup may need to be > fixed. For now i put this in my distro bugzilla and hope it will get some attention in proper time. This design might be affecting only my distro. Out of my head - i saw a number of logs, sharing numbers with ram disks. Did You tested those rules ? You can see, they are harmless and only add a couple of symlinks. Next time You'd boot Your box (or if it is no danger to You - service udevd restart) - You would know about Your system :-) >>So, as i want to be famous, would You, please, considering including >>this rule into UDEV examples ? :-) > > We don't provide a dead example file anymore. Nobody cared about that file, > it was outdated and some people expected this as "the default" udev file > and complained about the entries, so I just deleted it. Instead we carry > a lot of distro rules as examples now. So you need to convince a distro to > ship your rule to get it included. Good luck! :) ...and it would be distro-local ? Guess, there i s to be some wiki or something of a kind. In such a place, different distro's could publish their rules and compare the benefits. Or perhaps LSB is to care of those rules ? >>Ouugh, almost forgot to state a wish: >>Can there be on more key for rules ? >>Similar to RETURN, but matching not string form stdout, but the return >>code of program ( $? ) ? > > > You mean similar to "RESULT"? > Sure, i was typing RESULT, but was thinking of RETURN CODE :-) >>Why - cause i wanted to do if/else/then. >>I run a program to check if a symlink already exists - then i run >>another program to check if it does not exists ! > > > PROGRAM!="..." should catch non-zero exit's. You also can jump with GOTO="..." > to a LABEL="..." line (see the persistent disk rules examples). Where can i find such rules, if You do not ship Your own rulesets ? Article of righting UDEV rule is ether too basic or too outdated - there even no word about "+=" (Hmmm, how about -= ? :D ) PROGRAM != - is not solution. Please, look at my rules. There're just two rules in the file. And they represent if-then-else choice. If i would negate if-condition - i just swap then and else - but do not get rid of them. I still have to run the program twice, since in later rule i cannot refer to retcode of PROGRAM in prior rule. I just do not want to run the program twice, nor to make quite dumb and auxillary script. > Yes stderr is ignored. You will need to fork a shell for that to catch. But since i cannot escape \" in PROGRAM argument (and i already used single quotes) - that makes pain :-) To my experience, stderr output is 1) sent to user's tty 2) signals to UDEV to not try this rule any more (at list i saw that output once, while otherwise i should see it for every device) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel