On Mon, 14 Apr 1997, Dan Hollis wrote:
> I increased the size to 80, which fixed the problem. From what I can
> figure, this takes only 256 more bytes in the kernel (assuming the extra
> iotable port space is unused). Is there any problem with making this
> standard?
Everytime my memory-challenged test-target hears "...more bytes in the
kernel" it makes a quiet "Ekk" sound...:)
The current limit is on the low-side for systems with terminal servers.
I've just had a quick look at how difficult it would be to make this
scalable - it's non-trival.
request_region() can be (actually, most like is) called each before
kmalloc/slab has been initialised, and we wouldn't want to run the risk of
these failing anyway.
It might be possible to have the caller pass the memory for an io-resource
struct. For some resources this would come from bss/data section (such as
for "pic1" and "pic2" which will always be present). For other resources,
we could have a primitive non-page allocation function which would use
kmalloc if it had been initialised, or take memory from the start-up
ranges "start_mem-end_mem" otherwise. As a last resort resource.c would
have a few kept in reserve.
BTW: I've been looking at the start_mem/end_mem usage, and we can probably
do better (and be more flexible). One problem is that there might be a
hole in the address range (unlikely, but possible), and another problem is
that (at initialisation time) we give away several of pages that could be
used for DMA (particularly to the mem_map array - which becomes a more
serious problem on large memory systems).
A more intellgient initialisation memory allocation scheme would be
useful.
Regards,
markhe
------------------------------------------------------------------
Mark Hemment, Unix/C Software Engineer (Contractor)
markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/
"Success has many fathers, failure is a B**TARD!" - anon
------------------------------------------------------------------