On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
...
> Ok, given you post the remaining two RFCs later on this window as
> you indicate, I have no objections:
>
> Acked-by: Daniel Borkmann <[email protected]>
Ping, Alexei, are you still sending the patch for bpf_common.h or
do you want me to take care of this?
Cheers,
Daniel
On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann <[email protected]> wrote:
> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
> ...
>>
>> Ok, given you post the remaining two RFCs later on this window as
>> you indicate, I have no objections:
>>
>> Acked-by: Daniel Borkmann <[email protected]>
>
>
> Ping, Alexei, are you still sending the patch for bpf_common.h or
> do you want me to take care of this?
It's not forgotten.
I'm not sending it only because net-next is closed
and it seems to be -next material.
On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
> On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann <[email protected]> wrote:
>> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
>> ...
>>>
>>> Ok, given you post the remaining two RFCs later on this window as
>>> you indicate, I have no objections:
>>>
>>> Acked-by: Daniel Borkmann <[email protected]>
>>
>> Ping, Alexei, are you still sending the patch for bpf_common.h or
>> do you want me to take care of this?
>
> It's not forgotten.
> I'm not sending it only because net-next is closed
> and it seems to be -next material.
Well, the point was since it's UAPI you're modifying, that it needs
to be shipped before it first gets exposed to user land ...
I think that should be reason enough ... there's no point in doing
this at a later point in time.
On Tue, Oct 14, 2014 at 12:34 AM, Daniel Borkmann <[email protected]> wrote:
> On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
>>
>> On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann <[email protected]>
>> wrote:
>>>
>>> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
>>> ...
>>>>
>>>>
>>>> Ok, given you post the remaining two RFCs later on this window as
>>>> you indicate, I have no objections:
>>>>
>>>> Acked-by: Daniel Borkmann <[email protected]>
>>>
>>>
>>> Ping, Alexei, are you still sending the patch for bpf_common.h or
>>> do you want me to take care of this?
>>
>>
>> It's not forgotten.
>> I'm not sending it only because net-next is closed
>> and it seems to be -next material.
>
>
> Well, the point was since it's UAPI you're modifying, that it needs
> to be shipped before it first gets exposed to user land ...
>
> I think that should be reason enough ... there's no point in doing
> this at a later point in time.
Moving common #defines from filter.h into bpf_common.h can
be done at any point in time. For the sake of argument if
there is an app that includes both filter.h and bpf.h, it will
continue to work just fine.
Anyway, since you insist, I will send it now, though it definitely
can wait.
On 10/14/2014 10:43 AM, Alexei Starovoitov wrote:
> On Tue, Oct 14, 2014 at 12:34 AM, Daniel Borkmann <[email protected]> wrote:
>> On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
>>>
>>> On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann <[email protected]>
>>> wrote:
>>>>
>>>> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
>>>> ...
>>>>>
>>>>> Ok, given you post the remaining two RFCs later on this window as
>>>>> you indicate, I have no objections:
>>>>>
>>>>> Acked-by: Daniel Borkmann <[email protected]>
>>>>
>>>> Ping, Alexei, are you still sending the patch for bpf_common.h or
>>>> do you want me to take care of this?
>>>
>>> It's not forgotten.
>>> I'm not sending it only because net-next is closed
>>> and it seems to be -next material.
>>
>> Well, the point was since it's UAPI you're modifying, that it needs
>> to be shipped before it first gets exposed to user land ...
>>
>> I think that should be reason enough ... there's no point in doing
>> this at a later point in time.
>
> Moving common #defines from filter.h into bpf_common.h can
> be done at any point in time. For the sake of argument if
> there is an app that includes both filter.h and bpf.h, it will
> continue to work just fine.
Correct, but the argument was that we can _avoid_ this from the
very beginning. Thus, user space applications making use of eBPF
only need to include <linux/bpf.h>, nothing more.
Doing this at any later point in time will just lead to the need
to include both headers.