From owner-freebsd-current@FreeBSD.ORG Fri Mar 4 18:17:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8905A16A4CE; Fri, 4 Mar 2005 18:17:46 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FFA243D1D; Fri, 4 Mar 2005 18:17:46 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id E0613F3C1E; Fri, 4 Mar 2005 10:17:45 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05987-10; Fri, 4 Mar 2005 10:17:45 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 50A63F3C1C; Fri, 4 Mar 2005 10:17:45 -0800 (PST) From: Sean McNeil To: Brian Fundakowski Feldman In-Reply-To: <20050304144415.GE6011@green.homeunix.org> References: <20050303021608.1BB663284@mx2.synetsystems.com> <20050304144415.GE6011@green.homeunix.org> Content-Type: text/plain Date: Fri, 04 Mar 2005 10:17:45 -0800 Message-Id: <1109960265.7962.4.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Richard Todd cc: freebsd-current@freebsd.org Subject: Re: Recent major number changes on ptys break grantpt() and friends in lib/libc/stdlib/grantpt.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:17:46 -0000 On Fri, 2005-03-04 at 09:44 -0500, Brian Fundakowski Feldman wrote: > On Wed, Mar 02, 2005 at 07:39:09PM -0600, Richard Todd wrote: > > I managed to work around the immediate problem and stop my script from > > complaining by bludgeoning the p5-IO-Tty Makefile.PL with a blunt instrument > > to make it think this system didn't support grantpt() etc. (causing the module > > to fall back to other methods of dealing with ptys). The proper fix for > > grantpt.c is less clear, though. Changing it to figure the proper pty > > major number by stating a known pty node (say, /dev/ptyp0) would work, but from > > what I understand that's going to break when phk commits his forthcoming > > patch which will make the whole concept of major numbers go away. Any ideas? > > Just remove all knowledge of device majors/minors from the module. Why > should it care? All it could possibly do with that information is > sanity-check that the device name (that it already knows how to generate) > isn't somehow replaced with something else. This isn't a module, this is a libc function. It seems like you have some ideas how this can be fixed, so does that mean you are volunteering to do so? Or does someone else already claim responsibility for this part of libc? You are correct about it being a sanity check. The comment makes that clear. Worst case it could just be pulled out: /* * ISPTM(x) returns 0 for struct stat x if x is not a pty master. * The bounds checking may be unnecessary but it does eliminate doubt. */ ... Cheers, Sean