Thank you Ionut, i miss read the rlshell structure and thought it's first member was a swcli_context :)<br><br><div class="gmail_quote">On Mon, Mar 11, 2013 at 11:38 AM, Ionut Nicu <span dir="ltr"><<a href="mailto:ionut.nicu@mindbit.ro" target="_blank">ionut.nicu@mindbit.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Victor,<br>
<div class="im"><br>
On Mon, 2013-03-11 at 10:43 -0400, Victor Duta wrote:<br>
> I think that the API should also include the swcli_context in order to<br>
> use the message qeues to comunicate with the daemons and the AF_SWITCH<br>
> sockets . I also have a question regarding the MACRO SWCLI_CTX wich<br>
> seems to cast (struct cli_context *) to (struct swcli_context *).I've<br>
> inspected the 2 structures and it seems that they don't have anything<br>
> in common . Could i get a brief explanation of why this is<br>
> possible .<br>
<br>
<br>
</div>Putting back the mailing list into CC. Please hit the reply-all button<br>
when replying so that we keep a clean history on the mailing list.<br>
<br>
If you look more closely at the structures, swcli_context's first member<br>
is a struct rlshell_context. rlshell_context's first member is a struct<br>
cli_context. If you think how things are layed out in memory, the first<br>
memory area of a swcli_context is in fact a cli_context structure.<br>
<br>
This is a well know pattern for doing OOP in C. If you think OOP, you<br>
could say that rshell_context is a class derived from cli_context and<br>
swcli_context is class derived from rlshell_context. If you keep a<br>
pointer to a swcli_context structure you can safely "upcast" it to a<br>
pointer to a cli_context which is the "base object".<br>
<br>
I hope this answers your question.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ionut.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> On Mon, Mar 11, 2013 at 8:28 AM, Ionut Nicu <<a href="mailto:ionut.nicu@mindbit.ro">ionut.nicu@mindbit.ro</a>><br>
> wrote:<br>
> Hi Andreea,<br>
><br>
> On Mon, 2013-03-11 at 13:58 +0200, Andreea-Cristina Hodea<br>
> wrote:<br>
> > On Mon, Mar 11, 2013 at 1:38 PM, Andreea-Cristina Hodea<br>
> > <<a href="mailto:andreea.cristina.hodea@gmail.com">andreea.cristina.hodea@gmail.com</a>> wrote:<br>
> > > Hi,<br>
> > ><br>
> > > Now the cli makes ioctl calls and communicates with<br>
> daemons (cdp,<br>
> > > rstp) by using queues and shared memory. In both cases<br>
> (kernel calls<br>
> > > and daemons), the cli context is used and data structures<br>
> defined in<br>
> > > cli implementation. Should we consider that all<br>
> implementations of the<br>
> > > API would make use of the data structures defined in cli<br>
> > > implementation?<br>
> ><br>
> > After a discussion with Victor, we realized that some of the<br>
> > structures in cli implementation would be better moved to<br>
> switch API.<br>
> > We're thinking that some of the data structures, like<br>
> swcfgreq<br>
> > shouldn't be part of the cli at all, because it will depend<br>
> on the<br>
> > implementation of the Switch API which structures to use.<br>
> For ioctl<br>
> > calls, swcfgreq and ifreq structures are being used for<br>
> setting the<br>
> > parameters used by the the lisa kernel implementation, but<br>
> are these<br>
> > structures also useful for the other proposed<br>
> implementations?<br>
><br>
><br>
><br>
> My opinion is that those structures (e.g. swcfgreq which is<br>
> defined as<br>
> far as I recall in a kernel header) should only be used by the<br>
> LiSA<br>
> specific implementation of the switch API. The switch API<br>
> itself should<br>
> be more generic and hide the particularities of the underlying<br>
> implementation (be it LiSA, bridge/8021q or any other).<br>
><br>
> In any case, as I've discussed with Radu a while ago, some of<br>
> the<br>
> information that is now kept into the lisa switch kernel<br>
> module should<br>
> be taken out to user space. I'm thinking of information such<br>
> as<br>
> interface or vlan descriptions. This way you'll be able to<br>
> support other<br>
> implementations (bridge/8021q) without doing any weird stuff<br>
> in<br>
> userspace.<br>
><br>
> Regards,<br>
> Ionut.<br>
><br>
> _______________________________________________<br>
> LiSA-Devel mailing list<br>
> <a href="mailto:LiSA-Devel@lisa.mindbit.ro">LiSA-Devel@lisa.mindbit.ro</a><br>
> <a href="http://lisa.mindbit.ro/mailman/listinfo/lisa-devel" target="_blank">http://lisa.mindbit.ro/mailman/listinfo/lisa-devel</a><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>