=== rsalveti_ is now known as rsalveti === rsalveti_ is now known as rsalveti [07:54] moin === smb` is now known as smb [09:09] moin [09:09] morning [09:16] mornin [09:16] nggg, mumble fail [09:23] 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] diwic, You run that in a chroot? [09:24] smb, no, hmm, maybe I should? [09:24] diwic, more likely you will have ncurses in there [09:33] diwic, and if we don't have it let me know [09:33] apw, it worked in the precise-amd64 chroot, thansk [09:35] diwic, great [09:53] ppisati, did you see my PM last night ? [10:35] 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] heh, fun [12:14] * apw has a bad kernel panopoly day [12:50] apw: can you help with a little read-writer locks doubt, please? [12:50] *reader-writer [12:55] apw: I'm trying to replace rcu_read_lock/unlock with read_lock/unlock since the rcu calls are GPL_ONLY [12:56] 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] tseliot, i am unsure if you need the rmb as as the read_lock is a full barrier i believe [13:13] tseliot, but it seems workable in concept. performance may suck of course [13:16] 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] else you have no locking at all :) [13:17] this wholel _GPL thing is a daft fabrication [13:53] apw, overlayfs patch for quantal? [13:54] bjf, yes sitting here waiting to send ... doh [13:55] 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] ppisati, did not work out well for me [14:02] * apw runs a Q kernel on it [14:02] DOH [14:02] its that bad [14:02] (for me) [14:02] just started the do-release-upgrade thing [14:02] ok, i'll use a Q kernel on it [14:02] good luck with that, i have a gm45 and it is fucked [14:10] 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] s/impact/affect/ [14:11] then who are you locking against if there is no other rcu in the thing [14:11] is it in the driver model somewhere, if so it might work sort of [14:11] but ... hmmm is all i can say [14:12] apw: so, this is my original patch for linux 3.8: http://paste.ubuntu.com/5596010/ [14:13] well then you must be interlocking with something else in the core which is handling the write locking [14:14] 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] but you can't because it is not exported. [14:14] you locking there i don't think does anything [14:14] if it is not interlocked with the other side [14:15] * henrix -> late lunch [14:16] apw: hmm... I see what you mean [14:16] 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] (when preempt is off) [14:18] 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] 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] i am suggesting that to do that would be utterly wrong for so many reasons, but it might just about work [14:20] tseliot, what is not exported that you need [14:23] apw: I guess rcu_dereference is not GPL only, maybe only rcu_read_unlock and rcu_read_lock are [14:23] tseliot, they only are in some versions of rcu i think [14:23] only GPL only i think if we are using CONFIG_PREEMPT_RCU [14:24] debian.master/config/i386/config.common.i386:# CONFIG_PREEMPT_RCU is not set [14:24] debian.master/config/amd64/config.common.amd64:# CONFIG_PREEMPT_RCU is not set [14:24] which it isn't on our default kernels [14:24] 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] that would explain it [14:24] ahh then that makes sense [14:25] i think overall there is an issue with a core primative like rcu being gpl only [14:25] it really doesn't make sense in a fair world [14:25] * tseliot nods [14:26] apw: but how can it be that they're exported as GPL only if that config is enabled? [14:27] becasue it is only __rcu_read_lock which is GPL only exported, and there are two version [14:27] one version for PREMPT on and one for PREMEPT off [14:27] the one for PREEMPT off is an inline with nothing much in it and is not exported at all [14:27] and therefore has no way to limit it [14:27] aah, I see now [14:28] 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] into the code you have which is GPL (gpl with gpl is ok) and then use it from your proprietry code [14:28] as you are effectivly doing with rcu_dereference [14:29] right [14:30] it is also not clear it is not possible to randomly patch the kernel [14:31] to add a local_rcu_lock() function which is exported non-gpl which literally does rcu_lock_ ... its a farse [14:32] heh [14:32] do we have a kernel flavour with CONFIG_PREEMPT_RCU enabled? [14:32] or shall I just forget about it? [14:34] not that this driver would talk to as far as i know [14:35] i'll ask about it as well [14:35] back in 20 [14:36] apw: otherwise I'll just copy & paste the code if CONFIG_PREEMPT_RCU is defined [14:37] its hard to see how that is illegal dispite it being utterly not what they want :) [14:38] :D [14:40] it makes me wanna do it just because of that ;) [14:47] tseliot, something to find and extract the code you need from the kernel source :) [14:55] :) === kentb-out is now known as kentb [15:33] xnox, ppisati might be intrested in getting aufs/overlayfs into the nx7 kernel :) [15:33] ogra_: i just want sensible sbuild ;-) [15:34] well, the android source we have doesnt include either, needs porting work first [15:35] and if we possibly play with overlays for the upgrade procedure, it will be needed i guess [15:35] 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] not sure what stgraber's exact plans are but it would definitely be helpful to have it for different test scenarios [15:37] 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] xnox: open a lp bug please [15:54] xnox: i'm rushing out now [15:54] psivaa: ok. [15:54] ppisati: ^ :) [15:56] psivaa: sorry. [15:56] ppisati: ack. it will be bug 1076317 [15:56] 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] xnox: np [15:56] xnox: nice [15:57] * ppisati rushes out for some early workout [16:49] jsalisbury, i've forwarded you some background info and a possible workaround [16:49] cking, awesome, thanks, Colin! [16:50] 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] cking, cool, thanks [17:24] bjf: next week is SRU verification week right? [17:24] ogasawara, it's regression testing week [17:25] bjf: ah, thanks. can you point me to the calendar I should follow? [17:25] https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock [17:25] bjf: thanks === shadeslayer_ is now known as shadeslayer [18:19] * cking ~~-> catches the weekend [18:22] * henrix follows === kamalmostafa is now known as kamal