Sebastien Roy wrote: > Peter Memishian wrote: >> You can use fassign() to bind a vnode to a newly-allocated file descriptor >> in curproc's file descriptor "table". If that doesn't do quite what you >> need, you can probably build it with falloc() and setf(). Of course, all >> of the above requires that curproc be the right process :-) To ensure that >> with STREAMS, this sort of work needs to be deferred to the stream head. > > This all seems possible (which is good). :-) I need to connect some dots > between the possibilities... > > It seems like there are a couple of ways to go forward: > > 1. have the stream head intercept the "get door fd" ioctl request and > process it entirely in that context. This could be done by calling a > function in dls to do the work of translating the door handle to a > vnode_t, call fassign(), and doing all of this with appropriate locking. > This would require a modstub for the appropriate dls function, of course. > > 2. have the ioctl processing be split between dls and the stream head, > where dls passes back an opened vnode_t as part of its ioctl > acknowledgment, and the stream head intercepts this ack and translates > that to a fd in curproc's table. This seems significantly more complex, > and I'm not sure if it's necessary. > > Is my thought process entirely off here? I think 1 could be done, and 2 > seems repulsive.
This conversation got me thinking about the DLDIOC_DOORSERVER ioctl in UV used to set the door handle in the kernel based on a passed-in door fd. By the time this ioctl is processed by dld and dls calls door_ki_lookup(fd), how do we know that "fd" is valid? The door_ki_lookup() call eventually results in a getf(fd) call, and fd is looked-up in "curproc"... If the ioctl message was deferred and put on a queue, curproc won't be dlmgmtd, right? -Seb
