**** BEGIN LOGGING AT Mon Jan 15 02:59:58 2007
Jan 15 11:15:27 <[florian]> hi guys
Jan 15 11:15:33 <wrt> hi
Jan 15 11:53:43 <wigyori> yo
Jan 15 13:07:22 <CIA-6> nico * r6105 /packages/ipv6/aiccu/ (3 files in 2 dirs): update aiccu to 20070107 (should close: #1201)
Jan 15 13:12:28 <CIA-6> nico * r6106 /packages/net/miniupnpd/Makefile: update miniupnpd to 20070112
Jan 15 14:03:39 <[florian]> nbd: are you there ?
Jan 15 14:04:14 <nbd> yes
Jan 15 14:05:20 <[florian]> may I ask you some questions about how a driver interact with the /proc fs ?
Jan 15 14:05:50 <nbd> sure
Jan 15 14:06:01 <[florian]> I have a written a small driver that let me enable/disable the led on Qube2
Jan 15 14:06:11 <[florian]> and I created a /proc entry
Jan 15 14:06:15 <[florian]> named /proc/cobalt_led
Jan 15 14:06:19 <nbd> 2.4 or 2.6?
Jan 15 14:06:22 <[florian]> 2.6
Jan 15 14:06:42 <nbd> maybe you should look at the button/led framework
Jan 15 14:06:48 <nbd> might save some code that way
Jan 15 14:06:55 <[florian]> ok, I will have a look at it then
Jan 15 14:07:15 <[florian]> nbd: I have defined the two main callbacks : write/read
Jan 15 14:07:38 <[florian]> and I would like the /proc/cobalt_led to have a default value once loaded, how can I do that ?
Jan 15 14:09:08 <nbd> that doesn't really have much to do with /proc
Jan 15 14:09:19 <dragorn> add a modparm and modify udev/hotplug to load the module w/ the default parm set
Jan 15 14:11:07 <[florian]> dragorn: humm
Jan 15 14:12:36 <CIA-6> nico * r6107 /packages/net/parprouted/Makefile: update parprouted to 0.64, add dependency on libpthread
Jan 15 14:13:41 <[florian]> nbd: how is this done for instance in diag ?
Jan 15 14:14:30 <nbd> [florian]: it simply reads the gpio
Jan 15 14:15:13 <[florian]> nbd: ah, but I mean, while registering the /proc, how can you give it a value ?
Jan 15 14:15:36 <nbd> why not set the gpio to a known state
Jan 15 14:15:38 <nbd> so that when reading it it'll have the right initial value
Jan 15 14:15:50 <[florian]> I have a known state while registering
Jan 15 14:16:12 <nbd> then i don't understand your problem
Jan 15 14:16:54 <[florian]> what is the data field of the proc_dir_entry structure for ?
Jan 15 14:17:10 <nbd> for passing data to the read function
Jan 15 14:17:21 <[florian]> ok
Jan 15 14:17:23 <nbd> so that you can use the same reader for multiple /proc entries
Jan 15 14:17:43 <[florian]> well, my problem is that the /proc/cobalt_led when the module is loaded, has an empty value
Jan 15 14:17:54 <[florian]> and I would like to have a default value, like 1 or 0
Jan 15 14:18:07 <nbd> show me the code
Jan 15 14:18:09 <nbd> that'll make it easier
Jan 15 14:18:20 <[florian]> yeah you are right
Jan 15 14:19:54 <[florian]> http://pastebin.ca/317329
Jan 15 14:20:50 <nbd> your read function does not return any data
Jan 15 14:21:44 <nbd> actually it just contains some code that should belong to the write function
Jan 15 14:21:50 <[florian]> ok
Jan 15 14:22:02 <[florian]> when we talk about write/read on which side are we ? kernel or user ?
Jan 15 14:22:05 <nbd> /proc does not store any state of the 'files' in there
Jan 15 14:22:14 <nbd> write is when userspace writes something to the file
Jan 15 14:22:21 <nbd> read is when user space wants to read from the file
Jan 15 14:22:25 <[florian]> ok
Jan 15 14:22:53 <[florian]> so my read function should only return cobalt_led_state actually
Jan 15 14:23:00 <nbd> imho you should save yourself the trouble of fixing these proc handlers, as it's probably just as much work as using the led/button stuff
Jan 15 14:23:28 <[florian]> nbd: ok I will have a look at the LED api, I just found very few doc about it
Jan 15 14:23:48 <[florian]> nbd: what about the rest of the code, does this sound of to you ?
Jan 15 14:25:03 <nbd> i'd merge {enable,disable}_led into one function
Jan 15 14:25:09 <nbd> to just set the state
Jan 15 14:25:24 <[florian]> ok
Jan 15 14:25:56 <[florian]> why is not the diag driver using the LED api ?
Jan 15 14:26:05 <nbd> because it has to support 2.4
Jan 15 14:26:27 <[florian]> why not ifdef in the code ?
Jan 15 14:26:40 <[florian]> it would create too much 2.6 and 2.4 specific part of it ?
Jan 15 14:26:46 <nbd> simply not worth it
Jan 15 14:26:51 <[florian]> ok
Jan 15 14:26:56 <nbd> because then we'd have to have abstraction stuff for the scripts as well
Jan 15 14:27:01 <nbd> which creates unnecessary overhead
Jan 15 14:35:15 <nbd> seems like there's no generic button api yet. i thought someone had written something like that
Jan 15 14:54:05 <[florian]> ok, just ported the stuff the LED api
Jan 15 14:54:44 <[florian]> hu hu, just works !
Jan 15 14:55:30 <nbd> :)
Jan 15 14:55:55 <[florian]> I am really happy, now I can sleep without having too much blue light :)
Jan 15 14:56:14 <[florian]> now, let's see if it can be triggered easily on hard disk activity
Jan 15 14:59:04 <armijn> but lights are good!
Jan 15 15:01:39 <crazy_imp> i don't like led's if i want to sleep, i can (if you give your eyes some time) walk around in my room without any other light source :D
Jan 15 15:03:16 <crazy_imp> would be nice if the devices would come with a small tuneable resistor for all the led's so you could bring them down to a normal level, they don't need to be ultra-bright
Jan 15 15:03:45 <[florian]> yep
Jan 15 15:06:16 <[florian]> I am completely fond of xmoto, have you guys tried yet ?
Jan 15 15:06:37 <crazy_imp> whats that?
Jan 15 15:07:52 <[florian]> emerge xmoto ;)
Jan 15 15:08:03 <crazy_imp> later^^
Jan 15 15:08:31 <crazy_imp> is google down?
Jan 15 15:09:09 <[florian]> not now
Jan 15 15:09:37 <crazy_imp> thats wicked, google.de/.com doesn't work here but google.fi :D
Jan 15 15:35:36 <[florian]> the led api is incredibly easy to get used to :)
Jan 15 19:25:37 <Bartman007> [florian]: you aren't the only xmoto addict here.  and I've gotten several other people hooked :-)
Jan 15 22:34:24 <Bartman007> nbd: your .zip unpack fix in r6083 broke dhcp6
Jan 15 22:35:44 <Bartman007> it is prompting to replace files in trunk/build_<arch>/dhcp6-1.0/..
Jan 15 22:36:25 <Bartman007> err, trunk/build_<arch>/dhcp6-1.0/../client
Jan 15 22:39:08 <nbd> let me check...
Jan 15 22:39:28 <nbd> the fix was correct, the dhcp6 package is not
Jan 15 22:39:44 <Bartman007> I figured it was the fault of the package.
Jan 15 22:40:00 <nbd> where is the dhcp6 package?
Jan 15 22:41:13 <Bartman007> packages/ipv6/dhcp6
Jan 15 22:41:26 <nbd> ah
Jan 15 22:42:35 <CIA-6> nbd * r6108 /packages/ipv6/dhcp6/Makefile: fix unpacking of the dhcp6 package
Jan 15 22:42:36 <nbd> fixed
Jan 15 22:42:36 <nbd> :)
Jan 15 22:43:10 <Bartman007> cool.
Jan 15 22:44:20 <armijn> every weekend I decide "now I will start building OpenWrt" and then there is always a flurry of activity
Jan 15 22:44:23 <armijn> makes it hard :)
Jan 15 22:44:33 <nbd> :)
Jan 15 22:44:52 <Bartman007> armijn: only try to build at a time when normal people would be awake.
Jan 15 22:45:06 <armijn> but I clearly understand that you don't want to make a stable release...it would mean supporting it
Jan 15 22:45:08 <Bartman007> everyone knows that good code is generated at night.
Jan 15 22:45:10 <armijn> for a longer time
Jan 15 22:45:22 <nbd> yeah, most of the commits come from the european timezone, so it's easy to do :)
Jan 15 22:45:27 <armijn> Bartman007: I'm asleep at when normal people are awake
Jan 15 22:45:30 <armijn> -at
Jan 15 22:45:41 <Bartman007> armijn: use cron or at
Jan 15 22:45:45 <Bartman007> :-)
Jan 15 22:46:14 <armijn> hm
Jan 15 22:46:21 <armijn> but the next day there will be more fixes
Jan 15 22:46:38 <Bartman007> good code is also never finished
Jan 15 22:46:55 <armijn> bad code is never finished
Jan 15 22:46:59 <armijn> good code eventually is
Jan 15 22:47:17 <nbd> nah, good code always leaves places to build on
Jan 15 22:47:31 <Bartman007> good code may be finalized, but it is never finished
Jan 15 22:47:36 <armijn> stupid Realtek 8181 access points...bleh
Jan 15 22:47:47 <armijn> quite a few have some daemon running on port 31727
Jan 15 22:47:59 <armijn> which allows everybody to reset the MAC address, etc.
Jan 15 22:48:07 <armijn> still need to make some code that does that
Jan 15 22:48:37 <armijn> it has been known since 2004, but Edimax (who provided the software stack for most machines) is not fixing it
Jan 15 22:51:04 <armijn> quite sad
Jan 15 23:06:08 <Bartman007> looks like there are hosting issues with aiccu_20070107.tar.gz, permissions issues, though aiccu_20070115.tar.gz is available;   this is all at (http://www.sixxs.net/archive/sixxs/aiccu/unix/)
Jan 15 23:07:50 <[florian]> Bartman007: ok, I will update
Jan 16 01:44:09 <CIA-6> nbd * r6109 /trunk/target/linux/ (brcm-2.4/Makefile brcm-2.6/Makefile brcm47xx-2.6/Makefile): remove bogus part of the broadcom target descriptions
**** ENDING LOGGING AT Tue Jan 16 02:59:57 2007