Date: Thu, 9 Aug 2012 07:37:21 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Ed Schouten <ed@80386.nl> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge Message-ID: <201208090737.21547.hselasky@c2i.net> In-Reply-To: <CAJOYFBBPBva6KUvX7dxgDRD_Y3uH=OkWx6MCAh4pUWdGXCi6dg@mail.gmail.com> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208081941.17860.hselasky@c2i.net> <CAJOYFBBPBva6KUvX7dxgDRD_Y3uH=OkWx6MCAh4pUWdGXCi6dg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 08 August 2012 22:46:28 Ed Schouten wrote: > Hi Hans, > > 2012/8/8 Hans Petter Selasky <hselasky@c2i.net>: > > Are you sure that the new softc won't be used in any callbacks when > > tty_rel_gone() is called, except for tsw_free() ? > > Yes. Otherwise you would have already seen a kernel panic. See > /sys/sys/ttydevsw.h; it has assertions on the locking. > > > It is like a drain state, where a unit is collected for free, and then > > committed to free state when the tsw_free() is called. In the [unlocked] > > time in between the unit cannot be re-used. > > How is this different from calling alloc/free directly? Why would it > need to go through this `drain' state? Because multiple TTYS can share the same ucom unit, and then stuff gets more complicated. I would then need refcounting and such to figure out when to actually free everything. This is simply not needed. I'll make a patch soonish to extend tty.h with a #define tty_set_softc() if you don't mind. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208090737.21547.hselasky>