From owner-freebsd-hackers Sat May 27 18:34:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (adsl-63-193-112-57.dsl.snfc21.pacbell.net [63.193.112.57]) by hub.freebsd.org (Postfix) with ESMTP id DE65437B512 for ; Sat, 27 May 2000 18:34:30 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA01669; Sat, 27 May 2000 18:36:12 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005280136.SAA01669@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: Jeroen Ruigrok van der Werven , Dennis , John Hay , hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed In-reply-to: Your message of "Sat, 27 May 2000 22:59:31 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Sat, 27 May 2000 18:36:12 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Existing bus abstractions tend to let think that the same software driv= er > can deal with different buses, bridges or IO methods without having to > care about how these things actually behave, notably regarding bufferin= g > and ordering rules. This is untrue. A good bus abstraction lets you care as much or as little as necessary. = The NetBSD framework (which we use) allows you to do this. > Existing bus abstractions may let driver writer think that everything t= hat > addresses bridges, bus specific and arch specific properties is handled= > transparently given that the right abstract method is called in the rig= ht > place. This is untrue. This is called "a naive driver author", and it doesn't matter how good or= = bad the bus abstraction is; these people can write BASIC in any language.= > Existing bus transactions may let think that driver writers donnot have= = > to care with ordering rules and coherency issues between transactions i= n = > both directions targetting device and memory. > This is untrue. See above. > I donnot know how the right bus generic abstraction could be, but for > now, all those I saw donnot look statisfying to me, and it seems to me > that they may lead to having numerous quite aesthetic drivers that are > just broken due to driver (writer?) relying too much on some supposed = > generic cleverness of the bus abstraction that does not happen. = See above. > When some weak memory ordering is involved, the only way to make things= > right and not too sub-optimal is to insert explicit barriers in the dri= ver > code. Flushing everything after the IO from the 'bus write/read' > abstraction is broken. Nobody that I'm aware of does anything this stupid. We certainly expect = the driver author to care about macro-ordering of bus operations. > For example, if I want a WRITE TO MEMORY followed by a WRITE TO AN IO > REGISTER performed from the C code to be seen consistently from the dev= ice > (bus), most IO abstractions I have seen will do the bad work by just > performing a memory barrier (or some additionnal barrier) after the WRI= TE > TO THE IO REGISTER. If driver writer is not aware of this kind of > subtleties, very ennoying bugs will be generated all around, in my > opinion. Very few architectures even support I/O registers, and the only one that = most people care about already guarantees write ordering in hardware. = The example you're positing is basically a non-issue, with the exception = of operation re-ordering by the compiler (and for this see above). -- = \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message