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

To:	"Steven Rostedt" <srostedt@xxxxxxxxxx>
Subject:	[Xen-devel] Re: [PATCH] Turn blktap tapfds into a link list
From:	"Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date:	Fri, 29 Sep 2006 11:41:05 -0700
Cc:	xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date:	Fri, 29 Sep 2006 11:41:33 -0700
Domainkey-signature:	a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IRwbazmsjcCOS8JmaMIMr+7F9PAFSWwyeN3uhGHloHjik2oLLJTMoJ0MJeimdrZRtALCOMQ2EWXhE6mbfI9LzK+7LKcrv856Qgj8kmgqHpafcqWzj4cJhDWrAw7kiSTMNFM4/YLMpGgBxbRQNz+p7FAYs+HuOYGweTK0ujqlbK8=
Envelope-to:	www-data@xxxxxxxxxxxxxxxxxx
In-reply-to:	<451D66BD.3040205@xxxxxxxxxx>
List-help:	<mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id:	Xen developer discussion <xen-devel.lists.xensource.com>
List-post:	<mailto:xen-devel@lists.xensource.com>
List-subscribe:	<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe:	<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References:	<451C9A67.9000805@xxxxxxxxxx> <eacc82a40609291013x72ed2cf0x77e3e6b977146005@xxxxxxxxxxxxxx> <451D66BD.3040205@xxxxxxxxxx>
Sender:	xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

>  - 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