linux-kernel - Re: [ANNOUNCE] The -rt git tree

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: <alpine.DEB.1.10.0812091511300.19875@gandalf.stny.rr.com>
Date:	Tue, 9 Dec 2008 15:17:53 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Remy Bohmer <linux@...mer.net>
cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Clark Williams <clark.williams@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Gregory Haskins <ghaskins@...ell.com>,
	Darren Hart <dvhltc@...ibm.com>
Subject: Re: [ANNOUNCE] The -rt git tree

On Tue, 9 Dec 2008, Remy Bohmer wrote:

> Hello Steven,
> 
> It all sounds good!
> 
> But, I was wondering, why using the scripts to convert the spinlocks
> over and over, instead of pushing only the new lock API to mainline
> asap? That would save a lot of conversion complexity and sounds like
> migrating the RT patch to mainline much easier. It sounds to me like a
> major rename action, and as long as there is only a spinlock behind
> the new API, there is a very low risk in breaking things.
> Later on the rt-mutex can be integrated behind the new API. In the
> mean time everybody can get used to the new locking API.
> That would save complexity and improve stability of the rt-patchset,
> because it does not need to be figured out over and over if there are
> new locks in new code that need to be converted back to spinlocks...
> (In fact we only need to focus from there on new code that use the
> spinlock API, and if it is really required to use that.)
> 

Hi Remy,

Thanks!  And you have caught on to our plan ;-)  This is actually why we 
have the scripts. My plan was to start introducing the new API slowly over 
time, but in the mean time, the RT tree will keep the script to convert 
all the rest that we want to the new locks. Eventually (hopefully), all 
the locks in mainline will be the same as the locks in the rt git tree. 
When that happens, we will not need these scripts anymore.

The rt git tree is a place to start testing the waters of the new API. 
With this exposure, other developers will start understanding what it is 
made for.

One thing we want in mainline before we use this is interrupts as threads. 
This will first start out as drivers having their own interrupt threads, 
and eventually we can get rid of the need for softirqs and tasklets.  Then 
we could have a option to turn all interrupts into threads as RT does. If 
we do that, then the new lock API could be used even more immediately. It 
could then be used to convert locks that are spinlocks only because they 
are shared with an interrupt. The lock_t type could be changed to a mutex 
when interrupts are threads and spinlocks otherwise.

But first we need to take it slowly. And this git tree is the first step.

-- Steve

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