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

Reply via email to