Date: Wed, 05 Apr 1995 20:42:42 -0700 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> 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... Message-ID: <9774.797139762@freefall.cdrom.com> In-Reply-To: Your message of "Thu, 06 Apr 95 02:45:42 %2B1000." <199504051645.CAA25258@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9774.797139762>