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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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

> > > +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