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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
