From owner-freebsd-current  Thu Feb 23 08:45:33 1995
Return-Path: current-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06545 for current-outgoing; Thu, 23 Feb 1995 08:45:33 -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 IAA06538 for <current@FreeBSD.org>; Thu, 23 Feb 1995 08:45:25 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA01977; Fri, 24 Feb 1995 03:39:12 +1100
Date: Fri, 24 Feb 1995 03:39:12 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199502231639.DAA01977@godzilla.zeta.org.au>
To: pst@shockwave.com, ugen@netvision.net.il
Subject: Re: snp(4)/watch(8) code review comments
Cc: current@FreeBSD.org
Sender: current-owner@FreeBSD.org
Precedence: bulk

>I want to add a new field to cdevsw[] that is a vector to a function in the
>driver that will return a pointer to the right struct tty element given a
>major/minor number.  This sort of decision needs to be done locally to the
>driver to account for things like major/minor number masking (e.g. cua0 vs
>ttyd1 in the sio driver).

>Does anyone have an objection to my adding this new field?  It will simply
>be NULL for any device not supporting that vector and all invocations of it
>test for non-NULL first before calling.

A good idea...except I'd like to remove the tty struct in the cdevsw
completely.  It is currently only used (officially) by ttselect() and
could easily be replaced by a new arg to ttselect().  Having it in the
struct forces all tty drivers to allocate in the same way as well as
special select routines to clip the minor numbers.

A function field would be flexible enough to handle these problems nicely.
Do you need to call it for possibly-non-open devices?  This would inhibit
really simple implementations such as `table[minor(dev) & MASK]->tty'
(the table can only be guaranteed to be initialized for open devs).

Bruce