From owner-freebsd-hackers Sun Sep 28 05:31:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA29039 for hackers-outgoing; Sun, 28 Sep 1997 05:31:24 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA29029 for ; Sun, 28 Sep 1997 05:31:08 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id FAA00308; Sun, 28 Sep 1997 05:28:55 -0700 (PDT) Message-ID: <19970928052854.58152@hydrogen.nike.efn.org> Date: Sun, 28 Sep 1997 05:28:54 -0700 From: John-Mark Gurney To: FreeBSD Hackers Subject: preliminary design of new bus/device system for FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I've been looking at improving the bus/device design in freebsd to handle better conflicts in resources and making the design more expandable... right now I've put what I've writen down so far at http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html... I'm looking at using extent for resource management.. but also extending it so that we can include a tag so we know which device is the conflicting device... at the same time, I plan on improving extent so that it will coalesce objects into a sublist so that inserting a new extent will be faster, but still keep all extents seperate... Right now this bus design depends upon the creation of a processor bus that will initally create the resources and start probing... do we have anybody that is knowledgable about EISA/vlb design that can inform me (in private mail) on the specifics on how they hang off the processor bus along with the ISA bus? comments? suggestions? improvements? (the struct/memeber names are open to sugestion, just needed something now :) ) right now the only thing I'm questioning is possibly adding a busid feild to struct gendevice to make sure we don't call a probe/attach/etc on the wrong device... but I'm not sure that really should be neccessary... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD