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. > 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. Well, creating the device just means creating some internal data structures, right? So doing it at the time of node creation, or only for the time where the device is actually open, seems an implementation detail really... Having the distinction between nodes and devices more explicit might perhaps make the implementation clearer; I can't tell. The only difference it would make to the outside world is that if someone still holds a port to the node, while the actual device is closed, any status data would be kept, and would be preserved when someone opens the device again before the port is dropped. I'm not sure whether this case is very relevant, and what behaviour would be more desirable... > 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. Well, it's certainly a bit unusual that you can ls an arbitrary name and it will work, but the name doesn't show up in a directory listing... But I don't think it will cause any serious problems. It's certainly *not* as strange as the present (buggy) behaviour. > 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. Without dynamic devices, we would need a way to store the device configuration permanently, so that we don't need to explicitely set it up before launching pfinet. This is possible, but I'm not sure whether it is really desirable... I'm more and more inclined towards factoring the node management out of eth-multiplexer, and handling it by some external means: This would give us much more flexibility here. -antrik-
