For clarity:
I am not acking this patch, primarily because I am not happy with the
code in xlu_rdm_parse which is (a) the result of repeated
clone-and-hack and (b) consists of ad-hoc string pointer fiddling.
Yes, I knew you mentioned this previously but I also remember our last
deal was something as follows:
">>> Really I would prefer that this parsing was done with a miniature flex
>>> parser, rather than ad-hoc pointer arithmetic and use of strtok.
>>
>> Sorry, could you show this explicitly?
>
> Something like what was done for disk devices. See libxlu_disk_l.l
> for an example. In this case your code would be a lot less
> complicated than what you see there.
>
> After the codefreeze I would probably have some time to write it for
Sounds yourself would do this so currently I just keep the original, right?
Thanks
Tiejun
> you. (I think that would be valuable because libxlu_disk_l.l is a
> very complicated example, and I want be able to point future
> submitters at something simpler.)
>
> Ian."
Then I didn't receive any response again so I thought yourself made this
promise.
Thanks
Tiejun
If I had been able to review this patch earlier in the release cycle I
would be explictly nacking this patch. It is true that maybe someone
will have some time to clean this up later; but in practice it often
turns out that they don't - which is why we usually try not to accept
patches on the basis of promises to do further cleanup.
However, I am late to this party. I first made this complaint in
response to v7 on the 9th of July. Under the circumstances I am going
to stand aside and neither ack nor nack this patch.
The rules then say that the patch may be committed given that it has
Wei's ack as a tools maintainer.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
