Messages in this thread | | | Date | Mon, 5 Jul 1999 09:13:43 -0700 | From | David Hinds <> | Subject | Re: kernel/resource.c breakage |
| |
> I understand that work on a new PnP / bus management architecture has > started... That is nice. Are you also intending to do the other > changes suggested when this last came up? (We also said that module > loading should be separated from device initialization, and some > protocol should exist to allow the bus driver to tell the driver what > resources to use...) This protocol will also solve Tim's problem, as > the driver will _know_ beforehand that it has an 8-byte io range...
Those things are all nice but I have only modest plans. I don't really have the time or the motivation to do a full rewrite of how drivers interact with the kernel. The resource management changes are one step in that direction, and should make these things easier. But I'm working on just a few smaller, incremental changes.
You are correct that if a bus driver already knows that there's a parallel port in this spot and how big it is, Tim's driver shouldn't need to check before probing there. But until we decide on a way of communicating this information, I'd like for everything to still work.
There are a couple short-term options here. One would be to have two resource tables: one managed by request/check/release_region with the old semantics, filled in by drivers, and one by occupy/vacate_region, filled in by PCI and PnP bus managers. The two would be completely independent, and when picking resources for dynamic devices, we would check for conflicts in both. That's a quick fix and a bit inelegant, since it requires doubling some potentially large tables that almost always will contain mostly identical information.
The other option would be to introduce various fixups for drivers that need special accommodations in the current system. The issue becomes how many fixups are needed, and where should they go: in the drivers, or in the resource code, or in the bus drivers (PCI, PnP, etc)? If only a couple drivers are affected, this might be the best solution.
Are there more drivers with problems with the new resource code? I think the ftape problem is easily fixed by correcting the bounds of the existing check_region() call (right?). For the parallel port, there is the port size ambiguity issue. Are there more examples that people know about?
-- 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/
| |