linux-kernel - Re: [PATCH 0/6 V2] IIO: Out of staging step 1: The core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EB92F78.8090200@metafoo.de>
Date:	Tue, 08 Nov 2011 14:32:40 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	jic23@....ac.uk
CC:	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	guenter.roeck@...csson.com, khali@...ux-fr.org,
	dmitry.torokhov@...il.com, broonie@...nsource.wolfsonmicro.com,
	gregkh@...e.de, alan@...rguk.ukuu.org.uk, arnd@...db.de,
	linus.walleij@...aro.org, maxime.ripard@...e-electrons.com,
	Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH 0/6 V2] IIO: Out of staging step 1: The core

On 11/07/2011 03:52 PM, jic23@....ac.uk wrote:
> From: Jonathan Cameron <jic23@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/