From: Tony Ibbs <tibs@tonyibbs.co.uk>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Ibbs <tibs@kynesim.co.uk>,
linux-embedded@vger.kernel.org, rrw@kynesim.co.uk
Subject: Re: [RFC][PATCH] KBUS messaging subsystem
Date: Sun, 6 Feb 2011 21:07:38 +0000 [thread overview]
Message-ID: <02F6EA37-B85C-48EE-8444-F5FD9B9E2A31@tonyibbs.co.uk> (raw)
In-Reply-To: <AANLkTin+uw=y8kver3M-9OFOS-z=RvSHvFf_EBVOB71u@mail.gmail.com>
On 3 Feb 2011, at 17:32, Grant Likely wrote:
> The big issue that comes into play when implementing a new protocol in
> Linux is that once it is implemented, we need to support it until the
> end of time.
Indeed.
> That means it needs to be well thought out and there is
> a lot of resistance to implementing something new without first seeing
> that it is a measurable benefit that is worth supporting to the end of
> time.
And I believe this is a good thing. If KBUS doesn't get in, hopefully it
will be because it has been demonstrated why it should not.
> In your case, you'll need to show (or attract) a wider range of
> users who can say, "yes, this is better than the alternatives".
This is one of the reasons I wanted to start by talking to the embedded
linux mailing list, where we can get the attention of people working
with small systems.
> I suggest looking at working with dbus for that exact reason. If dbus
> can be made faster/better/more reliable by using a kbus backend, then
> you've got a big userbase saying that it is a valuable addition.
Well, that's presumably true, but does DBUS *need* to be those
things (i.e., is it doing well enough already), and is that enough
reason to put something into the kernel (previous attempts, e.g.,
http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster,
seem to have foundered).
> It also gives you a broad use-case that will stretch your assumptions
That *is* a good motivation, and is one of the reasons for the CELF
proposals. But I don't think it is sufficient to be KBUS's reason for
existence.
> and improve the implementation before it gets set in stone when
> merged.
and I'm not so convinced on this one, since it seems to present a bit of
a chiken-and-egg problem. We believe KBUS is ready for merging because
we've been using it to good effect. If we don't try to merge it, then we
won't find out if we're right (!). If it should be in the kernel, then
it's better to get it there sooner, so that it can be moulded/grown
in-tree.
> If kbus turns out to only be applicable to your corner of the universe
> then it becomes a lot harder to justify it as a generic Linux
> communication implementation.
On the other hand, that depends on how big the corner is. We've seen
many projects trying to hand construct new socket based systems for lack
of a KBUS, and these generally reinvent the same problems each time. The
idea of KBUS is to get away from that.
If you're working on a large-ish system, needing to interact with the
many high-level components that already interact using DBUS, then
clearly you should be using DBUS for that purpose.
However, if you're building a system from scratch, if you have Linux,
busybox, and a set of programs that need to communicate with each other,
and limited resources, then DBUS is not going to be chosen. But those
systems still need a reliable, already written messaging mechanism,
rather than another ad-hoc approach.
Personally, I don't see KBUS competing with DBUS. DBUS already has its
place, and I assume it is good at what it does. KBUS wants to come in
at a lower level, and satisfy different customers.
Tibs
next prev parent reply other threads:[~2011-02-06 21:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110128180158.6f670a51@spoon>
2011-02-02 3:40 ` [RFC][PATCH] KBUS messaging subsystem Grant Likely
2011-02-03 17:04 ` Tony Ibbs
2011-02-03 17:32 ` Grant Likely
2011-02-06 21:07 ` Tony Ibbs [this message]
2011-01-28 17:50 Tony Ibbs
2011-01-28 19:20 ` Sam Ravnborg
2011-02-03 16:59 ` Tony Ibbs
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=02F6EA37-B85C-48EE-8444-F5FD9B9E2A31@tonyibbs.co.uk \
--to=tibs@tonyibbs.co.uk \
--cc=grant.likely@secretlab.ca \
--cc=linux-embedded@vger.kernel.org \
--cc=rrw@kynesim.co.uk \
--cc=tibs@kynesim.co.uk \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).