[Click] Uniform handler interface?

[Roman Chertov]

Eddie,

Can you actually open a socket in a kernel module?  My impression was 
that it would be hard to do as there is no easy to use API (that I could 
find) to deal with file descriptors (e.g. no straight forward way to 
open files on disk).  Surely, there is rich Linux API, but most of the 
calls are for user-kernel communication.

Just curious to hear more on this subject.

Roman

Eddie Kohler wrote:
> Björn,
> 
> A ControlSocket for kernel space might be interesting, but it is not top on 
> our list of priorities.
> 
> There are ways to translate from ControlSocket to kernel handlers, however. 
> For instance, you can run a user-level Click proxy that translates 
> ControlSocket requests to kernel handlers.
> 
> man KernelHandlerProxy
> man ControlSocket   -- look for the PROXY keyword argument
> 
> Eddie
> 
> 
> 
> 
> Björn Smedman wrote:
>> Hi,
>>
>> We have some click router configurations that I am trying to move from
>> kernel-space to user-space. Making the switch was as simple as changing the
>> command we use to load the configuration from "click-install" to "click". We
>> where very impressed to find this complex router config with custom elements
>> and all working exactly as before without a single change to either config
>> or code. :)
>>
>> But the handler interface differences seem to require manual work. We have a
>> control process that interacts with the click router through handlers (both
>> read and write), and the interface to these handlers has changed completely
>> after the move to user-space. In kernel-space we used the clickfs handler to
>> file mappings. In user-space it seems we have to use ControlSocket.
>>
>> Is it possible to use ControlSocket in kernel-space as well? Is there some
>> "best practice" for interacting with router configs that can be moved freely
>> between user- and kernel-space? It seems to me that this is such a
>> compelling feature (to be able to debug in user-space and then move to
>> kernel for better performance) that it would be worth while to abstract the
>> handler interface.
>>
>> Thank you in advance.
>>
>> Best regards,
>>
>> Björn
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>