linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arioch <the_Arioch@nm.ru>
To: linux-hotplug@vger.kernel.org
Subject: Re: +rule: query device inode by Major and Minor - am i inventing
Date: Tue, 16 Aug 2005 10:52:00 +0000	[thread overview]
Message-ID: <ddsgfo$m1o$1@sea.gmane.org> (raw)
In-Reply-To: <4300318B.8040505@nm.ru>

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

  parent reply	other threads:[~2005-08-16 10:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-15  6:09 +rule: query device inode by Major and Minor - am i inventing brand Arioch
2005-08-15 13:40 ` +rule: query device inode by Major and Minor - am i inventing brand new bycicle ? Kay Sievers
2005-08-16 10:52 ` Arioch [this message]
2005-08-16 17:13 ` +rule: query device inode by Major and Minor - am i inventing Arioch
2005-08-16 18:18 ` Arioch
2005-08-16 18:29 ` +rule: query device inode by Major and Minor - am i inventing brand new bycicle ? Kay Sievers
2005-08-16 18:50 ` +rule: query device inode by Major and Minor - am i inventing Arioch
2005-08-16 21:28 ` +rule: query device inode by Major and Minor - am i inventing brand new bycicle ? Greg KH
2005-08-17  8:07 ` +rule: query device inode by Major and Minor - am i inventing Arioch
2005-08-18 17:59 ` +rule: query device inode by Major and Minor - am i inventing brand new bycicle ? Greg KH
2005-08-18 21:04 ` +rule: query device inode by Major and Minor - am i inventing Arioch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ddsgfo$m1o$1@sea.gmane.org' \
    --to=the_arioch@nm.ru \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).