From owner-freebsd-hackers Sun May 28 13:48:58 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 EAAB437B966 for ; Sun, 28 May 2000 13:48:53 -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 NAA04805; Sun, 28 May 2000 13:51:06 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005282051.NAA04805@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed In-reply-to: Your message of "Sun, 28 May 2000 00:41:56 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Sun, 28 May 2000 13:51:06 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Speaking about bus_space_*(): Does it make the thing follow the PCI > ordering rules? Very probably not since it is impossible on some system= s. There's no attempt to do this, no. However, it's possible to implement = this if there's a need. > Typically, a driver may want to order some operations and also not brea= k > post buffering each time a write is performed. It may for example want = to > order some operations, but not flush all writes immediately. I didn't s= ee > how to tell bus about that. The bus_space_barrier() interface takes the bus tag and handle as = arguments, so the ordering operations can make decisions about how they = should behave based on what you're operating on. > Hmmm... That's the point I disagree on, btw. Inserting implicit barrier= s > in the back of drivers can only be either sub-optimal or sometime not > match driver expectations about ordering. Bus interface should allow mo= re > flexibility to drivers regarding ordering, in my opinion. I think Warner answered this, and he probably understood your point = better; at the moment, the driver is solely responsible for managing = ordering. None of our current busspace backends perform any sort of = ordering. > By the way, as I wrote in my previous mail, I am unable to propose a > better interface. I only wanted to point out that bus abstractions are = far > from being perfect. They make portability possible without too much cod= e > complexity, but when working on a driver, I think we must not forget th= e > reality of what actually happens inside the machine. Just so. The real joy, of course, comes when you're trying to make a = drive behave "correctly" on a wide range of different machines. 8) -- = \\ 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