From owner-freebsd-hackers Wed May 6 20:35:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26600 for freebsd-hackers-outgoing; Wed, 6 May 1998 20:35:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com ([210.145.37.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26585 for ; Wed, 6 May 1998 20:35:16 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA00530; Wed, 6 May 1998 15:12:17 -0700 (PDT) Message-Id: <199805062212.PAA00530@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 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 15:12:16 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. No, it doesn't. But I may not have answered your specific qualms. > Think hot-swappable devices, and devices that *really* no one knows > about? Yes, what about them? How about a concrete problem rather than FUD? > 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'. Huh? You must specifically be talking about the resource starvation case where the "can but don't have to" device comes up before a "must have" device and takes the last interrupt. Firstly, there aren't too many devices in the "can but don't have to" class, so this is a pathalogical example. Second; you deal with it the same way you always would - you're subject to the behaviour of the driver for the first device and whether it allocates itself an interrupt. If you're concerned about that, fix the driver to export a sysctl variable and tweak it out of kernel.config. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message