From owner-freebsd-current Thu Feb 23 20:00:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA24520 for current-outgoing; Thu, 23 Feb 1995 20:00:55 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA24513 for ; Thu, 23 Feb 1995 20:00:45 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA13601; Fri, 24 Feb 1995 14:55:04 +1100 Date: Fri, 24 Feb 1995 14:55:04 +1100 From: Bruce Evans Message-Id: <199502240355.OAA13601@godzilla.zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Subject: Re: snp(4)/watch(8) code review comments Cc: current@FreeBSD.org, ugen@netvision.net.il Sender: current-owner@FreeBSD.org Precedence: bulk >I seem to recall that BSDI just passes in a pointer to the desired tty struct >entry. In this case, every driver would require a wrapper calling potentially >a common ttselect routine. All the current drives except the pty and console drivers already have a wrapper. >I have no problem with making this change if there are no objections, ttselect >gets replaced by > int ttyselect (struct tty *, int flag, struct proc *) >(note new name...since this is what BSDI calls the identical function). >It would be reasonable to discuss this with the appropriate NetBSD folks too >since it would good for the driver writers if we both support this change. Which NetBSD mailing list is appropriate? >Any objections to: > struct tty *xxxdevtotty (dev_t dev) >Returns a pointer to the right entry or NULL if entry not >available/initialized. OK. > Do you need to call it for possibly-non-open devices? >... >Do you mean open/initialized drivers or open devices? I could easily see >the case where one is mallocing "struct tty" as required (say for example >a pty driver without stupid limits). This would be a vast improvement >over the current hard coded size of the pty entry array. I mean open devices. I'd like to be able to free the tty structs when the device is closed. The session reference to the tty still stops this. References by the snoop device might have to stop it too. Bruce