On Tue, Apr 13, 2010 at 10:01 PM, Nguyen Thai Ngoc Duy <[email protected]> wrote: > Hi, > (...) > Except network and tty-related commands, others (sort of) work. wget > and vi work, although limited. Linux-specific commands won't work, > obviously.
Hi, I intend to port BusyBox to GNU Hurd, so I'm in a situation somewhat similar to yours. One question I have been asking to myself is whether and how the applets irrelevant to a target system should be dealt with: * disabled at the configuration stage using KConfig dependencies; * allowed to fail to build if the user chooses them; * allowed to build successfully with stub functions replacing the missing calls (a fake mount() function, for instance), but which will always fail at runtime. Of course, the first option would seem preferable from the user's point of view (though they may have some uses for stub commands), but on the other hand we don't want to end up with a myriad of HAVE_WHATEVER_SYSCALL configuration variables. So one possibility would be to use a few coarse-grained variables such as HAVE_COMPAT_UNIX (mount(), etc.) or HAVE_COMPAT_LINUX (/dev/loop*, etc.). A system would indicate whichever families of calls they mostly provide and fill-in the blanks with stub functions or system-specific implementations in a separate libbb source file. Do you think this could work? Denys, does it sound like it could be an acceptable solution? -- Jérémie Koenig <[email protected]> http://jk.fr.eu.org/ _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
