From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: The Next Generation
Date: Thu, 17 Feb 2005 19:09:41 +0000 [thread overview]
Message-ID: <20050217190941.GA1561@vrfy.org> (raw)
After the recent discussion about a possible new hotplug handler layout
I see the need for a completely different approach. We need to clean
up the current mess, reduce all the silly options and give a sane
environment without all the hacks and shortcomings.
A real "next generation" can only be sane with managed hotplug events,
which prevents races with sysfs timing and cares about order and
dependencies between the events.
The directory device match logic, even the more advanced one proposed
yesterday, will never meet our requirements to limit system usage
at event time. We should expect a ever growing number of hotplug events
and need to be prepared to execute only the stuff which is really needed
for a specific device.
For that reason, we should get rid of all the just too simple
brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
requires scripts to check if they are called for the right device.
I propose to make the udev architecture _the_ generic hotplug handler.
We use the same rules which we are using today to compose a name for a
specific device. We just need something like a POSTPROCESS="/sbin/some-program"
key for our rules which adds a program to a list of programs to be executed
after the device node is created.
udev needs a bit of tweaking to handle physical devices, but it applies the same
logic as we currently use for device naming.
This way we would get a nice, clean and understandable rule based event handling
with a single source of policy, and not the current mess with confusing directories
spreaded all over the system. And sure, it would give us the efficiency one can
expect from a "next generation" thing. :)
What do you think?
Thanks,
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://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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 reply other threads:[~2005-02-17 19:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-17 19:09 Kay Sievers [this message]
2005-02-17 20:21 ` The Next Generation Marco d'Itri
2005-02-17 20:35 ` Kay Sievers
2005-02-18 5:26 ` Alexander E. Patrakov
2005-02-24 11:29 ` Roman Kagan
2005-02-24 12:26 ` Kay Sievers
2005-02-24 17:51 ` Roman Kagan
2005-02-24 19:37 ` Kay Sievers
2005-02-24 20:39 ` Roman Kagan
2005-02-25 12:54 ` Kevin P. Fleming
2005-02-25 23:17 ` Greg KH
2005-02-25 23:59 ` Marco d'Itri
2005-02-26 0:07 ` Greg KH
2005-02-26 0:18 ` Kay Sievers
2005-02-27 20:13 ` David Brownell
2005-02-27 23:34 ` Kay Sievers
2005-02-28 17:02 ` Roman Kagan
2005-02-28 17:38 ` Kay Sievers
2005-02-28 18:41 ` Kay Sievers
2005-02-28 19:11 ` Roman Kagan
2005-02-28 19:49 ` Marco d'Itri
2005-02-28 20:37 ` Kay Sievers
2005-02-28 20:42 ` Chris Larson
2005-02-28 20:46 ` Kay Sievers
2005-02-28 20:50 ` Marco d'Itri
2005-02-28 21:01 ` Kay Sievers
2005-02-28 21:14 ` Erik van Konijnenburg
2005-02-28 21:25 ` Roman Kagan
2005-03-01 20:17 ` Tobias Klauser
2005-03-02 7:13 ` David Brownell
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=20050217190941.GA1561@vrfy.org \
--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).