Date: Sat, 20 May 2000 09:31:34 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: Warner Losh <imp@village.org> Cc: Alexander Langer <alex@big.endian.de>, doc@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: request for review: bus_alloc_resource(9) Message-ID: <392693B6.1FB6C64C@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> <200005200711.BAA44934@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
> In message <3925C91E.9CD7D9EE@bellatlantic.net> Sergey Babkin writes:
> : # 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
It says, about the case of negative return value. So I guess that
implies that in case if 0 is returned keeping resources is permitted.
> 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.
I suppose that "driver can assume that it will be the one attached"
means that the probe routine will not be called again for this
device, thet the resources won't change and that the attach routine
will be called eventually. Provided with all this keeping the resources
seems to be safe. But of course that's only my interpretation.
> : 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.
As far as I remember in prenewbus there were no "official resources".
Yes, I agree that keeping anything allocated when returning
from probe is a bad idea.
> : 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.
It's not like I'm saying that it MUST keep the resources from probe but
I suppose it's allowed to if it really wants.
> : 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
What about the case when device exists but is broken/misconfigured ?
Suppose, someone got the port address right but the DMA channel wrong.
Well, of course, this more intrusive part of probe may as well be moved to
the attach routine.
-SB
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?392693B6.1FB6C64C>