Havoc Pennington wrote: > Hi, > > On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: >> >> This is why I think kdbus is a bad idea: it solidifies as a linux kernel >> API something which runs counter to granular OS virtualization (and >> something which caused Windows to fall behind Linux in the container >> space). Splitting out the acceleration problem and leaving the rest to >> user space currently looks fine because the ideas Al and Andy are >> kicking around don't cause problems with OS virtualization. >> > > I'm interested in understanding this problem (if only for my own > curiosity) but I'm not confident I understand what you're saying > correctly. > > Can I try to explain back / ask questions and see what I have right? > > I think you are saying that if an application relies on a system > service (= any other process that runs on the system bus) then to > virtualize that app by itself in a dedicated container, the system bus > and the system service need to also be in the container. So the > container ends up with a bunch of stuff in it beyond only the > application. Right / wrong / confused? > > I also think you're saying that userspace dbus has the same issue > (this isn't a userspace vs. kernel thing per se), the objection to > kdbus is that it makes this issue more solidified / harder to fix? > > Do you have ideas on how to go about fixing it, whether in userspace > or kernel dbus? > > Havoc
So far as I understand (and this may be wrong), this is the use case of kdbus "endpoints" - you'd create a (constrained) kdbus endpoint on the host, and then expose it to the application, such that the application uses it as if it were the system bus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
