From owner-freebsd-doc Sat May 20 0:12: 2 2000 Delivered-To: freebsd-doc@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D539437B517; Sat, 20 May 2000 00:11:51 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA96475; Sat, 20 May 2000 01:11:43 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost.village.org [127.0.0.1]) by billy-club.village.org (8.9.3/8.8.3) with ESMTP id BAA44934; Sat, 20 May 2000 01:11:00 -0600 (MDT) Message-Id: <200005200711.BAA44934@billy-club.village.org> To: Sergey Babkin Subject: Re: request for review: bus_alloc_resource(9) Cc: Alexander Langer , doc@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 19 May 2000 19:07:10 EDT." <3925C91E.9CD7D9EE@bellatlantic.net> References: <3925C91E.9CD7D9EE@bellatlantic.net> <3924931E.A8471B0@bellatlantic.net> <20000518223846.A16098@cichlids.cichlids.com> <200005182332.RAA97696@harmony.village.org> <200005190116.TAA98120@harmony.village.org> Date: Sat, 20 May 2000 01:11:00 -0600 From: Warner Losh Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3925C91E.9CD7D9EE@bellatlantic.net> Sergey Babkin writes: : Warner Losh wrote: : > : > In message <3924931E.A8471B0@bellatlantic.net> Sergey Babkin writes: : > : The code seems to guarantee that if the probe routine returns 0 : > : then the attach routine will be called right away. So if the probe : > : routine returns 0 they don't have to be freed. Actually, the : > : comments seem to say explicitly that the resources should be : > : freed only if the probe routine returns a negative value but not 0. : > : Or am I missing something ? : > : > The code doesn't write the guarantee. In general probe routines are : > supposed to be idempotent. You are supposed to be able to have them : > be called multiple times, at least in theory. The probe routine : > should not hold resources past the end of its execution, positive or : > negative. : > : > I'm not sure where you found the comments that say that the probe : > routine can hold resources after it is called. I couldn't find any. : : Sorry that I did not quote it in the first e-mail. In kern/device_if.m: A pointer would have been sufficient :-) : # Probe to see if the device is present. Return 0 if the device exists, : # ENXIO if it cannot be found. If some other error happens during the : # probe (such as a memory allocation failure), an appropriate error code : # should be returned. For cases where more than one driver matches a : # device, a priority value can be returned. In this case, success codes : # are values less than or equal to zero with the highest value representing : # the best match. Failure codes are represented by positive values and : # the regular unix error codes should be used for the purpose. : : # If a driver returns a success code which is less than zero, it must : # not assume that it will be the same driver which is attached to the : # device. In particular, it must not assume that any values stored in : # the softc structure will be available for its attach method and any : # resources allocated during probe must be released and re-allocated : # if the attach method is called. If a success code of zero is : # returned, the driver can assume that it will be the one attached. Notice it doesn't say that one can hold RESOURCES past the end of probe. Only that values set in the softc (which one should try to avoid) aren't guaranteed to be there if the return value is < 0. It can only assume that it will be the driver that is attached. This comment is poorly worded anyway and should be changed to explicitly state that one shouldn't hold resources at the end of the probe routine. : That comment does not guarantee that attach will be called right : away but I suppose it guarantees that if probe() returns 0 it : may expect that attach() will eventually be called and keep the : resources and contents of its structs softc between probe() and : attach(). Yes and no. It has long been stated that one cannot hold resources past the end of a probe. It is attaches job to allocate them permanantly, code and docs notwithstanding. I recall this coming up from time to time on the newbus list a long time ago, but haven't checked the archives. Going back in time to prenewbus, this certainly was the case. And it is the case in other Unixes that I've worked on in the past. : Yes, that's what I said in the first quoted paraghaph: if probe : returns <0 (priority arbitration between multiple drivers in a class) : or >0 (error) then it must free the resources before exit and don't : assume that the contents of struct softc will be presevred between : probe and attach. But if probe returns 0 it may keep the resources. I'm still not sure that I agree. Unless I hear from the new-bus meister, I won't feel obligated to necessarily keep this condition in the NEWCARD code. I don't think I'll need to violate it, but I will if I have to because of how things are allocated in most device drivers right now. : Also some resources have problems with freeing them: for example, : if a piece of memory was allocated using bus_dmamem_alloc() with : lowaddr of BUS_SPACE_MAXADDR_24BIT then bus_dmamem_free() won't : really free it but just throw it away (I suppose contigfree() did not : exist when it was written). So it's better to keep these resources : between probe and attach if probe returns 0. No. Absolutely not. One should allocate them once only in the attach code. The probe code almost never needs to do a DMA to probe the device. Probes are supposed to be non-destructive (eg read only on the registers) if at all possible. One shouldn't try to allocate it there anyway for the same reason you say we should. If you are using it to see if the device exists, and it doesn't, then you can't free it. Sounds like a bad way to probe the hardware. The probe routine is supposed to do the absolute minimum to the hardware to see if it is really there. It shouldn't be bringing in all kinds of extra resources that it doesn't need to determine if the device is there or not. Probe's role in self-identiftying buses is simple. Check the identifying characteristics against a table and return the string associated with that characteristic. On the ISA bus (the only non-self identifying bus we have), it is sadly necessary to touch the hardware to see if it readlly exists. Some hardware is easy to non-destructively probe. Most of the early pc hardware is impossible to non-destructively probe. The changes to the state of the device for an ISA bus probe shouldn't be relied on in the attach routine (sio violates this, for example). It makes it harder to adapt to self identifying buses in the future (I had to call the isa probe to set the hardware to a known state in the pci probe code which should have just checked the config ID tags and returned). Likewise with pccard. I guess that's another reason I tend to be vehiment in keeping the wall of separation between the two. I've been burned by drivers in the past that didn't and it was a royal PITA to sort that all out. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message