Date: Fri, 4 Jul 2008 05:34:06 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Ed Schouten <ed@80386.nl> Cc: FreeBSD Arch <arch@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: MPSAFE TTY schedule Message-ID: <20080703193406.GS29380@server.vk2pj.dyndns.org> In-Reply-To: <20080702190901.GS14567@hoeg.nl> References: <20080702190901.GS14567@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ed@80386.nl> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080703193406.GS29380>