Messages in this thread |  | | Subject | Re: 1.99.14 & duplicate NE2000 | Date | Sun, 9 Jun 1996 21:13:41 -0400 (EDT) | From | "Andrew E. Mileski" <> |
| |
> 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. > > 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 > wrote it a long time ago and don't remember what I was thinking at the > time. Maybe I did it that way to be compatible with its predecessor, > snarf_region().
ATTENTION! :-)
I've re-written the request_region stuff already, as part of the PnP Project. I've done some major rearrangement, so I'd hate to see somebody go and change something before my patch was in.
The _OLD_ code wasn't good at all (even has a race in it).
I'll be updating the PnP patch to v2.0.0 very soon (last patch I did was for v1.3.98). Perhaps we can put this in the next v2.*.* kernel? The PnP code is 100% innocent (incomplete), even if enabled, and will hopefully draw some interested parties to do some PnP hacking.
If people are concerned, I can pull out the PnP code too :-( The new request_region code (and such) are _NOT_ dependent on it (but the PnP code is). The code is solid though - I've been running it for quite a while, as have others, with no problems.
The _NEW_ resource management code adds the _LONG_ awaited address space management too (/proc/addresses).
Just sign me "the snarf killer" :-)
-- Andrew E. Mileski mailto:aem@ott.hookup.net http://www.redhat.com/~aem/ Linux Plug-and-Play Project http://www.redhat.com/pnp/
Red Hat Software sponsors these pages - I have no other affilitation with Red Hat Software, and I have never used any of their products.
|  |