[02:49] <zul> heylo
[03:40] <johnm> Hi guys
[03:40] <johnm> BenC: do you publish your ubuntu git repo somewhere by chance?
[03:41] <zul> http://kernel.org/git
[03:42] <fabbione> johnm: only on kenrel.org
[03:43] <zul> hi fabbione
[03:43] <fabbione> hey zul
[03:43] <johnm> that'll work for me, thanks
[04:45] <BenC> bah, stupid docbook failure caused i386 to fail to build
[05:05] <infinity> BenC: Hah, I was *just* about to bug you about the build failure, too.
[05:06] <BenC> maybe I should be doing a full build on my i386 box to catch this sort of thing
[05:06] <BenC> first time it's happened though, so probably not worth the effort
[05:06] <infinity> Probably. :)
[05:06] <infinity> You know how much I love people using my buildds as testing infrastructure. :P
[05:07] <BenC> hehe
[05:27] <infinity> BenC: Do we know that putting shell expansion like $(uname -r) in modprobe.d files actually works?
[05:27] <infinity> BenC: Or is that completely untested? :)
[05:27] <BenC> No, I tested it
[05:27] <infinity> Spiffy.
[05:27] <BenC> Put "test install echo $(uname -r)" in a modprobe.d file
[05:28] <BenC> and do "sudo modprobe test"
[05:28] <BenC> it should echo it
[05:28] <infinity> Oh, and for the record, not sure what your comment was all about, but modprobe.d filenames don't have to relate to the module name in any way.
[05:28] <infinity> (Usually, they follow the package name, though in this case I agree that it makes sense to use the module name anyway)
[05:29] <BenC> yeah yeah
[05:29] <BenC> I meant to say that the module name in the file cannot be duplicated in other files without bad effects :)
[05:29] <infinity> Ahh, yeah, I ran into that.
[05:30] <infinity> I can't recall if it picks the last or the first, or does all of them or what, but I remember testing this when I used an 'install' hack for the nvidia kernel modules.
[05:36] <Keybuk> I tend to use package name, or blacklist-$class
[05:36] <Keybuk> infinity: first, iirc
[05:37] <infinity> Well, packagename is a bit awkward in this case, because it's lrm-common, which could grow more of these files.
[05:37] <infinity> And blacklist-foo is clearly wrong, since it's not a blacklist. :)
[05:37] <Keybuk> what's going in it?
[05:37] <infinity> install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; \
[05:37] <infinity>         /sbin/ipw3945d-$(uname -r) --quiet
[05:37] <infinity> remove  ipw3945 /sbin/ipw3945d-$(uname -r) --kill ; \
[05:37] <infinity>         /sbin/modprobe -r --ignore-remove ipw3945
[05:37] <Keybuk> uhhh
[05:37] <infinity> Was just going to name it "ipw3945", which seems sane. :)
[05:37] <Keybuk> why not do that as a udev rule instead/
[05:38] <Keybuk> slightly more elegant
[05:38] <infinity> Does udev trigger on removal of the module?
[05:38] <Keybuk> yes
[05:38] <Keybuk> SUBSYSTEM=="module", ACTION=="remove"
[05:38] <infinity> Then give me the udev rules to replace the above, and I'll do that.
[05:38] <infinity> I don't much care, I (and apparently BenC also) just happen to know how to do it this way.
[05:39] <Keybuk> SUBSYSTEM=="module", NAME=="ipw3945", ACTION=="add", RUN+="sh -c '/sbin/ipw3945-$(uname -r) --quiet'"
[05:39] <Keybuk> SUBSYSTEM=="module", NAME=="ipw3945", ACTION=="remove", RUN+="sh -c '/sbin/ipw3945-$(uname -r) --kill'"
[05:39] <infinity> I fail to see how that's much more elegant than doing it from modprobe, mind you.
[05:40] <infinity> It also adds a hard dependency on udev, which isn't necessarily true otherwise.
[05:40] <Keybuk> I tend to cry at install/remove rules :)
[05:40] <Keybuk> udev rule is triggered by insmod/rmmod too
[05:41] <infinity> But requires udev.
[05:41] <Keybuk> yes, there is that
[05:41] <infinity> So, in one case, we have modprobe-specific, in the other case, udev-specific.
[05:42] <infinity> Note that the kernel image depends on modprobe, but doesn't depend on udev.
[05:42] <Keybuk> we don't start any daemons from modprobe rules at the moment
[05:42] <infinity> No time like the present to start. :)
[05:42] <infinity> This is a somewhat special daemon.  We don't start any other "module helpers" at all, from udev or modprobe.
[05:42] <BenC> Keybuk: does the udev rule trigger when someone does "modprobe -r ipw3945"?
[05:43] <BenC> because that's what we need
[05:43] <Keybuk> BenC: yes, it triggers because the kernel's module handler is sysfs-ified
[05:43] <BenC> so it will call the udev rule before it actuallt removes the module?
[05:43] <BenC> because the module cannot be removed until the daemon is killed
[05:43] <Keybuk> "while it's removing" is probably the best description
[05:43] <Keybuk> I don't know exactly where
[05:44] <BenC> then it wont work, because "while it is removing" can't happen with the ref-count > 0
[05:44] <Keybuk> ok
[05:44] <Keybuk> then do it your way
[05:44] <BenC> it's not my way, it's the "Intel Way" :)
[05:44] <infinity> It's a stopgap anyway, until someone reverse engineers the daemon and shoves the code in the driver. :)
[05:45] <infinity> BenC: What are you doing this weekend? :)
[05:45] <Keybuk> why's it a userspace daemon and not a kernel thread, anyway?
[05:45] <BenC> Keybuk: because it is binary only
[05:45] <infinity> To avoid license issues.
[05:45] <BenC> regulatory restrictions
[05:45] <BenC> yeah, keeps the driver "free"
[05:45] <Keybuk> heh, someone can soon port that into the kernel
[05:45] <Keybuk> infinity: you'll have to do it; BenC's a USian
[05:46] <BenC> they probably will, but then Intel will still not be held liable :)
[05:47] <infinity> Yeah, Intel just wants to be able to waive liabilty.  So they release the binary daemon, let some other hacker reverse engineer it, everyone wins.
[05:47] <BenC> and then we can control tx power, and other neat stuff on the chipset
[05:47] <infinity> A double-edged sword that one.
[05:48] <infinity> Let the user control Tx power, and three days later, half of them complain that they blew up their transmitters.
[05:48] <BenC> I'd worry about tx power bumps, but where I live, I'm not likely to interfere with too many others
[05:48] <infinity> (You have no idea how many people I've seem blow up their wlan cards and APs with firmware hacks..)
[05:48] <BenC> doubtful the hillbillies have any serious 80211 networks around
[05:48] <infinity> If I bump the Tx on my AP, the thing starts overheating in a matter of minutes.
[05:49] <BenC> I have my linksys AP's bumped in power so I can reach the barn
[05:50] <infinity> I can't seem to much improve things in my house anyway.  The place is a faraday cage.
[05:50] <infinity> Plaster on wire mesh in the walls, it looks like.  Can't get reliable transmission between the living room and my bedroom with any two 802.11b/g devices I've tried.
[05:51] <infinity> A repeater in the hallway would fix it, I guess, but it just doesn't seem worth the effort.
[05:51] <BenC> hehe
[05:51] <BenC> I had a repeater for awhile, in the well house, didn't really help much
[05:51] <BenC> your house was definitely not designed by a geek
[05:52] <infinity> Well, a repeater in the hall would allow me to bounce a line-of-sight triangle around the two offending walls between here and the bed.
[05:53] <infinity> But I think I'd rather just move to something that was built in the last century.  (In the last decade would be smashing, too)
[08:21] <BenC> infinity: 21.32 built successfully
[08:22] <infinity> BenC: I've been watching. :)
[08:22] <infinity> LRM is on its way up already.
[08:22] <BenC> ok, I'll do linux-meta in a few hours
[08:22] <infinity> Well, the orig is on its way to chinstrap, the diff and dsc are getting some final love from me.
[08:23] <BenC> does lrm create any udeb's?
[08:23] <infinity> Yup.
[08:23] <BenC> anyway to get the ipw3945 daemon in the installer?
[08:23] <infinity> nic-restricted-modules and nic-restricted-firmware.
[08:23] <BenC> if so, I'll add it to the nic-udeb
[08:23] <infinity> And I already put the ipw3945d stuff in the nic-r-m udeb.
[08:23] <infinity> Way ahead of you. :)
[08:23] <BenC> sweet, I'll get the driver done too, thanks!
[08:26] <infinity> BenC: May as well pop out a 21.33 with that change ASAP, the buildds can take it. :)
[08:26] <infinity> And it'd be nice to see this in the next d-i build, so the next daily CDs are something we can point people at to test if it works.