[This followup was posted to comp.os.minix and a copy was sent to the
cited author.]
article <
81420ede-0178-4c95...@googlegroups.com>,
einste...@gmail.com says...
Krunal,
I recommend you take a traditional engineering "divide and
conquer" approach. Consider the following hypothetical -
You have a graphical program running on a Linux box. The
Linux box has a TCP (ethernet) connection to a Minix box.
You can log-in remotely from the Linux box to the Minix box,
transfer files (via ckermit or ftp, etc.).
The graphical program on the Linux box allows the user to
click on options, enter choices for directory and file
names, etc. There is a 'GO' button that builds a Minix
kernel when pressed by issuing commands to the Minix box.
The 'GO' action may have to first create a make file
from the designated options and choices which winds up on
the Minix box. The 'GO' action should also check for
option compatibility and completeness, supply any needed
defaults, etc.
Parallel execution is handled by having the make file or
other commands from the graphical program run commands on
the Minix box in the background. Parallel execution will
also require creating and running some sort of 'listener'
process to receive asynchronous messages from the background
processes that they are done.
Of course, the 'GO' action should also be prepared to
detect and handle failures in the kernel build.
After the kernel is built, the graphical program moves the
new kernel (as needed) to it's active location, updates the
boot manager files and boot sector, etc. Then it can command
the Minix box to reboot. The default options should probably
try to retain a 'stable' kernel as well as an 'experimental'.
Once the above scenario is working, the other half of the
"divide and conquer" is to implement a GUI system on the Minix
box (X-windows, D-Flat, etc.) and transfer the graphical
interface to run on the Minix box.
Even if you never actually use the Linux box, the above
framework should allow you to see how to break-out all the
individual tasks (& data files & commands, etc.) needed for
your goal. It should also help you to organize incremental
development and testing.
E.g. - first get an X-windows program to accept options
and issue a make file+command to build a simple
'hello world!' program. Pass the commands through a
subroutine that can be re-purposed to use remote or local
TCP channels, or can launch remote commands, or can 'fork'
a command to a child process, etc. Test for success,
failure, time-out, etc.
Second, get the kernel to (re)build from a script that
creates a make file from a file of options.
Third, make a graphical program that collects the kernel
options, creates an options file, and then runs the script.
Finally, consolidate all of the above into your graphical
program, and simplify it to issue the needed commands w/
the designated options directly. Move checks from the
make file to the graphical program as needed/convenient.
Of course, the graphical program must launch with the
usual hierarchy of 'defaults' from command-line options,
environment variables, and config file(s) :-).