From owner-freebsd-current@FreeBSD.ORG Fri Mar 4 20:10:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1EF2D16A4CE; Fri, 4 Mar 2005 20:10:30 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j24KATTk076699; Fri, 4 Mar 2005 15:10:29 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j24KAL5V076693; Fri, 4 Mar 2005 15:10:21 -0500 (EST) (envelope-from green) Date: Fri, 4 Mar 2005 15:10:21 -0500 From: Brian Fundakowski Feldman To: Sean McNeil Message-ID: <20050304201020.GH6011@green.homeunix.org> References: <20050303021608.1BB663284@mx2.synetsystems.com> <20050304144415.GE6011@green.homeunix.org> <1109960265.7962.4.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109960265.7962.4.camel@server.mcneil.com> User-Agent: Mutt/1.5.6i 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 20:10:30 -0000 On Fri, Mar 04, 2005 at 10:17:45AM -0800, Sean McNeil wrote: > 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. > */ > ... Whether you want to call libc a module or not, sure, I'll fix it ;) It indeed should be pulled out. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\