Date: Sat, 27 May 2000 22:59:31 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl> Cc: 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: <Pine.LNX.4.10.10005272157290.1197-100000@linux.local> In-Reply-To: <20000527215735.A43304@lucifer.bart.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 May 2000, Jeroen Ruigrok van der Werven wrote: > -On [20000527 21:06], Dennis (dennis@etinc.com) wrote: > > > >Its seems rather humorous that the "generic" bus implementation requires > >that isa drivers be hacked into the kernel with a build-time include. Ve= ry > >humorous indeed. Is this a temporary condition as was the deboggle in v3= =2E0? >=20 > Yeah I laugh my ass off. You figure out at what or whom. Hmmm... When I see all those bus abstractions floating around in different O/Ses, I donnot laugh at all, but I am sad. In order to work correctly, it is the concrete device driver that must be aware of what actually happens about IO and DMA. Thinking that generic bus abstraction can be clever enough to deal with all that is a serious mistake in my opinion. A device support is a pair that consists in a software driver + a device that may incorporate firmware, and both parts may need to have some consistant view of some data in some place in order to work correctly. 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. 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. Existing bus transactions may let think that driver writers donnot have=20 to care with ordering rules and coherency issues between transactions in=20 both directions targetting device and memory. This is untrue. 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=20 generic cleverness of the bus abstraction that does not happen.=20 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 driver code. Flushing everything after the IO from the 'bus write/read' abstraction is broken. 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. G=E9rard. 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?Pine.LNX.4.10.10005272157290.1197-100000>