**** BEGIN LOGGING AT Fri May 09 03:00:01 2014 May 09 05:20:46 build #568 of uml is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/568 May 09 06:56:17 build #561 of x86 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/561 May 09 07:36:17 build #603 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/603 May 09 08:08:50 here is a diff of /proc/meminfo about 4.5 hours apart: http://sprunge.us/NZbN May 09 08:09:09 user-space process size didn't change May 09 08:28:00 russell--, memleak problems ? **** BEGIN LOGGING AT Fri May 09 08:32:12 2014 May 09 08:34:58 nighty-_: seemingly May 09 09:47:59 nbd r40742 trunk/package/libs/uclient/Makefile * uclient: fix uclient-fetch permissions May 09 10:05:07 hi all! May 09 10:05:46 nbd i am starting to understand how netifd is structured May 09 10:06:57 nbd: Felix, what do you think about this patch? Is it acceptable to solve the dhcp options this way? http://patchwork.openwrt.org/patch/5215/ May 09 10:08:01 but i still i am missing some piece like this i don't understand why is that way https://gitorious.org/netifd/netifd/source/98ca67469da70accd710b14c28e77be2126170a8:system.h#L59-60 May 09 10:12:20 slachta: don't do it that way May 09 10:12:50 cyrusff: Any other recommended way? May 09 10:12:56 yep one second May 09 10:12:59 looking for example May 09 10:13:40 slachta: https://dev.openwrt.org/browser/trunk/package/network/ipv6/odhcp6c/files/dhcpv6.script#L78 May 09 10:13:43 like that May 09 10:14:22 cyrusff: thank you, I will rework that :-) May 09 10:33:58 sure no May 09 10:34:00 *np May 09 11:18:55 nbd r40743 trunk/package/network/services/uhttpd/Makefile * uhttpd: update to the latest version, fixes cgi path handling issues May 09 11:26:39 nbd at the moment netifd is using ioctl to configure vlan, but from what i have understood there is no possibility to implement 802.1ad support with ioctl May 09 11:26:46 so i should use netlink May 09 11:27:43 yes May 09 11:28:42 i was thinking to implement functions calling thel vlan_ad instead of vlan May 09 11:29:08 then after have them working for 802.1ad generalize them so they support 802.1q too May 09 11:29:50 and that talk together if it is the case to port the actual 802.1q code to the new function (aka delete old function and rename the vlan_ad functions to vlan) May 09 11:57:05 luka r40744 trunk/tools/ quilt/patches/000-relocatable.patch quilt/Makefile quilt/patches/001-fix_compile.patch * [tools] quilt: update to 0.63 May 09 11:59:17 cyrus r40745 trunk/package/network/ipv6/odhcp6c/files/dhcpv6.script * odhcp6c: bring up nested interfaces on config change May 09 12:00:36 g10h4ck: fine with me May 09 13:30:40 nbd vid for vlan need just 12bit but it seems the most similar blob type is BLOBMSG_TYPE_INT32 May 09 13:31:06 it is ok to use that or should i pay some more attention to that ? May 09 13:31:14 INT32 is the standard integer type May 09 13:31:22 so yes, use that May 09 13:31:48 thanks :) May 09 13:33:16 nbd it is ok to use "proto" to specify if it is 802.1ad or 802.1q ? or this will make confusion with interfaces proto ? May 09 13:36:23 it should be type May 09 13:36:30 there is a type macvlan May 09 13:36:42 so the new ones would be type 8021q and type 8021ad May 09 13:37:25 jow_laptop type in this case is vlan May 09 13:37:47 but well we can model it as you said too May 09 13:38:59 but what i am trying to do is to implement 8021q and ad with the seme device and specify q or ad with an option (like you do with ip link add ...) May 09 13:40:50 we need an abstraction for ip link add in the near future for tunneling as well May 09 13:41:18 just try to keep the config hierarchy flat May 09 13:41:40 and try to keep it consisten May 09 13:41:56 for example as it would be done like proposed above you would have a config device type macvlan May 09 13:42:02 so you are suggesting to do different device type instead of specifing proto ? May 09 13:42:04 and config device type vlan proto q/ad May 09 13:42:32 then either make macvlan a proto too (config device type vlan proto macvlan) or q and ad distinct types May 09 13:42:59 well macvlan is not a vlan May 09 13:43:02 but i got the point May 09 13:44:08 would appreciate some other comments though May 09 13:45:10 i think it all depends on if you potentially want to run other network protocols on them May 09 13:49:06 the fact is that for ad and q the code is pretty identical May 09 13:49:25 how can i structure it in a way to not duplicate code ? May 09 13:56:06 ping jow_laptop May 09 13:56:48 cyrus r40746 trunk/package/network/ ipv6/odhcp6c/files/dhcpv6.script config/netifd/Makefile * netifd: Fix nested protocols going offline at reload + various route issues May 09 13:57:05 so the user see different type but the code is the same May 09 13:58:25 g10h4ck: you could use the same functions to set stuff up and pass an additional bool or enum value to differentiate between the protos May 09 13:59:00 like the stuff in system-linux.c where the same function is used to add/remove stuff and whether to add or remove is indicated by a bool May 09 13:59:49 so i have to define but 8021q_device_type 8021ad_device_type May 09 14:00:18 I have looked at Linuxtag schedule - is there anything interesting to recommend ? May 09 14:01:26 g10h4ck: I really have no opinion on the option type vs. option proto May 09 14:01:45 g10h4ck: I felt that adding a 3rd config layer would be confusing maybe, but on the other hand... idk May 09 14:01:56 idk ? May 09 14:02:00 i dont know May 09 14:02:22 what I usually do is to write some mockup uci configs that describe what you intend to configure May 09 14:02:31 then see if they make sense and are somewhat understandable May 09 14:02:52 then write the code according to it May 09 14:03:04 jow_laptop i think using type is more understandable May 09 14:03:32 but it wanna be perfect if we find a way to avoid code duplication... May 09 14:17:35 jow_laptop can i access type option from inside the device code just like mode or other options are accessed ? May 09 14:17:51 so it wouldn't be a problem May 09 14:22:46 I think so, yes May 09 14:23:29 so ther eshouldn't be a problem May 09 14:24:03 i can use the same device type and then inside the code check if it is ad or q May 09 14:26:24 yeah May 09 14:49:25 jow_laptop nbd in macvlan_base_cb what stay for cb ? May 09 15:11:03 in fact i believe there is a lot of code duplication with macvlan too... May 09 15:11:31 and probably it would be the same with a lot of other "virtual device" May 09 15:12:22 i am not C programming patterns expert would it be possible to have a base_virtual_device_type with good part of common stuff ? May 09 15:12:54 i come mainly from C++ and lua May 09 15:23:30 how can i test stuff being sure not briking my evices ? May 09 15:23:41 *devices May 09 15:24:11 well default config doesn't have vlanad related stuff May 09 15:24:31 so failsafe should work till i don't break already working things May 09 15:24:42 maybe i should get a serial access kit May 09 15:33:36 a serial console is very helpful when working with a router May 09 15:34:13 as for code duplication: what's the code that you consider duplicated and want reduce? May 09 15:35:18 for example macvlan_base_cb it seems to me that there will be a vlanad_base_cb almost identical to the one from macvlan May 09 15:35:40 now that you are there what cb stays for ? May 09 15:36:06 typically it's short for callback May 09 15:36:22 thanks :) it make perfectly sense May 09 15:36:59 do you agree that the two functions will be wuite similar ? May 09 15:39:46 yes May 09 15:39:52 i guess that one function will be easy to abstract May 09 15:40:13 yeah May 09 15:40:38 what it is the correct way to do that in C and in the specific case of netifd ? May 09 15:41:00 i suggest you do the simple thing first and write a similar function May 09 15:41:04 and we'll abstract it later May 09 15:41:09 ok :) May 09 15:41:18 the approach that i will probably take is this: May 09 15:41:51 create a struct (maybe sub_device or something like that) that groups together the struct device and struct device_user May 09 15:42:09 and has a common set of callbacks May 09 15:42:46 the idea is that this will be used for all cases where you have one device stacked on top of exactly one other device May 09 15:42:58 so not bridge, but the different kinds of vlan May 09 15:43:32 and the specific vlan type implementation only needs to define a create, a destroy and a config apply method or something like that May 09 15:43:52 but before writing the code for that, we need to make sure that all important cases are covered and this abstraction doesn't end up restricting useful cases May 09 15:44:37 ok May 09 16:44:21 <5EXAA8SU8> build #52 of pxa is complete: Failure [failed shell] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/52 May 09 17:46:25 <5EXAA8SU8> build #604 of atheros is complete: Failure [failed compile_2] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/604 May 09 17:46:25 <5EXAA8SU8> build #589 of ramips is complete: Failure [failed compile_2] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/589 May 09 17:46:54 <5EXAA8SU8> build #635 of brcm63xx is complete: Failure [failed compile_2] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/635 May 09 17:48:48 <5EXAA8SU8> build #559 of ppc44x is complete: Failure [failed shell shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/559 May 09 17:48:54 <5EXAA8SU8> build #604 of orion is complete: Failure [failed shell compile_2] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/604 May 09 17:50:20 <5EXAA8SU8> build #559 of rb532 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/559 May 09 18:04:21 <5EXAA8SU8> build #528 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/528 May 09 18:59:43 thepeople: cvs is missing from at least one of the buildbots, http://buildbot.openwrt.org:8010/broken_packages/ar71xx/transocks/compile.txt May 09 19:04:55 Is it possible to call '$(call Build/Configure/Default)' macro to process configure scripts in other subdirectory other than the default $(PKG_BUILDIR_DIR)? May 09 19:06:47 I tried ''$(call Build/Configure/Default,CONFIGURE_PATH="$(PKG_BUILD_DIR)/")' to no avail. May 09 19:10:06 <5EXAA8SU8> build #54 of mpc83xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/54 May 09 20:03:16 <5EXAA8SU8> build #55 of realview is complete: Failure [failed shell_15] Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/55 May 09 20:48:16 <5EXAA8SU8> build #466 of iop32x is complete: Failure [failed shell shell_10 shell_15] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/466 May 09 21:06:33 <5EXAA8SU8> build #538 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/538 May 09 21:24:41 <5EXAA8SU8> build #53 of cns3xxx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/53 May 10 02:08:01 <5EXAA8SU8> build #569 of uml is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/569 **** ENDING LOGGING AT Sat May 10 02:59:59 2014