From owner-freebsd-hackers Mon Dec 22 12:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25725 for hackers-outgoing; Mon, 22 Dec 1997 12:47:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25709 for ; Mon, 22 Dec 1997 12:47:08 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id NAA08975; Mon, 22 Dec 1997 13:45:05 -0700 (MST) Date: Mon, 22 Dec 1997 13:45:05 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199712222045.NAA08975@narnia.plutotech.com> To: John-Mark Gurney cc: hackers@FreeBSD.org Subject: Re: converting drivers to dynamic memory... Newsgroups: pluto.freebsd.hackers In-Reply-To: <19971218035032.46460@hydrogen.nike.efn.org> <199712181217.EAA24070@resnet.uoregon.edu> <19971218044804.38303@hydrogen.nike.efn.org> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > if you do it right, you have to touch almost the ENTIRE system... and > modify any part of the system that calls drivers.. that means changing > the tty, char, block, and net interface code... ALONG with doing the > modifications to the driver... I personally haven't looked at the > interface layer for any of that code yet, so I don't know how long it > would take to modify the whole system... You don't have to modify the entire system in order to start "doing it right". Start by making the ISA interrupt handlers take a void* instead of an int and many of the reasons device drivers have static tables goes away. Change the areas of the kernel that need "fast softc lookup" so that they don't require lookups at all (like interrupt handlers), and have the areas that you can't change (or can afford to postpone changing) use an interface that is as space efficient as possible. For instance, open and close aren't speed critical, so a linear search is fine. If you want something faster, go with a reallocating array (the SCSI code already has an implementation of this) and just do the offset. Remeber that if DEVFS is done correctly, there will be almost no reason to do any lookups at all once you have the device's vnode, so I'm guessing a linked list will be more than adequate. Don't get me wrong. I like cool algorithms, but I think they should only be used when appropriate for the task at hand. Take your B Tree code and use it in a filesystem. That would be a great application for it. > -- > John-Mark Gurney Modem/FAX: +1 541 683 6954 > Cu Networking P.O. Box 5693, 97405 > Live in Peace, destroy Micro$oft, support free software, run FreeBSD -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations ===========================================