bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some questions about libports and notification of ports


From: Thomas Bushnell BSG
Subject: Re: Some questions about libports and notification of ports
Date: Sat, 23 Aug 2008 09:36:56 -0700

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]