From owner-freebsd-hackers Sat Sep 30 13:54:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA16872 for hackers-outgoing; Sat, 30 Sep 1995 13:54:37 -0700 Received: from Wit401402.student.utwente.nl (Wit401402.student.utwente.nl [130.89.236.162]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA16863 for ; Sat, 30 Sep 1995 13:54:32 -0700 Received: (from alain@localhost) by Wit401402.student.utwente.nl (8.6.12/8.6.9) id VAA00655; Sat, 30 Sep 1995 21:54:16 +0100 Date: Sat, 30 Sep 1995 21:54:16 +0100 (MET) From: Alain Kalker Reply-To: A.C.P.M.Kalker@student.utwente.nl To: Bruce Evans cc: hackers@freebsd.org, julian@ref.tfs.com Subject: Re: correctness of isa.c In-Reply-To: <199509301130.VAA32657@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 30 Sep 1995, Bruce Evans wrote: > >(also while we're about it, why is id_irq a bitfield? > >it's almost believable, but is there a really good reason?) > > There is no good reason, at least now. The bitmap is more general > except it doesn't allow out of bounds values, but nothing uses the > flexibility, and lots of things assume that only one bit is set > (things that do ffs(id_irq) won't work right if multiple bits are > set). > > Bruce > Any chance of making id_drq a bitfield as well? This would solve the problems that will arise when writing drivers for the next generation multimedia add-on boards which use multiple DMA channels. In fact the problem already exists in the sound driver, which currently (ab)uses id_flags for a second DMA channel. --- Alain