Hi,
As antrik suggested, the virtual devices of eth-multiplexer are created
dynamically. now there is an issue of management of virtual devices.
eth-multiplexer is a netfs translator and the files in the directory on
which it sits represent its virtual devices.
At the beginning, I think the virtual device should be created when a
client such as pfinet tries to access a device (the steps of accessing
the virtual device are calling file_name_lookup, device_open,
device_read or deivice_write), so the directory where eth-multiplexer
sits can somehow be the place to show the status of devices. 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.
I can postpone the creation of the virtual device. for example, it can
be created when the client calls device_open. so, when "ls" is called
with a device name, only the node is created. The next time when "ls" is
called on the directory, "ls" doesn't display the device. This behavior
is still as strange as the one above.
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. It's really not what we expect.
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". It
seems more logical.
Best regards,
Zheng Da
