Messages in this thread | | | Date | Sat, 3 Jul 1999 22:42:43 -0700 | From | David Hinds <> | Subject | Re: kernel/resource.c breakage |
| |
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/
| |