From owner-freebsd-hackers Thu Dec 18 05:41:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA18766 for hackers-outgoing; Thu, 18 Dec 1997 05:41:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp8.portal.net.au [202.12.71.108]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18759 for ; Thu, 18 Dec 1997 05:40:56 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id AAA00353; Fri, 19 Dec 1997 00:05:19 +1030 (CST) Message-Id: <199712181335.AAA00353@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: FreeBSD Hackers Subject: Re: converting drivers to dynamic memory... In-reply-to: Your message of "Thu, 18 Dec 1997 03:50:32 -0800." <19971218035032.46460@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Dec 1997 00:05:18 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > well... one of the things that will need to be done in preperation > for moving to a dynamic system which will be required by the bus/device > code, we will need to eliminate ALL static datat that depends upon > Ndevice to size itself. This is traditionally the softc array (or pointer array), and not much else. > There are two ways that we can fix this problem. The first (and > technically the best) is to be extend many of the calling functions > to pass around a void * pointer that will point to that devices > resources. Though this is technically best, it will require that > most major parts of the kernel be significantly changes. > > The second solution is to continue to use the major/minor code scheme, > but use a binary tree or a B-tree to obtain the private data. This > can cause a performance impact if we use if for things like the sio, > but this can be fixed by changing the interrupt interface. > > I think that we should go with the second solution as it will be I do not. And you have missed the most obvious (and most widely discussed) solution, which various people are already working on. Understand that when DEVFS hits us properly (and all that's holding it up now are buggy consumers), dev_t will cease to be what it currently is. The dev_t argument is present everywhere that you want to reference your device softc. So, when you create your DEVFS node, one of the objects you pass in will be stored in the device token that's passed back on all your devices references. In the normal case, this will be a pointer to your softc, which you can retrieve in the normal fashion. There will be no major/minor numbers soon. mike "Real hackers run -current with DEVFS and SLICE on their laptops"