Click Dynamic loading

[Prem Gopalan]

Hi Eddie,
	   We are trying to get some non-click code [to be used as a
router plugin] (as source) downloaded to our machine so that we can create
an archive and somehow(we are still figuring out how !) without changing
the configuration in /proc/click/config, install this new module(.ko file)
and then let click (through the use of an 'Invoke' element) call functions
of this new module whenever an active packet reaches this element. 

In the process, we needed to use some form of IPC to communicate with User
processes. We wrote a new element that has such code(like calls to
sys_msgget, sys_msgrcv, do_execve etc) but I get 'unresolved symbols'
error messages when I try to use insmod to insert the compiled click.o
code. All such functions( which are declared asmlinkage in their header
files..) produce these 'unresolved' messages. Are we going wrong in
assuming that Kernel functions (other than ofcourse printk, memcpy etc)
can be invoked from the click.o module. Is there any restriction on what
calls can be made ?(ofcourse, system calls cannot be and we may need to
call their 'base' function instead of changing from user -> kernel mode).

Any help on this would be greatly appreciated. Thanks for your patience.

Prem.


On Fri, 21 Apr 2000, Eddie Kohler wrote:

> Hi Prem,
> 
> > 	Thanks for your prompt reply on dynamic loading of modules in
> > Click. We just tried it out and it works fine the first time; but when
> > click is already loaded as kernel module and is running as router, it says
> > the device is busy and the configuration cannot be loaded. We thought that
> > it should be possible for click-install to rmmod click and remove it..but
> > that doesnt happen. Why ?
> 
> I don't know. That should work, and it generally does work for us. Can you
> please send a configuration (including .cc file) and tell me exactly what
> steps you followed that didn't work? If you have trouble unloading a Click
> configuration, try "click-uninstall"; that should get rid of everything.
> However, if there is a bug in your .cc file, such that it gets the
> reference counts wrong and ends up with a dangling reference count, that
> may prevent tthe unload, and cause the behavior you saw. So send us the
> configuration, but check your reference counts too.
> 
> > Also, we are trying to build a dynamic loader that automatically downloads
> > modules from remote servers if they do not exist on the same server. So we
> > are interested in knowing if the click configuration is ripped apart each
> > time we do click-install with a different archive made with the same
> > configuration file but with a different (downloaded) module. Or does it
> > just install the package/module and leaves the config in
> > /proc/click/config intact ? 
> 
> It always does a new install to /proc/click/config.
> 
> > In case, it does change the configuration file on the fly, what happens to
> > packets "trapped" in elements/queues as per the old configuration.
> 
> They are thrown away. We do plan to change this behavior eventually. It
> sounds like you would want us to change it soon.
> 
> > Do let us know if our line of thinking is on the right track. Thanks a
> > million for all your help.
> 
> I think your line of thinking is correct. But there's one thing that
> confuses me. Is the dynamic loader designed to download Click code from
> other places? Or just arbitrary modules that have nothing to do with Click?
> 
> Sounds like a cool project!
> 
> love,
> ed
> 



Prem Gopalan
Home phone: 1-765-746-1896