From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev enhancements
Date: Thu, 16 Dec 2004 21:55:02 +0000 [thread overview]
Message-ID: <1103234102.14134.170.camel@localhost.localdomain> (raw)
In-Reply-To: <41C1551F.6060601@suse.de>
On Thu, 2004-12-16 at 10:27 +0100, Hannes Reinecke wrote:
> I'm trying to figure out the best way to incorporating udev into some
> system tools. Currently we're facing the following problem:
>
> Any program dealing with device nodes (e.g. parted) need to figure out
> some information about the device it handles:
> - partition naming: given a device name, generate the name of a
> partition on that device.
> - number of partitions: each block device type has it's own maximal
> number of partitions.
>
> These information is mostly gathered from the device name. Of course,
> you can't do that if you're using udev.
Why? You still know the sysfs path with the kernel device name in it.
> So, to retain the existing functionality we would need to add two major
> improvements to udev:
>
> - Build udevinfo as library. This way any program can just link to this
> library and retrieve any information from there instead of rely on some
> build-in logic. That should actually be quite simple ...
Why do you want to link against it? What's the problem with executing
it, which is much easier to maintain?
> - Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would
> a partition on that device be named?
> The latter is the _really_ hard part. Currently there is no relationship
> in udev between a device and the partitions associated to that device.
> I would love to see that, though, as it would simplify the rules and the
> run-time behaviour of udev significantly.
> With the current setup we have to re-run any program fetching
> information about the device (e.g. scsi_id) every time a new partition
> has been detected. If we had a device->partition relationship, we could
> re-use the information from the device and just paste the
> partition-specific bits to the end.
You may just use a PROGRAM script on the partitions rule, that returns
the node name of the main block device.
Kay
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
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
next prev parent reply other threads:[~2004-12-16 21:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-16 9:27 udev enhancements Hannes Reinecke
2004-12-16 14:41 ` Harald Hoyer
2004-12-16 14:48 ` Olaf Hering
2004-12-16 21:55 ` Kay Sievers [this message]
2004-12-21 16:59 ` Greg KH
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=1103234102.14134.170.camel@localhost.localdomain \
--to=kay.sievers@vrfy.org \
--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).