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-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
