Re: [PATCH 00/11] RFC: KBUS messaging subsystem

Florian Fainelli
2011-05-17T08:46:16Z

Hello,

Sorry for this late answer.

On Tuesday 22 March 2011 20:36:40 Jonathan Corbet wrote:
> On Fri, 18 Mar 2011 17:21:09 +0000
>
> Tony Ibbs <tibs@tonyibbs.co.uk> wrote:
> > KBUS is a lightweight, Linux kernel mediated messaging system,
> > particularly intended for use in embedded environments.
>
> I've spent a bit of time looking at this code...this isn't a detailed
> review by any stretch, more like a few impressions.
>
> - Why kbus over, say, a user-space daemon and unix-domain sockets? I'm
> not sure I see the advantage that comes with putting this into kernel
> space.

I also fail to see why this would be required. In my opininon you are trading
the reliability over complexity by putting this in the kernel.

Most implementations (if not all) involving system-wide message delivery for
other daemons are running in user-space. Having a daemon for message delivery
to other kbus clients/servers does not not seem less reliable to me. If you
had in mind that this daemon might be killed under OOM conditions, then maybe
your whole system has an issue, issue which could be circumvented by making
sure the messaging process gets respawned when possible (upstart like
mechanism or such).

>
> - The interface is ... creative. If you have to do this in kernel space,
> it would be nice to do away with the split write()/ioctl() API for
> reading or writing messages. It seems like either a write(), OR an
> ioctl() with a message data pointer would suffice; that would cut the
> number of syscalls the applications need to make too.
>
> Even better might be to just use the socket API.

Indeed, I would also suggest having a look at what generic netlink already
provides like messages per application PID, multicasting and marshaling. If
you intend to keep a part of it in the kernel, you should have a look at this,
because from my experience with generic netlink, most of the hard job you are
re-doing here, has already been done in a generic manner.

>
> - Does anything bound the size of a message fed into the kernel with
> write()? I couldn't find it. It seems like an application could
> consume arbitrary amounts of kernel memory.
>
> - It would be good to use the kernel's dynamic debugging and tracing
> facilities rather than rolling your own.
>
> - There's lots of kmalloc()/memset() pairs that could be kzalloc().
>
> That's as far as I could get for now.
>
> Thanks,
>
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html