replacing extent(9) with vmem(9): lessons learned

[David Young <dyoung%pobox.com@localhost>]

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
    address, ~(vmem_addr_t)0.

    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.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933