Messages in this thread | | | Date | Wed, 3 Aug 2011 23:48:26 +0300 | Subject | Re: RFC: [Restatement] KBUS messaging subsystem | From | Pekka Enberg <> |
| |
Hi Tony,
Your description doesn't really explain what you want to use this thing exactly for in userspace.
On Fri, Jul 29, 2011 at 12:48 AM, Tony Ibbs <tibs@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 of things for free, including list handling, > reference counting, thread safety and (on larger systems) > multi-processor support, which we would otherwise have to write and > debug ourselves. This also keeps our codebase smaller.
That's not a reason to put this into the kernel, really.
> * It helps give us reliability, partly because of the code we're > relying on, partly because of the strictures of working in the > kernel, partly by shielding us from userspace.
So now instead of crashing in userspace, we crash the kernel? This seems like a bogus argument as well.
> * It reduces message copying (we have userspace to kernel back to > userspace, as opposed to a userspace daemon communicating with > clients via sockets)
Now this sounds like a real reason but you'd have to explain why you can't reuse existing zero-copy mechanisms like splice() and tee().
> * It makes it simple for us to tell when a message recipient has "gone > away", as the kernel will call our "release" callback for us.
Again, sounds like a reasonable technical requirement but doesn't really justify putting all this code into the kernel.
> * It allows us to provide the functionality on systems without > requiring anything much beyond /dev and maybe /proc in userspace.
Why is this important?
Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |