On 22 Aug 2011, at 02:15, Bryan Donlan wrote:
I think this may well be the core problem here - is KBUS, as proposed,
a general API lots of people will find useful, or is it something that
will fit _your_ use case well, but other use cases poorly?
Indeed.
And, by the way, thanks a lot for
On 15 Aug 2011, at 12:46, Pekka Enberg wrote:
Hi Tony,
Hi. Thanks for your reply
On Sun, Aug 7, 2011 at 11:24 PM, Tony Ibbs t...@tonyibbs.co.uk wrote:
Real examples of usage that aren't the STB are a bit difficult to give
because they belong to customer projects that we're not allowed
On 3 Aug 2011, at 21:14, Tony Ibbs wrote:
On 29 Jul 2011, at 00:58, Colin Walters wrote:
You don't mention what your performance requirements are
(if any) for example.
We don't particularly have any...
My colleague says that he has previously done measurements that show
KBUS to be about
that we're not allowed to
talk about.
On Fri, Jul 29, 2011 at 12:48 AM, Tony Ibbs t...@tonyibbs.co.uk wrote:
So why did we write it as a kernel module?
==
As implementors, a kernel module makes a lot of sense. Not least
because:
* It gives us a lot
On 17 May 2011, at 09:50, Florian Fainelli wrote:
Sorry for this late answer.
And apologies for my own late response. I'll try to keep this short as
I hope the Restatement side-thread will address some of it.
On Tuesday 22 March 2011 20:36:40 Jonathan Corbet wrote:
- Why kbus over, say, a
The company I work for does a fair amount of stuff on embedded
systems, and we often need a simple way to send interprocess
messages. DBUS is too large and complex for this, and the ad-hoc
solutions we've seen people develop normally have significant
problems. So we wrote our own. Since it's a
On 17 May 2011, at 09:50, Florian Fainelli wrote:
Hello,
Sorry for this late answer.
Not a problem from here, all responses are helpful. In, turn, apologies
for taking so long to reply.
Most implementations (if not all) involving system-wide message
delivery for other daemons are running
On 18 Apr 2011, at 15:01, Mark Brown wrote:
On Fri, Apr 15, 2011 at 04:46:08PM -0600, Jonathan Corbet wrote:
That means getting more people to look at the patch, which could be hard.
The problem is that, if you wait, they'll only squeal when the code is
close to going in, and you could
and tracing
facilities rather than rolling your own.
- There's lots of kmalloc()/memset() pairs that could be kzalloc().
I shall address these next, although I'm afraid it may be a few days.
Thanks, by the way, for the timely LWN article on the dynamic debugging
interface.
Signed-off-by: Tony Ibbs t
On 24 Mar 2011, at 18:03, James Chapman wrote:
On 23/03/2011 23:13, Tony Ibbs wrote:
...stuff I've left out, because it's expanded on below...
I don't understand what Kbus really brings either.
From one angle, KBUS aims to fit the particular needs of the embedded
user:
1. It's relatively
Various internal datastructures, and communication between source
files.
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
ipc/kbus_internal.h | 626 +++
1 files changed, 626 insertions(+), 0 deletions(-)
create mode 100644 ipc/kbus_internal.h
This first version of the main source file just provides device
open/close and various basic IOCTLs, including bind/unbind.
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
ipc/kbus_main.c | 1061 +++
1 files changed, 1061 insertions(+), 0
Users do not always know how many KBUS devices will be needed when
the system starts. This allows a normal user to request an extra
device.
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
include/linux/kbus_defns.h | 12 +++-
ipc/kbus_main.c| 17 +
2
documentation.
There is a brief introduction to the concept here:
http://presentations.kbus.googlecode.com/hg/talks/europython2010.html#limpets
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
include/linux/kbus_defns.h | 30 -
ipc/kbus_internal.h|5 +
ipc/kbus_main.c| 376
Sometimes a recipient has bound to a message name more than once,
but only wants to receive one copy of each message matching those
bindings.
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
include/linux/kbus_defns.h | 18 +++---
ipc/kbus_internal.h| 30
ipc
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
init/Kconfig |2 +
ipc/Kconfig | 117 ++
ipc/Makefile |9
3 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 ipc/Kconfig
diff --git a/init/Kconfig b/init
This introduces two pseudo-files which expose some of the current
KBUS internal state. The bindings file, in particular, is used
in the KBUS test scripts (which are part of the userspace Python
binding).
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
ipc/kbus_report.c | 256
In order to make sending Replier Bind Events reliable, we need
to introduce set-aside message lists, in case a client that
wants to receive such events has a full list when the event
occurs (making bind/unbind depend on the recipient of the
event is not acceptable).
Signed-off-by: Tony Ibbs t
On 28 Feb 2011, at 07:52, Grant Likely wrote:
On Mon, Feb 28, 2011 at 12:48 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Just go ahead and post to lkml. There isn't a whole lot of point in
holding back from there, and that is the only way you'll get the level
of review that you need
On 28 Feb 2011, at 19:23, Sam Ravnborg wrote:
You are using /proc/* to something that is not process related.
At lkml you will be requested to use something else.
OK. That's mainly through ignorance of what I *should* be using
instead (and perhaps poor reading of Linux Device Drivers). Do you
KBUS is a lightweight, Linux kernel mediated, message system,
particularly intended for use in embedded environments.
It is meant to be simple to use and understand. It is designed to
provide predictable message delivery, deterministic message ordering,
and a guaranteed reply for each request.
From: Tibs t...@tonyibbs.co.uk
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
Documentation/Kbus.txt | 1222
1 files changed, 1222 insertions(+), 0 deletions(-)
create mode 100644 Documentation/Kbus.txt
diff --git a/Documentation/Kbus.txt b
From: Tibs t...@tonyibbs.co.uk
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
include/linux/kbus_defns.h | 666
1 files changed, 666 insertions(+), 0 deletions(-)
create mode 100644 include/linux/kbus_defns.h
diff --git a/include/linux
From: Tibs t...@tonyibbs.co.uk
Amend the ipc Makefile.
Add an ipc Kconfig for KBUS.
Amend the init Kconfig appropriately.
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk
---
init/Kconfig |3 ++
ipc/Kconfig | 99 ++
ipc/Makefile |5
If there is a better way for me to submit this, please let me know.
The source is still
Signed-off-by: Tony Ibbs t...@tonyibbs.co.uk--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Fri, 28 Jan 2011 20:20:42 +0100
Sam Ravnborg s...@ravnborg.org wrote:
[Edited cc: list as my smtp server refused to send the original reply]
Apologies - I had copied down Grant Likely's email address wrong at ELCE.
Should I just submit the patch to this list?
You will get more feedback
+
From: Tony Ibbs t...@kynesim.co.uk
To: Linux-embedded linux-embedded@vger.kernel.org
[...]
Should I just submit the patch to this list?
[...]
Yes. If you want review, then posting a URLs doesn't help. :-) Send
it as an email so that I can just hit 'reply' and start typing.
Post
27 matches
Mail list logo
