Date: Sat, 27 May 2000 15:43:54 -0600 From: Warner Losh <imp@village.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: <200005272143.PAA00751@harmony.village.org> In-Reply-To: Your message of "Sat, 27 May 2000 22:59:31 %2B0200." <Pine.LNX.4.10.10005272157290.1197-100000@linux.local> References: <Pine.LNX.4.10.10005272157290.1197-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.LNX.4.10.10005272157290.1197-100000@linux.local> =?ISO-8859-1?Q?G=E9rard_Roudier?= writes: : Existing bus abstractions tend to let think that the same software driver : can deal with different buses, bridges or IO methods without having to : care about how these things actually behave, notably regarding buffering : and ordering rules. This is untrue. That statement is false. We have several drivers in the tree that work on memory mapped or I/O mapped devices attached to many different types of buses. NetBSD takes this even farther than we do. : Existing bus abstractions may let driver writer think that everything that : addresses bridges, bus specific and arch specific properties is handled : transparently given that the right abstract method is called in the right : place. This is untrue. But it does handle them transparently. : Existing bus transactions may let think that driver writers donnot have : to care with ordering rules and coherency issues between transactions in : both directions targetting device and memory. : This is untrue. NetBSD's busdma does a great job of this. DMA is a horrible issue with some machines donig it in virtual address space, and others doing it in physical address space with no cache coherency. NetBSD does it just fine and we're basically using the NetBSD interface. : 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 device : (bus), most IO abstractions I have seen will do the bad work by just : performing a memory barrier (or some additionnal barrier) after the WRITE : 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. Most drivers do not do this. Those that do need to write to both will use the proper tags. When the proper tags are used in the bus space stuff, the proper barriers will be inserted at the right time (eg after the write to memory) on those architectures that need it. Most of these complaints are based on busspace, rather than the newbus. bus space came from NetBSD and is working their very well. FreeBSD has an older version of bus space in its tree. I've tried to update it in the past, but the newbus stuff and the new NetBSD bus space stuff overlap somewhat making it hard to modernize the busspace stuff in FreeBSD. We will have to do it with the Sparc or MIPS ports that are in the wings, but for now we are fat and happy. :-( Warner 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?200005272143.PAA00751>