From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
linux-media <linux-media@vger.kernel.org>
Subject: Re: [RFC] Support for events with a large payload
Date: Wed, 03 Jul 2013 21:34:04 +0200 [thread overview]
Message-ID: <3981855.thaXQaXO7C@avalon> (raw)
In-Reply-To: <20130702230159.GO2064@valkosipuli.retiisi.org.uk>
On Wednesday 03 July 2013 02:01:59 Sakari Ailus wrote:
> On Mon, Jun 24, 2013 at 03:40:14PM +0200, Hans Verkuil wrote:
> ...
>
> > Since the payloads are larger I am less concerned about speed. There is
> > one problem, though: if you dequeue the event and the buffer that should
> > receive the payload is too small, then you have lost that payload. You
> > can't allocate a new, larger, buffer and retry. So this approach can only
> > work if you really know the maximum payload size.
> >
> > The advantage is also that you won't lose payloads.
>
> Forgot to answer this one --- I think it's fair to assume the user knows the
> maximum size of the payload. What we also could do in such a case is to
> return the error (e.g. ENOSPC) and put the required size to the large event
> size field. But first someone must come up with a variable size event
> without well defined maximum size for this to make much sense.
And while we're discussing use cases, Hans, what are you current use cases for
>64 bytes event payloads ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-07-03 19:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 12:14 [RFC] Support for events with a large payload Hans Verkuil
2013-06-06 21:38 ` Sakari Ailus
2013-06-18 21:22 ` Laurent Pinchart
2013-06-19 6:32 ` Hans Verkuil
2013-06-22 22:46 ` Sakari Ailus
2013-06-24 12:57 ` Hans Verkuil
2013-06-24 22:05 ` Sylwester Nawrocki
2013-06-22 20:58 ` Sakari Ailus
2013-06-24 13:40 ` Hans Verkuil
2013-07-02 22:57 ` Sakari Ailus
2013-07-02 23:01 ` Sakari Ailus
2013-07-03 19:34 ` Laurent Pinchart [this message]
2013-07-06 21:54 ` Sylwester Nawrocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3981855.thaXQaXO7C@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.