This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] libxl: blktap2 portiblity fixes

Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxl: blktap2 portiblity 
> On Monday 26 July 2010 16:53:02 Ian Jackson wrote:
> > Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxl: blktap2 portiblity 
> fixes"):
> > > Can you use the c/s numbers, please?
> >
> > Changeset numbers are not guaranteed to be meaningful outside a
> > particular tree, particularly in the presence of merges.
> >
> > > It was not necessary to backout c/s 21834 as this wasn't the root cause.
> >
> > I think by 21834 you mean 24277e3237ca.
> No, c/s 21834 has the hash e76befc7fe2d.

Thus proving my point.  In my tree 21834 is 24277e3237ca :-).
I'm sorry that I may have reverted more than was necessary.  I just
wanted to get everything back to a known good state.

> That's doable but I don't see if a standalone const-correctness
> patch makes sense just to make gcc happy with an other patch.

The reason is that const-correctness changes shouldn't be checked in
as "portability to netbsd".  It also means that if for any reason
there is some argument or rework needed for other parts of your
patchset, it's possible to apply the ones which are clearly right.
And it simplifies the review if you can explain for each patch what
one thing it does.

> > This should be done by moving the relevant #includes to osdep.h, where
> > all this kind of thing should be done.
> Should this header be re-used by tools/console/daemon/io.c ?
> If yes, where is the best place to put osdep.h ?

Perhaps.  That would make it a public header rather than a private
one.  On the other hand xenconsoled is not a libxl caller so it's not
clear where that public header would live.  I don't think that we need
to cross this bridge right away.  Regardless, finding an example
elsewhere in the tree, in directory which doesn't have an osdep.h,
isn't a good reason not to put #ifdef #include stuff in the header we
do have for it in libxl.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>