Date: Tue, 4 Feb 1997 19:40:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, bakul@torrentnet.com, phk@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: device driver open semantics... Message-ID: <199702050240.TAA13922@phaeton.artisoft.com> In-Reply-To: <199702030259.NAA02097@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 3, 97 01:29:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702050240.TAA13922>