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

[Jonathan Cameron]

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.
> 
> 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.

All in all, there are parts of our userspace interface that are still
'flexible' but they are typically for devices types we haven't yet put
much effort into.  The main types are all well covered with consistent
interfaces now.
> 
> With the new in-kernel interface the user-space buffer support becomes just
> another consumer anyway.
That would perhaps 'ideally' be true, but we really don't have that
level of separation at the moment.  The in kernel buffer access route
'works' but that's as far as I would go right now.

> So we could keep it in staging for now. Something
> similar is probably possible for event support.
True, but we haven't even started on inkernel interfaces for that path
yet.  They are probably going to be 'fairly' simple, but it needs doing.
> 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.
Easy - move the name space.  Nothing else will work without adding code
to the out of staging part which isn't going to be acceptable.

Overall, I understand your point, but I'm far from convinced we can do
enough of the core in one go to be of practical use.

To do what you suggest we need complete separation between the core and
the userspace parts of IIO.  That is a far from trivial change.  I am
happy to spend some time investigating the possiblity of doing this, but
a few issues come to mind.

1) Elements that are not covered by the chan_spec. Some are fairly
standard, many just aren't.

2) Do we really want a map to do channel association?  Just imagine what
it will look like for some of the bigger devices with hundreds
of channels...

Anyhow, even if we do this. I still think the core move needs to occur
in a couple of stages.  The eventual pull to Linus may include all of
them, but it may well not if we don't get it all sorted in one cycle.

Jonathan
--
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/