[lkml]   [2011]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/6 V2] IIO: Out of staging step 1: The core
    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, wrote:
    >>> From: Jonathan Cameron <>
    >>> [...]
    >>> 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
    >>> 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

     \ /
      Last update: 2011-11-08 15:55    [W:0.032 / U:7.224 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site