[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 04/11] libxl: move libxl__device_from_disk to libxl_internal.c
On Fri, 18 May 2012, Ian Campbell wrote: > On Fri, 2012-05-18 at 16:16 +0100, Roger Pau Monne wrote: > > Ian Campbell wrote: > > > On Fri, 2012-05-18 at 15:55 +0100, Roger Pau Monne wrote: > > >>> @@ -429,6 +429,46 @@ libxl_device_model_version > > >> libxl__device_model_version_running(libxl__gc *gc, > > >>> return value; > > >>> } > > >>> > > >>> +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > > >>> + libxl_device_disk *disk, > > >>> + libxl__device *device) > > >> I think this should be moved to libxl_device instead of > > >> libxl_internal, since it's a device related function. > > > > > > I think it'd be better to leave it in the original file, libxl is so > > > confused about what goes where that it doesn't really matter... > > > > > > If we do want to move it we can do it later as a pure code motion > > > change. > > > > In my hotplug series I'm moving most libxl_device_{...}_add to provide > > an internal implementation that takes an ao, making something quite > > similar to what Stefano does, if I start moving all those to > > libxl_internal we will fill this file with functions that could be > > somewhere else (libxl_device). > > I didn't propose moving this function tolibxl_internal, quite the > opposite. I proposed leaving it in libxl.c where it is (or rather , > where the body current effectively is). If and when we want to move it > we can do that as a separate pure code motion change. Do we have an agreement that I should repost this patch keeping libxl__device_from_disk in libxl.c? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |