Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]