Hi,
On Sun, Feb 01, 2009 at 02:20:41AM +0000, Da Zheng wrote:
In the current implementation, the device and the node associated to
it are created when file_name_lookup() is called. when the last
client closes the virtual device, the device is destroyed along with
the node.
However, there are several problems: If the program that access the
device file is "ls", the behavior is quite strange. if "ls" accesses
a device file, for example "ls veth0" is called, eth-multiplexer
creates the node and the virtual device. since "ls" never open the
device, the device is never destroyed and the device file always
exists in the directory.
This is a bug. 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.
Another problem is that if the device is created in
file_name_lookup(), any user can create a device as long as the user
has the read permission of the directory where eth-multiplexer sits.
Well, the user can open an arbitrary dynamically-created device for
reading. I'm don't know whether this makes any sense for network
devices; but it doesn't really seem wrong...
so maybe it is better to give up the idea that the directory where
eth-multiplexer sits is the place to show the status of devices and
allow the client to operate the device file just like the normal file.
for example, before accessing the device, the client has to create a
device with "touch eth0" and afterwards, destroy it with "rm eth0".
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.