<alMalsamo>"Work is ongoing to use other, smaller POSIX kernels." what other kernels does this refer to? <oriansj>pabs3: well we knew bootstrapping is a rapidly moving target. It is why getting sources we can use checked into long term storage is an essential task (so that source sticks around long term). <oriansj>unmatched-paren: interesting find but the lack of a license is a serious problem. <oriansj>alMalsamo: well bauen1 has a kernel that he wrote and was working to get it buildable by TCC, I am uncertain of the exact status of that work (last I checked it was x86 only and needed GCC) <oriansj>but that being said we only need only a dozen or so system calls supported to bootstrap up to TCC; so simpler, single tasking kernels are also an option. <bauen1>oriansj: yes, i didn't work any further on it <bauen1>oriansj: well, that but mostly time <bauen1>oriansj: if i have time and interest again, i would also start looking into writing a microkernel, as that is potentially easier to bootstrap on bare metal <oriansj>bauen1: hmmm, well if we wanted to go extreme and solve it I could take a month to convert a C kernel to assembly and then hand convert to M0 <stikonas>we should at least get C kernel working... <stikonas>but that might take time. We don't have many people doing kernel work here. <bauen1>stikonas: there's quite a few hobby C kernels that (in theory) could be converted to be tinycc compatible (or tinycc could be patched), that could support running at least parts of the bootstrap, see e.g. https://github.com/klange/toaruos/ and osdev <oriansj>fortunately (or perhaps not so) our needs are rather boring: atleast single tasking, a handful of syscalls and that is it <oriansj>no need for any libc or dynamic linking <oriansj>AwesomeAdam54321: doesn't matter honestly, we only need one properly bootstrapped. <oriansj>so I guess the one that most appeals to someone willing to do the work <bauen1>arm sbcs are quite cheap to come by and often already have open source drivers for everything <oriansj>bauen1: well the only driver needed would be reading/writing to a single media <oriansj>no need for TTY support or even basic display <oriansj>(unless one wishes to just display what is being exec'd and what is exiting) <bauen1>oriansj: you'd need some sort of filesystem, now you could get away with read-only filesystems and a tmpfs if you have enough ram <oriansj>bauen1: well we can assume as much RAM as we need. <oriansj>as 4GB seems to be enough for live-bootstrap to really get going <oriansj>and we only need to support the stage0-posix, Mes-m2 and TCC-meslibc bits <oriansj>as we can just use TCC to build a more powerful kernel with much more support <oriansj>and then we just write that kernel somewhere (like a separate media) with a handful of pieces and continue from there <oriansj>possibly step 20 (tcc 0.9.27 (musl)) if we really need it ***Guest8046 is now known as roptat
<oriansj>as we would want the kernel to be as *MINIMAL* as possible; to make the assembly version into something auditable. <oriansj>cc_* is about 16KB of assembly and it isn't the easiest thing to audit. So if the assembly version of the kernel can be under 64KB it will still be auditable (with considerable effort) so smaller will be better. <bauen1>oriansj: i still think you'd need some more drivers, as you would need to audit the source code before you compile and execute it <oriansj>bauen1: let us assume one has a trusted method of putting source code on the media and we can solve that later <oriansj>we are not going to be doing development nor auditing on that kernel while it runs <oriansj>everything that can stripped out, should be <stikonas>oriansj: only C prototype of cc_* is 16 KiB <stikonas>cc_* itself is about 200 KiB of assembly <stikonas>but yes, I agree that we should first get something stripped down (without development or auditing) <oriansj>I don't count the comments against the auditability of assembly <oriansj>I guess I have a new project I need to find time for. <oriansj>just make it a git submodule named x86 and copy the kaem.x86, after.kaem and x86.answers files from stage0-posix <stikonas>oriansj: and then you are adding x86 part as a submodule t stage0-posix? <oriansj>you both have commit access to the repo to allow any updates you need <stikonas>(just asking to understand whether we are dublicating code) <oriansj>stikonas: yes I am going to replace the x86 folder with a submodule pointing to that repo <oriansj>and I'll be repeating this process for all other architecture as well and granting the most active developers for those architectures commit access to them <stikonas>well, I guess benefits would be only visible once we start reducing rootfs.py into something very minimal <stikonas>but that's coming soon after fossy is done with his current PR <oriansj>and hopefully the lack of submodules and binaries will enable the bits to finally make it onto savannah <stikonas>yaeh, I think that binaries part was a bit of misunderstanding <stikonas>after all our binaries are so minimal that you can inspect them by hand (that takes a bit of effort but is certainly doable) <oriansj>yeah, I am guessing bootstrap-seeds will never make it onto savannah without a few champions