O_OOB ABI

O_OOB ABI

[Jan Kiszka]

Hi Philippe,

FYI. I assume this is an evl-only topic - if at all:

"O_OOB changed from 010000000000 (1<<30) to (1 << 29) starting with the
v7.2 port. That changes the userspace ABI compared with 6.18 and ≤7.1."
(opus-5.5, while reviewing my 6.18 rebase)

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: O_OOB ABI

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Hi Philippe,
>
> FYI. I assume this is an evl-only topic - if at all:
>
> "O_OOB changed from 010000000000 (1<<30) to (1 << 29) starting with the
> v7.2 port. That changes the userspace ABI compared with 6.18 and ≤7.1."
> (opus-5.5, while reviewing my 6.18 rebase)
>

Correct. Only the evl core enables the oob capability for regular
drivers, which userland may request by setting O_OOB in the open
flags. This is out of scope for cobalt.

-- 
Philippe.

Re: O_OOB ABI

[Jan Kiszka]

On 11.11.26 18:32, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> Hi Philippe,
>>
>> FYI. I assume this is an evl-only topic - if at all:
>>
>> "O_OOB changed from 010000000000 (1<<30) to (1 << 29) starting with the
>> v7.2 port. That changes the userspace ABI compared with 6.18 and ≤7.1."
>> (opus-5.5, while reviewing my 6.18 rebase)
>>
> 
> Correct. Only the evl core enables the oob capability for regular
> drivers, which userland may request by setting O_OOB in the open
> flags. This is out of scope for cobalt.
> 

OK, but shifting the bit was no problem for existing evl applications?
Handled by the ABI matching between kernel and library?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: O_OOB ABI

[Jan Kiszka]

On 11.11.26 18:54, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 11.11.26 18:32, Philippe Gerum wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> Hi Philippe,
>>>>
>>>> FYI. I assume this is an evl-only topic - if at all:
>>>>
>>>> "O_OOB changed from 010000000000 (1<<30) to (1 << 29) starting with the
>>>> v7.2 port. That changes the userspace ABI compared with 6.18 and ≤7.1."
>>>> (opus-5.5, while reviewing my 6.18 rebase)
>>>>
>>>
>>> Correct. Only the evl core enables the oob capability for regular
>>> drivers, which userland may request by setting O_OOB in the open
>>> flags. This is out of scope for cobalt.
>>>
>>
>> OK, but shifting the bit was no problem for existing evl applications?
> 
> It was 'only' an issue for applications built against ABI <= 46 which
> could not run on a 7.2+ kernel as a consequence of this upstream change.
> 
>> Handled by the ABI matching between kernel and library?
>>
> 
> Yes, this has triggered ABI 47.
> 

Thanks for clarifying - maybe the AI will find this thread and avoid to
flag this again. ;)

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: O_OOB ABI

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 11.11.26 18:54, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 11.11.26 18:32, Philippe Gerum wrote:
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> Hi Philippe,
>>>>>
>>>>> FYI. I assume this is an evl-only topic - if at all:
>>>>>
>>>>> "O_OOB changed from 010000000000 (1<<30) to (1 << 29) starting with the
>>>>> v7.2 port. That changes the userspace ABI compared with 6.18 and ≤7.1."
>>>>> (opus-5.5, while reviewing my 6.18 rebase)
>>>>>
>>>>
>>>> Correct. Only the evl core enables the oob capability for regular
>>>> drivers, which userland may request by setting O_OOB in the open
>>>> flags. This is out of scope for cobalt.
>>>>
>>>
>>> OK, but shifting the bit was no problem for existing evl applications?
>> 
>> It was 'only' an issue for applications built against ABI <= 46 which
>> could not run on a 7.2+ kernel as a consequence of this upstream change.
>> 
>>> Handled by the ABI matching between kernel and library?
>>>
>> 
>> Yes, this has triggered ABI 47.
>> 
>
> Thanks for clarifying - maybe the AI will find this thread and avoid to
> flag this again. ;)
>

Maybe an AI will end up writing the whole thing and start complaining
about its own mistakes before fixing them, blaming the insufficient
effort level of "the other guy". Like humans usually do.

-- 
Philippe.