linux-kernel - Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201103151038.40559.arnd@arndb.de>
Date:	Tue, 15 Mar 2011 10:38:40 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	mems applications <mems.applications@...com>,
	rdunlap@...otime.net, carmine.iascone@...com, matteo.dameno@...com,
	rubini@...vis.unipv.it, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Greg KH <greg@...ah.com>
Subject: Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc

On Tuesday 15 March 2011 00:23:59 Jonathan Cameron wrote:
> > 
> > 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 ;)

Do you think it would help to split the iio codebase into a smaller part
for the relatively clean drivers that can be put into shape for
drivers/iio, and the bulk of the code that stays in staging for a bit
longer, until it gets converted to the new one in small chunks?

That may be less frustrating than trying to do it all at once. In particular,
you could do major internal rewrites much faster if you don't have
to immediately worry about breaking dozens of drivers in the process.

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