> >> >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.
For this class of problems, you don't care. Inheritance is fine; what
you're almost doing is cloning within the driver; on each open you cons a
new sub-softc and attach it to the open instance.
I think this is quite desirable.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
