Date: Thu, 13 Mar 2008 15:53:14 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Ed Schouten" <ed@80386.nl> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: New TTY layer: condvar(9) and Giant Message-ID: <3bbf2fe10803130753p623867d8j3cbb65e0c78a2164@mail.gmail.com> In-Reply-To: <20080313135035.GB80576@hoeg.nl> References: <20080313135035.GB80576@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/3/13, Ed Schouten <ed@80386.nl>: > Hello everyone, > > Almost a month ago I started working on my assignment for my internship, > to reimplement a new TTY layer that fixes a lot of architectural > problems. So far, things are going quite fast: > > - I've already implemented a basic TTY layer, which has support for > canonical and non-canonical mode. It still misses important features > including flow control, but it seems to work quite good. Unlike the > old layer, it doesn't buffer data as much, which should hopefully mean > it's a bit faster. > - I'm using a new PTY driver called pts(4). It works quite good, but it > misses the compatibility bits, which we'll need to have to support > older FreeBSD or Linux binaries. > - Some of you may have read I'm working on syscons now. I've got syscons > working with the new TTY layer; I'm typing this message through > syscons. ;-) > > A lot of drivers that are used by the old TTY layer aren't mpsafe yet. > Of course, I'm willing to fix this, but this cannot be done in the > nearby future. This is why the new TTY layer should still allow TTY's to > be run under Giant. > > In my initial implementation, each TTY device had its own mutex. In > theory, this is great. The PTY driver already uses this and it works > fine. There will be a lot of drivers, however, that want to use a > per-class mutex to lock all related TTY devices down at once (i.e. > syscons, which allocates 16 virtual TTY's). This is why I introduced a > per-class lock. When set to Giant, all TTY instances will lock down the > Giant lock when entering the TTY layer. > > Unfortunately, I discovered condvar(9) can't properly unlock/lock the > Giant, which causes the system to panic. The condvar routines already > call DROP_GIANT before unlocking the lock itself. I don't think we should allow this. Giant is alredy too hidden inside other locking primitives creating a lot of mis-understanding, mis-conceptions and mis-assumptions. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10803130753p623867d8j3cbb65e0c78a2164>