On 11/9/18 1:28 PM, Edward Cree wrote:
> On 09/11/18 21:14, Alexei Starovoitov wrote:
>> same link, but i cannot make it right now.
>> have to extinguish few fires.
>> may be at 2pm (unlikely) or 3pm (more likely) PST?
>
> Yep I can do either of those, just let me know which when you can.
still
On 09/11/18 21:14, Alexei Starovoitov wrote:
> same link, but i cannot make it right now.
> have to extinguish few fires.
> may be at 2pm (unlikely) or 3pm (more likely) PST?
Yep I can do either of those, just let me know which when you can.
On 11/9/18 12:00 PM, Edward Cree wrote:
> On 09/11/18 04:35, Alexei Starovoitov wrote:
>> On Thu, Nov 08, 2018 at 10:56:55PM +, Edward Cree wrote:
>>> think this question of maps should be discussed in tomorrow's
>>> call, since it is when we start having other kinds of instances
>> turned
On 09/11/18 04:35, Alexei Starovoitov wrote:
> On Thu, Nov 08, 2018 at 10:56:55PM +, Edward Cree wrote:
>> think this question of maps should be discussed in tomorrow's
>> call, since it is when we start having other kinds of instances
> turned out most of us have a conflict, so the earliest
On Thu, Nov 08, 2018 at 10:56:55PM +, Edward Cree wrote:
> On 08/11/18 19:42, Alexei Starovoitov wrote:
> > same link let's continue at 1pm PST.
> So, one thing we didn't really get onto was maps, and you mentioned that it
> wasn't really clear what I was proposing there.
let's discuss
On 11/8/18 2:56 PM, Edward Cree wrote:
> On 08/11/18 19:42, Alexei Starovoitov wrote:
>> same link let's continue at 1pm PST.
> So, one thing we didn't really get onto was maps, and you mentioned that it
> wasn't really clear what I was proposing there.
> What I have in mind comes in two
On 08/11/18 19:42, Alexei Starovoitov wrote:
> same link let's continue at 1pm PST.
So, one thing we didn't really get onto was maps, and you mentioned that it
wasn't really clear what I was proposing there.
What I have in mind comes in two parts:
1) map type. A new BTF_KIND_MAP with metadata
On Thu, Nov 8, 2018 at 10:21 AM Alexei Starovoitov
wrote:
>
> On Thu, Nov 08, 2018 at 05:58:56PM +, Edward Cree wrote:
> >
> > > Happy to jump on the call to explain it again.
> > > 10:30am pacific time works for me tomorrow.
> > That works for me (that's in ~30 minutes from now if I've
On Thu, Nov 08, 2018 at 05:58:56PM +, Edward Cree wrote:
>
> > Happy to jump on the call to explain it again.
> > 10:30am pacific time works for me tomorrow.
> That works for me (that's in ~30 minutes from now if I've converted
> correctly.) Please email me offlist with the phone number to
On 07/11/18 21:49, Alexei Starovoitov wrote:
> On Wed, Nov 07, 2018 at 07:29:31PM +, Edward Cree wrote:
>> Whereas I don't, and I don't feel like my core criticisms have
>> been addressed _at all_. The only answer I get to "BTF should
>> store type and instance information in separate
On Wed, Nov 07, 2018 at 07:29:31PM +, Edward Cree wrote:
> Whereas I don't, and I don't feel like my core criticisms have
> been addressed _at all_. The only answer I get to "BTF should
> store type and instance information in separate records" is
> "it's a debuginfo",
...
> I am just
On 07/11/18 00:59, Alexei Starovoitov wrote:
> Function name and function argument names are part of the same debug info.
> Splitting them makes no sense.
... except where combining them involves creating pain elsewhere.
Sure the function name *could* go in the type record, but there
still needs
On Tue, Nov 06, 2018 at 10:58:42PM +, Edward Cree wrote:
> share its type record with 'foo'. And partly just because the
> name of the function itself is no more part of its type than the
> name of an integer variable is part of the integer's type.
correct. function name is not part of
On 06/11/18 21:56, Alexei Starovoitov wrote:
> that looks very weird to me. Why split func name from argument names?
> The 'function name' as seen by the BTF may not be the symbol name
> as seen in elf file.
The symbol name will be in the symbol table, which is not the same
thing as the functions
On Tue, Nov 06, 2018 at 06:52:11PM +, Edward Cree wrote:
> On 06/11/18 06:29, Alexei Starovoitov wrote:
> > BTF is not pure type information. BTF is everything that verifier needs
> > to know to make safety decisions that bpf instruction set doesn't have.
> Yes, I'm not disputing that and
On 06/11/18 06:29, Alexei Starovoitov wrote:
> BTF is not pure type information. BTF is everything that verifier needs
> to know to make safety decisions that bpf instruction set doesn't have.
Yes, I'm not disputing that and never have.
I'm just saying that it will be much cleaner and better if
On Thu, Nov 01, 2018 at 09:08:37PM +, Edward Cree wrote:
> I've spent a bit more time thinking about / sleeping on this, and I
> still think there's a major disagreement here. Basically it seems
> like I'm saying "the design of BTF is wrong" and you're saying "but
> it's the design" (with
I've spent a bit more time thinking about / sleeping on this, and I
still think there's a major disagreement here. Basically it seems
like I'm saying "the design of BTF is wrong" and you're saying "but
it's the design" (with the possible implication — I'm not entirely
sure — of "but that's
On Fri, Oct 19, 2018 at 10:26:53PM +0100, Edward Cree wrote:
> On 19/10/18 20:36, Martin Lau wrote:
> > On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
> >> But you *do* have such a new section.
> >> The patch comment talks about a 'FuncInfo Table' which appears to
> > Note that the
On 19/10/18 20:36, Martin Lau wrote:
> On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
>> But you *do* have such a new section.
>> The patch comment talks about a 'FuncInfo Table' which appears to
> Note that the new section, which contains the FuncInfo Table,
> is in a new ELF
On Fri, Oct 19, 2018 at 12:36:49PM -0700, Martin Lau wrote:
> On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
> > On 18/10/18 22:19, Martin Lau wrote:
> > > As I have mentioned earlier, it is also special to
> > > the kernel because the BTF verifier and bpf_prog_load()
> > > need to
On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
> On 18/10/18 22:19, Martin Lau wrote:
> > As I have mentioned earlier, it is also special to
> > the kernel because the BTF verifier and bpf_prog_load()
> > need to do different checks for FUNC and FUNC_PROTO to
> > ensure they are
On 18/10/18 22:19, Martin Lau wrote:
> As I have mentioned earlier, it is also special to
> the kernel because the BTF verifier and bpf_prog_load()
> need to do different checks for FUNC and FUNC_PROTO to
> ensure they are sane.
>
> First, we need to agree that the kernel needs to verify
> them
On Thu, Oct 18, 2018 at 08:41:52PM +0100, Edward Cree wrote:
> On 18/10/18 19:12, Martin Lau wrote:
> > The BTF verification and bpf_prog_load() has to treat
> > them differently.
> >
> > Are you suggesting they can be treated the same for
> > the kernel verification purpose?
> >
> > or
> >
> >
On 18/10/18 19:12, Martin Lau wrote:
> The BTF verification and bpf_prog_load() has to treat
> them differently.
>
> Are you suggesting they can be treated the same for
> the kernel verification purpose?
>
> or
>
> The concern is, having two kind, BTF_KIND_FUNC_PROTO and
> BTF_KIND_FUNC, is
On Thu, Oct 18, 2018 at 05:47:11PM +0100, Edward Cree wrote:
> On 17/10/18 18:50, Martin Lau wrote:
> > On Wed, Oct 17, 2018 at 10:25:21AM -0700, Yonghong Song wrote:
> >> What you stated is true, BTF_KIND_FUNC_PROTO corresponds to
> >> dwarf subroutine tag which has no name while BTF_KIND_FUNC
>
On 17/10/18 18:50, Martin Lau wrote:
> On Wed, Oct 17, 2018 at 10:25:21AM -0700, Yonghong Song wrote:
>> What you stated is true, BTF_KIND_FUNC_PROTO corresponds to
>> dwarf subroutine tag which has no name while BTF_KIND_FUNC
>> must have a valid name. The original design is to have both
>> since
On Wed, Oct 17, 2018 at 10:25:21AM -0700, Yonghong Song wrote:
>
>
> On 10/17/18 9:13 AM, Edward Cree wrote:
> > On 17/10/18 08:23, Yonghong Song wrote:
> >> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
> >> support to the type section. BTF_KIND_FUNC_PROTO is used
> >> to specify the
On 10/17/18 9:13 AM, Edward Cree wrote:
> On 17/10/18 08:23, Yonghong Song wrote:
>> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
>> support to the type section. BTF_KIND_FUNC_PROTO is used
>> to specify the type of a function pointer. With this,
>> BTF has a complete set of C types
On 17/10/18 08:23, Yonghong Song wrote:
> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
> support to the type section. BTF_KIND_FUNC_PROTO is used
> to specify the type of a function pointer. With this,
> BTF has a complete set of C types (except float).
>
> BTF_KIND_FUNC is used to
30 matches
Mail list logo
