From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v4 4/9] tools/libxc: Scripts for inspection/valdiation of legacy and new streams Date: Wed, 7 May 2014 13:27:27 +0100 Message-ID: <536A26AF.3040109@citrix.com> References: <1398883012-28413-1-git-send-email-andrew.cooper3@citrix.com> <1398883012-28413-5-git-send-email-andrew.cooper3@citrix.com> <1399464201.13430.24.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1399464201.13430.24.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Frediano Ziglio , David Vrabel , Xen-devel List-Id: xen-devel@lists.xenproject.org On 07/05/14 13:03, Ian Campbell wrote: > On Wed, 2014-04-30 at 19:36 +0100, Andrew Cooper wrote: > > I suppose these are for debugging/inspecting rather than to be used in > practice? In which case I don't think there's any need for me to review > especially. > > My only thought is that the need to repeat all of the data types is a > bit unfortunate and risks bugs and/or deviation. I can well imagine you > don't want to invent up an IDL or anything, is there anything out there > which might suffice? SWIG seems like overkill. > http://code.google.com/p/ctypesgen/ perhaps? > > ("these debug tools are not important enough to stress over" is a valid > rebuttal here IMHO). > > Since submitting this series, I have discarded "inspect-legacy32.py". "generate.py" is also debugging which can safely disappear when this series becomes non-RFC I expect validate.py to remain even if only as a developer script. The new "legacy.py" (name subject to sensible suggestions) is the converstion tool from legacy migration streams. Given two fds, it picks apart the legacy format and writes a v2 stream. Both legacy.py and validate.py depend on streamspec.py as the stream specification. The risk of divergence from stream_format.h is a concern, but streamspec.py also includes type->"str" dictionaries to match the lookup functions in common.c. On the other hand, I cant see any way to generate one from the other without radically changing the use of python struct packing strings, which is the RightWay to do the python side of things. ~Andrew