On 04/01/08 16:59 -0800, ron minnich wrote:
I'm writing an 'empty' payload for testing. It will do nothing but POST and send out chars in a tight loop.
I am wondering about making it part of v3 tree. Just make an emptypayload directory. This would make testing easier.
This would be a good start for the payload library idea that we've been tossing around. A few months ago, I rearranged bits and pieces of FILO into a C like library - I have a helloworld sitting around somewhere. Uwe and I have discussed in the past adding things like tinylib and his ncurses work from GSOC, and its not out of the realm of possibility to port something like directFB or TWIN in too.
But believe it or not - if you want to start off rewriting code from scratch, that would be better. I think that if we had a payload library, it would behoove us all to licence it LGPL. As a vendor, I think our biggest selling point for LinuxBIOS is that the customer has control over the payload to do what they need to do, and sometimes, for better or worse, those payloads need to do things that customers cannot or will not expose with GPL. A great example is the long lamented CE loader. There are two measly variables in the information structure for CE that are not yet exposed by Microsoft (If you have the CE development kit, you can see the header, but its capped off by the usual nasty Microsoft copyright message). If the library was LGPL, then we could at least publish the binary payload, which would be a start until Microsoft moved on and saw fit to document the last few variables.
I would be happy to work with you on the loader scripts and other fun that we would need to make it go. My thought is that we can make some shell wrappers around gcc to point to the right locations, and then it would be as easy as:
libpayload-gcc -o mypayload mypayload.c
just give us a main() and a pocket full of dreams and we'll do the rest.
Jordan