[lkml]   [1996]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 1.99.14 & duplicate NE2000
> 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().


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
Linux Plug-and-Play Project

Red Hat Software sponsors these pages - I have no other affilitation
with Red Hat Software, and I have never used any of their products.

 \ /
  Last update: 2005-03-22 13:37    [W:0.069 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site