Sergiu Ivanov wrote: > 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. Yes, you are right. My mistake. I didn't realize I initialized stat in ds_device_open(). > > 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 :-) Not at all:-)
Zheng Da
