From owner-freebsd-arch@FreeBSD.ORG Thu Jul 3 21:42:00 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 B610F1065670 for ; Thu, 3 Jul 2008 21:42:00 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1878FC0C for ; Thu, 3 Jul 2008 21:42:00 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m63L9QJF080937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 14:09:27 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <486D4006.2050303@freebsd.org> Date: Thu, 03 Jul 2008 14:09:26 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Ed Schouten References: <20080702190901.GS14567@hoeg.nl> <20080703193406.GS29380@server.vk2pj.dyndns.org> <20080703205220.GW14567@hoeg.nl> In-Reply-To: <20080703205220.GW14567@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Current , FreeBSD Arch Subject: Re: MPSAFE TTY schedule [uart vs sio] 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, 03 Jul 2008 21:42:00 -0000 Ed Schouten wrote: > Hello Peter, > > * Peter Jeremy wrote: > >> 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? >> > > PTY's are deallocated when unused, which means the PTY number is reused > when possible. We still enfore the 1000 PTY limit, because utmp(5) only > supports line names of eight bytes long ("pts/999\0"). > > >>> - 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. >> > > Well, even though I'd rather let other people assess me, I think I've > been very proactive so far. As you can see, I sent my email to the list > two days ago. In those two days I've fixed both umodem(4) and uftdi(4) > to work with the new TTY layer again. > > >>> 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. >> > > Well, sio(4) isn't impossible to port to the new TTY layer, but the > first thing I noticed when I was hacking on the TTY layer during my > internship, was that the uart(4) code was so easy to read, I only had to > alter a single 396 line C file containing all the TTY interaction, while > the sio(4) was somewhat (tenfold) more complex. > > But I just got told sio(4) is required for pc98, because uart(4) is not > supported there. This means I'll seriously consider porting sio(4) one > of these days. It's no biggie, even though I think someone could better > take the effort to extend uart(4). > I would suggest first investigating how difficult it is to port uart to pc98. Given that we're broadening our platform support having a single serial driver seems preferable. > The same with dcons(4). Even though I don't have any hardware to test it > personally, I'll try to make sure we'll get it working in time. > I believe dcons is important and there are many people that can pitch in on this driver so I'm less worried about it. FWIW I'm 100% behind you on moving this stuff forward. This is a large project and you cannot be expected to do it by yourself. In the case of platform-specific requirements (like pc98) where you won't have access to equipment I think it's fair to request platform maintainers help. > >> 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. >> > > So let us take a look at the list again: > > >> 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). >> > > Removing the drivers which have been fixed, or will be fixed in time: > > >> cy(4), digi(4), ubser(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), >> rc(4), si(4). >> > > After I've committed the new TTY layer, I'm going to extend its design, > so we can have hooks again, similar to the old line discipline idea. > This has already been discussed. I'm also planning on reviving drivers > like nmdm(4) and snp(4) by then. This means we've only got these > drivers left: > > >> cy(4), digi(4), rp(4), rc(4), si(4). >> > > Who actually owns one of these devices? If you do, please contact me. If > I didn't make myself clear enough: I *am* willing to (assist in > porting|port) these drivers. > > digi is perhaps most important in this list but I think you should expect other folks to help. Sam