Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1687071 > unrolled thread

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] usb: gadget: functions: add ftrace export over USB Pratyush Anand <panand@redhat.com> - 2017-07-14 07:40 +0200
    Re: [PATCH] usb: gadget: functions: add ftrace export over USB Felipe Balbi <felipe.balbi@linux.intel.com> - 2017-07-14 09:00 +0200

#1687071 — Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Hi Felipe,

On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote:
> +static void notrace ftrace_write(struct trace_export *ftrace, const void *buf,
> +				 unsigned int len)
> +{
> +	struct usb_ftrace		*trace = ftrace_to_trace(ftrace);
> +	struct usb_request		*req = next_request(&trace->list);
> +
> +	if (!req)
> +		return;
> +
> +	if (!trace->in->enabled)
> +		return;
> +
> +	req->buf = kmemdup(buf, len, GFP_ATOMIC);

Probably we can avoid the copy of trace data.

We can make write() call of "struct trace_export" as posted. Can have a 
write_complete() callback function implemented in  struct trace_export,which 
can be called from your ftrace_complete().

We need to execute __buffer_unlock_commit() only in write_complete() in case 
of ftrace_export is enabled.


> +	req->length = len;
> +	req->context = trace;
> +	req->complete = ftrace_complete;
> +	list_move_tail(&req->list, &trace->pending);
> +
> +	schedule_work(&trace->queue_work);
> +}
> +

--
Pratyush

[toc] | [next] | [standalone]

#1687118

[Multipart message — attachments visible in raw view] — view raw

Hi,

Pratyush Anand <panand@redhat.com> writes:
> Hi Felipe,
>
> On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote:
>> +static void notrace ftrace_write(struct trace_export *ftrace, const void *buf,
>> +				 unsigned int len)
>> +{
>> +	struct usb_ftrace		*trace = ftrace_to_trace(ftrace);
>> +	struct usb_request		*req = next_request(&trace->list);
>> +
>> +	if (!req)
>> +		return;
>> +
>> +	if (!trace->in->enabled)
>> +		return;
>> +
>> +	req->buf = kmemdup(buf, len, GFP_ATOMIC);
>
> Probably we can avoid the copy of trace data.

not with current setup. I have no control over data's lifetime. If I
did, then this would be zero-copy.

> We can make write() call of "struct trace_export" as posted. Can have a 

that would require further patching in trace core which is not part of
$subject. Also, if we turn this into asynchronous calls, we could run
out of trace buffer before the first chunk of data is transferred over
to the other side.

> write_complete() callback function implemented in  struct trace_export,which 
> can be called from your ftrace_complete().

well, you're welcome to propose a patch :-)

-- 
balbi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web