=== rsalveti_ is now known as rsalveti | ||
=== rsalveti_ is now known as rsalveti | ||
ppisati | moin | 07:54 |
---|---|---|
=== smb` is now known as smb | ||
apw | moin | 09:09 |
smb | morning | 09:09 |
cking | mornin | 09:16 |
cking | nggg, mumble fail | 09:16 |
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:23 |
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:24 |
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:33 |
apw | diwic, great | 09:35 |
ogra_ | ppisati, did you see my PM last night ? | 09:53 |
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:35 |
ogra_ | heh, fun | 10:36 |
* apw has a bad kernel panopoly day | 12:14 | |
tseliot | apw: can you help with a little read-writer locks doubt, please? | 12:50 |
tseliot | *reader-writer | 12:50 |
tseliot | apw: I'm trying to replace rcu_read_lock/unlock with read_lock/unlock since the rcu calls are GPL_ONLY | 12:55 |
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/ | 12:56 |
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:13 |
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:16 |
apw | this wholel _GPL thing is a daft fabrication | 13:17 |
bjf | apw, overlayfs patch for quantal? | 13:53 |
apw | bjf, yes sitting here waiting to send ... doh | 13:54 |
apw | i am all out of sync following the 10 crashes i have had this morning | 13:55 |
* 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:02 |
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:10 |
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:11 |
tseliot | apw: so, this is my original patch for linux 3.8: http://paste.ubuntu.com/5596010/ | 14:12 |
apw | well then you must be interlocking with something else in the core which is handling the write locking | 14:13 |
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:14 |
* henrix -> late lunch | 14:15 | |
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:16 |
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:18 |
apw | i am suggesting that to do that would be utterly wrong for so many reasons, but it might just about work | 14:19 |
apw | tseliot, what is not exported that you need | 14:20 |
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:23 |
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:24 |
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:25 | |
tseliot | apw: but how can it be that they're exported as GPL only if that config is enabled? | 14:26 |
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:27 |
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:28 |
tseliot | right | 14:29 |
apw | it is also not clear it is not possible to randomly patch the kernel | 14:30 |
apw | to add a local_rcu_lock() function which is exported non-gpl which literally does rcu_lock_ ... its a farse | 14:31 |
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:32 |
apw | not that this driver would talk to as far as i know | 14:34 |
apw | i'll ask about it as well | 14:35 |
ppisati | back in 20 | 14:35 |
tseliot | apw: otherwise I'll just copy & paste the code if CONFIG_PREEMPT_RCU is defined | 14:36 |
apw | its hard to see how that is illegal dispite it being utterly not what they want :) | 14:37 |
tseliot | :D | 14:38 |
tseliot | it makes me wanna do it just because of that ;) | 14:40 |
apw | tseliot, something to find and extract the code you need from the kernel source :) | 14:47 |
tseliot | :) | 14:55 |
=== kentb-out is now known as kentb | ||
ogra_ | xnox, ppisati might be intrested in getting aufs/overlayfs into the nx7 kernel :) | 15:33 |
xnox | ogra_: i just want sensible sbuild ;-) | 15:33 |
ogra_ | well, the android source we have doesnt include either, needs porting work first | 15:34 |
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:35 |
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:37 |
ppisati | xnox: open a lp bug please | 15:53 |
ppisati | xnox: i'm rushing out now | 15:54 |
xnox | psivaa: ok. | 15:54 |
psivaa | ppisati: ^ :) | 15:54 |
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:56 |
* ppisati rushes out for some early workout | 15:57 | |
cking | jsalisbury, i've forwarded you some background info and a possible workaround | 16:49 |
jsalisbury | cking, awesome, thanks, Colin! | 16:49 |
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 | 16:50 |
ogasawara | bjf: next week is SRU verification week right? | 17:24 |
bjf | ogasawara, it's regression testing week | 17:24 |
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 | 17:25 |
=== shadeslayer_ is now known as shadeslayer | ||
* cking ~~-> catches the weekend | 18:19 | |
* henrix follows | 18:22 | |
=== kamalmostafa is now known as kamal |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!