Hello, On Tue, Dec 22, 2009 at 07:40:12PM +0800, Da Zheng wrote: > Could you tell me why initializing node status here is perferred?
The multiplexer creates nodes on any demand, whether the client intends to further use the node to create a (virtual) device or not. This means that, for instance, $ file mux/<any-name> will always find the <any-name> file. An important remark is that there is a one-to-one relationship between light nodes and devices. Now let's see what happens if one really runs the aforementioned command. When file tries to open <any-name>, the multiplexer will create a new node with <any-name> (suppose this name does not exist yet), but since file does not intend to open any devices, no lnode will be created. Then, file will io_stat the port it has got, and the multiplexer will return the stat information of its underlying node, according to the original code. I hope I managed to make it clear :-) The problem I tried to solve with this patch was that running file mux/<any-name> could return surprising results, should the multiplexer be sitting on a directory (and it is so when the multiplexer is used in conjunction with unionmount) -- any non-existent filename under mux/ would be a directory. Whether this is bad for the human typing the command at the shell is a matter of taste, but the fundamental problem was that all new nodes without devices associated had the same inode number as the node underlying the multiplexer, which confused unionmount severely (unionmount actually didn't work with multiplexer because of this inode number confusion). I don't really remember which exactly piece of code in unionmount refused to function, but the reason I remember pretty well. There is a second argument which relies mainly on the idea of keeping affiliated pieces of code together. Let me put it like this: the stat information is something relevant in libnetfs business, and less in device business. Therefore, it would be better to set up the stat information when a *node* is created, and not postpone it till the actual creation of a device. As you might have seen above, this purely intuitive reasoning has a pretty strong practical background :-) Hopefully, my (unexpectedly) overgrown E-mail has not bored you to death :-) Regards, Sergiu