On Thu, Jun 23, 2011 at 10:03:12PM +0200, Wolfgang Denk wrote: > Dear "Jason Hobbs", > Is this all new code, or was it copied from some other project? If > so, reference would be needed.
All new code. > Then, we need documentation how this is going to be used. Please add a > README with documentation of the interfaces and usage examples. Ok - I'll add this. > Also, I would like to know why you didn't adapt for example the menu > code from barebox - which specific advantages do you see in the code > you have chosen? I looked over barebox's menu code after you pointed it out, and it does have more functionality and a fancier interface than this implementation. Unfortunately, it appears that there aren't any menus defined to use it in the barebox codebase to provide a real example for it. The primary advantage of the implementation I've provided over the barebox implementation is simplicity. >From a user interface perspective, there are no ANSI terminal codes used, and selection of a choice is just typing out the name of the desired choice. It should work on any terminal, and would be easy to use with expect type automation tools. This simple prompt is also the default behavior for pxelinux, so should be familiar to end users. >From an implementation perspective, the code does exactly what's needed for pxecfg without adding extra features that would require some invention of functionality to prevent introduction of untested and dead code. It could work equally well for other jobs that just require a user to make a choice between some options presented on the screen, and if anything else is needed in the future, it should be extensible to accommodate. The simplicity makes the code size small - ~1k when built for my platform, vs ~2.5k for barebox's menu code. An example complexity from barebox's menu code we don't use here is each menu entry having its own display, destroy, and "call when selected action" method. Instead, we implement display the same way for all menus, destroy the same way for all entries in a menu, and the selected entry is merely returned to the caller for it to handle. The implementation also hides the details of the menu's internal structure from consumers of the interface - the menu and menu_item struct's are not externally defined, forcing all interaction to go through the function interfaces. Interface consumers provide a name and an opaque pointer to a data structure of the user's choice for each item, and the rest is shielded from the consumer's view. This should help prevent coding errors and make maintenance of the internals easier by preventing consumers from relying the implementation rather than the interface. Thanks, Jason _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
