Date: Sat, 27 May 2000 18:36:12 -0700 From: Mike Smith <msmith@freebsd.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl>, Dennis <dennis@etinc.com>, John Hay <jhay@mikom.csir.co.za>, hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed Message-ID: <200005280136.SAA01669@mass.cdrom.com> In-Reply-To: Your message of "Sat, 27 May 2000 22:59:31 %2B0200." <Pine.LNX.4.10.10005272157290.1197-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005280136.SAA01669>