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/