On Wed, 31 Aug 2016 10:24:56 +0200
Arnd Bergmann wrote:
> On Tuesday, August 30, 2016 12:53:53 PM CEST Andy Lutomirski wrote:
> > Egads! OK, I see why this is a mess.
> >
> > I guess we should be creating the metadata from the syscall tables
> > instead of from the syscall definitions, but I gu
On 31.08.2016 02:01, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 4:28 PM, Steven Rostedt wrote:
On Tue, 30 Aug 2016 16:09:04 -0700
Andy Lutomirski wrote:
But none of this should be a problem at all for MIPS, right? AFAICT
the only problem for MIPS is that there *is* a mapping from meta
On Tuesday, August 30, 2016 12:53:53 PM CEST Andy Lutomirski wrote:
> Egads! OK, I see why this is a mess.
>
> I guess we should be creating the metadata from the syscall tables
> instead of from the syscall definitions, but I guess that's currently
> a nasty per-arch mess.
>
I've been thinking
On 31.08.2016 01:28, Steven Rostedt wrote:
On Tue, 30 Aug 2016 16:09:04 -0700
Andy Lutomirski wrote:
But none of this should be a problem at all for MIPS, right? AFAICT
the only problem for MIPS is that there *is* a mapping from metadata
to nr. If that mapping got removed, MIPS should just w
On Tue, Aug 30, 2016 at 4:28 PM, Steven Rostedt wrote:
> On Tue, 30 Aug 2016 16:09:04 -0700
> Andy Lutomirski wrote:
>
>> But none of this should be a problem at all for MIPS, right? AFAICT
>> the only problem for MIPS is that there *is* a mapping from metadata
>> to nr. If that mapping got rem
On Tue, 30 Aug 2016 16:09:04 -0700
Andy Lutomirski wrote:
> But none of this should be a problem at all for MIPS, right? AFAICT
> the only problem for MIPS is that there *is* a mapping from metadata
> to nr. If that mapping got removed, MIPS should just work, right?
Wait, where's the mapping o
On Tue, Aug 30, 2016 at 3:30 PM, Steven Rostedt wrote:
> On Tue, 30 Aug 2016 15:08:19 -0700
> Andy Lutomirski wrote:
>
>> On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt wrote:
>> > On Tue, 30 Aug 2016 14:45:05 -0700
>> > Andy Lutomirski wrote:
>> >
>> >> I wonder: could more of it be dynamical
On Tue, 30 Aug 2016 15:08:19 -0700
Andy Lutomirski wrote:
> On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt wrote:
> > On Tue, 30 Aug 2016 14:45:05 -0700
> > Andy Lutomirski wrote:
> >
> >> I wonder: could more of it be dynamically allocated? I.e. statically
> >> generate metadata with args
On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt wrote:
> On Tue, 30 Aug 2016 14:45:05 -0700
> Andy Lutomirski wrote:
>
>> I wonder: could more of it be dynamically allocated? I.e. statically
>> generate metadata with args and name and whatever but without any nr.
>> Then dynamically allocate the
On Tue, 30 Aug 2016 14:45:05 -0700
Andy Lutomirski wrote:
> I wonder: could more of it be dynamically allocated? I.e. statically
> generate metadata with args and name and whatever but without any nr.
> Then dynamically allocate the map from nr to metadata?
Any ideas on how to do that?
>
> >
On Aug 30, 2016 1:58 PM, "Steven Rostedt" wrote:
>
> On Tue, 30 Aug 2016 12:53:53 -0700
> Andy Lutomirski wrote:
>
>
> > Egads! OK, I see why this is a mess.
>
> :-)
>
> >
> > I guess we should be creating the metadata from the syscall tables
> > instead of from the syscall definitions, but I gu
On Tue, 30 Aug 2016 12:53:53 -0700
Andy Lutomirski wrote:
> Egads! OK, I see why this is a mess.
:-)
>
> I guess we should be creating the metadata from the syscall tables
> instead of from the syscall definitions, but I guess that's currently
> a nasty per-arch mess.
Yep.
>
> Could we at
On Tue, Aug 30, 2016 at 12:29 PM, Steven Rostedt wrote:
> On Tue, 30 Aug 2016 11:52:39 -0700
> Andy Lutomirski wrote:
>
>
>> Okay, I think I see what's going on. init_ftrace_syscalls() does:
>>
>> meta = find_syscall_meta(addr);
>>
>> Unless I'm missing some reason why this is a sensible
On Tue, 30 Aug 2016 11:52:39 -0700
Andy Lutomirski wrote:
> Okay, I think I see what's going on. init_ftrace_syscalls() does:
>
> meta = find_syscall_meta(addr);
>
> Unless I'm missing some reason why this is a sensible thing to do,
> this seems overcomplicated and incorrect. There i
On Tue, Aug 30, 2016 at 1:14 AM, Marcin Nowakowski
wrote:
>
>
> On 30.08.2016 01:55, Andy Lutomirski wrote:
>>
>> On Aug 29, 2016 11:30 AM, "Marcin Nowakowski"
>> wrote:
>>>
>>>
>>> Syscall metadata makes an assumption that only a single syscall number
>>> corresponds to a given method. This is t
On 30.08.2016 01:55, Andy Lutomirski wrote:
On Aug 29, 2016 11:30 AM, "Marcin Nowakowski"
wrote:
Syscall metadata makes an assumption that only a single syscall number
corresponds to a given method. This is true for most archs, but
can break tracing otherwise.
For MIPS platforms, depending
On Aug 29, 2016 11:30 AM, "Marcin Nowakowski"
wrote:
>
> Syscall metadata makes an assumption that only a single syscall number
> corresponds to a given method. This is true for most archs, but
> can break tracing otherwise.
>
> For MIPS platforms, depending on the choice of supported ABIs, up to
Syscall metadata makes an assumption that only a single syscall number
corresponds to a given method. This is true for most archs, but
can break tracing otherwise.
For MIPS platforms, depending on the choice of supported ABIs, up to 3
system call numbers can correspond to the same call - depending
18 matches
Mail list logo
