[03:21] <tkup> how do you create a /proc/sys entry in a kernel module. proc_register(&proc_root, &my_proc_entry) creates one in /proc
[04:39] <mjg59> BenC: prism54usb is supposed to be moving to softmac
[04:39] <mjg59> BenC: So if we can get that in, it would be great
[04:41] <mjg59> Oh, and prism54softmac seems to drive full prism54 hardware as well
[04:45] <BenC> ah, nice
[04:50] <mjg59> Possibly best to contact Jean-Baptiste to find out what's going on there
[04:51] <mjg59> There's almost no publically available information
[05:04] <mjg59> BenC: Checking Jean Tourrilhes's list, it looks like we have every currently available wireless driver (with the possible exception of the prism54usb stuff)
[05:05] <mjg59> Oh, and the Realtek stuff
[05:05] <mjg59> (Which you pulled because it was broken)
[05:08] <mjg59> Nngh. The Realtek stuff is still some weird other ieee80211 stack derived thing
[05:21] <BenC> great, latest bcm43xx driver seems to be using stuff that isn't available in softmac/ieee80211
[05:21] <mjg59> You're pulling the git tree for that now?
[05:21] <mjg59> (They moved away from mercurial)
[05:22] <BenC> oh, did they?
[05:22] <mjg59> Yeah
[05:22] <mjg59> Might explain it :)
[05:22] <BenC> yeah, definitely
[05:22] <BenC> thanks
[05:25] <BenC> gonna have to go with their daily snapshots...they are following linus tree now
[05:25] <mjg59> Nnngh. The rtl8180 stuff /still/ looks like pain
[05:25] <mjg59> Would probably be easy to port to softmac
[05:29] <mjg59> Gah, fuck, yes.
[05:29] <mjg59> It conflicts with the in-kernel stuff
[05:29] <mjg59> Stupid, stupid thing
[05:53] <mjg59> BenC: Still around?
[05:55] <BenC> yeah
[05:56] <BenC> just updated bcm43xx/softmac drivers on pb to test it
[05:56] <BenC> seems to be ok, but still only stable at 11M
[05:56] <mjg59> BenC: I've figured out a way to deal with rtl8180
[05:56] <mjg59> But I'm not sure you're going to like it
[05:56] <mjg59> Grab the newstack and their custom ieee80211 code
[05:56] <mjg59> Then (and this is the tricky bit)
[05:56] <BenC> sed?
[05:57] <mjg59> sed -i s/ieee80211/rtl_ieee80211/g *.c *.h
[05:57] <mjg59> Indeed
[05:57] <mjg59> It seems to work - their 80211 stack is entirely independent from the kernel one
[05:57] <BenC> well, I could just remove all the EXPORT_SYMBOLS and compile the ieee80211 stack into the module
[05:57] <mjg59> Nnf. Yeah, I guess.
[05:57] <mjg59> I'm not sure if that's any cleaner.
[05:58] <mjg59> Fucking insane.
[05:58] <BenC> so how hacked up is their ieee80211 stack?
[05:58] <mjg59> Not /very/, but it's based on a fairly ancient checkout
[05:58] <BenC> softmac has some hacking in the stock ieee80211 stack now
[05:59] <BenC> but it doesn't appear to break things
[05:59] <mjg59> Nowadays it should just be ported to softmac instead, but that's going to take a little while to look at the driver
[05:59] <mjg59> BenC: Actually, keeping it modular is probably more sensible
[05:59] <mjg59> That way we can get the 8187 (USB) driver as well
[05:59] <BenC> true
[06:01] <mjg59> Now all we need is an Inprocomm driver
[06:36] <mjg59> BenC: Hmm, no. prism54usb still seems to need its own madwifi-based stack.
[06:45] <kozz> BenC: and then in the directory debian/patches? the thing is that that directory do not exist
[06:46] <BenC> kozz: that's because there are no patches, everything is applied in the tree
[06:50] <kozz> right, can I find them somewhere?
[06:51] <BenC> sure, download linux-2.6.15.1.tar.bz2 and diff it
[06:52] <BenC> there are no seperate patches
[06:52] <BenC> it's all in the tree
[06:56] <kozz> seems like a strange solution, but ok, thanks
[07:21] <mjg59> BenC: Another one for you - http://www.saillard.org/linux/mrv8k/files/
[07:21] <mjg59> (Marvell lala driver, seems to be used on some Asus boards)
[03:16] <zul> heylo
[04:51] <zul> heylo...again
[05:59] <Mithrandir> BenC: *sigh*, my nvidia problem seems to have gone away, magically. :-/
[06:00] <BenC> sweet :)
[06:01] <Mithrandir> I'll see if I can make it come back somehow.
[06:47] <lamont> hrm.. first a word from our sponsors
[06:48] <BenC> lamont: do builds logs for *-security still go to your buildLogs url?
[06:48] <lamont> BenC: no
[06:48] <lamont> never have
[06:48] <BenC> where can I find them?
[06:48] <lamont> ask me or infinity nicely
[06:48] <lamont> the issue is that the -security builds are (generally) embargoed fixes
[06:48] <lamont> hence we don't publish them
[06:49] <BenC> just need to watch linux-source-2.6.{8,10,12} builds I just uploaded
[06:49] <lamont> well, watching never works anyway... - the log only shows up once the build is finished...
[06:49] <lamont> but I can certainly take a gander for you
[06:49] <BenC> well, that's what I meant :)
[06:49] <BenC> probably too soon to see anything
[06:50] <BenC> unless they failed really early
[06:53] <zul> BenC: i have some new crack for you
[06:53] <zul> ill put it in my tree tonight
[06:53] <BenC> ok
[06:54] <zul> just the rt2600 dirver and other bits
[07:30] <lamont> module ipv6 relocation of symbol in6_dev_finish_destroy is out of range (0x3ffeff7c in 17 bits)
[07:30] <lamont> ew
[08:00] <lamont> hppa report: 2.6.15-12.17 + klibc_1.1.16-1ubuntu1 booted.
[08:01] <lamont> BenC: does the ipv6 module get built with a massive (or series of) ld -r commands?
[08:01] <BenC> not sure
[08:01] <lamont> if so, that would explain the problem.
[08:02] <lamont> (binutils borkage for hppa)
[08:02] <BenC> is klibc working for ia64 yet?
[08:03] <lamont> BenC: that's the next test...
[08:16] <lamont> dist-upgrading my ia64 box to dapper is going to work,right???
[08:30] <zul> hehe..
[10:55] <lamont> hrm... ia64 runs elilo at upgrade time, but asks the user (outside of debconf) whether or not to run it.. --> bug
[11:10] <BenC> lamont: elilo needs to be run for update-initramfs too, which is something that doesn't happen right now (probably doesn't for lilo either)
[11:11] <lamont> BenC: it's more that it needs to not ask.
[11:11] <BenC> yeah
[11:11] <BenC> yaboot doesn't ask, it just does
[11:11] <BenC> same with grub