> > sane things") -- By skipping the check, it doesn't get blocked by
> > the dummy ioport table entry, and instead overwrites the reserve
> > ioport entry with its own ioport entry.
>
> Ummm, I don't think this is how request_region() works. A second call
> to request_region() for an already-allocated region will silently
> fail: it will not replace the old entry with the new one.
True, it doesn't replace the old entry with the new one, but the point
is that the driver doesn't get blocked by the reserved entry. I believe
the original snarf_region() did replace the old entry with the new one
as I described above, but I can't recall 100%.
> I think it would probably be a good idea for request_region() to
> return a success/failure indication. I wonder why it doesn't, but I
I think that it would be better to have check_region() to return -EPERM
if the region is reserved, -EBUSY if a driver has already snarfed it
up, or zero if free. Drivers that want to probe into reserved regions
when given an explicit i/o would then be updated to check for the EPERM
return value, so that "reserve=" still works as it was intended to.
> I had thought that the meaning of "reserve=" was to tell the system to
> avoid probing for *anything* at certain addresses... like, it was
> saying that certain addresses specified devices unknown to Linux. But
> I was just rewriting what was already there, not making it up from
> scratch. I think if a reserved entry should be replaced as Paul
> suggests, then there should be a specific test for this situation, so
> that regions allocated by other drivers cannot be replaced this way.
Actually the meaning of "reserve=" was as I described. Donald Becker and
Peter MacDonald implemented the i/o port registry (and "reserve=") waaay
back in 0.99pl13 to block certain SCSI probes from hanging on ne2k cards.
Here is a quote from Donald that I dug out of a 2yr old copy of the
Ethernet-HowTo:
" ...... A correct device driver shouldn't probe a reserved
region, unless another boot argument explicitly specifies that
it do so. This implies that "reserve" will most often be used
with some other boot argument. Hence if you specify a "reserve"
region to protect a specific device, you must generally specify
an explicit probe for that device. Most drivers ignore the port
registration table if they are given an explicit address."
Paul.