Re: 32-on-64: pvfb issue

[Gerd Hoffmann <kraxel@suse.de>]

Keir Fraser wrote:
> On 19/1/07 11:43, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> 
>>> How about a patch to clear the page *and* write a newly-defined protocol
>>> field? Or are you still planning to kludge the bitwidth check in the
>>> backend?
>> That is better, yes.  Minimum patch attached.  For unstable I'll brew a
>> nicer version with defines and so on when adjusting the backend code to
>> be able to deal with both protocols.
> 
> Thinking about this some more -- isn't it a bit skank to have the protocol
> field embedded in the middle of the structure which it effectively defines?

When writing something new I would have placed it at the start of the
struct, but with the situation we have now it is more important not
shuffle the fields around.  All the fields before the new protocol field
have a fixed size and no alignment problems, so you can be sure the
protocol field has a fixed place everythere.  Changing the struct is
only possible after the protocol field of course.  The only pending
change is switching from the page directory to grant tables, so this
isn't too bad.

> Pvfb does interact with xenbus already, so poking a protocol field in there
> seems reasonable and makes the scheme the same as blkfront/blkback.

Would be more consistent across drivers, yes.  I still think it would be
placed better in the struct next to the fb config, but if you insist on
having it in xenstore I can do it that way too.

> Right now, since we make no
> effort to ensure protocol compat across machine architectures (for example
> we use native endianness) I suggest that we define a per-architecture
> protocol name: 'x86_32', 'x86_64', 'ia64', 'powerpc64', etc.

Hmm, not sure I like that idea, especially for pvfb as there certainly
will come the protocol switch to grant tables, so using the arch names
doesn't sound like a good idea to me.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>