Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Sat, 2008-08-23 at 13:25 +0200, Da Zheng wrote:
> I have to make sure every ports has been destroyed so when the 
> translator exits, it can check if there are still users.

Huh?  When the translator exits, all the ports are going to be destroyed
anyway.

> OK, maybe I should make the things more clear.
> I'm writing a filter translator called eth-filter whose function is to 
> forward and filter the packet between the network device and the user 
> program such as pfinet,
> so eth-filter needs to build a "pipe" for them.
> eth-filter needs two ports, so it can get the packet from the user 
> program and the network device.

That's the task.

> The user program can exit, it's quite normal, but the device cannot.
> so the network device always holds the send right to the port of 
> eth-filter.

Yes, fine.

> Let's see what the result will be. The device keeps sending the packet 
> to the eth-filter and eth-filter should forward it to the user program.
> But the user program doesn't exit any more.

> In this case, eth-filter must tell the device: the user program doesn't 
> exist, so please don't send me any packets that is to the user program.

Excellent.  *That's* the right way to think.

So you have two ports.  When the one going to the user is destroyed, you
need to tell the device not to send any more packets.

And we have a way to do that: by calling device_set_filter, and clearing
out the port there.  The driver will then drop its send right for you.

> The only way I can find is to destroy the port for the device. I think 
> it's the way of operating the network device. device_close() doesn't work.
> After the port is destroyed, the device will find the send right is a 
> dead name and stop sending the packets (that should be to the user 
> program) to eth-filter.

The reason device_close doesn't work is because the device_t is totally
separate from the port installed with device_set_filter. 

> It's exactly why I think it's difficult to operate.
> ports_get_right() can be called several times. Let's think about the 
> sequence as follow (it's not in the same function):
> struct port_info *port;
> ports_create_port(..., &port);
> ...
> ports_get_right(port);
> ...
> ports_get_right(port);
> ...
> ports_get_right(port);
> ...
> When should I call ports_port_deref()? after the first time of calling 
> ports_get_right()? or after the last time?

You don't call ports_port_deref because of ports_get_right *AT ALL*.
You call it because the variable PORT holds a reference, and *that*
reference is going away.  The call to ports_port_deref has *nothing* to
do with ports_get_right at all.  It is because the variable PORT holds a
reference, and that's a stack variable which is going to be deallocated
once this function returns.

Thomas