From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [patch/rfc] multiprotocol blkback drivers (32-on-64) Date: Mon, 18 Dec 2006 17:58:34 +0000 Message-ID: References: <4586D974.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4586D974.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Gerd Hoffmann Cc: Xen devel list List-Id: xen-devel@lists.xenproject.org Gerd's description is along the lines of what I would implement myself. How does your bi-modal approach work? -- Keir On 18/12/06 17:09, "Jan Beulich" wrote: > I understand you favor this over the bi-modal approach I took? Any specific > advantages? Jan > >>>> Gerd Hoffmann 18.12.06 17:39 >>> > Hi, > > This is a patch for the block interface, frontend drivers, backend > drivers and tools to support multiple ring protocols. Right there are > now just two: the 32bit and the 64bit one. If needed it can be extended. > > Interface changes (io/blkif.h) > * Have both request structs there, with "v1" and "v2" added to the > name. The old name is aliased to the native protocol of the > architecture. > * Add helper functions to convert v1/v2 requests to native. > > Frontend changes: > * Create a new node "protocol", add the protocol number it speaks > there. > > Backend changes: > * Look at the "protocol" number of the frontend and switch ring > handling accordingly. If the protocol node isn't present it assumes > native protocol. > * As the request struct is copied anyway before being processed (for > security reasons) it is converted to native at that point so most > backend code doesn't need to know what the frontend speaks. > * In case of blktap this is completely transparent to userspace, the > kernel/userspace ring is always native no matter what the frontend > speaks. > > Tools changes: > * Add one more option to the disk configuration, so one can specify the > protocol the frontend speaks in the config file. This is needed for > old frontends which don't advertise the protocol they are speaking > themself. > I'm not that happy with this approach, but it works for now and I'm > kida lost in the stack of python classes doing domain and device > handling ... > > Consider the code experimental, not all frontend/backend combinations > are tested. > > Comments? Questions? Suggesions? > > cheers, > Gerd > > PS: Anyone working on blkback/blktap code sharing? While walking > through the code I've noticed quite alot of it is cut&paste ...