|From:||Jonathan Cameron <jic23-AT-cam.ac.uk>|
|To:||Jean Delvare <khali-AT-linux-fr.org>|
|Subject:||Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc|
|Date:||Mon, 14 Mar 2011 23:23:59 +0000|
|Cc:||Arnd Bergmann <arnd-AT-arndb.de>, mems applications <mems.applications-AT-st.com>, rdunlap-AT-xenotime.net, carmine.iascone-AT-st.com, matteo.dameno-AT-st.com, rubini-AT-ipvvis.unipv.it, linux-doc-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, Guenter Roeck <guenter.roeck-AT-ericsson.com>|
On 03/14/11 21:42, Jean Delvare wrote: > On Mon, 14 Mar 2011 21:36:43 +0100, Arnd Bergmann wrote: >> On Monday 14 March 2011 21:18:09 Jean Delvare wrote: >>> Jonathan is correct. Pressure sensors are not hardware monitoring >>> devices, their drivers have nothing to do in drivers/hwmon. This is >>> something for drivers/misc or staging/iio. >> >> I generally try to prevent people from adding more ad-hoc interfaces >> to drivers/misc. Anything that is called a drivers/misc driver to me >> must qualify as "there can't possibly be a second driver with the >> same semantics", otherwise it should be part of another subsystem >> with clear rules, or be put into its own file system. > > I see drivers/misc differently. I see it as "not enough drivers of the > same type to justify a new subsystem". So I encourage people to put > things there in the absence of any suitable subsystem, until someone > gets enough motivation to start such a subsystem. This is more > pragmatic than requesting subsystems to be created upfront. To my mind, there will one day be a suitable 'sensors' subsystem so an important side point is to try and minimise interface changes needed to move to that (IIO or something better). Sysfs is easy to fix, so lets at least work on shared interfaces in there. Hwmon is a mature and reasonable starting point; it's where we got a lot of IIO's similar interfaces from. The trick is convincing people to consider generality and it's a hard trick to pull off. > > That being said, staging is another option nowadays. > >> While it seems that right now everyone is just trying to keep move >> the driver to some other subsystem, I think it's worth noting that >> it is indeed a useful thing to have the driver, I'm optimistic >> that we can find some place for it. ;-) >> >> Now how about the IIO stuff? This is the first time I've even >> heard about it. Does it have any major disadvantages besides >> being staging-quality? To play devil's advocate with my own code... It's big. If all you want is something that looks like hwmon then you won't care about maybe 80% of the core and support code. Just look at hwmon to see how slim a subsystem can be. Now a key point is to ensure such driver writers don't have to care. I think we achieve that (though there is room for improvement of course!) The issue is that its the heavy 'interesting' bits that the developers need which are also the reason the whole thing exists in the first place. The other big issue for contributors is that there is still a reasonable amount of churn in the core code and that brings a test burden that continues after a driver is merged (if they use the more complex bits that is). > > This is indeed the major disadvantage. IIO seems to take a lot of time > to move out of staging, although I don't know what the current ETA is. > Whilst I'd like to say soon there are a couple more big changes to make (such as the ongoing changes to allow threaded interrupts for the triggers - basically implementing what Thomas Gleixner suggested and having virtual interrupt chips) and some of these will take a fair bit of bedding down. In the original write I got quite a few things wrong :( Mind you quite a lot of evolution of requirements has taken place as well. Usual sob story (50+ drivers of mixed quality to avoid breaking, little manpower, steady stream of new drivers keeping people busy reviewing etc etc) Having said that, for the simple drivers the interfaces are mostly fixed and nothing much has changed for quite a few months. (e.g. anything that is slow and only uses hwmon style sysfs interfaces). Of course, if anyone does have any time (looks around hopefully...) Particularly helpful are people pointing out what really needs fixing before attempting to move out of staging. Much better if we get that sort of feedback in plenty of time rather than on sending a pull request to Linus. I like to spread my arguments out ;) Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds