"Vladimir B. Grebenschikov" wrote: > As far as I understand _key_ word is "open", each new instance appears > on open(), but fork() and dup() only do regular work. dup'ed or fork'ed > descriptors will be same from driver's point of view, but each new > open() will create new instance.
No. The problem is that if you open the same thing N times, you will get N references to the single vnode of the thing. For devices, it's possible to kludge this, so that the device gives you a different vnode for each instance; however, the close is not sufficiently tracked unless you also give back a different minor number for each open instance. The problem is that there is no per reference instance information that is stored with the vnode and given to the device, as a context, with each operation, other tha the device context itself. So the only way to do this is a different minor number, so that the device is capable of maintaining its own per open instance information. It's also really questionable what the correct course of action for the fork/dup/dup2 code is. Consider the case of a program that intentionally forks, so that one process can read from the /etc/tty and write to the device, while the other can do the opposite (this is how the original "cu" program worked). On top of this, add descriptor passing. This breaks down to: are you creating a new open instance, or are you manipulating a reference to an existing open instance? Pushing this information over the "struct fileops" barrier is not a very easy thing to do. It would require reorganization of a lot of code. While this code is in *dire* need of reorganization, when you are done, if you can't answer the question about whether you are doing a "dup" or passing a reference to a single instance when you pass an FD between processes... well... you're in a bit of a jam. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
