svn commit: r184208 - head/sys/dev/uart

Ed Schouten ed at 80386.nl
Fri Oct 24 15:28:20 UTC 2008


* John Baldwin <jhb at freebsd.org> wrote:
> On Friday 24 October 2008 12:50:12 am Ed Schouten wrote:
> > * John Baldwin <jhb at freebsd.org> 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 <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20081024/7a6c79a4/attachment.pgp


More information about the svn-src-all mailing list