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 <tibs@xxxxxxxxxxxxxx> 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 to >> talk about. > > That's part of the problem, I suppose. We usually don't merge new > kernel facilities unless we're able to understand (and see) real > applications that need them. I understand. It is a bit of a chicken-and-egg problem. > On Sun, Aug 7, 2011 at 11:24 PM, Tony Ibbs <tibs@xxxxxxxxxxxxxx> wrote: >> I assume the real point of your post is that I wrote about the reasons >> why we made KBUS a kernel module, but did not really address the >> reasons why KBUS might want to be a kernel module in general usage. > > I simply don't see a convincing argument why existing IPC and other > kernel mechanisms are not sufficient to implement what you need. I'm > sure there is one but it's not apparent from your emails. Our major concern, strongly based on experience, is that given the existing kernel mechanisms, users do not build robust (or even sometimes working!) solutions for inter-process communication. This is in large part because they do not realise (at the start) how difficult this is to do. Especially if they want to keep it small. The only *sure* way of solving this is to provide a mechanism that is "always there", and that really means a solution provided by the kernel. This needs to be at a higher level than what is currently available, but obviously what exactly is provided is then a matter for discussion. We'd obviously argue that KBUS hits a "sweet spot" for the needs we perceive, given our application areas. > The whole thing feels more like "lets put a message broker into the > kernel" rather than set of kernel APIs that make sense. I suppose the > rather extensive ioctl() ABI is partly to blame here. I'm not sure what you mean by "message broker", except that it's plainly meant to be a bad thing - the wikipedia meaning doesn't seem terribly applicable to KBUS, as it covers an awful lot more territory (mind, the discussion page is amusing). I'll freely admit we started with the idea of what functionality we wanted and then chose a simple-to-implement API to make it happen. *If* KBUS were in the kernel, with its current functionality, what API would you expect? (not just "a sockety one", but what actual API?) If one recasts as a sockety API, how is many new socket options better than a set of ioctls? (or is that just one of those questions to which the answer is "well, it is"?) > I'm not saying you need to implement everything in userspace but I'm > also not convinced we want _all of this_ in the kernel. That's quite understandable. So, given the functionality we want, what would you put in the kernel, and what in userspace? (I'm personally sceptical about how much can be split this way, but still) (I realise that both this and the previous question are asking you to do work, but I'm honestly hoping that even if KBUS-as-is is not applicable, we might figure out an irreducible set of higher level constructs than those which are currently present which will attack the problem we wrote KBUS to attack.) Tibs -- 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
