Re: [Xen-devel] Compilation error crossbuilding tools.

[Sander Bogaert <sander.bogaert@xxxxxxxxxxxxx>]

On 8 April 2013 19:08, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
>
> On Mon, 8 Apr 2013, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] Compilation error crossbuilding 
> > tools."):
> > > On Mon, 8 Apr 2013, Ian Jackson wrote:
> > > > The problem seems to be that the return
> > > > value from lseek is being passed to printf(PRIx64).  I guess we have
> > > > FILE_OFFSET_BITS=64 or some such so that the return value from lseek
> > > > is 32-bit.
> >
> > I meant =32 of course.
> >
> > > Yes, you are right.
> >
> > tools/blktap is never going to be supported on arm, is it ?
>
> Correct
>
>
> > So perhaps the right answer is just to disable the build.
>
> I agree, we should just disable it.
>
>
> > But we should figure out how to set FILE_OFFSET_BITS=64 anyway perhaps ?
>
> indeed

I disabled blktap and blktap2 in Makefile & Rules.mk, I would attach a
patch but what I did is not very clean :-) It would be disabled for
all linux builds. I didn't see a way to differentiate in architectures
in those files. The tools build fine now.

In response to Julien, after a relogin things worked as described.
I'll add this small caveat to the wiki.

A question: why is it blktap wouldn't be used on ARM?

I think I fail to see the big difference between blktap and the
'classic' blkback & blkfront split driver approach. I read the wiki
entry and the original notes from the blktap author. Is this correct:
the domU blktap driver is like dom0's blkback driver and the userspace
tools replace the classic domU's blkfront part? This provides a more
abstract interface to userspace allowing more 'freedom' in accessing
the disk from domU userspace?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel