**** BEGIN LOGGING AT Fri Sep 20 03:00:00 2013
Sep 20 15:26:06 <ant_work> bluelightning: Jay7: do you master the use of preprocessor macros as functions?
Sep 20 15:26:48 <bluelightning> I don't think I've ever had to write such a construct, though I've seen them a lot in code
Sep 20 15:27:03 <ant_work> idem until yesterday ;)
Sep 20 15:27:04 <Jay7> it's better to avoid using macroses at all :)
Sep 20 15:27:13 <ant_work> https://lkml.org/lkml/2013/9/18/568
Sep 20 15:27:26 <ant_work> so I did
Sep 20 15:27:27 <ant_work> http://paste.debian.net/43498/
Sep 20 15:27:44 <ant_work> but...
Sep 20 15:27:54 <ant_work> in asm/memory.h I see as well
Sep 20 15:28:00 <ant_work> #define __va(x)                 ((void *)__phys_to_virt((unsigned long)(x)))
Sep 20 15:28:15 <ant_work> so maybe I could simplify  #define param_start(x) __va(x)
Sep 20 15:28:28 <ant_work> the code compiles and *even* runs
Sep 20 15:28:31 <ant_work> :p
Sep 20 15:28:40 <ant_work> just is not my daily bread...
Sep 20 15:28:55 <ant_work> do you spot obvious errors?
Sep 20 15:29:46 <ant_work> afaik the extra pair of () is only necessary for aritmetic
Sep 20 15:29:59 <ant_work> so one could go as well...
Sep 20 15:30:20 <ant_work> but if they use it in the header there must be a valid reason
Sep 20 15:47:56 <Jay7> ant_work: I think it's easier to send updated version to ML and look :)
Sep 20 15:48:21 <ant_work> I fear we'll have v5, v6...
Sep 20 15:48:57 <Jay7> or try to catch some hardcore C programmer :)
Sep 20 15:49:06 <Jay7> someone from klibc e.g. :)
Sep 20 15:49:29 <ant_work> good idea
Sep 20 15:50:24 <ant_work> btw  Preliminary kexec support for Linux/m68k
Sep 20 15:50:34 <ant_work> mira of #klibc will be happy
Sep 20 15:58:36 <ant_work> Jay7: anyway, I think the __va() macro should be preferred
Sep 20 15:58:48 <ant_work> I'll change that
Sep 20 15:59:01 <Jay7> I don't know context, so I can't give right answer :)
Sep 20 15:59:27 <ant_work> np
Sep 20 16:32:52 <Jay7> ant_work: btw
Sep 20 16:33:06 <Jay7> do you have something non-merged in your github kexecboot repo?
Sep 20 16:34:32 <ant_work> 5 commits
Sep 20 16:34:54 <ant_work> https://github.com/kexecboot/kexecboot/network
Sep 20 16:35:10 <ant_work> 6
Sep 20 16:36:16 <Jay7> ah, ok
Sep 20 16:36:23 <Jay7> tomorrow is deadline
Sep 20 16:36:32 <ant_work> one zeldin patch is not merged iirc
Sep 20 16:36:34 <Jay7> I consider to do quick run this night..
Sep 20 16:36:39 <ant_work> ok
Sep 20 16:37:09 <Jay7> 1) be able to work w/o procfs
Sep 20 16:37:18 <Jay7> 2) add EXEC boot method
Sep 20 16:37:25 <ant_work> gosh
Sep 20 16:37:58 <ant_work> that's much work
Sep 20 16:38:27 <Jay7> I'll try at least :)
Sep 20 16:38:49 <Jay7> http://elinux.org/Improve_kexecboot
Sep 20 16:39:26 <Jay7> we have done already some things from (1)
Sep 20 16:39:30 <Jay7> completely done (2)
Sep 20 16:40:17 <Jay7> (5) need more work to implement
Sep 20 16:45:30 <ant_work> bbl
Sep 20 18:58:44 <Jay7> ant_home: hi
Sep 20 18:58:51 <Jay7> I'm about fb.stride
Sep 20 18:59:25 <Jay7> are you building from your branch?
Sep 20 19:00:27 <Jay7> well.. right question is how wide is it tested? :)
Sep 20 19:23:49 <ant_home> I've built qvga and vga
Sep 20 19:24:00 <ant_home> but tested only on LE
Sep 20 19:24:21 <ant_home> brb
Sep 20 20:31:29 <Jay7> no.. I feel too sleepy
Sep 20 20:31:43 <Jay7> so I'll only merge changes tonight
Sep 20 20:33:16 <Jay7> ok, merged
Sep 20 20:33:55 <Jay7> a lot of code shuffling needed to implement ability to run w/o procfs
Sep 20 20:34:02 <Jay7> may be tomorrow
Sep 20 20:36:51 * Jay7 -> sleep
Sep 20 20:37:06 <ant_home> there are a couple of 'new' kexec based text-gui bootloader
Sep 20 20:37:32 <ant_home> check their code as wll
**** ENDING LOGGING AT Sat Sep 21 03:00:00 2013