Re: the virtual device management in eth-multiplexer

[olafBuddenhagen]

Hi,

On Fri, Feb 13, 2009 at 08:50:39PM +0000, Da Zheng wrote:
> olafBuddenhagen@gmx.net wrote:

>> The node should go away when it no longer has any users. When pfinet
>> (or some other real user) uses a device, it will probably discard the
>> port to the FS node (resulting from file_name_lookup() ) after the
>> device_open(), but it still has the port for the actual device, so
>> the node is in use -- the open device keeps the node around. When the
>> client closes the device, there are no references anymore, and the
>> node is destroyed.
>>
>> ls on the other hand never does device_open(). The moment it discards
>> the port from file_name_lookup(), the node isn't referenced anymore,
>> and should be destroyed immediately, without the device ever having
>> been opened.
>>   
> I don't really like this way: the node is discarded when the device is
> still open.

No, it's not!

I explicitely said that the node is *not* discarded when it is still
used, i.e. when the device it represents is still open. It is only
discarded when there are *no* users anymore, i.e. neither references to
the node itself, nor to the actual device.

>> I already considered such a possibility: allow explicitely creating
>> static devices *in addition* to the dynamic ones... Though I wonder
>> whether in this case it wouldn't be better simply to set up devnode
>> instances explicitely.
>>
>> In any case, I want to keep the dynamic nodes -- it's just much more
>> convenient.
>>   
> It depends on what you mean "dynamic". I think the current
> implementation is too "dynamic":-) If you compare my original
> implementation (the number of virtual devices  is set when the
> eth-mutliplexer is started), the way of creating the  virtual device
> explicitly with "touch" (or something else) is still very  dynamic.

Well, I think we both agree that we don't want to go back to the
original implementation, where the number of devices was fixed up front
:-) I wasn't talking about that part at all. I was talking only about
creation of the device (filesystem) nodes.

Again, I think nodes created automatically is much more convenient. If
we have pfinet and the multiplexer set up as passive translators, so
they are both launched automatically, the node for pfinet must be
accessible directly when the multiplexer starts, without explicit setup.

(Well, it is theoretically possible to set up the pfinet static
translator such that it will create the node first, doing something like

   settrans /server/socket/2 sh -c 'touch /eth/0 && exec /hurd/pfinet -i /eth/0 
...'

-- but I hope you agree that this would be rather icky, and defeat the
point of explicitely managed nodes anyways :-) )

As I already said, the only other option would be for the node setup to
be stored permanently, across multiplexer invocations -- which would be
complicated, and probably not offer much advatage over explicitely
setting up nodes with devnode...

> By the way, antrik, just let you know that I won't work on Hurd or
> join  the Friday meeting in this and next month because I am busying
> on my  master thesis now.

OK. I hope though that we can still discuss things from time to time at
least -- otherwise it is very hard to get back into the flow after two
months :-)

-antrik-