Functions added to extern for stand alone programs

[PATCH] Functions added to extern for stand alone programs

This patch contains updated to the extern files for stand alone programs:
-Functions have been added to the extern list
-Function order has been modified to group related function together. -XF_VERSION increased to 4
-Function netboot_common changed from static to extern

The patch file is attached

This is the second patch

This feature does not seem to fall into any category in the list of U-Boot Custodians, so I guess it goes to you, Wolfgang.

The patch file is attached.

-Jeffrey Mann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_extern_func.patch
Type: application/octet-stream
Size: 7086 bytes
Desc: add_extern_func.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070509/e5310660/attachment.obj

...

...

Please post plain text.

...

+#if defined (CONFIG_4xx)	|| defined (CONFIG_MPC5xxx) || defined (CONFIG_74xx_7xx) || \
+    defined (CONFIG_74x)	|| defined (CONFIG_75x)	    || defined (CONFIG_74xx)	 || \

+ defined (CONFIG_MPC8220)|| defined (CONFIG_MPC85xx) || defined (CONFIG_MPC86xx) || \
+ defined (CONFIG_MPC83XX)
+ gd->jt[XF_out8] = (void *) out8;
+ gd->jt[XF_in8] = (void *) in8;
+ gd->jt[XF_in16] = (void *) in16;
+ gd->jt[XF_out16] = (void *) out16;
+ gd->jt[XF_in32] = (void *) in32;
+ gd->jt[XF_out32] = (void *) out32;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_NET)
+ gd->jt[XF_netboot_common] = (void *) netboot_common;
+#endif
+ gd->jt[XF_strcmp] = (void *) strcmp;
+#if (CONFIG_COMMANDS & CFG_CMD_NAND)
+ gd->jt[XF_do_nand] = (void *) do_nand;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_DATE)
+ gd->jt[XF_rtc_get] = (void *) rtc_get;
+ gd->jt[XF_do_date] = (void *) do_date;
+#endif
#if (CONFIG_COMMANDS & CFG_CMD_I2C)
gd->jt[XF_i2c_write] = (void *) i2c_write; gd->jt[XF_i2c_read] = (void *) i2c_read;
+ gd->jt[XF_i2c_probe] = (void *) i2c_probe;
#endif /* CFG_CMD_I2C */
+#if (CONFIG_COMMANDS & CFG_CMD_USB)
+ gd->jt[XF_usb_init] = (void *) usb_init;
+ gd->jt[XF_usb_stop] = (void *) usb_stop;
+#endif
+#if !defined(CFG_NO_FLASH)
+ gd->jt[XF_flash_write] = (void *) flash_write;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
+ gd->jt[XF_do_protect] = (void *) do_protect;
+ gd->jt[XF_do_flerase] = (void *) do_flerase;
+#endif
}

This #ifdef maze is too much even for my standards. And that does mean something.

Is there anybody out there with an idea how to avoid that?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,    CEO: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

my gut feeling is that

        gd->jt[XF_foo]  = foo;

should happen at the end of the file which defines foo.
This would remove the need for external definitions and ifdef mazes. But it would require some sort of jt_init function to be called in each file. This could be done using some linker magic (like module initialization in the kernel, or cli functions in u-boot)...

- Amnon

I apologize, I KNOW I selected 'plain text'.

I suppose that is one solution. "Linker magic" is beyond me, but would be very clean.

I didn't think it was that maze-like. The ifdefs are NOT nested, and I gouped all of the functions with the same ifdefs together in a reaonable order. Also, the ifdefs were removed from _exports.h and exports.h because they are not needed there, only when initializing the jump table in exports.c. But yes, that leads to a lot of them. I was just thinking about this and I was going to propose something else, but I think that by splitting up the jump table initialization, it gets even messier.

-JM

The cond_syscall() macro in the Linux kernel might be worth stealing. How about something like this?

#define cond_extern(name) asm(".weak\t" #name "\n\t.set\t" #name ", unimpl_extern")

static int unimpl_extern(void)
{
return -ENOSYS; /* or something more appropriate */
}

cond_extern(do_protect);
cond_extern(do_flerase);

Haavard

I do not understand what this does. Does it work?

How is this different that using the dummy function?

-Jeff

Yes, it does. See file: gcc.info, node: Function Attributes,
section: 5.24 Declaring Attributes of Functions

The main difference is that with "normal" functions you must make sure that the dummy function does not get compiled / linked when you implement a real function. "Weak" are simply overwritten if any user provides another (real) function with the same name. No #ifdef mess any more :-)

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen

So in practice, it would look something like this?:

void jumptable_init (void)

{
        int i;

        gd->jt = (void **) malloc (XF_MAX * sizeof (void *));
        for (i = 0; i < XF_MAX; i++)
                gd->jt[i] = (void *) dummy;

#define EXPORT_FUNC(name) asm(".weak\t" #name "\n\t.set\t" #name ", dummy"); #include <_exports.h>
#undef EXPORT_FUNC

        gd->jt[XF_get_version] = (void *) get_version;
        gd->jt[XF_malloc] = (void *) malloc;
        gd->jt[XF_free] = (void *) free;
        gd->jt[XF_getenv] = (void *) getenv;
        gd->jt[XF_setenv] = (void *) setenv;
        gd->jt[XF_get_timer] = (void *) get_timer;
        gd->jt[XF_simple_strtoul] = (void *) simple_strtoul;
        gd->jt[XF_udelay] = (void *) udelay;
        gd->jt[XF_install_hdlr] = (void *) irq_install_handler;
        gd->jt[XF_free_hdlr] = (void *) irq_free_handler;
        gd->jt[XF_i2c_write] = (void *) i2c_write;
        gd->jt[XF_i2c_read] = (void *) i2c_read;
      ........

}

it could't really be that simple, could it? I bet my sintax is wrong, and I still do not compleatly understand how the compiler intreprets "weak" and "set". But I can see how this would work.

-Jeff

Maybe.

I never used this assembler trickery before myself. So far, I only played with the C variant of it. Like that:

-> cat foo.c
#include <stdio.h>

int func(int, int);

int main (void)

{
        int i = func (2, 7);

        printf ("i = %d\n", i);

        return 0;
}

-> cat func.c
#include <stdio.h>

int __func (int a, int b)

{
        printf ("Default func called: %d + %d\n", a, b);

        return (a + b);
}

int func(int a, int b) __attribute__ ((weak, alias ("__func"))); -> cat private.c
#include <stdio.h>

int func (int a, int b)

{
        printf ("Private func called: %d * %d\n", a, b);

        return (a * b);
}

-> gcc -c *.c
-> gcc -o foo foo.o func.o
-> ./foo
Default func called: 2 + 7
i = 9
-> gcc -o bar foo.o func.o private.o
-> ./bar
Private func called: 2 * 7
i = 14

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is a human characteristic to love little  animals,  especially  if
they're attractive in some way.
	-- McCoy, "The Trouble with Tribbles", stardate 4525.6