From owner-freebsd-current Tue Feb 4 18:44:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19950 for current-outgoing; Tue, 4 Feb 1997 18:44:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA19917; Tue, 4 Feb 1997 18:44:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA13922; Tue, 4 Feb 1997 19:40:36 -0700 From: Terry Lambert Message-Id: <199702050240.TAA13922@phaeton.artisoft.com> Subject: Re: device driver open semantics... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 4 Feb 1997 19:40:36 -0700 (MST) Cc: terry@lambert.org, bakul@torrentnet.com, phk@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199702030259.NAA02097@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 3, 97 01:29:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I disagree. The driver should not depend on the system doing > > reference counting for it. Mark me down as being "for" calling > > the close once per close. Reference counting is a very simple > > modification to make, and there are great benefits to things like > > CDROM writers that can also function as readers, non-bidirectional > > sound cards, etc., etc.. > > 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? What would be the real effect? I suspect that you could put a flag in the device flags that says "call close once instead of on each close and count outside the device" if you really wanted to. You could go the other way, but it shouldn't be the default because it provides less information. An AND + BNZ is cheap... and you can more han make back the clock cycles for that by murdering the absolutely *stupid* "struct fileops" anyway. Plus there is pleanty of room for logic reordering to reduce the number of compares, and so on, in the success cases (which should be the default code path, and therefore the shortest). In your average case, close() isn't called during fork/exec. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.