[Click] ControlSocket in kernel click - read handles remotely.

[Torquato Bertani]

Hi Eddie,

now everything is much more clear :)

I didn't know you can run click in userlevel and kernel module at the
same time. I'll recompile and retry.

Many thanks!
Torquato


On 3/21/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> Hi Torquato,
>
> You would use a very simple two-line userlevel Click script, like the one I
> gave, IN ADDITION TO the kernel script (which is unconstrained and doesn't
> need to have any ControlSocket or anything).
>
> So yes, recompile with --enable-userlevel --enable-linuxmodule.
>
> Hope this is clear
> E
>
>
> Torquato Bertani wrote:
> >>The ControlSocket opens a socket for all addresses, not just local ones.
> >
> >
> > Ok, thanks that.
> >
> >
> >>You are looking for the KernelHandlerProxy element.  A configuration like this:
> >>
> >>    ControlSocket(TCP, 8000, PROXY khp);
> >>    khp :: KernelHandlerProxy;
> >>
> >>will allow you read and write kernel handlers by connecting to port 8000 and
> >>speaking ControlSocket language.
> >
> >
> > This is exactly what I did first but the response was :
> > unkwnown element class: 'ControlSocket'
> > unkwnown element class: 'KernelHandlerProxy'
> >
> > I looked for their source code and founded in userlevel directory. So
> > I thought I can't use them if I compile click with the
> > --disable-userlevel option. So I thought I can't use them I use click
> > as kernel module. Then I wrote here :)
> >
> > But if you tell me that elements work also in click as kernel module I
> > should recompile click with the --enable-userlevel
> > --enable-linuxmodule, right?
> >
> > Thanks
> > Torquato
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>