lkml.org 
[lkml]   [2003]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] udev enhancements to use kernel event queue


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.158 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site