Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement libxl__blktap_devpath and libxl__device_destroy_tapdisk

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: 30 October 2012 11:26
> To: Thanos Makatos
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
> libxl__blktap_devpath and libxl__device_destroy_tapdisk
> 
> > > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > > >
> > > >  LIBXLU_LIBS =
> > > > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> > > >         ln -sf $< $@
> > > >
> > > >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > > > +       make -C $(XEN_BLKTAP3)
> > >
> > > This shouldn't be needed if the tools/Makefile has things ordered
> > > correctly. It is reasonable for tools/libxl to assume that its
> > > prerequisites are already built. People who build with make -C
> > > tools/libxl need to take care of this themself.
> >
> > I've added this so I can build libxl from within tools/libxl without
> > worrying about building tools/blktap3, it simplifies development,
> > doesn't it?
> 
> If we did this for everything our Makefiles would be an unholy mess.
> Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry
> this patch locally.

Ok.

> 
> > > > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > > > +        libxl_disk_format format) {
> > > > +    const char *type = NULL;
> > > > +    char *params = NULL;
> > > > +    struct tap_list tap;
> > > > +    int err = 0;
> > > > +
> > > > +    type = libxl__device_disk_string_of_format(format);
> > > > +
> > > > +    /*
> > > > +     * Ensure that no other tapdisk is serving this path.
> > > > +     * XXX Does libxl protect us against race conditions?
> > >
> > > Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?
> >
> > I don't think so, I'll have a look. This could be a problem if two
> > guest VMs are created at the same time and they both use the same
> VDI,
> > obviously a corner case. Should we protect against that or we're
> > getting paranoid?
> 
> TBH I'm not sure what the semantics of sharing these things are
> supposed to be.
> 
> Ian

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