[clucas@rotomalug.org: [KJ] set_current_state()]

[clucas@rotomalug.org: [KJ] set_current_state()]

[Christophe Lucas]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

----- Forwarded message from Christophe Lucas <clucas@rotomalug.org> -----
From: Christophe Lucas <clucas@rotomalug.org>
To: nacc@us.ibm.com
Subject: [KJ] set_current_state()

Hi,

I have seen that in 2.6.12-rc3-kj, there is this patch :
http://coderock.org/kj/2.6.12-rc3-kj/split/set_current_state-drivers_net_tokenring_tms380tr.patch

Can it be one janitor thing ?

I think yes, and have a patchset about this kind of work.

What do you think about this?

Sorry if I waste your time.
-- 
	~Christophe

----- End forwarded message -----

-- 
	~Christophe


[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [clucas@rotomalug.org: [KJ] set_current_state()]

[Nish Aravamudan]

Christophe,

Sorry for not replying earlier, have been swamped at work.

> I have seen that in 2.6.12-rc3-kj, there is this patch :
> http://coderock.org/kj/2.6.12-rc3-kj/split/set_current_state-drivers_net_tokenring_tms380tr.patch
> 
> Can it be one janitor thing ?

Sure, the only trick is knowing when you do and do not need memory
barriers. Then you can choose between set_current_state() and
__set_current_state() respectively.

> I think yes, and have a patchset about this kind of work.
> 
> What do you think about this?

Seems reasonable -- expect some contention, though, these changes
don't achieve much (as in fixing broken code), unfortunately :)

Thanks,
Nish

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors