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

[Lars-Peter Clausen]

On 11/08/2011 03:23 PM, Jonathan Cameron wrote:
> On 11/08/2011 01:32 PM, Lars-Peter Clausen wrote:
>> On 11/07/2011 03:52 PM, jic23@xxxxxxxxx wrote:
>>> From: Jonathan Cameron <jic23@xxxxxxxxxx>
>>>
>>> [...]
>>> 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.
> It's the only option that looks plausible.  We just aren't going to get
> anyone to review all the code in one go.  The original move into staging
> was entirely about exposure, rather than code quality (not to say we
> haven't improved that as well!)  The other thing is that the
> simple stuff is mature and useful.  The buffering and event side of
> things is still evolving and hence it may be a while yet before it is
> stable enough.  (It was mature until the whole in kernel interface stuff
> came up and lead to a substantial rewrite!)
>  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.
> True. That would be fixed by a simple namespace move though.  Annoying,
> but plausible.

Still two almost identical frameworks for the same purpose. The code for the
out-of-staging and still-in-staging branches have already started to divert.
Having both in the mainline kernel is going to be maintenance hell. People
will start sending patches for one, but not the other. I just don't think
this will workout well.

>>
>> 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.
> Partly that, and partly that and partly there are controversial elements
> to be discussed in each of the major parts.  There's a lot of pressure
> to get 'something' out for the simple drivers now even if we take a
> while to 'discuss' the other elements.  Hence it needs to happen in
> chunks from the point of view of review, even if the final pull request
> will bring over the whole core.
> 

If the core split-up is just for review and is not intended to be merged
part-by-part over several kernel releases I don't see a problem.

- Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/