On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote: > On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: > > > > > Sure, but seems I need to ask again: What is the exact reason not to > > > > implement > > > > the muticast message multiplexing/subscription part of the connector as > > > > a > > > > generic part of netlink? That would be nice to have and useful for other > > > > subsystems too as an option to the current broadcast. > > > > > > This is a good point, in general, consider generically extending Netlink > > > itself instead of creating these separate things. > > > > > Connector requires it's own registration technique for > > 1. hide all transport [netlink] layer from higher protocols which use > > connector > > Why?
User should not know about low-level transport -
it is like socket layer - write only data and do not care about
how it will be delivered.
> > 2. create different group appointment for the given connector's ID
> > [it was different, now new group which is eqal to idx field is appointed
> > to
> > the new callback]
>
> I don't understand.
In the previous versions netlink group was assigned as incremented
counter,
that was not convenient, but now we have 2-way ID, which is better
from users point of view - idx is supposed to be major id, val -
some subsystem of that set.
> > 3. provide more generic set of ids
>
> What do you mean by "ids"?
Each connector message requires pair of u32 ids - idx and val.
Idx is generic system id [which is equal to the appropriate netlink
group
in current implementation], while val is id of some subsytem
inside idx.
Using only group without it's own connector's id will heavily
complex callback register/unregister notification [Jamal's suggested
feature]
for example.
>
> - James
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
