[07:54] <ppisati> moin
[09:09] <apw> moin
[09:09] <smb> morning
[09:16] <cking> mornin
[09:16] <cking> nggg, mumble fail
[09:23] <diwic> I'm trying to run fdr editconfigs on gomeisa, but it fails due to a missing ncurses-devel package; what should I do instead?
[09:24] <smb> diwic, You run that in a chroot?
[09:24] <diwic> smb, no, hmm, maybe I should?
[09:24] <smb> diwic, more likely you will have ncurses in there
[09:33] <apw> diwic, and if we don't have it let me know
[09:33] <diwic> apw, it worked in the precise-amd64 chroot, thansk
[09:35] <apw> diwic, great
[09:53] <ogra_> ppisati, did you see my PM last night ?
[10:35] <xnox> Hello all =) is it just me or there is no: overlayfs, aufs, unionfs on the linux-nexus7 kernels ?! Can we enable them please =)))))
[10:36] <ogra_> heh, fun
[12:14]  * apw has a bad kernel panopoly day
[12:50] <tseliot> apw: can you help with a little read-writer locks doubt, please?
[12:50] <tseliot> *reader-writer
[12:55] <tseliot> apw: I'm trying to replace rcu_read_lock/unlock with read_lock/unlock since the rcu calls are GPL_ONLY
[12:56] <tseliot> apw: so, I was wondering if something like this could work (I don't have the hardware to test it): http://paste.ubuntu.com/5595857/
[13:13] <apw> tseliot, i am unsure if you need the rmb as as the read_lock is a full barrier i believe
[13:13] <apw> tseliot, but it seems workable in concept.  performance may suck of course
[13:16] <apw> tseliot, of course ... i should say ... you need to make the current write side locking also take this new lock in write mode
[13:16] <apw> else you have no locking at all :)
[13:17] <apw> this wholel _GPL thing is a daft fabrication
[13:53] <bjf> apw, overlayfs patch for quantal?
[13:54] <apw> bjf, yes sitting here waiting to send ... doh
[13:55] <apw> i am all out of sync following the 10 crashes i have had this morning
[14:02]  * ppisati is updating his laptop to R: Goodbye Cruel World!
[14:02] <apw> ppisati, did not work out well for me
[14:02]  * apw runs a Q kernel on it
[14:02] <ppisati> DOH
[14:02] <apw> its that bad
[14:02] <apw> (for me)
[14:02] <ppisati> just started the do-release-upgrade thing
[14:02] <ppisati> ok, i'll use a Q kernel on it
[14:02] <apw> good luck with that, i have a gm45 and it is fucked
[14:10] <tseliot> apw: I don't think there's any write_lock in the code. I had to introduce rcu_read_lock() (following the example of some open drivers) because upstream broke the API. I'm wondering how it may impact performance in the broadcom wireless driver...
[14:10] <tseliot> s/impact/affect/
[14:11] <apw> then who are you locking against if there is no other rcu in the thing
[14:11] <apw> is it in the driver model somewhere, if so it might work sort of
[14:11] <apw> but ... hmmm is all i can say
[14:12] <tseliot> apw: so, this is my original patch for linux 3.8: http://paste.ubuntu.com/5596010/
[14:13] <apw> well then you must be interlocking with something else in the core which is handling the write locking
[14:14] <apw> essentially you are in a hole with no spade at this point as you should be using the same locking as they are, else you are wasting your time
[14:14] <apw> but you can't because it is not exported.
[14:14] <apw> you locking there i don't think does anything 
[14:14] <apw> if it is not interlocked with the other side
[14:15]  * henrix -> late lunch
[14:16] <tseliot> apw: hmm... I see what you mean
[14:16] <apw> tseliot, as long as you have the rcu_dereference, you can probabally get away with it int he common case, because read_lock_rcu is a bit of a noop in a lot of cases
[14:16] <apw> (when preempt is off)
[14:18] <apw> but if they are exporting the 80211 interfaces for use by non-gpl code, but those rely on GPL only locking ... it isn't really exporte
[14:18] <tseliot> apw: are you suggesting that I get rid of the lock/unlock and that I simply use my local equivalent for rcu_dereference?
[14:19] <apw> i am suggesting that to do that would be utterly wrong for so many reasons, but it might just about work
[14:20] <apw> tseliot, what is not exported that you need
[14:23] <tseliot> apw: I guess rcu_dereference is not GPL only, maybe only rcu_read_unlock and rcu_read_lock are
[14:23] <apw> tseliot, they only are in some versions of rcu i think
[14:23] <apw> only GPL only i think if we are using CONFIG_PREEMPT_RCU
[14:24] <apw> debian.master/config/i386/config.common.i386:# CONFIG_PREEMPT_RCU is not set
[14:24] <apw> debian.master/config/amd64/config.common.amd64:# CONFIG_PREEMPT_RCU is not set
[14:24] <apw> which it isn't on our default kernels
[14:24] <tseliot> apw: right now my original patch doesn't fail in Ubuntu but some developers on Arch Linux and another distro I can't recall are complaining about the GPL only issue
[14:24] <tseliot> that would explain it
[14:24] <apw> ahh then that makes sense
[14:25] <apw> i think overall there is an issue with a core primative like rcu being gpl only
[14:25] <apw> it really doesn't make sense in a fair world
[14:25]  * tseliot nods
[14:26] <tseliot> apw: but how can it be that they're exported as GPL only if that config is enabled?
[14:27] <apw> becasue it is only __rcu_read_lock which is GPL only exported, and there are two version
[14:27] <apw> one version for PREMPT on and one for PREMEPT off
[14:27] <apw> the one for PREEMPT off is an inline with nothing much in it and is not exported at all
[14:27] <apw> and therefore has no way to limit it
[14:27] <tseliot> aah, I see now
[14:28] <apw> the stupidity is you can (as far as i can see) take the code out of the middle of the function and inline it
[14:28] <apw> into the code you have which is GPL (gpl with gpl is ok) and then use it from your proprietry code
[14:28] <apw> as you are effectivly doing with rcu_dereference
[14:29] <tseliot> right
[14:30] <apw> it is also not clear it is not possible to randomly patch the kernel
[14:31] <apw> to add a local_rcu_lock() function which is exported non-gpl which literally does rcu_lock_ ... its a farse
[14:32] <tseliot> heh
[14:32] <tseliot> do we have a kernel flavour with CONFIG_PREEMPT_RCU enabled?
[14:32] <tseliot> or shall I just forget about it?
[14:34] <apw> not that this driver would talk to as far as i know
[14:35] <apw> i'll ask about it as well
[14:35] <ppisati> back in 20
[14:36] <tseliot> apw: otherwise I'll just copy & paste the code if CONFIG_PREEMPT_RCU is defined
[14:37] <apw> its hard to see how that is illegal dispite it being utterly not what they want :)
[14:38] <tseliot> :D
[14:40] <tseliot> it makes me wanna do it just because of that ;)
[14:47] <apw> tseliot, something to find and extract the code you need from the kernel source :)
[14:55] <tseliot> :)
[15:33] <ogra_> xnox, ppisati might be intrested in getting aufs/overlayfs into the nx7 kernel  :)
[15:33] <xnox> ogra_: i just want sensible sbuild ;-)
[15:34] <ogra_> well, the android source we have doesnt include either, needs porting work first 
[15:35] <ogra_> and if we possibly play with overlays for the upgrade procedure, it will be needed i guess
[15:35] <xnox> ogra_: how hard can it be? I thought android kernel doesn't care much about fs stack (as in doing / changing it extensively)
[15:35] <ogra_> not sure what stgraber's exact plans are but it would definitely be helpful to have it for different test scenarios
[15:37] <stgraber> so far I'm avoiding the use of an actual overlay filesystem because we can't be sure we'll have one in the kernel, but I certainly wouldn't mind having one ;)
[15:53] <ppisati> xnox: open a lp bug please
[15:54] <ppisati> xnox: i'm rushing out now
[15:54] <xnox> psivaa: ok.
[15:54] <psivaa> ppisati: ^ :)
[15:56] <xnox> psivaa: sorry.
[15:56] <xnox> ppisati: ack. it will be bug 1076317
[15:56] <ubot2`> Launchpad bug 1076317 in ubuntu-nexus7 "please add aufs/overlayfs/unionfs support to android based kernels" [High,Confirmed] https://launchpad.net/bugs/1076317
[15:56] <psivaa> xnox: np
[15:56] <ppisati> xnox: nice
[15:57]  * ppisati rushes out for some early workout
[16:49] <cking> jsalisbury, i've forwarded you some background info and a possible workaround 
[16:49] <jsalisbury> cking, awesome, thanks, Colin!
[16:50] <cking> if we can get the ACPI tables though, I can check out my hypothesis, but there is no harm in spinning them a test kernel 
[16:50] <jsalisbury> cking, cool, thanks
[17:24] <ogasawara> bjf: next week is SRU verification week right?
[17:24] <bjf> ogasawara, it's regression testing week
[17:25] <ogasawara> bjf: ah, thanks.  can you point me to the calendar I should follow?
[17:25] <bjf> https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
[17:25] <ogasawara> bjf: thanks
[18:19]  * cking ~~-> catches the weekend
[18:22]  * henrix follows