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. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- statefulness in character device drivers Dave Rufino
- Re: statefulness in character device drivers Poul-Henning Kamp
- Re: statefulness in character device drivers Alfred Perlstein
- Re: statefulness in character device driver... Dave Rufino
- Re: statefulness in character device dr... Poul-Henning Kamp
- Re: statefulness in character devi... Terry Lambert
- Re: statefulness in character ... Poul-Henning Kamp
- Re: statefulness in charac... Alfred Perlstein
- Re: statefulness in charac... Dave Rufino
- Re: statefulness in charac... Poul-Henning Kamp
- Re: statefulness in charac... Alfred Perlstein
- Re: statefulness in charac... Robert Watson
- Re: statefulness in charac... Alfred Perlstein
- Re: statefulness in charac... Terry Lambert
- Re: statefulness in charac... Robert Watson
- Re: statefulness in charac... Dave Rufino
- Re: statefulness in charac... Dave Rufino
- Re: statefulness in charac... Terry Lambert
- Re: statefulness in charac... Terry Lambert