This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>