> - Linear searches of the tapfds list are a little grim where they
> appear in
> the data path (blktap_ioctl, blktap_kick_user, fast_flush_area,
I didn't like this either. Perhaps I could switch it back to an array
of pointers. And I could even have the array be able to resize, with
the use of rcu locks.
> do_block_io_op, dispatch_rw_block_io). If we are happy with a limit of
> 254 concurrent devices for the immediate term, I wonder if a lookup
> indexed by minor and allocated on use might be better?
Yeah, I think I do agree with you on this. I really don't like that
linear search. Maybe I did it because I was tired and it seemed cool. ;)
Fair enough. :) Resizable lookup array of pointers sounds great.
Then again 254 pointers may not be the worst overhead. ;)
> - I enjoyed seeing the domid_translate array go away, I think we can kill
> this translation all together though by moving the domid/busid lookup
> out of blktapctrl and into xenbus, and filling it in directly when a
> new vbd is connected.
This is a separate issue, and would need to be looked at later. (I'm not
to sure on the interworkings of that code).
Absolutely, that comment was partially a note-to-self. ;)
> - With dynamic allocation, MAX_TAP_DEV seems a little unnecessary.
> we just allocate until we run out of minors now?
Sure! I just was keeping it in sync with what was there. The old code
didn't allocate more than MAX_TAP_DEV so I wasn't about to change it.
Change away -- the current maximum is pretty arbitrary.
> I'm inclined to wait until immediately after the 3.0.3 barrier with this
> Sound okay?
Sounds fine with me. Thanks,
excellent -- thanks again to both you and Stephen for all the patches
this week. The code is much improved now and it's great to have all
Xen-devel mailing list