Date: Sat, 8 Dec 2001 11:45:18 +0000 (GMT) From: Dave Rufino <dr263@hermes.cam.ac.uk> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <bright@mu.org>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: statefulness in character device drivers Message-ID: <Pine.SOL.4.33.0112081142390.9831-100000@green.csi.cam.ac.uk> In-Reply-To: <49036.1007811221@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Dec 2001, Poul-Henning Kamp wrote: > In message <Pine.SOL.4.33.0112081058220.29494-100000@orange.csi.cam.ac.uk>, Dav > e Rufino writes: > > > > > >On Sat, 8 Dec 2001, Poul-Henning Kamp wrote: > > > >> >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. > > > >Speaking for myself, first open and final close would be all I need for > >the nvidia driver - though i'm sure tracking dup/dup2/fcntl would be > >preferable in the general case. > > first open/last close has been the UNIX way for decades... Oops, I meant it shouldn't be necessary to be notified of dup()ed fds in the device driver, which is probably not what you were driving at anyway :/ David 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?Pine.SOL.4.33.0112081142390.9831-100000>