**** BEGIN LOGGING AT Thu Feb 15 02:59:57 2007 Feb 15 03:29:28 thepeople * r6301 /packages/net/stunnel/Makefile: update stunnel to 4.20 Feb 15 17:28:51 <[pjf]> nbd, why does target description in /trunk/target/linux/atheros-2.6/Makefile say it only supports AR2315-AR2317? for me it seems the target supports more chips, AR2313 to name one Feb 15 17:29:47 that's old information Feb 15 17:29:57 haven't updated it after i added 2313 support Feb 15 17:30:03 <[pjf]> ah, great Feb 15 17:31:03 <[pjf]> I was worried 2313 is not supported yet Feb 15 17:32:35 <[pjf]> btw are you aware of any reference explaining what all these AR* actually are? I can see that one "Atheros WLAN Solution" (marketing crap) is frequently referred to as different AR* chips Feb 15 17:33:12 <[mbm]> ar = atheros; the madwifi docs expolain the model numbers Feb 15 17:34:46 <[pjf]> yes, but e.g. AR2313 seems to be a "major revision" of AR5312 - I'm just curious what actually sits behind these numbers - ie. is it a multiband MAC, is it a CPU, or whatever Feb 15 17:37:24 <[mbm]> 2313 is an soc; cpu, ethernet, wifi all in one Feb 15 17:39:55 <[pjf]> [mbm]: thanks for mentioning madwifi docs - I've found it (http://madwifi.org/wiki/Chipsets) Feb 15 17:50:32 5312,2312,2313 support isn't fully there yet Feb 15 17:50:37 working on it.. Feb 15 17:53:19 <[pjf]> Kaloz: what's missing in current support? Feb 15 17:54:08 we need to detect these somehow (have a few ideas, just dunno how to implement them yet), and set some values based on that Feb 15 17:54:35 because currently the 5312's flash access is fsck'ed up, and the 2312's and the 2313's ethernet Feb 15 17:55:17 Kaloz: try recompiling with the patch that i moved out of aruba-2.6 to generic-2.6 Feb 15 17:55:35 the tlbex change Feb 15 17:56:22 nbd: nah, the problem is that the 5312 needs width 2 while the others need 1, and 2312 and 2313 uses enet1 while 5312 uses enet0 or both enet0 and enet1 Feb 15 17:56:51 width for flash access i mean Feb 15 17:56:59 ah Feb 15 17:58:48 <[mbm]> nbd: what was that emulate instruction patch from last week? there's a whiterussian ticket which references that section of code Feb 15 18:00:02 generic-2.4/patches/115-branch_emul_fix.patch Feb 15 18:00:47 <[pjf]> Kaloz: any way I could help? Feb 15 18:01:00 <[pjf]> or do you plan to fix these soon? Feb 15 18:01:15 <[mbm]> nbd: https://dev.openwrt.org/ticket/1361 Feb 15 18:02:36 hmm Feb 15 18:02:37 weird Feb 15 18:02:44 doesn't have to be related Feb 15 18:02:57 <[mbm]> probably isn't Feb 15 18:04:02 <[mbm]> was just going to look to see if it was the same bug or if we'd just leave it as another wontfix whiterussian Feb 15 18:07:06 <[pjf]> Kaloz: not sure if you've noticed my previous notes about atheros.openwrt.net "fork" - I've found there a driver for ar531x flash - http://pastebin.ca/357489 Feb 15 18:07:58 <[pjf]> Kaloz: lines 131+ seem to be doing what you said about width Feb 15 18:08:33 hmz Feb 15 18:08:52 nbd: what do you think? that one or the one i've suggested? Feb 15 18:09:28 ? Feb 15 18:10:02 nbd: see [pjf]'s pastebin Feb 15 18:10:15 we won't use that one Feb 15 18:10:15 nbd: probably mine (reading into the board data) could be better for madwifi in the future, right? Feb 15 18:10:18 no need for a separate flash map driver Feb 15 18:10:28 nbd: well, we will need it sooner or later Feb 15 18:10:28 all it takes is setting up a platform device for physmap Feb 15 18:10:33 nbd: to detect the flash size Feb 15 18:10:37 no Feb 15 18:10:40 <[mbm]> hmm uclibc 0.9.28.1 came out last month Feb 15 18:10:43 we can do that from the board setup Feb 15 18:10:52 [mbm]: i have an uncommitted patch for openwrt Feb 15 18:11:03 <[mbm]> ah ok Feb 15 18:11:03 [mbm]: didn't get around to testing it more Feb 15 18:11:05 but it works on one platform Feb 15 18:11:12 <[mbm]> heh, was just about to try it myself Feb 15 18:11:14 nbd: really? fine (i know it works on spiflash, just didn1t know we cna do that for the nor) Feb 15 18:11:31 for spiflash we still use a custom driver Feb 15 18:11:36 yeah Feb 15 18:11:40 because of the custom flash ops Feb 15 18:11:41 but for nor flash we can skip that Feb 15 18:11:50 and have physmap use cfi detection Feb 15 18:12:01 nbd: okay, i got it now Feb 15 18:16:53 <[pjf]> hmm, any of you plan to fix the flash support on 5312 soon? Feb 15 18:17:29 sure Feb 15 18:17:59 <[pjf]> great, any ETA? ;-) Feb 15 18:18:19 "soon" ;) Feb 15 18:18:36 but for real, today or tomorrow Feb 15 18:18:47 <[mbm]> can't seem to find a uclibc changelog Feb 15 18:19:12 <[pjf]> oh that's really a good news for me :) Feb 15 18:19:12 [mbm]: well, other then being on a newer version that has some fixed i'm not interested in .28.1 Feb 15 18:19:19 [mbm]: all the new toys are in svn only Feb 15 18:19:38 <[mbm]> I know Feb 15 18:19:51 <[mbm]> I just wanted to know what the .1 fixed Feb 15 18:20:20 <[pjf]> Kaloz: regarding this ethernet driver - could you explain the issue a little more? Feb 15 18:20:46 <[pjf]> Kaloz: do you mean that ethernet devices appear under different names in userspace? Feb 15 18:23:01 the 5312 has two ethernets (even if only one is used on most of the designs), but the 2312 and 2313 has only one Feb 15 18:25:11 <[pjf]> any eta on this too? ;-) Feb 15 18:26:23 <[mbm]> what's the eta on the eta of the eta? Feb 15 18:27:37 eta? Feb 15 18:27:40 * loswillios hides Feb 15 18:27:50 <[pjf]> [mbm]: just asking Feb 15 18:28:39 <[mbm]> [pjf]: you have no sense of sarcasm Feb 15 18:29:08 * [mbm] didn't mean anything by it Feb 15 18:29:23 <[pjf]> [mbm]: probably I'm too new here ;-) Feb 15 20:06:24 [pjf]: yes. people that know this channel well simply ignore everything [mbm] says :) Feb 15 20:14:30 <[mbm]> nbd: that explains so much Feb 15 20:14:51 :) Feb 15 20:39:20 <[mbm]> hmm need to take another look at the package build system .. if I type make and compile everything, typing make again should return me to the prompt almost immediately Feb 15 20:46:31 never had that happen to mew Feb 15 20:48:45 <[mbm]> seems to be repackaging everything each time I run make Feb 15 21:00:22 <[mbm]> think it's time to take another look at package.mk and the verbose system Feb 15 21:13:29 nbd * r6302 /trunk/target/linux/atheros-2.6/ (6 files in 3 dirs): some ar531x cleanup Feb 15 21:45:44 <[mbm]> several superfluous calls to $(call ...) that can be removed from the makefile Feb 15 21:45:52 which ones? Feb 15 21:46:23 <[mbm]> things like $(call Build/Prepare) can be changed to $(Build/Prepare) Feb 15 21:46:57 * [mbm] still tidying up the package makefile looking for the cause of the sluggishness Feb 15 22:02:50 [mbm]: imho the timestamp.pl checks are making it sluggish Feb 15 22:03:11 i don't think the actual make syntax is making much difference Feb 15 22:04:29 <[mbm]> more to the point it's running build/compile way too often Feb 15 22:04:42 <[mbm]> every time I run make it wants to recompile Feb 15 22:39:07 mbm: you there? Feb 15 22:39:12 <[mbm]> yep. Feb 15 22:39:26 <[mbm]> quite omnipotent. Feb 15 22:39:54 OK, so where were we at -- I believe discussing replacement of devfs. Feb 15 22:40:03 <[mbm]> sure Feb 15 22:43:40 I have had a look at mdev, and am not totally convinced. mdev can populate the dev directory based on what modules are in the kernel, but it then needs to rely on another mechanism for hotplugging of devices. Feb 15 22:45:21 It looks like hotplug2 is the preferred mechanism for that, but it is not absolutely foolproof. Well I guess a lot of other mechanisms are not foolproof, but the udev procedures do work really well. Feb 15 22:46:31 I am prepared to try mdev and hotplug2 on a test system to see how well it works, in the mean time, in my 'production' systems I will use udev, because I know it works. Feb 15 22:48:07 <[mbm]> hmm Feb 15 22:48:31 <[mbm]> probably end up writing more custom hotplug scripts Feb 15 22:50:37 for many devices hotplugging is not really necessary, I think Feb 15 22:50:53 the ones without USB thingies for example Feb 15 22:51:10 This is the great thing about udev, there are VERY few scripts to write - udev essentially is tru plug and play. People may think it is bloat, but it generally figures out what needs to be done. Feb 15 22:54:29 <[mbm]> armijn: hotplug is used as an event system on openwrt Feb 15 22:54:45 <[mbm]> you press a button and it triggers off a hotplug event to run a button handler script Feb 15 22:55:08 <[mbm]> soon it'll be to the point that if you move network cables around it automatically restarts those interfaces Feb 15 22:56:44 that is done with ifplug Feb 15 22:58:07 <[mbm]> no, that's a daemon Feb 15 22:59:05 * armijn prods [florian] Feb 15 22:59:23 [florian]: do you have any estimate about Nagios flash + memory footprint? Feb 15 22:59:49 as in, how much memory and flash would be advisable to run Nagios in a decent way, with OpenWrt, on a router Feb 15 22:59:55 (did that make sense?) Feb 15 23:01:27 * loswillios tries to get a 32/128 733Mhz device on ebay Feb 15 23:04:48 ifplugd is cetainly a daemon, and it controls network devices very well, especiall on embedded devices which go on/and off-line from time to time. Feb 15 23:05:52 <[mbm]> yeah but that's a polled io inteded for interfaces which know their media state Feb 15 23:06:04 <[mbm]> we're talking about vlans Feb 15 23:07:43 I will but out now, but at least I now know where to find the developers, and if I have further questions, I will come back if I may? Feb 15 23:07:55 <[mbm]> sure Feb 15 23:08:09 thanks and good night. Feb 15 23:45:06 * [pjf] points http://hyperfighter.sk/ar-soc/ as another "linux on ar2313" project, linux 2.4 though Feb 15 23:45:29 <[mbm]> useless. Feb 15 23:46:16 <[pjf]> ack Feb 16 00:06:30 <[mbm]> ugh. Feb 16 00:06:41 <[mbm]> the package makefile deletes the package directory each compile? Feb 16 00:06:45 <[mbm]> annoying. Feb 16 00:07:28 i think we can get rid of many timestamp check problems if we move the ipkg build dir outside of PKG_BUILD_DIR Feb 16 00:07:49 we could use build_ARCH/ipkg-build Feb 16 00:07:55 or something like that Feb 16 00:08:13 <[mbm]> could have ipkg_ARCH/package Feb 16 00:09:00 <[mbm]> anyways, looks like most of the crap I was seeing was caused by it having to rebuild the ipkg each time Feb 16 00:09:08 nah, not another toplevel dir Feb 16 00:09:16 <[mbm]> imho it should only do that on a clean Feb 16 00:09:51 you mean it kills PKG_BUILD_DIR? Feb 16 00:10:36 <[mbm]> look at the package/Makefile compile rule Feb 16 00:11:04 <[mbm]> @-rm -f $(PACKAGE_DIR)/*.ipk Feb 16 00:11:07 <[mbm]> why!? Feb 16 00:11:23 ah, that one Feb 16 00:11:53 <[mbm]> let them clutter $(PACKAGE_DIR) all they want and only clean it when doing a package-clean or a clean Feb 16 00:12:31 <[mbm]> if I say clean, wipe the whole directory Feb 16 00:12:52 <[mbm]> if I say {package}-clean then just wipe {package}*ipkg Feb 16 00:13:21 <[mbm]> don't make me sit through pointless ipkg recompiles every time I type make Feb 16 00:13:35 cluttered bin/packages is problematic for the image builder Feb 16 00:14:10 <[mbm]> you're honestly going to tell me you think that rm rule was a good idea? Feb 16 00:14:16 no Feb 16 00:14:29 i may have committed it by accident Feb 16 00:14:47 let's throw it out, but we need a replacement Feb 16 00:15:13 base-files has the openwrt svn rev in its version number Feb 16 00:15:32 changing the base files and recompiling will leave more than one package in the packages directory Feb 16 00:15:53 <[mbm]> only if the rev changes Feb 16 00:16:09 <[mbm]> that was the point of adding rev to the name Feb 16 00:16:53 <[mbm]> something that would almost work is each time it's about to make a $package.ipkg it removes all existing $package*ipkg Feb 16 00:17:17 <[mbm]> so that it only rebuilds the ipkg when forced to Feb 16 00:17:36 <[mbm]> just need to watch out for namespace collision with the packages Feb 16 00:17:39 how about this? http://nbd.name/diff.txt Feb 16 00:18:22 <[mbm]> looks exactly like what I just said ;) Feb 16 00:19:00 yep Feb 16 00:19:09 was working on it before i read what you wrote :) Feb 16 00:20:05 <[mbm]> commit that, I've still got more work to do on my package.mk cleanup Feb 16 00:21:17 nbd * r6303 /trunk/include/package.mk: when building a package, make sure that older versions get removed Feb 16 00:21:42 nbd * r6304 /trunk/package/Makefile: remove annoying package rm command Feb 16 00:23:23 <[mbm]> much better. 660+ packages already compiled and I can now run 'make' without waiting for them to repackage Feb 16 00:24:11 <[mbm]> only takes 1m30 vs the 30+ min it used to Feb 16 00:24:36 that will be nice Feb 16 00:25:22 * [mbm] compiled every damn package Feb 16 00:25:39 have you though about subsorting bin by arch? Feb 16 00:25:48 thought Feb 16 00:26:17 should probably be sorted by board Feb 16 00:27:02 and we can probably remove the '-2.6' from most image filenames Feb 16 00:27:06 except for broadcom Feb 16 00:27:13 where there's both 2.4 and 2.6 Feb 16 00:27:37 mbm * r6305 /trunk/package/Makefile: remove obsolete compile-targets rule Feb 16 00:27:42 <[mbm]> ;) Feb 16 00:28:41 that commit is broken Feb 16 00:28:47 <[mbm]> ? Feb 16 00:28:49 ifeq ($(MAKECMDGOALS),compile-targets) Feb 16 00:28:49 MAKEFLAGS:=$(MAKEFLAGS) -j$(CONFIG_JLEVEL) Feb 16 00:28:51 ... Feb 16 00:29:25 <[mbm]> oh, right, missed that Feb 16 00:29:29 <[mbm]> should also be compile Feb 16 00:30:11 * [mbm] checks Feb 16 00:33:12 <[mbm]> ok, looks good Feb 16 00:33:18 mbm * r6306 /trunk/package/Makefile: missed a reference to compile-targets **** ENDING LOGGING AT Fri Feb 16 02:59:57 2007