On 6/24/20 8:05 PM, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>>>> On Mon, 22 Jun 2020, Julien Grall wrote:
>>>>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide
>>>>>>>> it
>>>>>>>> via
>>>>>>>>
>>>>>>>> CFLAGS or something. This can also be done for the location of Xen
>>>>>>>> headers.
>>>>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative
>>>>>>> would be to allow the user to specify through the Kconfig.
>>>>>> You mean specifying via Kconfig something like "0x00040d00"?
>>>>> Possibly yes.
>>>>>
>>>>>> And what about the headers? How will we provide their location if we
>>>>>> decide
>>>>>> not to include those
>>>>>>
>>>>>> in the tree?
>>>>> I would do through Kconfig as well.
>>>> If we specify the external location of the Xen headers via Kconfig, it
>>>> seems to me that we should be able to detect the interface version
>>>> automatically from any Makefile as part of the build. No need to ask the
>>>> user.
>>>>
>>>> However, if Oleksandr is thinking of using the Xen headers for the
>>>> hypercalls definitions, then I think we might not need external headers
>>>> at all because that is a stable interface, as Julien wrote. We could
>>>> just define our own few headers for just what you need like Linux does.
>>> This is a good idea: I'll try to get the minimal set of headers from Linux
>>>
>>> instead of Xen as those seem to be well prepared for such a use-case. This
>>>
>>> way we'll have headers in U-boot tree and guarantee that we have a minimal
>>>
>>> subset which is easier to maintain. I'll keep you updated on the progress
>> We've managed to strip the headers and remove __XEN__ and the rest
>> definitions
>>
>> we were talking about. So, these are now the minimal required set of headers
>>
>> that allows U-boot to build serial and block drivers. Please take a look at
>> [1]
>>
>> Pull request for comments is at [2]
> I think this is the right approach. There is no build-dependency on Xen
> anymore, is that correct?
No dependency
