[U-Boot] [PATCH 1/2] COMMON: Add __stringify() function
This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf()
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org --- include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/common.h b/include/common.h index d1dd65a..451917d 100644 --- a/include/common.h +++ b/include/common.h @@ -268,6 +268,13 @@ typedef void (interrupt_handler_t)(void *); const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );})
+/** + * __stringify - preprocessor magic to return string from number + * @x: constant number + */ +#define __stringify_1(x...) #x +#define __stringify(x...) __stringify_1(x) + /* * Function Prototypes */
This shall eliminate the need for bubblesorting of commands at runtime. Every command definition structure is now put into it's own subsection of section .u_boot_cmd, that is .u_boot_cmd.<name> . These are then put into .u_boot_cmd by linker and lastly, linker uses SORT() over these subsections to make proper order on them. This shall eliminate some runtime overhead.
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org --- arch/arm/cpu/u-boot.lds | 2 +- common/cmd_help.c | 2 +- include/command.h | 9 ++++++--- 3 files changed, 8 insertions(+), 5 deletions(-)
******** * NOTE * THIS PATCH IS CRAZY ********
Further notes: - This is only compile-tested with gcc-4.7 (debian 4.7.1-5, binutils 2.22) - This patch affects only arm926t, obviously to make it proper, every linkerscript would have to be adjusted - I'm not sure at all the macro logic is correct, please check - Can this crash on *BSD or with older linker/cpp? - Please don't rip me limb to limb ;-)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index e49ca0c..c39193b 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -50,7 +50,7 @@ SECTIONS
. = .; __u_boot_cmd_start = .; - .u_boot_cmd : { *(.u_boot_cmd) } + .u_boot_cmd : { *(SORT(.u_boot_cmd.*)) } __u_boot_cmd_end = .;
. = ALIGN(4); diff --git a/common/cmd_help.c b/common/cmd_help.c index 8c8178e..5d778f5 100644 --- a/common/cmd_help.c +++ b/common/cmd_help.c @@ -41,7 +41,7 @@ U_BOOT_CMD( );
/* This does not use the U_BOOT_CMD macro as ? can't be used in symbol names */ -cmd_tbl_t __u_boot_cmd_question_mark Struct_Section = { +cmd_tbl_t __u_boot_cmd_question_mark Struct_Section(?) = { "?", CONFIG_SYS_MAXARGS, 1, do_help, "alias for 'help'", #ifdef CONFIG_SYS_LONGHELP diff --git a/include/command.h b/include/command.h index 6e1bdc2..42b4c6a 100644 --- a/include/command.h +++ b/include/command.h @@ -149,8 +149,11 @@ int cmd_process(int flag, int argc, char * const argv[], #define CMD_FLAG_REPEAT 0x0001 /* repeat last command */ #define CMD_FLAG_BOOTD 0x0002 /* command is from bootd */
-#define Struct_Section __attribute__((unused, section(".u_boot_cmd"), \ - aligned(4))) +#define __sectstr(__cmd,__name) .__cmd.__name +#define sectstr(type, __name) __stringify(__sectstr(type, __name)) + +#define Struct_Section(__name) \ + __attribute__((unused, section(sectstr(u_boot_cmd, __name)), aligned(4)))
#ifdef CONFIG_AUTO_COMPLETE # define _CMD_COMPLETE(x) x, @@ -170,7 +173,7 @@ int cmd_process(int flag, int argc, char * const argv[], U_BOOT_CMD_MKENT_COMPLETE(name,maxargs,rep,cmd,usage,help,NULL)
#define U_BOOT_CMD_COMPLETE(name,maxargs,rep,cmd,usage,help,comp) \ - cmd_tbl_t __u_boot_cmd_##name Struct_Section = \ + cmd_tbl_t __u_boot_cmd_##name Struct_Section(name) = \ U_BOOT_CMD_MKENT_COMPLETE(name,maxargs,rep,cmd,usage,help,comp)
#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \
Dear Marek Vasut,
In message 1343483279-11572-2-git-send-email-marex@denx.de you wrote:
This shall eliminate the need for bubblesorting of commands at runtime. Every command definition structure is now put into it's own subsection of section .u_boot_cmd, that is .u_boot_cmd.<name> . These are then put into .u_boot_cmd by linker and lastly, linker uses SORT() over these subsections to make proper order on them. This shall eliminate some runtime overhead.
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org
arch/arm/cpu/u-boot.lds | 2 +- common/cmd_help.c | 2 +- include/command.h | 9 ++++++--- 3 files changed, 8 insertions(+), 5 deletions(-)
Seems incomplete in several aspects:
1) what about all the non-ARM architecures and the board specific linker scripts?
2) what about removing the sort code?
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 1343483279-11572-2-git-send-email-marex@denx.de you wrote:
This shall eliminate the need for bubblesorting of commands at runtime. Every command definition structure is now put into it's own subsection of section .u_boot_cmd, that is .u_boot_cmd.<name> . These are then put into .u_boot_cmd by linker and lastly, linker uses SORT() over these subsections to make proper order on them. This shall eliminate some runtime overhead.
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org
arch/arm/cpu/u-boot.lds | 2 +- common/cmd_help.c | 2 +- include/command.h | 9 ++++++--- 3 files changed, 8 insertions(+), 5 deletions(-)
Seems incomplete in several aspects:
Below the section:
* NOTE * THIS PATCH IS CRAZY
There are a few notes. I'd actually like to know if this approach is correct at all, it might break on some crazy configurations or such.
- what about all the non-ARM architecures and the board specific linker scripts?
- This patch affects only arm926t, obviously to make it proper, every linkerscript would have to be adjusted
Which sucks, since there're a lot of them. But it can probably be automated.
- what about removing the sort code?
You mean in the _do_help() in common/command.c? We can do not only that, but we can do bisect search in find_cmd_tbl() now too. I'm still trying to figure out the most optimal implementation. The current one I have trimmed down the time by roughly 60%, but I don't like it.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201207282039.34518.marex@denx.de you wrote:
Seems incomplete in several aspects:
Below the section:
- NOTE * THIS PATCH IS CRAZY
Then what is actually the purpose of such a posting? Just dumping unsorted thoughts to community?
You are experienced enough to know what would be needed for a semi-clean patch, even if it's "just for RFC"...
There are a few notes. I'd actually like to know if this approach is correct at all, it might break on some crazy configurations or such.
Define "correct". It may be possible - but what would be the advantage? Which problem does it solve? In which way is it better than the current code?
- what about all the non-ARM architecures and the board specific linker scripts?
- This patch affects only arm926t, obviously to make it proper, every linkerscript would have to be adjusted
Which sucks, since there're a lot of them. But it can probably be automated.
Actually I doubt it makes sense at all.
I envision a situation where some "pluggable" code (say, a standalone application, or some form of loadable module whatever) can add new commands - it would be nice if these would still appear in sorted order, but this cannot be done at compile-time.
So please explain which actual problem you are rying to solve.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201207282039.34518.marex@denx.de you wrote:
Seems incomplete in several aspects:
Below the section:
- NOTE * THIS PATCH IS CRAZY
Then what is actually the purpose of such a posting? Just dumping unsorted thoughts to community?
I'd prefer to get some feedback, you know ...
You are experienced enough to know what would be needed for a semi-clean patch, even if it's "just for RFC"...
If you mean droping the ascii art ... well, yes.
But for draft patch, I'd like to actually see further ideas.
There are a few notes. I'd actually like to know if this approach is correct at all, it might break on some crazy configurations or such.
Define "correct".
If there's not some obvious flub in the code. If this kind of abuse of CPP is correct or not.
It may be possible - but what would be the advantage?
The list of commands will be already sorted.
Which problem does it solve?
Optimization, nothing else.
In which way is it better than the current code?
It's a bit faster.
what about all the non-ARM architecures and the board specific
linker scripts?
This patch affects only arm926t, obviously to make it proper, every
linkerscript would have to be adjusted
Which sucks, since there're a lot of them. But it can probably be automated.
Actually I doubt it makes sense at all.
It actually does ... but not in such a plain context.
I did this patch because we want the driver lists sorted. So I did this research and implemented it on the command list. I wanted to gather some feedback on if this actually can be done in such a way or if there'll be problems with toolchains maybe. Or any other issues.
I envision a situation where some "pluggable" code (say, a standalone application, or some form of loadable module whatever) can add new commands - it would be nice if these would still appear in sorted order, but this cannot be done at compile-time.
Certainly ... but we can keep a separate runtime table for these added commands.
So please explain which actual problem you are rying to solve.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 1343483279-11572-1-git-send-email-marex@denx.de you wrote:
This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf()
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
If you want to unify the use of such a macro, fine - but then please replace all ocurrences of equivalent definitions all over the code.
Thanks.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 1343483279-11572-1-git-send-email-marex@denx.de you wrote:
This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf()
Signed-off-by: Marek Vasut marex@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Mike Frysinger vapier@gentoo.org
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
If you want to unify the use of such a macro, fine - but then please replace all ocurrences of equivalent definitions all over the code.
Thanks.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201207282139.05998.marex@denx.de you wrote:
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
As for existing use, see for example
arch/powerpc/include/asm/processor.h:#define stringify(s) tostring(s) drivers/mtd/ubi/build.c:#include <linux/stringify.h> include/configs/km/keymile-common.h:#define xstr(s) str(s) include/configs/imx27lite-common.h:#define xstr(s) str(s) include/configs/tx25.h:#define xstr(s) str(s) include/configs/mx35pdk.h:#define xstr(s) str(s) include/configs/cam_enc_4xx.h:#define xstr(s) str(s) include/configs/ea20.h:#define xstr(s) str(s) include/configs/MPC8308RDB.h:#define xstr(s) str(s) include/configs/mpc8308_p1m.h:#define xstr(s) str(s) include/configs/flea3.h:#define xstr(s) str(s) include/configs/enbw_cmc.h:#define xstr(s) str(s) include/configs/at91sam9263ek.h:#define xstr(s) str(s) include/configs/amcc-common.h:#define xstr(s) str(s) include/configs/tam3517-common.h:#define xstr(s) str(s) include/configs/manroland/common.h:#define xstr(s) str(s) include/configs/qong.h:#define xstr(s) str(s) include/configs/ima3-mx53.h:#define xstr(s) str(s)
If you want to unify the use of such a macro, fine - but then please replace all ocurrences of equivalent definitions all over the code.
All these above (and any I eventually didn't find) should be replaced, then.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201207282139.05998.marex@denx.de you wrote:
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
I really wanted to keep this one separate, but I'll bend here. But if you mention those xstr()s below, it might be actually better to add __stringify() and then replace all those crazy xstr()s.
As for existing use, see for example
[...]
include/configs/ima3-mx53.h:#define xstr(s) str(s)
Thanks for pointing this out.
If you want to unify the use of such a macro, fine - but then please replace all ocurrences of equivalent definitions all over the code.
All these above (and any I eventually didn't find) should be replaced, then.
Good.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
On Saturday 28 July 2012 15:57:33 Wolfgang Denk wrote:
Marek Vasut wrote:
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
As for existing use, see for example
there's also MK_STR() and XMK_STR(). would be good to import linux/stringify.h (rather than adding these macros to common.h) and converting all consumers over to that. -mike
Dear Mike Frysinger,
On Saturday 28 July 2012 15:57:33 Wolfgang Denk wrote:
Marek Vasut wrote:
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
As for existing use, see for example
there's also MK_STR() and XMK_STR().
Grunt ... how do you find those? Or is it that you just happened to run over them?
would be good to import linux/stringify.h (rather than adding these macros to common.h) and converting all consumers over to that.
I wonder, what's the gain?
-mike
Best regards, Marek Vasut
On Tuesday 31 July 2012 09:55:55 Marek Vasut wrote:
Dear Mike Frysinger,
On Saturday 28 July 2012 15:57:33 Wolfgang Denk wrote:
Marek Vasut wrote:
include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
As for existing use, see for example
there's also MK_STR() and XMK_STR().
Grunt ... how do you find those? Or is it that you just happened to run over them?
these are the ones we use in Blackfin boards that i happened to stumble across when reading some common code
would be good to import linux/stringify.h (rather than adding these macros to common.h) and converting all consumers over to that.
I wonder, what's the gain?
one less way we're different from linux for importing code -mike
Dear Mike Frysinger,
On Tuesday 31 July 2012 09:55:55 Marek Vasut wrote:
Dear Mike Frysinger,
On Saturday 28 July 2012 15:57:33 Wolfgang Denk wrote:
Marek Vasut wrote:
> include/common.h | 7 +++++++ > 1 file changed, 7 insertions(+)
We have similar things already, and we don't add dead code - you add a macro without users here.
It's used in 2/2 ... what macro do you have in mind ?
Then add it with the patch that uses it.
As for existing use, see for example
there's also MK_STR() and XMK_STR().
Grunt ... how do you find those? Or is it that you just happened to run over them?
these are the ones we use in Blackfin boards that i happened to stumble across when reading some common code
Ugh ... makes you feel like Indy, discovering gems in crazy places and fighting hordes of evil code ...
would be good to import linux/stringify.h (rather than adding these macros to common.h) and converting all consumers over to that.
I wonder, what's the gain?
one less way we're different from linux for importing code
Not that that macro is ever gonna change, but so be it.
-mike
Best regards, Marek Vasut
On Tuesday 31 July 2012 10:08:51 Marek Vasut wrote:
Dear Mike Frysinger,
On Tuesday 31 July 2012 09:55:55 Marek Vasut wrote:
Dear Mike Frysinger,
would be good to import linux/stringify.h (rather than adding these macros to common.h) and converting all consumers over to that.
I wonder, what's the gain?
one less way we're different from linux for importing code
Not that that macro is ever gonna change, but so be it.
i meant #include's, not the API itself. you're right that likely this API will never change. -mike
participants (3)
-
Marek Vasut -
Mike Frysinger -
Wolfgang Denk