From owner-freebsd-current  Wed Apr  5 20:42:57 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id UAA09787
          for current-outgoing; Wed, 5 Apr 1995 20:42:57 -0700
Received: from localhost (localhost [127.0.0.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id UAA09780
          ; Wed, 5 Apr 1995 20:42:56 -0700
X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol
To: Bruce Evans <bde@zeta.org.au>
cc: ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com,
        freebsd-current@freefall.cdrom.com
Subject: Re: Strange kernel printf... 
In-reply-to: Your message of "Thu, 06 Apr 95 02:45:42 +1000."
             <199504051645.CAA25258@godzilla.zeta.org.au> 
Date: Wed, 05 Apr 1995 20:42:42 -0700
Message-ID: <9774.797139762@freefall.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
Sender: current-owner@FreeBSD.org
Precedence: bulk

> This is particularly annoying because the driver lies about the ports
> that it uses.  It actually uses IO_TIMER1 and IO_PPI.  The config struct
> has no way to represent multiple ports per driver, and the config line
> doesn't use either because IO_TIMER1 should conflict with the clock
> "driver" and IO_PPI would conflict with keyboard drivers.

Hmmmmm.  Would it be useful to have config changed to:

1. Generate arrays of allocated addresses, IRQs (are there any devices
   made that more than one?), DMA channels, etc. where it currently holds
   only a single value.

2. Accept a somewhat altered config file specification:

device <foo> at <bus>[#|?] port <port>[,<port> ..] irq <irq>[,<irq> ..] drq <drq>[, <drq> ..]
	[conflict_ok <conflict_type>[, <conflict-type> ..]]

Where "conflict_ok" would take arguments like "iomem, irq, drq, etc."
to enable bits in an "allowed conflicts" mask.  This would eliminate
the ALLOW_CONFLICT_* horrors I inflicted upon the code many months ago.

I resisted the impulse to also add some sort of probe priority flag,
but if someone can really think of a serious use not already catered
to by natural config file ordering (which also kinda bites, now that I
think about it - very counter-intuitive!).

Seriously, we always talk about how evil config is but no one really
does anything about it.  Sort of like our attitude towards government,
but I digress.  How hard would it REALLY be to finally fix config
properly?

						Jordan