Date: Tue, 4 Feb 1997 20:31:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bakul@torrentnet.com, phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: device driver open semantics... Message-ID: <199702050331.UAA14117@phaeton.artisoft.com> In-Reply-To: <199702050247.NAA19221@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 5, 97 01:17:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This would do horrible things to the fork/exec timings. 8( > > > > ... well, the exec() timings anyway, if the close_on_exec was set > > on the fd open on the device, since fork wouldn't close(), > > but must already open(), right? > > Ah, actually it'd be fork() that would suffer, as you'd have to go > and call open() for every device that it had open. And it's not the > calling that would cost, but scanning the open fds to see whether it > had to be called for each. Hmmm... I think I disagree with this. I think the act of obtaining a vnode is an 'open' and the act of releasing it as 'close'. I think a fork/exec would simply create an alias refernce to an existing vnode, not get a new one (I don't see how it could, without saving the lookup path, or without a "reopen" hack). This also goes for a device vnode that is already in the directory lookup cache, since it will get a cache hit and never call the real open, as well. The real close only gets called on the last vnode reference going away... the vnode is in the system open file table, and there are multiple processes with per process open file table references to the same system open file table entry. A relookup, of course, originates a system open file table entry, and so would initiate an alias entry at the system open file table entry... but still, only one open. But a real open is called to get the vnode, even if it is an alias which is returned. So you can refernce count the flags, which only occur on a real open on a vnode. Each alias (reference count) on the vnode created this way has a seperate "open" device call to instance the mode flags for the alias instance. What was being discussed was changing the device close to take a parameter... then calling it once per alias instance destruction (when it is removed from the system open file table). The device would reference count actual calls to the open/close. Because the fork/exec create a vnode alias without referncing the open call (mostly because they create a per process open file table reference for a system open file table entry), no open/close is called. The open/close is only called on manipulation of the system open file table entry. System open file table entry aliases for the vnode are inherently impossible to coelesce, because of differening flags values which need to be compared on read/write (and should be tracked there). For flags which are identical, the entries can be coelesced... but this would probably be done at open-time, and would cause the close method to be called, but add the reference counts resulting from the per process open file tables to the system open file table entry being coelesced to... and then the close method would be called for the flags value destroying both the reference count for, and the duplicate system open file table entry reference to, the vnode in question. So really, it will have no effect on fork/exec timings after the initial setup for the series of fork/exec which inherit the per process open file table state. The difference is between a user space open instance, and a device "open" instance, which is really only a reference, not really an open. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702050331.UAA14117>