[LiSA-Devel] Switch API prototyping

Ionut Nicu ionut.nicu at mindbit.ro
Mon Mar 11 17:38:34 EET 2013


Hi Victor,

On Mon, 2013-03-11 at 10:43 -0400, Victor Duta wrote:
> I think that the API should also include the swcli_context in order to
> use the message qeues to comunicate with the daemons and the AF_SWITCH
> sockets . I also have a question regarding the MACRO SWCLI_CTX wich
> seems to cast (struct cli_context *) to (struct swcli_context *).I've
> inspected the 2 structures and it seems that they don't have anything
> in common . Could i get a brief explanation of why this is
> possible .   


Putting back the mailing list into CC. Please hit the reply-all button
when replying so that we keep a clean history on the mailing list.

If you look more closely at the structures, swcli_context's first member
is a struct rlshell_context. rlshell_context's first member is a struct
cli_context. If you think how things are layed out in memory, the first
memory area of a swcli_context is in fact a cli_context structure.

This is a well know pattern for doing OOP in C. If you think OOP, you
could say that rshell_context is a class derived from cli_context and
swcli_context is class derived from rlshell_context. If you keep a
pointer to a swcli_context structure you can safely "upcast" it to a
pointer to a cli_context which is the "base object".

I hope this answers your question.

Ionut.


> 
> On Mon, Mar 11, 2013 at 8:28 AM, Ionut Nicu <ionut.nicu at mindbit.ro>
> wrote:
>         Hi Andreea,
>         
>         On Mon, 2013-03-11 at 13:58 +0200, Andreea-Cristina Hodea
>         wrote:
>         > On Mon, Mar 11, 2013 at 1:38 PM, Andreea-Cristina Hodea
>         > <andreea.cristina.hodea at gmail.com> wrote:
>         > > Hi,
>         > >
>         > > Now the cli makes ioctl calls and communicates with
>         daemons (cdp,
>         > > rstp) by using queues and shared memory. In both cases
>         (kernel calls
>         > > and daemons), the cli context is used and data structures
>         defined in
>         > > cli implementation. Should we consider that all
>         implementations of the
>         > > API would make use of the data structures defined in cli
>         > > implementation?
>         >
>         > After a discussion with Victor, we realized that some of the
>         > structures in cli implementation would be better moved to
>         switch API.
>         > We're thinking that some of the data structures, like
>         swcfgreq
>         > shouldn't be part of the cli at all, because it will depend
>         on the
>         > implementation of the Switch API which structures to use.
>         For ioctl
>         > calls, swcfgreq and ifreq structures are being used for
>         setting the
>         > parameters used by the the lisa kernel implementation, but
>         are these
>         > structures also useful for the other proposed
>         implementations?
>         
>         
>         
>         My opinion is that those structures (e.g. swcfgreq which is
>         defined as
>         far as I recall in a kernel header) should only be used by the
>         LiSA
>         specific implementation of the switch API. The switch API
>         itself should
>         be more generic and hide the particularities of the underlying
>         implementation (be it LiSA, bridge/8021q or any other).
>         
>         In any case, as I've discussed with Radu a while ago, some of
>         the
>         information that is now kept into the lisa switch kernel
>         module should
>         be taken out to user space. I'm thinking of information such
>         as
>         interface or vlan descriptions. This way you'll be able to
>         support other
>         implementations (bridge/8021q) without doing any weird stuff
>         in
>         userspace.
>         
>         Regards,
>         Ionut.
>         
>         _______________________________________________
>         LiSA-Devel mailing list
>         LiSA-Devel at lisa.mindbit.ro
>         http://lisa.mindbit.ro/mailman/listinfo/lisa-devel
>         
> 




More information about the LiSA-Devel mailing list