Re: 1.99.14 & duplicate NE2000

Andrew E. Mileski (aem@nic.ott.hookup.net)
Sun, 9 Jun 1996 21:13:41 -0400 (EDT)

> 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.