Date: Sat, 08 Dec 2001 11:51:32 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dave Rufino <dr263@hermes.cam.ac.uk>, Alfred Perlstein <bright@mu.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: statefulness in character device drivers Message-ID: <47779.1007808692@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 08 Dec 2001 02:20:50 PST." <3C11E982.F50F2353@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3C11E982.F50F2353@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> >> Most likely he means a per-open(2) opaque datum that is kept in >> >> struct file and passed to the underlying routines. >> > >> >Sorry, unbelievably bad at explaining myself. Per-open data is what i >> >meant. The reason I'm interested is it would make a full nvidia driver >> >port quite a bit easier. >> >> Sorry, I know of no current plans which adress this. >> >> The issue is non-trivial to fix because we currently don't pass >> dup(2) events through the vnode layer. > >Are you sure this is even necessary? > >They are talking about "per-open", not "per-fd-instance" data, >which could easily exclude dup, dup2, and fcntl(f_DUPFD). If you don't include dup/dup2/fnctl in your accounting, you can only reliably tell "first open", "another open", "some close" and "final close". You an modulate this with the pid, but you still have no idea what is going on in any amount of detail. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47779.1007808692>