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-head/attachments/20081024/7a6c79a4/attachment.pgp
More information about the svn-src-head
mailing list