sketch on init.app

[effbiae]

hi ian,

i want to bundle k scripts with k.app in the BMFS.
this will stop monitor from auto loading k because there will be more than one file in bmfs.
i propose auto loading a program if it is called 'init.app'

this PR is a sketch (not tested) of how it would look - i think it's simpler code, too. feel free to reject the PR if it's not right and implement it properly

also, here is a patch to baremetal.sh i'd need in order to bundle k (as init.app) with k scripts and data:

diff --git a/baremetal.sh b/baremetal.sh
index ec99812..69b7c49 100755
--- a/baremetal.sh
+++ b/baremetal.sh
@@ -410,12 +410,14 @@ function baremetal_bnr-uefi {
        baremetal_run-uefi
 }
 
-function baremetal_app {
+function baremetal_init_app {
        baremetal_sys_check
        cd sys
        if [ -f $1 ]; then
                ./bmfs bmfs.img format /force
-               ./bmfs bmfs.img write $1
+               for x in $*; do
+                       ./bmfs bmfs.img write $x
+               done
                cat fat32.img bmfs.img > baremetal_os.img
                cd ..
        else
@@ -486,8 +488,8 @@ elif [ $# -eq 1 ]; then
                baremetal_bnr
        elif [ "$1" == "bnr-uefi" ]; then
                baremetal_bnr-uefi
-       elif [[ "$*" == *".app"* ]]; then
-               baremetal_app $1
+       elif [[ "$1" == "init.app" ]]; then
+               baremetal_init_app $*
        else
                echo "Invalid argument '$1'"
        fi

it's hard to hack on baremetal with the mutiple repos and the ./baremetal.sh setup script. this is the main reason i'm posting a patch to baremetal.sh and not a PR. had you ever thought of condensing everything into the one repo?

best,
jack

[effbiae]

i've added a repo that will test this new functionality at
https://github.com/effbiae/init-bm

forget that patch for baremetal.sh. try this one:

diff --git a/baremetal.sh b/baremetal.sh
index ec99812..abc231f 100755
--- a/baremetal.sh
+++ b/baremetal.sh
@@ -410,13 +410,16 @@ function baremetal_bnr-uefi {
 	baremetal_run-uefi
 }
 
-function baremetal_app {
+function baremetal_init_app {
 	baremetal_sys_check
 	cd sys
 	if [ -f $1 ]; then
 		./bmfs bmfs.img format /force
-		./bmfs bmfs.img write $1
+		for x in $*; do
+			./bmfs bmfs.img write $x
+		done
 		cat fat32.img bmfs.img > baremetal_os.img
+		ls -l baremetal_os.img
 		cd ..
 	else
 		echo "$1 does not exist."
@@ -486,9 +489,6 @@ elif [ $# -eq 1 ]; then
 		baremetal_bnr
 	elif [ "$1" == "bnr-uefi" ]; then
 		baremetal_bnr-uefi
-	elif [[ "$*" == *".app"* ]]; then
-		baremetal_app $1
-	else
 		echo "Invalid argument '$1'"
 	fi
 elif [ $# -eq 2 ]; then
@@ -497,4 +497,8 @@ elif [ $# -eq 2 ]; then
 	elif [ "$1" == "install" ]; then
 		baremetal_install $2
 	fi
+else
+	if [ "$1" == "init.app" ]; then
+		baremetal_init_app $@
+	fi
 fi

[IanSeyler]

I'll take a look into this. I wonder if the auto started app name should be entered somewhere when monitor is built.

Everything used to be in a single repo back when the project started. Things were parted out as some people just wanted to make use of Pure64. The CLI was removed from the kernel and became Monitor since I have no need for a user interface with BareMetal-Node.

[effbiae]

yes, you could pass the auto start app name in a macro at build time. in c, this would look like

cc -DINIT=init.app c.c

Then in c.c
#ifndef INIT
#define INIT init.app
#endif

char* init=#INIT

[effbiae]

But linux/unix hard code "init" as the name of the first process that is run, so no need to make it configurable

[IanSeyler]

I've updated Monitor to search the disk for a file called "init.app". If one is found it will be auto-started.

[IanSeyler]

NASM does have some command line options that I use for building Pure64 (two different binaries from the same source). I'll look into that as well.