linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: jic23@cam.ac.uk
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	guenter.roeck@ericsson.com, khali@linux-fr.org,
	dmitry.torokhov@gmail.com, broonie@opensource.wolfsonmicro.com,
	gregkh@suse.de, alan@lxorguk.ukuu.org.uk, arnd@arndb.de,
	linus.walleij@linaro.org, maxime.ripard@free-electrons.com,
	Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH 0/6 V2] IIO: Out of staging step 1: The core
Date: Tue, 08 Nov 2011 14:32:40 +0100	[thread overview]
Message-ID: <4EB92F78.8090200@metafoo.de> (raw)
In-Reply-To: <1320677563-18378-1-git-send-email-jic23@cam.ac.uk>

On 11/07/2011 03:52 PM, jic23@cam.ac.uk wrote:
> From: Jonathan Cameron <jic23@kernel.org>
> 
> [...]
> Dear All,
> 
> Firstly note that I have pushed ahead of this alongside the ongoing
> discussions on how to handle in kernel interfaces for the devices
> covered by IIO.  I propose to build those on top of this patch
> set and will be working on that support whilst this set is
> under review.
> 
> Secondly, this code has some namespace clashes with the staging
> IIO code, so you will need a couple of patches that can be found
> in https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
> 
> This is our first attempt to propose moving 'some' of the
> Industrial I/O subsystem out of staging.  This cover letter
> attempts to explain what IIO is and why it is needed.
> All comments welcome on this as well as the code!


I don't think moving just part of the IIO core out of staging will work. We
now end up with two competing frameworks for the same purpose which mostly
have the same API. If I for example enable both ST_IIO and IIO at the same
time everything will explode, since both want to register the same device class.

In my opinion we should move all of the core interface including events and
buffer support at once. Drivers of course can stay in staging. I guess the
main reason why this code is still in staging is that we don't fell
confident enough about the user-space ABI yet. The overall code quality is
ok and there are no major problems with the internal API.

With the new in-kernel interface the user-space buffer support becomes just
another consumer anyway. So we could keep it in staging for now. Something
similar is probably possible for event support. Provide the in-kernel
interfaces out of staging, but keep the user-space delivery mechanism in
staging for now.

I'll try to come up with some patches which allow coexistence of the
in-staging and out-of-staging IIO parts.

- Lars

  parent reply	other threads:[~2011-11-08 13:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07 14:52 [PATCH 0/6 V2] IIO: Out of staging step 1: The core jic23
2011-11-07 14:52 ` [PATCH 1/6] IIO: Core sysfs only support jic23
2011-11-11 10:40   ` Michael Hennerich
2012-02-01 15:20   ` Maxime Ripard
2011-11-07 14:52 ` [PATCH 2/6] IIO:ADC: max1363 initial import jic23
2011-11-07 14:52 ` [PATCH 3/6] IIO:ADC:ad799x " jic23
2011-11-08 13:07   ` Lars-Peter Clausen
2011-11-08 13:35     ` Jonathan Cameron
2011-11-07 14:52 ` [PATCH 4/6] IIO:light:tsl2563 initial move out of staging jic23
2011-11-07 14:52 ` [PATCH 5/6] IIO:imu:adis16400 partial move from staging jic23
2011-11-11 10:41   ` Michael Hennerich
2011-11-07 14:52 ` [PATCH 6/6] IIO: ABI documetation jic23
2011-11-11 10:41   ` Michael Hennerich
2011-11-08 13:32 ` Lars-Peter Clausen [this message]
2011-11-08 14:23   ` [PATCH 0/6 V2] IIO: Out of staging step 1: The core Jonathan Cameron
2011-11-08 14:53     ` Lars-Peter Clausen
2011-11-08 15:29       ` Jonathan Cameron

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=4EB92F78.8090200@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@suse.de \
    --cc=guenter.roeck@ericsson.com \
    --cc=jic23@cam.ac.uk \
    --cc=jic23@kernel.org \
    --cc=khali@linux-fr.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).