From owner-freebsd-hackers Fri Sep 12 01:49:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA17922 for hackers-outgoing; Fri, 12 Sep 1997 01:49:59 -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 BAA17907 for ; Fri, 12 Sep 1997 01:49:52 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA02163; Fri, 12 Sep 1997 01:45:38 -0700 (PDT) Message-ID: <19970912014538.17294@hydrogen.nike.efn.org> Date: Fri, 12 Sep 1997 01:45:38 -0700 From: John-Mark Gurney To: Luigi Rizzo Cc: Mike Smith , perhaps@yes.no, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support References: <199709120614.QAA01493@word.smith.net.au> <199709120631.IAA02519@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709120631.IAA02519@labinfo.iet.unipi.it>; from Luigi Rizzo on Fri, Sep 12, 1997 at 08:31:12AM +0200 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 Luigi Rizzo scribbled this message on Sep 12: > Ok, also thanks to being in a different timezone I could read all > this thread before having a chance to post. > > Unfortunately the only conclusion I can gather from the discussion > is that there is not complete agreement on what should be done. > > As long as there is a manual override mechanism, which we already > have for legacy ISA and PnP (Terry, this is what the pnp code in > -current does), I am not concerned about what gets implemented to > automate resource allocation. If anything fails, there is a backdoor. > So I'll avoid further comments waiting for someone to volunteer > for a sample implementation :) > > What I think is important to have (also to test possible solutions > etc.) is the 'extent' manager mentioned earlier in this thread. I've started looking at it.. and the header looks promising... if I remeber right... it does more than I thought it would.. and looks like we should adopt it... I'm going to start looking at the code.. and after that, see if I can't get a kernel that will use the extent as a resource checker... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD