Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1281087 > unrolled thread

Re: [kbuild-all] [PATCH] locking_selftest: Save/restore migrate_disable_atomic in locking selftest

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [kbuild-all] [PATCH] locking_selftest: Save/restore  migrate_disable_atomic in locking selftest Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2015-12-01 19:00 +0100
    Re: [kbuild-all] [PATCH] locking_selftest: Save/restore  migrate_disable_atomic in locking selftest Fengguang Wu <lkp@intel.com> - 2015-12-03 03:00 +0100

#1281087 — Re: [kbuild-all] [PATCH] locking_selftest: Save/restore migrate_disable_atomic in locking selftest

On 11/23/2015 04:03 PM, Fengguang Wu wrote:
> Thanks! Yes, a stable branch name would be better than "linux-4.1.y-rt"
> that's like to become stable over time.

finally. I got to it.
I pushed two branches @ pub/scm/linux/kernel/git/rt/linux-rt-devel.git:

	for-kbuild-bot/current-stable [0]
	for-kbuild-bot/prepare-release [1]

Branch [0] should contain the last -RT release. This could be used for
testing patches against (if you find one with the RT marker in subject).
The tree should start a stable-tree marker (currently it is v4.1.13)
and have -RT tree applied on top. You should be able compile after each
commit (between the stable tag and HEAD) and nothing should introduce
warnings or fail to compile.
The second branch [1] would be similar to the first one except that I
plan to push stuff there before I make a release it. Does this make
sense or do I over think this?
If you do compile tests, it would be nice if you could enable
CONFIG_PREEMPT_RT_FULL. That is where most of the changes start to work.
Nevertheless it should also work without it(i.e. no preemption or
desktop).
If you have slightly different naming scheme or suggestions just tell
me I will adapt to it:)

Thank you for the service.

> Thanks,
> Fengguang

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

[toc] | [next] | [standalone]

#1282642

Hi Sebastian,

On Tue, Dec 01, 2015 at 06:59:44PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/23/2015 04:03 PM, Fengguang Wu wrote:
> > Thanks! Yes, a stable branch name would be better than "linux-4.1.y-rt"
> > that's like to become stable over time.
> 
> finally. I got to it.
> I pushed two branches @ pub/scm/linux/kernel/git/rt/linux-rt-devel.git:
> 
> 	for-kbuild-bot/current-stable [0]
> 	for-kbuild-bot/prepare-release [1]
> 
> Branch [0] should contain the last -RT release. This could be used for
> testing patches against (if you find one with the RT marker in subject).
> The tree should start a stable-tree marker (currently it is v4.1.13)
> and have -RT tree applied on top. You should be able compile after each
> commit (between the stable tag and HEAD) and nothing should introduce
> warnings or fail to compile.

Got it, I've updated the RT => for-kbuild-bot/current-stable mapping
accordingly, thanks for the info!

> The second branch [1] would be similar to the first one except that I
> plan to push stuff there before I make a release it. Does this make
> sense or do I over think this?

It's fair enough.

> If you do compile tests, it would be nice if you could enable
> CONFIG_PREEMPT_RT_FULL. That is where most of the changes start to work.
> Nevertheless it should also work without it(i.e. no preemption or
> desktop).

OK, I'll increase testing for CONFIG_PREEMPT_RT_FULL when it's the RT tree.

> If you have slightly different naming scheme or suggestions just tell
> me I will adapt to it:)
> 
> Thank you for the service.

You are welcome!

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web