From: Mike Anderson <andmike@us.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
dm-devel@redhat.com, Alasdair G Kergon <agk@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [2.6.23 PATCH 14/18] dm: netlink add to core
Date: Thu, 12 Jul 2007 10:34:10 -0700 [thread overview]
Message-ID: <20070712173410.GA2505@us.ibm.com> (raw)
In-Reply-To: <m1bqehfyp0.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman <ebiederm@xmission.com> wrote:
> I may be a little off but looking at the events types defined.
> device down, device up. Defining a completely new interface for this
> looks absolutely absurd.
>
>
> This is device hotplug isn't it? As such we should be using the
> hotplug infrastructure and not reinventing the wheel here.
>
I assume device hotplug means kobject_uevent and KOBJ_* events. The
original intent was to have a little more structure in the data format the
env strings. I also wanted to reduce the number of allocations that where
happening with GFP_KERNEL to send an event.
Currently the patch is only supporting a couple of events with the intent of
adding more over time. I see that I could map most events to KOBJ_CHANGE,
previously it did not seem like the correct fit.
> If it isn't hotplug it looks like something that inotify should
> handle.
>
> If that isn't the case I am fairly certain that md already has a
> mechanism to handle this, and those two should stay in sync
> if at all possible on this kind of thing.
>
Device mapper does have a "event happened" interface today, but post the
event the user must determine the context of the event (dm also sends a
kobject_uevent KOBJ_CHANGE only for a resume event). This patch was only
effecting dm, but I know the md has similar infrastructure. This patch
was passing out the event context through netlink that already existed but
was lost through the current generic event interface.
The existing event interfaces was left in place to not effect existing users
allowing migration over to a netlink interface over time.
> So this appears to be a gratuitous user interface addition.
> Why do we need a new user interface for this?
While I understand Evgeniy and Davids comment about utilizing the
genetlink interface, I guess I am not seeing that utilizing a netlink
channel for a subsystem as a gratuitous user interface addition vs.
running everything through kobject_uevent.
Thanks,
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2007-07-12 17:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070711210159.GF24114@agk.fab.redhat.com>
2007-07-11 21:34 ` [2.6.23 PATCH 14/18] dm: netlink add to core Andrew Morton
2007-07-12 0:40 ` Mike Anderson
2007-07-12 23:13 ` Johannes Berg
2007-07-12 15:07 ` Eric W. Biederman
2007-07-12 17:34 ` Mike Anderson [this message]
2007-07-12 19:37 ` Eric W. Biederman
2007-07-12 21:18 ` Alasdair G Kergon
2007-07-12 23:41 ` Mike Anderson
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=20070712173410.GA2505@us.ibm.com \
--to=andmike@us.ibm.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dm-devel@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@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).