Re: EF_BPF_GNU_XBPF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> Hello BPF people!
>>
>> In order to ease the testing of the GCC bpf port we are adding a number
>> of extensions to the BPF ISA.
>>
>> We would like to use one bit in the e_flags field of the ELF header in
>> order to flag that the code in the ELF file is not plain eBPF:
>>
>> For EM_BPF:
>>
>> #define EF_BPF_GNU_XBPF 0x00000001
>>
>> Any objection?
>
> I've looked at your lpc slides and the extensions don't look like BPF
> extensions.
> At least I didn't see any attempt to make them verifiable.

It is an extension in the sense it is a superset of BPF.  Call it a
variant if you want.

As such, the property of being verifiable is irrelevant.  If we wanted
the extensions to be verifiable we would probably ask for them to be
added to BPF proper.  That's not the case, and that's precisely the
reason why we need to use that bit.

> In that sense it's not BPF and it's not correct to use EM_BPF for it.
> I suggest to define your own EM for your ISA.

Sorry, but that's not how ELF machine numbers work :)

It is perfectly normal, and also common practice, to use the same
machine code for several variants of the same base architecture, and I
see no reason for EM_BPF to be handled differently.  It would be silly,
and very inconvenient, to allocate a new machine number.

I don't think you people are using that bit in e_flags (or any bit, for
that matter).  So we just need to agree in reserving that bit for
EF_BPF_GNU_XBPF.

Shouldn't be a big matter surely?  There are 31 bits left ;)



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux