[Ksummit-2008-discuss] proposal for discussion..

Marcel Holtmann holtmann at linux.intel.com
Mon Aug 25 14:15:30 PDT 2008


Hi Evgeniy,

>> Netlink and D-Bus share actually a lot things and are quite similar.
>> However when using netlink we mean using it from C/C++ programs
>> mostly. So what happens currently is that we export a kernel/ 
>> userspace
>> API over netlink and then we have system daemon wrapping these into a
>> D-Bus API. That is not helpful. Inaky and I wanna remove the netlink
>> step in this scenario.
>
> You will have to put new socket(AF_DBUS) call instead of AF_UNIX into
> any binding (or appropriate underlying library), so you can just  
> replace
> it with netlink.

true, but then I have to pass the D-Bus message and convert it to a  
netlink message. I really don't wanna do this, but I open for  
suggestions here. However wrapping the D-Bus wire format into another  
protocols wire format seems wrong to me.

>> D-Bus also supports a really nice separation between running things  
>> in
>> session versus system level. It also has a good lifetime monitoring  
>> of
>> process and other nice perks that are useful.
>>
>> When talking with some people the proposal to put D-Bus over netlink
>> came up and I am open for discussion, but that seems odd to me.  
>> Mainly
>> because D-Bus clearly specifies a good wire protocol. Some parts are
>> in the specification itself (I admit that), but neverless it is a
>> fully specified protocol.
>
> It is not about dbus protocol, which is cool. Well, it is a small  
> local
> horror, at least it was it several years ago, but it does not  
> prevent it
> from being cool :) Protocols are just like colours: every felt pen has
> own taste for different people.
>
> I consider dbus as ip/tcp/http/whatever, but netlink (or unix  
> socket) as
> an ethernet. Netlink already has all needed bits for low-level
> transport, which can be effectively used by the higher-level protocol
> like dbus. It has built in broadcasting and memory limit capabilities,
> which dbus do need.

See my point above. We can discuss the details. Currently I would go  
for AF_DBUS instead of putting it over netlink.

>> And all of them could use zerocopy to pass messages around. If  
>> AF_DBUS
>> is odd, then we could use shared memory as transport.
>
> It is pretty unlikely imho that such zero-copy approach for small  
> enough
> dbus messages will have any benefit.

Actually zerocopy is only one reason for me. The latency improvements  
and less context switches are also a point for me.

>> I really like to hear the pros and cons about it. Currently I see a
>> lot of benefits from doing this.
>>
>> And don't get me wrong here. For some parts of the D-Bus protocol are
>> really thing they are overdesigned and weird, but I have my 2 cents
>> for a lot of protocols. Maybe someone just needs to define D-Bus as a
>> RFC document. Would that make any difference? Would it make it a
>> better specification?
>
> I do not argue against dbus, if it solves some task, and especially  
> when
> it does it good, it is a good idea. I just want to note, that  
> transport
> layer for this protocol as a new socket type is a quite excessive  
> step,
> which can be replaced by using netlink for the purpose of the  
> transport
> layer for dbus. And very likely anyone will only benefit from this  
> step,
> since netlink is quite common transport and lots of people already  
> know
> how to work with it and thus simply bind to dbus dataflow on top of  
> it.

That would be a discussion point. Currently I am not sold on it, but  
that might change since I haven't looked into it in details. However D- 
Bus also has a manager component to assign unique and well known bus  
names. So this needs some further investigation. The prototype I am  
working is using AF_DBUS.

Regards

Marcel



More information about the Ksummit-2008-discuss mailing list