Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - pfil_run_hooks: (7 Items)
   
pfil_run_hooks  
Hi,

we would be interested in porting io-net filters to io-pkt as well
and having pfil_run_hooks() calling filter code looks promising.

If doing so, what would be the best way of attaching the filter
code to io-pkt that gets called by pfil_run_hooks()? Could I
write a fake driver which uses only the entry and shutdown
functions and in the entry function instead of calling
dev_attach() I would call pfil_head_register()?
pfil_head_register() would be called on eth_input_pfil_hook for
the rx direction and on the interface hooks of
interest (&ifp->if_pfil) for the tx direction?

Thankful for any help,
Peter Engstrom
Prisma Engineering
Re: pfil_run_hooks  
Hi, 

I found the autoip module which shows a bit how pfil hooks are
setup in an entry function, so things are getting clearer. Is
there any difference in loading an lsm or driver module in the
case where I would like to implement an ethernet filter
(iopkt_drvr_entry vs iopkt_lsm_entry)?

I would like to be able to shut down or remove the module 
as well without slaying io-pkt (I guess that is not implemented in the autoip module).

Regards,
Peter Engstrom
Re: pfil_run_hooks  
On Fri, Jul 11, 2008 at 08:25:18AM -0400, Peter Engstrom wrote:
> Hi, 
> 
> I found the autoip module which shows a bit how pfil hooks are
> setup in an entry function, so things are getting clearer. Is
> there any difference in loading an lsm or driver module in the
> case where I would like to implement an ethernet filter
> (iopkt_drvr_entry vs iopkt_lsm_entry)?

The loading is basically the same.  Drivers are
a bit more structured in that they all pretty
much call dev_attach() at some point whereas
lsm's are generally left to attach however they
want.

> 
> I would like to be able to shut down or remove the module 
> as well without slaying io-pkt (I guess that is not implemented in the autoip module).

Again there's no set shutdown method for lsm's.  You
could poke your lsm into unloading via an ioctl,
rmdir() on its namespace entry (assuming it creates
one), other method...

Regards,

-seanb
Re: pfil_run_hooks  
> On Fri, Jul 11, 2008 at 08:25:18AM -0400, Peter Engstrom wrote:
> > 
> > I would like to be able to shut down or remove the module 
> > as well without slaying io-pkt (I guess that is not implemented in the 
> autoip module).
> 
> Again there's no set shutdown method for lsm's.  You
> could poke your lsm into unloading via an ioctl,
> rmdir() on its namespace entry (assuming it creates
> one), other method...
> 

For the unloading part is there any example code available somewhere
or could you give me a hint/idea about what functions I would typically need to call to unload an lsm module?

Regards,
Peter Engstrom 
Re: pfil_run_hooks  
On Fri, Jul 25, 2008 at 12:26:27PM -0400, Peter Engstrom wrote:
> > On Fri, Jul 11, 2008 at 08:25:18AM -0400, Peter Engstrom wrote:
> > > 
> > > I would like to be able to shut down or remove the module 
> > > as well without slaying io-pkt (I guess that is not implemented in the 
> > autoip module).
> > 
> > Again there's no set shutdown method for lsm's.  You
> > could poke your lsm into unloading via an ioctl,
> > rmdir() on its namespace entry (assuming it creates
> > one), other method...
> > 
> 
> For the unloading part is there any example code available somewhere
> or could you give me a hint/idea about what functions I would typically need to call to unload an lsm module?
> 

We don't unload any lsm's ATM AFAIK.  The only step that
is probably absolutely necessary is nw_dlclose() at the
very end to unmap the dll.  The rest depends on what the
lsm does WRT registering with various subsystems in the
stack.  You might look at dev_detach() which is the 
starting point for unloading drivers.

-seanb
RE: pfil_run_hooks  
I guess that this is also obvious, but if you've registered functions
with pfil_add_hook, make sure that you pfil_remove_hook.

	Robert.

-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Friday, July 25, 2008 1:06 PM
To: ionetmig-networking
Subject: Re: pfil_run_hooks

On Fri, Jul 25, 2008 at 12:26:27PM -0400, Peter Engstrom wrote:
> > On Fri, Jul 11, 2008 at 08:25:18AM -0400, Peter Engstrom wrote:
> > > 
> > > I would like to be able to shut down or remove the module 
> > > as well without slaying io-pkt (I guess that is not implemented in
the 
> > autoip module).
> > 
> > Again there's no set shutdown method for lsm's.  You
> > could poke your lsm into unloading via an ioctl,
> > rmdir() on its namespace entry (assuming it creates
> > one), other method...
> > 
> 
> For the unloading part is there any example code available somewhere
> or could you give me a hint/idea about what functions I would
typically need to call to unload an lsm module?
> 

We don't unload any lsm's ATM AFAIK.  The only step that
is probably absolutely necessary is nw_dlclose() at the
very end to unmap the dll.  The rest depends on what the
lsm does WRT registering with various subsystems in the
stack.  You might look at dev_detach() which is the 
starting point for unloading drivers.

-seanb

_______________________________________________
io-net migration
http://community.qnx.com/sf/go/post11088
Re: RE: pfil_run_hooks  
Hi,

I have looked a bit more into the unloading code in io-pkt.  I also
have looked at the shim layer code which manages to support unloading
of "io-net" drivers among other things. Very nice.

However, I am looking for a simple solution to load and unload a
module which would hook up to the ethernet layer using the
pfil_hooks. The pfil_hooks interface is fine I think. The problem is
being able to register a shutdown function and having the module
unloaded.

One solution would be loading the module as a driver instead of as an
lsm, registering some fake interface and using 'ifconfig ... destroy'
to unload the module. However, this dirties the interface list seen
with ifconfig and is unelegant.

Returning to the lsm approach I miss some kind of API in io-pkt which
would allow me to register a shutdown function, a way of triggering a
call to the registered shutdown function and then having the module
unloaded.

I cannot add such an API in another module loaded on startup before
the other modules that I would like to load/unload, since I would not
have access to its functions. If there is a way of having access to
functions/symbols between modules please tell me since that would be a
viable solution.

The code which calls dlclose() must be in io-pkt and not in the
module, since I guess the module cannot call dlclose() on itself. I
could arrange to get called in the module by calling resmgr_attach()
for a device file but the problem remains that it cannot call
dlclose() on itself.

Thank you for any help,
Peter Engstrom