[LiSA-Devel] Switch API prototyping

[Victor Duta]

Thank you Ionut, i miss read the rlshell structure and thought it's first
member was a swcli_context  :)

On Mon, Mar 11, 2013 at 11:38 AM, Ionut Nicu <ionut.nicu at mindbit.ro> wrote:

> 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
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lisa.mindbit.ro/pipermail/lisa-devel/attachments/20130311/ed346ef6/attachment.html