Hi,
On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 functions
in it and
the number of PSCI calls. That's it.
IsĀ this really a problem? It is quite natural to find declarations for
something.c in something.h. By moving declaration into different file,
you are hiding it from anyone who does not carry sacred knowledge (or
use grep/cscope, yes).
And then, when people decide to extend something.c they continue to put
declarations into inappropriate.h. Just look at processor.h as a good
example. All functions it define are implemented either in traps.c or
domain.c. But functions from processor.c are defined in procinfo.h.
I can tell for sure, that this confuses newbies.
So it is not going to help to update because the header will unlikely
need to
change when adding new PSCI call.
Yes. But at least we can put comment above switch(fid):
/* Please don't forget to update call count in (v)psci.h */
See my answer on my own e-mail I sent few minutes ago. I said I will
create a the vpsci.h.
[...]
I looked at some implementation of SMCCC and those calls are either not
handled or the number are not correct.
I agree that *some* implementations can not conform to SMCCC.But, I
thought
you want Xen to follow standards as close as possible...
It is not about cannot conform but only implements partially SMCCC. I
could name
ATF for that (yes).
So it makes me more confident the call count is not something people
seem to
care.
So, you propose to fix this only when something will trip over this?
No, I am just saying that it is not that important if we get it wrong.
That number does not tell you anything. You can have 2 functions and
still does not know where they are (it is not always possible to just
probe a function ID because they may have side-effect).
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel