From owner-freebsd-hackers Thu Dec 18 11:30:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15655 for hackers-outgoing; Thu, 18 Dec 1997 11:30:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15636 for ; Thu, 18 Dec 1997 11:30:03 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA06766; Thu, 18 Dec 1997 12:29:59 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd006752; Thu Dec 18 12:29:53 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA11029; Thu, 18 Dec 1997 12:29:51 -0700 (MST) From: Terry Lambert Message-Id: <199712181929.MAA11029@usr05.primenet.com> Subject: Re: converting drivers to dynamic memory... To: gurney_j@resnet.uoregon.edu Date: Thu, 18 Dec 1997 19:29:51 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971218035032.46460@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 03:50:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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 > initalially easier to do. I have B-tree code already writen, (I was > writing it for another use in my bus/device code) which we could use > to access this information. (Some people will say, why not linked > lists, and then I will say, sio, I have 12 ports on my term server, > plus you get better data density) I think this will be a problem, since Julian intends to make majors and minors "go away". This is a very good thing, but it will require you use your first apprach. I don't think the change should be all that difficult. The main issue is how to convert one driver at a time. I think this can be done with common glue code on top to make them look like the old drivers for the near term. > On another note, how do people feel about more complex data structures > becoming standard parts of the kernel. I think there are a number of > places that using a more complex data structure would be a big win. > I have code for both Fibonacci Heaps and B-tree's that just need some > cleaning up to be generally useful. The code bloat would actually be > quite small. The Fib heap code is under 3k, and the B-tree code is > 4736 bytes, but this includes some debuging code (printing tree and > checking that the tree is in order). I would like to see the Fibonacci code in there... the B-tree code, I don't know; is there a plan to convert the routing code? 8-) 8-) 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.