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: <3efb10970812091206l2e6a17a6tc475a57b942cd28f@mail.gmail.com>
Date:	Tue, 9 Dec 2008 21:06:34 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Steven Rostedt" <rostedt@...dmis.org>
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

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

Kind Regards,

Remy

2008/12/9 Steven Rostedt <rostedt@...dmis.org>:
>
> On Tue, 9 Dec 2008, Fr?d?ric Weisbecker wrote:
>>
>> Hi Steve.
>>
>> That's a good news.
>>
>> But after converting these spinlocks into lock_t, how will you synchronize with
>> the mainline on each release? You will have a huge amount of conflicts
>> at every merges...
>
> This is why master is separate from rt-master. The rt-master will grow
> like tip/master does. But the master will be recreated each time.
> Basically, the creation of master is this:
>
>
> git checkout master
> git reset --hard rt-master
> ./scripts/convert-spinlocks
> git commit -a -m 'Convert all spinlocks to lock_t'
> ./scripts/convert-locks
> git commit -a -m 'Convert some locks back to spinlock_t'
>
> Thus we do not need to worry about the conflicts caused by the lock
> conversion. That will be done automatically each time we create a new
> master.
>
> -- 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/
>
--
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/