Date: Thu, 23 Feb 1995 09:40:17 -0800 From: Paul Traina <pst@shockwave.com> To: Bruce Evans <bde@zeta.org.au> Cc: ugen@netvision.net.il, current@FreeBSD.org Subject: Re: snp(4)/watch(8) code review comments Message-ID: <199502231740.JAA16718@precipice.Shockwave.COM> In-Reply-To: Your message of "Fri, 24 Feb 1995 03:39:12 %2B1100." <199502231639.DAA01977@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Bruce Evans <bde@zeta.org.au> Subject: Re: snp(4)/watch(8) code review comments >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. 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. 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. A function field would be flexible enough to handle these problems nicely. Any objections to: struct tty *xxxdevtotty (dev_t dev) Returns a pointer to the right entry or NULL if entry not available/initialized. Do you need to call it for possibly-non-open devices? It should be robust enough to call for non-open devices and return an error indication if there's a problem. The $25k question is should we add a boolean parameter that would cause a tty entry to be malloced, initialized, and linked in if one doesn't already exist? If so, then the driver can use the same routine in its init code. Maybe later, seems like too much of a mess for this week. :-) 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). 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502231740.JAA16718>