From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 08:43:34 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 5ADC71065673; Mon, 7 Jul 2008 08:43:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 2457D8FC14; Mon, 7 Jul 2008 08:43:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m63JYbSg017475; Fri, 4 Jul 2008 05:34:37 +1000 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m63JY7mu006019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2008 05:34:09 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m63JY77W031093; Fri, 4 Jul 2008 05:34:07 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m63JY6ow031092; Fri, 4 Jul 2008 05:34:07 +1000 (EST) (envelope-from peter) Date: Fri, 4 Jul 2008 05:34:06 +1000 From: Peter Jeremy To: Ed Schouten Message-ID: <20080703193406.GS29380@server.vk2pj.dyndns.org> References: <20080702190901.GS14567@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5L6AZ1aJH5mDrqCQ" Content-Disposition: inline In-Reply-To: <20080702190901.GS14567@hoeg.nl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Arch , FreeBSD Current Subject: Re: MPSAFE TTY schedule 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: Mon, 07 Jul 2008 08:43:34 -0000 --5L6AZ1aJH5mDrqCQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jul-02 21:09:01 +0200, Ed Schouten wrote: >+ The new pseudo-terminal driver is capable of garbage collecting unused > PTY's. Because PTY's are never recycled, they are a lot more robust > (they are always initialized the same, no need to revoke() them before > usage, etc). When you say 'never recycled', does this include the PTY number? If so, long running busy systems are going to get some fairly large numbers. When will the PTY number wrap? What is the impact on tools (eg ps, w) that assume they can represent a PTY in a small number of digits? What about utmp(5) which uses PTY number in the index? >- Not all drivers have been ported to the new TTY layer yet. These > drivers still need to be ported: sio(4), cy(4), digi(4), ubser(4), > uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), rc(4), si(4), > umodem(4), dcons(4). > >Even though drivers are very important to have, I am convinced we can >get these working not long after the code as been integrated. ... > If you really care about one of these drivers, >please port it to the new TTY layer as soon as possible! IMHO, this is not a reasonable approach: "Hi everyone. I'm going to break infrastructure that a whole bunch of drivers depend on. If you don't fix your drivers in the next few weeks then I'll disconnect them". Either you need to provide compatibility shims (possibly temporary and not MPSAFE) or you need to be far more pro-active in assisting with porting existing consumers of the TTY layer. >TTY layer into our kernel. I would really appreciate it if I could get >this code in before the end of the summer break, because I've got heaps >of spare time to fix any problems then. That's all very nice but what about the maintainers of all the other drivers that you are impacting? > sio(4) has not been ported to the new TTY layer and is very hard > to do so. This is the only mention of how much effort is involved in porting a driver to use the MPSAFE TTY layer and "very hard" is not a good start. I can't quickly find any documentation on how to go about porting an existing driver - definitely there are no section 9 man pages describing the new API in your patchset. IMHO, if you can't commit fixed drivers along with the MPSAFE TTY layer, a more reasonable schedule is to replace the existing TTY layer with an MPSAFE TTY layer that includes compatibility shims. If the shims make things non-MPSAFE (which is likely) then warn that they will be going away in (say) six months. This gives developers a more reasonable timeframe in which to update, as well as working drivers whilst they adapt them. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --5L6AZ1aJH5mDrqCQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhtKa4ACgkQ/opHv/APuIcUoQCgvbCXHvJ4XbBUfRb9scImg/D7 dmMAoIHMk6BMCiTO5ZVyVuLFEIZpEhFX =2AQg -----END PGP SIGNATURE----- --5L6AZ1aJH5mDrqCQ--