* John Baldwin <[EMAIL PROTECTED]> wrote:
> On Friday 24 October 2008 12:50:12 am Ed Schouten wrote:
> > * John Baldwin <[EMAIL PROTECTED]> wrote:
> > > Perhaps have tty drivers sleep in detach until the tty is completely 
> > > gone?  
> > > Either that or free the unit number in the tty layer when the tty is 
> > > abandoned.
> > 
> > Well, I could add a routine to the TTY layer that does that. The reason
> > why the TTY layer is a little `lazy' with deallocating TTY unit numbers,
> > is because I want to be absolutely sure processes agree they do not use
> > the TTY (device name) anymore.
> > 
> > I'll see if I can add a sleepable tty_gone() routine one of these days.
> 
> I think what you want then is for the detach() routines to block until the 
> tty 
> is fully drained.  This is similar to what we do for other places 
> (ether_ifdetach() is supposed to sleep until the ifnet is completely 
> unreferenced from userland for example (it may not fully ensure this yet, but 
> that is the way the driver should use the API, the driver can't possibly 
> close that sort of race in its own code).
> 
> Actually, detach() _needs_ to block because when you kldunload a driver, once 
> detach() returns the code segment for that module can be unmapped.  If there 
> are threads in that driver's tty routines still then you can get kernel page 
> faults.

Yes. That's true, but the reason why I implemented the way it is right
now, is because the current behaviour is *very* pleasant to implement
things like pts(4). There is no blocking inside the close() path of a
pseudo-terminal master device (which makes no sense) and the tsw_free
routine just returns the unit number back to the unrhdr (see
ptsdrv_free() in sys/kern/tty_pts.c).

But as I said, I will add a routine which does this. Apart from that,
drivers could already implement the sleeping themselves, by just
sleeping on a conditional variable until tsw_free() has been called. But
it's easier to provide a proper routine to do this.

-- 
 Ed Schouten <[EMAIL PROTECTED]>
 WWW: http://80386.nl/

Attachment: pgpWeDZ57PSFN.pgp
Description: PGP signature

Reply via email to