[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510911190700o6f4e80cm172c14dc0f28451d@mail.gmail.com>
Date: Thu, 19 Nov 2009 16:00:46 +0100
From: Kay Sievers <kay.sievers@...y.org>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: David Zeuthen <david@...ar.dk>, linux-kernel@...r.kernel.org,
axboe@...nel.dk, linux-hotplug@...r.kernel.org
Subject: Re: [PATCH] [RFC] Add support for uevents on block device idle
changes
On Thu, Nov 19, 2009 at 15:48, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Thu, Nov 19, 2009 at 03:34:53PM +0100, Kay Sievers wrote:
>
>> Single-subscriber event interfaces are usually a no-go for generic
>> infrastructure like this. We still have the unmodified HAL running
>> until it is dead, and this works only because there are no such
>> awkward interfaces. In a few years we will probably have diskfoo
>> replacing dk-disks, and then ... :)
>
> If you've got any ideas for what a multi-subscriber interface would look
> like, I'm happy look at it.
Yeah, it would not be as simple as your patch. It probably involves a
way to get a file descriptor per listener, to let the kernel know if
anybody is interested, and to auto-cleanup when the listener dies, and
to have per instance timers.
> I don't think there's an especially
> compelling use-case for one right now so I'm not enthusiastic about the
> additional complexity that'd be required,
Right, but we've been there, and it's a pain, if you can not subscribe
to an interface because something else is already using it/expecting
it is the only user ever. So there needs to be a good reason for
adding something like this as a new interface, which will very likely
hit us back some day.
> but as long as there's basic
> agreement that it's not practical to do this in userspace then we're at
> least on the same page.
I'm all for executing the policy inside the kernel and let userspace
only enable/configure it. It think there is not much to disagr4ee
about such an approach.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists