On 12/10/17 12:22, Manish Jaggi wrote:
Hi Julien,
Why do you omit parts of mail where I have asked a question , please
avoid skiping that removes the context.
I believe I answered it just after because you asked twice the same
thing. So may I dropped the context but the answer was there...
For your convenience here the replicated answer.
"Why? The generation of IORT is fairly standalone.
And again, this was suggestion to share in the future and an expectation
for this series. What I care the most is the generation to be fully
separated from the rest."
I raised a valid point and it was totally ignored and you asked me to
explain the rationale on a later point.
So if you choose to ignore my first point, how can I put any point.
Well, maybe you should read the e-mail more carefully because your point
have been addressed. If they are not, then please say it rather than
accusing the reviewers on spending not enough time on your series...
[...]
Now if you see both the codes are quite similar and there is redundancy
in libxl and in xen code for preparing ACPI tables for dom0 and domU.
The point I am raising is quite clear, if all other tables like MADT,
XSDT, RSDP, GTDT etc does not share a common generation code with xen
what is so special about IORT.
Either we move all generation into a common code or keep redundancy for
IORT.
I hope I have shown the code and made the point quite clear.
Please provide a technical answer rather than a simple "Why".
Why do you still continue arguing on how this is going to interact with
libxl when your only work now (as I stated in every single e-mail) is
for Dom0.
If the generation is generic enough, it will require little code to
interface. After all, you only need:
- informations (e.g DeviceID, MasterID...)
- buffer for writing the generated IORT
So now it is maybe time for you to suggest an interface we can discuss on.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
