qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC PATCH 2/6] ram_blocks: Convert to a QLIST


From: Chris Wright
Subject: [Qemu-devel] Re: [RFC PATCH 2/6] ram_blocks: Convert to a QLIST
Date: Tue, 8 Jun 2010 14:26:59 -0700
User-agent: Mutt/1.5.20 (2009-08-17)

* Alex Williamson (address@hidden) wrote:
>  extern int phys_ram_fd;
> -extern uint8_t *phys_ram_dirty;
>  extern ram_addr_t ram_size;
> -extern ram_addr_t last_ram_offset;
> +
> +typedef struct RAMBlock {
> +    uint8_t *host;
> +    ram_addr_t offset;
> +    ram_addr_t length;
> +    QLIST_ENTRY(RAMBlock) next;
> +} RAMBlock;
> +
> +typedef struct RAMList {
> +    uint8_t *phys_dirty;
> +    ram_addr_t last_offset;
> +    QLIST_HEAD(ram, RAMBlock) blocks;
> +} RAMList;
> +extern RAMList ram;

such a generic name for global namespace

>  void *qemu_get_ram_ptr(ram_addr_t addr)
>  {
> -    RAMBlock *prev;
> -    RAMBlock **prevp;
>      RAMBlock *block;
>  
> -    prev = NULL;
> -    prevp = &ram_blocks;
> -    block = ram_blocks;
> -    while (block && (block->offset > addr
> -                     || block->offset + block->length <= addr)) {
> -        if (prev)
> -          prevp = &prev->next;
> -        prev = block;
> -        block = block->next;
> -    }
> -    if (!block) {
> -        fprintf(stderr, "Bad ram offset %" PRIx64 "\n", (uint64_t)addr);
> -        abort();
> -    }
> -    /* Move this entry to to start of the list.  */
> -    if (prev) {
> -        prev->next = block->next;
> -        block->next = *prevp;
> -        *prevp = block;
> +    QLIST_FOREACH(block, &ram.blocks, next) {
> +        if (addr - block->offset < block->length) {
> +            QLIST_REMOVE(block, next);
> +            QLIST_INSERT_HEAD(&ram.blocks, block, next);
> +            return block->host + (addr - block->offset);
> +        }
>      }
> -    return block->host + (addr - block->offset);
> +
> +    return NULL;

Why not preserve the error message and abort()?  In error cases this
would now just segfault.

Minor nits aside, this too looks like a nice cleanup.

Acked-by: Chris Wright <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]