> -----Original Message-----
> From: Ian Jackson <ian.jack...@citrix.com>
> Sent: 29 November 2019 16:08
> To: Durrant, Paul <pdurr...@amazon.com>
> Cc: Wei Liu <w...@xen.org>; Anthony Perard <anthony.per...@citrix.com>; xen-
> de...@lists.xenproject.org; George Dunlap <george.dun...@citrix.com>;
> Andrew Cooper <andrew.coop...@citrix.com>; Jan Beulich
> <jbeul...@suse.com>; Julien Grall <jul...@xen.org>; Konrad Rzeszutek Wilk
> <konrad.w...@oracle.com>; Stefano Stabellini <sstabell...@kernel.org>;
> Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>; Volodymyr
> Babchuk <volodymyr_babc...@epam.com>; Roger Pau Monne
> <roger....@citrix.com>
> Subject: RE: [PATCH-for-4.13 v5] Rationalize max_grant_frames and
> max_maptrack_frames handling
>
> Durrant, Paul writes ("RE: [PATCH-for-4.13 v5] Rationalize
> max_grant_frames and max_maptrack_frames handling"):
> > > -----Original Message-----
> > > From: Ian Jackson <ian.jack...@citrix.com>
> ...
> > > Is there some reason we wouldn't use ~0 to mean default ?
> > >
> > > In the tools area we normally spell this as
> > > ~(some appropriate type)0
> > > to make sure it has the right width. But if we know the type and it
> > > is of fixed length, as here, 0xffffffffu is OK too.
> > >
> > > > The type change here makes me feel a bit uncomfortable, though in
> > > > practice it may not matter. I don't see anyone would specify a value
> > > > that would become negative when cast from uint32 to integer.
> > >
> > > The problem with the type change is that in principle we have to audit
> > > all the places the variables are used.
> >
> > Can a toolstack maintainer please come up with a concrete suggestion as
> to what the patch should do then? It's now at v6 and time is short.
>
> I think our proposal is to drop the type change, continue to use
> uint32_t everwhere for these values, and specify the "use default"
> value to be all-bits-set.
>
Where? Everywhere or just in buildinfo? The switch from uint32_t to int32_t in
the domctl does not, of course, change the width at all.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
