From owner-freebsd-hackers Wed May 6 09:39:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA26403 for freebsd-hackers-outgoing; Wed, 6 May 1998 09:39:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA26382 for ; Wed, 6 May 1998 09:39:09 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id JAA08371; Wed, 6 May 1998 09:38:22 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805061638.JAA08371@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Mike Smith , Archie Cobbs , stefan@promo.de (Stefan Bethke), luigi@labinfo.iet.unipi.it, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? In-reply-to: Your message of "Wed, 06 May 1998 09:17:25 MDT." <199805061517.JAA05337@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 May 1998 09:38:22 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The device driver can tell the upper layer which resources it wants or does not need. The gus pnp section of the voxware sound driver behaves fairly much like the enclosed outline and my experience shows that is not that hard to implement granted in the case of the gus pnp module it has no upper layer to talk to however that can easily be done . My point is that the model is feasible. Amancio > > > CASE #1: Kernel config file looks like this: > > > -------------------------------------------- > > > > > > device foo0 > > > > > > In this case, the kernel automatically configures stuff for driver > > > foo0. If the BIOS has already configured the card, and that's > > > acceptable, the kernel can go along. Otherwise, the kernel should > > > pick resources that are free and configure the card itself. > > > > > > > > > CASE #2: Kernel config file looks like this: > > > -------------------------------------------- > > > > > > device foo0 port 0x220 irq 7 vector foointr > > > > > > Kernel should override whatever is already configured in the > > > card (if anything) with the given values. > > > > > > > > > Does this make sense to anyone else besides me? What are the > > > technical things that need to be done to make it happen? > > > > This actually falls a little short. It's easier to look at it from a > > different angle, too. > > > > For each PnP device/function in the system > ... > > For each explicitly-configured ISA devices > ... > > Things is, this falls really short for non-ISA/non-PnP devices as well. > Think hot-swappable devices, and devices that *really* no one knows > about? Also, devices that can use IRQ's, but don't necessarily need > them. How do you say 'go ahead and use it', vs. 'don't bother'. > > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message