Date: Sun, 28 May 2000 13:51:06 -0700 From: Mike Smith <msmith@freebsd.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed Message-ID: <200005282051.NAA04805@mass.cdrom.com> In-Reply-To: Your message of "Sun, 28 May 2000 00:41:56 %2B0200." <Pine.LNX.4.10.10005280003250.1425-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005282051.NAA04805>