Date: Fri, 19 May 2000 19:07:10 -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: <3925C91E.9CD7D9EE@bellatlantic.net> References: <3924931E.A8471B0@bellatlantic.net> <20000518223846.A16098@cichlids.cichlids.com> <200005182332.RAA97696@harmony.village.org> <200005190116.TAA98120@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
#
# 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.
#
# Devices which implement busses should use this method to probe for
# the existence of devices attached to the bus and add them as
# children. If this is combined with the use of bus_generic_attach,
# the child devices will be automatically probed and attached.
#
METHOD int probe {
device_t dev;
};
> It is also legal for buses to probe all their devices before attaching
> any of them (the pci bus does this, iirc, so that generic drivers can
> handle some hardware and more specific drivers can handle other).
> There's nothing that states probe_and_attach is the only way to get
> things done.
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().
> Finally, there's a comment in subr_bus:
> device_set_driver(child, best->driver);
> if (pri < 0) {
> /*
> * A bit bogus. Call the probe method again to make sure
> * that we have the right description.
> */
> DEVICE_PROBE(child);
> }
>
> which indicates to me that the probe routines will be called multiple
> times if they return < 0 (pri is the priority they returned, 0 meaning
> it is mine and nobody else's).
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.
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.
-SB
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3925C91E.9CD7D9EE>