Re: kernel/resource.c breakage

David Hinds (dhinds@zen.stanford.edu)
Sat, 3 Jul 1999 22:42:43 -0700


On Sun, Jul 04, 1999 at 02:02:51AM +0200, Mikael Pettersson wrote:
>
> Since David Hinds is co-author of <linux/ioport.h> and resource.c,
> I assume there's a need for the new functionality (available I/O
> regions not tied to any particular driver) for pcmcia. However,
> I don't think we should do this by making incompatible changes to
> existing interfaces. Instead I argue that:
> (a) The new release_region() ought to be renamed to some name
> not present in pre-2.3.7 kernels. yield_region() perhaps?
> (b) The new vacate_region() ought to be renamed to release_region(),
> in order to preserve the old semantics under its existing name.
> As far as I can tell, there's nothing in the kernel that actually
> uses the "new and improved" semantics, so these renamings shouldn't
> break anything. I'll submit a patch to Linus, if this proposal is
> accepted.

You are correct that the semantics of release_region() have subtly
changed, and that in unusual cases, drivers will need to be tweaked to
accommodate it. I had not thought that any drivers did the sort of
thing that ftape apparently does. I think that fixing the drivers is
the correct course of action, not effectively reverting the new
semantics as you suggest. Especially if ftape is the only example of
this issue.

To briefly describe what the new semantics are: occupy_region and
vacate_region are used to describe physical resources committed to
devices. request_region() and release_region() are used to associate
a resource with a device driver, and to prevent conflicts between
drivers. request_region() implies that a resource is committed by
hardware, so release_region() doesn't remove all traces of the
allocation: the hardware still exists. A bus driver that can control
how devices are configured is a fair user of occupy/vacate calls. An
ordinary driver should use request/release. We need these semantics
for PCMCIA as well as for any other dynamically configured bus, and it
would be semantically incorrect to allow device drivers to continue to
use the calls with the old meanings. The old semantics were broken.

-- Dave Hinds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/