From owner-freebsd-arch@FreeBSD.ORG Thu Mar 13 14:53:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F321065670 for ; Thu, 13 Mar 2008 14:53:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2348FC15 for ; Thu, 13 Mar 2008 14:53:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so4085545fka.11 for ; Thu, 13 Mar 2008 07:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=9l5zCdBHDeBRsdJ3CEnWMvKiABKfwJVi/E0GqdE9SyI=; b=xBv4hqW68xOPQk7nKGtfNrZf7m1P18Zr0u4HX+/Z1AVA41lz3ZZn6TwY8pkt6xqWaVEhnQyUK0qx5Lm3p/HLwFwUXN5/51VH/s3SQuaaZ7Q+dk3xDQ6D/cWcTnWbh0Wn4MFHveAjC+xQ2tAf1lduZSXGtCx0x90xqdtQGhQBXTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=o16UPuV/qNub4jl2/HtcsNJcphlMPtx2tt4r40bg/+ext9ecc04KkiVNr1Gc7ztYWqVJeWLJzpmJU6dfmbfaERqFkZYTARtr1MPYx09pit94Q/7vMVLkCWYlN5A/plqq9FTCd/xW7g4XmEn6lZp3InlGHpMOQ0ADjGGBr7SjYQg= Received: by 10.82.127.14 with SMTP id z14mr23371281buc.3.1205419994230; Thu, 13 Mar 2008 07:53:14 -0700 (PDT) Received: by 10.86.30.17 with HTTP; Thu, 13 Mar 2008 07:53:14 -0700 (PDT) Message-ID: <3bbf2fe10803130753p623867d8j3cbb65e0c78a2164@mail.gmail.com> Date: Thu, 13 Mar 2008 15:53:14 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Ed Schouten" In-Reply-To: <20080313135035.GB80576@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080313135035.GB80576@hoeg.nl> X-Google-Sender-Auth: 90bab4486d957c24 Cc: FreeBSD Arch Subject: Re: New TTY layer: condvar(9) and Giant X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 14:53:17 -0000 2008/3/13, Ed Schouten : > 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