[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
replacing extent(9) with vmem(9): lessons learned
I've tried to replace the management of i386 bus space by extent(9) with
management by vmem(9). I've found some API/implementation problems in
vmem(9) that make vmem(9) a dissatisfying replacement for extent(9).
Problem 1: vmem(9) cannot manage a region that begins at 0.
vmem(9) reserves the address 0 for indicating errors. For
example, vmem_xalloc(9) returns VMEM_ADDR_NULL (0) if it cannot
find a suitable region.
extent(9) indicates errors "out of band" instead of reserving
an address for error indications, so it can manage a region
starting at 0.
No workaround that I have found is very satisfying.
Problem 2: vmem(9) cannot manage a region that includes the maximum
This is an implementation problem. Sometimes vmem(9) will add
the start of a region to the size of a region without checking
for overflow. For example, 0x1 (start) + 0xffffffff (size) ==
0. Every use of BT_END() needs some TLC.
Problem 3: vmem(9) uses malloc(9)/pool(9)/RUN_ONCE(9), but
the bus space regions are initialized and used before
malloc(9)/pool(9)/RUN_ONCE(9) are available.
I have a rudimentary fix in my tree. I added a new API routine,
vmem_create_storage(..., void *storage, size_t storage_size)
for creating a vmem_t with static storage. I made the
implementation use the static storage if it was available.
By making several compromises, I did get NetBSD/i386 to boot to
multiuser after an extent->vmem switch.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |