From: Steven Dake <sdake@mvista.com>
To: Oliver Neukum <oliver@neukum.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udev enhancements to use kernel event queue
Date: Fri, 13 Jun 2003 09:03:19 -0700 [thread overview]
Message-ID: <3EE9F5C7.8070304@mvista.com> (raw)
In-Reply-To: <200306130027.09288.oliver@neukum.org>
Oliver Neukum wrote:
>>If it works for you or doesn't or you like the idea or don't, I've love
>>to hear about it
>>
>>
>
>+ default:
>+ result = -EINVAL;
>+ break;
>+ }
>+ return (result);
>
>Must return ENOTTY.
>
>+static int sdeq_open (struct inode *inode, struct file *file)
>+{
>+ MOD_INC_USE_COUNT;
>+
>+ return 0;
>+}
>+
>+static int sdeq_release (struct inode *inode, struct file *file)
>+{
>+ MOD_DEC_USE_COUNT;
>+
>+ return (0);
>+}
>
>Wrong. release does not map to close()
>
>
>
hmm not sure where I got that from i'll fix thanks.
>Aside from that, what exactly are you trying to do?
>You are not solving the fundamental device node reuse race,
>yet you are making necessary a further demon.
>
>
For device enumeration, I see a daemon as necessary. The main goal of
this work is to solve the out-of-order execution of sbin/hotplug and
improve performance of the system during device enumeration with
significant (200 disks, 4 partitions each) amounts of devices. Boot
time with this scheme appears, in my rudimentary tests, to be faster on
the order of 1-2 seconds for bootup for the case of just 12 disks. I
would imagine 200 disks (which I don't have a good way to test, as I
don't have 200 disks:) would provide better speed gains during bootup.
This compares greg's original udev to this patched udev binary.
>You are not addressing queue limits. The current hotplug
>scheme does so, admittedly crudely by failing to spawn
>a task, but considering the small numbers of events in
>question here, for the time being we can live with that.
>
>You can just as well add load control and error detection
>to the current scheme. You fail to do so in your scheme.
>You cannot queue events forever in unlimited numbers.
>
>
I agree there should be some way of limiting events. I'll add this set
of code.
>As for ordering, this is a real problem, but not fundamental.
>You can make user space locking work. IMHO it will not be
>pretty if done with shell scripts, but it can work.
>There _is_ a basic problem with the kernel 'overtaking'
>user space in its view of the device tree, but you cannot solve
>that _at_ _all_ in user space.
>
>In short, if you feel that the hotplug scheme is inadequate
>for your needs, then write industry strength devfs2.
>
>
devfs is not appropriate as it does not allow for complex policy with
external attributes that the kernel is unaware of. For an example, lets
take the situation where a policy must access a cluster-wide manager to
determine some information before it can make a policy decision. For
that to occur, there must be sockets, and hopefully libc, which puts the
entire thing in user space. Who would want to write policies in the
kernel? uck.
> Regards
> Oliver
>
>
>
>
Thanks
-steve
next prev parent reply other threads:[~2003-06-13 15:53 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-12 19:10 [PATCH] udev enhancements to use kernel event queue Steven Dake
2003-06-12 21:47 ` Patrick Mochel
2003-06-13 16:31 ` Steven Dake
2003-06-13 17:06 ` Patrick Mochel
2003-06-12 21:47 ` Greg KH
2003-06-12 22:03 ` Andrew Morton
2003-06-12 22:50 ` Greg KH
2003-06-12 22:51 ` Andrew Morton
2003-06-12 23:02 ` Greg KH
2003-06-12 23:09 ` Greg KH
2003-06-12 23:14 ` Patrick Mochel
2003-06-12 23:16 ` Robert Love
2003-06-12 23:25 ` Greg KH
2003-06-13 20:01 ` Oliver Neukum
2003-06-18 22:59 ` Greg KH
2003-06-19 0:12 ` Kevin P. Fleming
2003-06-19 0:20 ` Greg KH
2003-06-19 0:42 ` Kevin P. Fleming
2003-06-19 0:51 ` Greg KH
2003-06-19 0:25 ` Andrew Morton
2003-06-19 6:27 ` Oliver Neukum
2003-06-12 23:25 ` Patrick Mochel
2003-06-12 23:29 ` Robert Love
2003-06-12 23:32 ` Greg KH
2003-06-12 23:34 ` Patrick Mochel
2003-06-12 23:40 ` Paul Mackerras
2003-06-12 23:50 ` Robert Love
2003-06-13 12:44 ` Richard B. Johnson
2003-06-13 12:54 ` Olivier Galibert
2003-06-12 23:52 ` Patrick Mochel
2003-06-13 8:41 ` Alan Cox
2003-06-13 11:00 ` Paul Mackerras
2003-06-13 11:07 ` Herbert Xu
2003-06-13 13:31 ` Alan Cox
2003-06-13 19:57 ` Joe Korty
2003-06-13 21:10 ` Alan Cox
2003-06-13 11:17 ` David Schwartz
2003-06-13 15:44 ` Davide Libenzi
2003-06-12 23:42 ` Robert Love
2003-06-12 23:45 ` Davide Libenzi
2003-06-12 23:05 ` Robert Love
2003-06-19 19:51 ` Werner Almesberger
2003-06-26 12:17 ` Tommi Virtanen
2003-06-26 14:35 ` Werner Almesberger
2003-06-13 8:40 ` Alan Cox
2003-06-13 9:14 ` Olivier Galibert
2003-06-19 20:53 ` Werner Almesberger
2003-06-13 16:05 ` Steven Dake
2003-06-13 16:32 ` Greg KH
2003-06-13 15:51 ` Steven Dake
2003-06-13 16:41 ` Patrick Mochel
2003-06-13 16:42 ` Greg KH
2003-06-13 17:17 ` Chris Friesen
2003-06-12 22:27 ` Oliver Neukum
2003-06-13 16:03 ` Steven Dake [this message]
2003-06-13 16:50 ` Patrick Mochel
2003-06-13 17:10 ` Steven Dake
2003-06-13 18:26 ` Greg KH
2003-06-13 19:02 ` Patrick Mansfield
2003-06-13 17:32 ` Oliver Neukum
2003-06-13 18:23 ` Greg KH
2003-06-13 18:24 ` Greg KH
2003-06-13 7:17 ` Christoph Hellwig
2003-06-13 18:06 ` Linus Torvalds
2003-06-19 23:32 ` Werner Almesberger
2003-06-19 23:42 ` Steven Dake
2003-06-20 0:05 ` Linus Torvalds
2003-06-20 0:10 ` Steven Dake
2003-06-20 0:43 ` Linus Torvalds
2003-06-20 2:26 ` Werner Almesberger
2003-06-20 17:03 ` Steven Dake
2003-06-20 17:18 ` Patrick Mochel
2003-06-14 6:36 John Bradford
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=3EE9F5C7.8070304@mvista.com \
--to=sdake@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.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).