[Xen-devel] Re: [PATCH] Turn blktap tapfds into a link list

["Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>]

> >  - 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
> > array
> >    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.
> > Shouldn't
> >    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
> > one.
> > 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
the feedback.

a.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel