unloading an io-net driver

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?

Murf

John A. Murphy <murf@perftech.com> wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount.

Why wouldn’t you want to use unmount? That is the “official” way to
remove an io-net module.

I beleive there is a programatically. In which case you call the umount
function, and then you wait for the device in /dev/io-net to disappear.

Cheers,
Camz.


Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting www.qnxzone.com

camz@passageway.com wrote:

John A. Murphy <> murf@perftech.com> > wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount.


Why wouldn’t you want to use unmount? That is the “official” way to
remove an io-net module.

I beleive there is a programatically. In which case you call the umount
function, and then you wait for the device in /dev/io-net to disappear.

Cheers,
Camz.

In order to use umount you have to know the name, and under QNX 6.3 the

name is different than it was under 6.2: en_en0 under 6.2, but en_en1
under 6.3. There’s the same problem with calling the umount function;
you have to know what io-net decided to call your module.

Murf

io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <murf@perftech.com> wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?

Murf

Thanks! I’ll give that a try. Meanwhile we’re just asking the filter
for the name io-net gave it, then running umount with that name; not
very elegant, but it get the job done.

Murf

Sean Boudreau wrote:

io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf

I tried postponing the MsgReply (to the message that asked me to unload)
until the destructor was called, and that, not surprisingly, does the
same thing that just never calling MsgReply at all does - it makes the
program that sent the unload message get ESRCH in response to its
MsgSend. And that still not late enough to allow immediately reloading
the module. I guess we’ll stick with asking the module for it’s name
and running umount. But thanks for the destructor tip! I’m sure I’ll
find a use for that…

Murf

Sean Boudreau wrote:

io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf

Hm…

If you are going to immediately reloading the module, why bother
unload it? Can’t you tell the module “re-initialize” ?

-xtang

John A. Murphy <murf@perftech.com> wrote in message
news:cqa318$gb1$1@inn.qnx.com

I tried postponing the MsgReply (to the message that asked me to unload)
until the destructor was called, and that, not surprisingly, does the
same thing that just never calling MsgReply at all does - it makes the
program that sent the unload message get ESRCH in response to its
MsgSend. And that still not late enough to allow immediately reloading
the module. I guess we’ll stick with asking the module for it’s name
and running umount. But thanks for the destructor tip! I’m sure I’ll
find a use for that…

Murf

Sean Boudreau wrote:

io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf

How is the client finding your filter? I assume it’s
not via /dev/io-net/en_enX otherwise you could just
umount it. Could the ESRCH be caused by you ripping
out the namespace entry before the shutdown2 / destructor?

You could always send a struct sigevent up front in a
message proper which gets replied to early and MsgDeliver()
said event in your destructor at dlclose().

-seanb

John A. Murphy <murf@perftech.com> wrote:

I tried postponing the MsgReply (to the message that asked me to unload)
until the destructor was called, and that, not surprisingly, does the
same thing that just never calling MsgReply at all does - it makes the
program that sent the unload message get ESRCH in response to its
MsgSend. And that still not late enough to allow immediately reloading
the module. I guess we’ll stick with asking the module for it’s name
and running umount. But thanks for the destructor tip! I’m sure I’ll
find a use for that…

Murf

Sean Boudreau wrote:

io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:

We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf

Because we’ll be reloading a diferent version of the module; this whole
thing is part of an update procedure.

Murf

Xiaodan Tang wrote:

Hm…

If you are going to immediately reloading the module, why bother
unload it? Can’t you tell the module “re-initialize” ?

-xtang

John A. Murphy <> murf@perftech.com> > wrote in message
news:cqa318$gb1$> 1@inn.qnx.com> …

I tried postponing the MsgReply (to the message that asked me to unload)
until the destructor was called, and that, not surprisingly, does the
same thing that just never calling MsgReply at all does - it makes the
program that sent the unload message get ESRCH in response to its
MsgSend. And that still not late enough to allow immediately reloading
the module. I guess we’ll stick with asking the module for it’s name
and running umount. But thanks for the destructor tip! I’m sure I’ll
find a use for that…

Murf

Sean Boudreau wrote:


io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:


We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf

The filter creates its own resource manager (with, of course, its own
name); we send the unload message to that RM, and yes, I assume the
ESRCH is a result of ripping out the RM.

I like the MsgDeliver idea, but I think we’ll just live with what we’ve
got for awhile: we already create several statistics “files” via
resmgr_attach, and I’m just creating another one that we read to get the
/dev/io-net/en_enX name.

Thanks for the help and the great ideas!

Murf

Sean Boudreau wrote:

How is the client finding your filter? I assume it’s
not via /dev/io-net/en_enX otherwise you could just
umount it. Could the ESRCH be caused by you ripping
out the namespace entry before the shutdown2 / destructor?

You could always send a struct sigevent up front in a
message proper which gets replied to early and MsgDeliver()
said event in your destructor at dlclose().

-seanb

John A. Murphy <> murf@perftech.com> > wrote:

I tried postponing the MsgReply (to the message that asked me to unload)
until the destructor was called, and that, not surprisingly, does the
same thing that just never calling MsgReply at all does - it makes the
program that sent the unload message get ESRCH in response to its
MsgSend. And that still not late enough to allow immediately reloading
the module. I guess we’ll stick with asking the module for it’s name
and running umount. But thanks for the destructor tip! I’m sure I’ll
find a use for that…


Murf


Sean Boudreau wrote:


io-net doesn’t raise any event on unload. You might
try using gcc’s destructor attribute which will cause
the function to be called at dlclose() which is probably
as late as you’ll get:

void your_fini(void) attribute((destructor));

void
your_fini(void)
{
return;
}

-seanb

John A. Murphy <> murf@perftech.com> > wrote:


We’d like to be able to unload an io-net driver (actually a filter)
without having to use umount. We can send our filter a message that
tells it to call the io-net dereg function, and successfully unload the
module - but how can we tell when the deregistering/unloading process is
complete? We’ve tried postponing the reply to our message until
shutdown2 gets called, but that not long enough. What are our options
for determining that deregistering the io-net module is complete?


Murf