All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>, <linux-iio@vger.kernel.org>,
	"Hartmut Knaack" <knaack.h@gmx.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	"Eugen Hristev" <eugen.hristev@microchip.com>
Subject: Re: Potential IIO meeting / future directions discussion at ELCE 2018 - Edinburgh 22-24 Oct
Date: Sun, 1 Jul 2018 12:09:27 +0100	[thread overview]
Message-ID: <20180701120927.000061dc@huawei.com> (raw)
In-Reply-To: <CAEnQRZA16Abt6GYYVk1rKGqTLWT7hPcw0=iMQLqkWefp=JekOg@mail.gmail.com>

On Fri, 29 Jun 2018 10:48:01 +0300
Daniel Baluta <daniel.baluta@gmail.com> wrote:

> On Thu, Jun 28, 2018 at 8:11 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> > On 06/28/2018 04:24 PM, Jonathan Cameron wrote:  
> >> Hi All,
> >>
> >> I know at least a few IIO developers are likely to be at the Embedded Linux
> >> Conference Europe in a few months time.   Hence this email is exploring the
> >> possibility of us doing something we have never done for IIO before and have
> >> a formal meet up.   I would propose the topics to discuss would be loosely
> >> around future directions for IIO development.  This might consist of actual
> >> proposals or simply discussion of pain points.
> >>
> >> I'm not sure how long a session would be sensible, but one possibility is
> >> to propose it as a BoF as that fits in their standard schedule without needing
> >> any additional organization - I think by default that only gives us an hour or
> >> so.  However, the deadline to propose one of those is this Sunday so things are
> >> little tight.  We don't need a fully planned schedule but it would be good to
> >> have made a start.  If we decide to do this I'll write an abstract and submit it.
> >>
> >> So I'm looking for topics and some idea of who is going to be there
> >> or might be persuaded to make the trip!  
> > I'll be at ELCE and I'm very interested in sitting down and having a longer
> > discussion about the state of the framework, potential future developments,
> > their requirements and how to get there.
> >
> > I think a BoF would be good as a discussion starter and then maybe follow up
> > on that with the people who are interested and have a more focused discussion.  
> 
> I'll be there. Although, I'm mainly involved now with IIO via Outreachy/GSoC
> I think it is a good idea to have the meeting in the form of a BoF.
> 
> CC-ing Eugen, I noticed he has done a lot of work recently in the IIO area.
> 
> thanks,
> Daniel.

Cool - so it sounds like there is enough interest (given the very short notice!)
to apply for a BoF.  The tricky bit is I need to put together an abstract by
later today.

So off the top of my head topics that come to mind are:

1. Userspace ABI pain points - the recent extensive discussions around the energy
   meters have certainly shown there are some nasty corners.  The currently open
   question about floating point support is also interesting (though we may well have
   come to a conclusion about that long before October).
 
2. High performance usecases - (Lars leading this one if he is willing)
   DMA buffers and moving that infrastructure forward.  There is a lot of
   out of kernel code around this currently, it would be nice to drag it in
   once we are sure on how it should work long term!

3. Missing in kernel consumer infrastructure.  We never implemented consumer
   interfaces for events.  I assume this may be because no one cares, but
   it does sometimes feel like we are working around that in some of the
   use cases rather than just fixing it.

4. The Front end / back end split. This is most interesting for SoC ADCs where
   we currently put out an IIO interface to userspace that no one cares about
   (sometimes).  The plan was always to make that optional.  Would be interesting
   to explore pushing this forward.  This includes things like the little used
   available callbacks.

5. General performance questions - can we narrow the gap with the dodgy userspace
   hacks?

N. General process discussion - Is the current maintainer / review process
   quick enough that it isn't causing anyone too much pain?  What can we do
   better?  I'm always happy to get some feedback on this btw.

So if at all possible, what I'm looking for is additional (of better) ideas to put
down as somewhat of a placeholder to show we have lots to talk about.

If not I'll throw the above in with some editing.

Jonathan


  reply	other threads:[~2018-07-01 11:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 14:24 Potential IIO meeting / future directions discussion at ELCE 2018 - Edinburgh 22-24 Oct Jonathan Cameron
2018-06-28 17:11 ` Lars-Peter Clausen
2018-06-29  7:48   ` Daniel Baluta
2018-07-01 11:09     ` Jonathan Cameron [this message]
2018-07-01 15:16       ` Lars-Peter Clausen
2018-07-01 17:07         ` Jonathan Cameron
2018-07-01 17:27           ` Jonathan Cameron
2018-08-19 19:39             ` Jonathan Cameron
2018-07-02  0:08 ` Matt Ranostay

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=20180701120927.000061dc@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=daniel.baluta@gmail.com \
    --cc=eugen.hristev@microchip.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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.