<oriansj>danderson: the distinction between stage0 and stage0-posix is that stage0 is bare metal only and stage0-posix is only depending on a POSIX kernel that supports the following syscalls: exit, execve, fork, waitpid, brk, open, close, read, write, lseek, chmod for up to M2-Planet+mescc-tools (excluding Kaem) but mescc-tools-extra+Kaem needs fchmod, access, chdir, fchdir, mkdir, mknod, getcwd, umask and uname. Mes also needs unlink, ioctl, <oriansj>stat and fsync (assuming I didn't miss anything janneke ) <oriansj>So one should have everything one needs to build a more complete POSIX written in either M2-Planet's C subset or MesCC's C subset <stikonas>tcc probably wouldn't add any new syscalls... <stikonas>so maybe one can just go to tcc instead of mescc <oriansj>And the initial kernel could be written in Assembly or in the C subset that M2-Planet running on bare metal supports <oriansj>stikonas: mes-m2 doesn't use all of the syscalls in meslibc but TCC supposdedly does <stikonas>oh yes, that's most likely true, since mes-m2 can be built with just a few files from lib/*/*.c (as is shown by building it with m2-planet) <danderson>oriansj: thanks for the rundown. That's a fairly wide API surface, but certainly less than a full production kernel. <xentrac>also last time we talked about this I think we established that it doesn't actually have to multitask <xentrac>what does "ioctl" mean here? presumably not the entire ioctl interface <danderson>once you get up to a shell, I'd think it'd be hard to avoid multitasking <danderson>although I suppose a bespoke shell could execute pipelines serially, buffering output between them <stikonas>I don't see ioctl used in mes, it does implement it in libc though <stikonas>danderson: well, bash doesn't do that... <danderson>right, so, could you replace bash with a posix shell that only executes sequentially until you build up to a full-featured kernel? <xentrac>danderson: yeah, MS-DOS executed pipelines that way <danderson>Probably not easily, in the sense that no software assumes such a terrible environment these days <danderson>But basic multitasking isn't *too* hard, if you don't need memory protection or performance or security or... :P <xentrac>you can do multitasking that's robustly usable pretty easily <xentrac>it's just several times slower than more optimized implementations <xentrac>my experience with small machines in the past leads me to believe that memory protection, preemptive multitasking, and being able to kill infinite loops are extremely important for usability <stikonas>one would think that there should be a lot of embedded developers in this project based on environment... <xentrac>also, though, tracing and program state inspection, which are commonly provided by a debugger <oriansj>danderson: well the Kaem shell does only execute serially but it doesn't support pipes (as they aren't needed until after TCC) <oriansj>And multitasking doesn't need to extend beyond process runs until it forks or exits. If forked, just sleep until forked process is done. (as it is just doing waitpid) <oriansj>but yes, such a kernel wouldn't be designed to be usable by humans but rather the bare subset of perfect programs that never have bugs or problems bootstrapping a more advanced kernel. <fossy>pipes are an intentional non feature <fossy>to reduce kernel requirements <oriansj>exec, exit, fork and waitpid are the minimal subset required for having processes spawned from a shell to do work. brk is needed if you want a non-fixed amount of memory. open, close, read, write, lseek are the minimal subset required for working with files. chmod is only needed on filesystems that require the executable bit to be set to execute binaries. chdir and getcwd are needed for the shell to change directories and not have <oriansj>everything be done in absolute addresses. uname is needed to have architecture/OS specific behaviors (get_machine not absolutely required) mkdir needed for mkdir and untar. The remainder could be removed with some effort should it come down to that. <danderson>does stage0-posix require a specific syscall interface? Would this stub kernel have to emulate linux's calling convention? <oriansj>danderson: no. All of the pieces could be ported to CP/M just by changing out the read and write functions to use CP/M conventions. <oriansj>require -> no; currently use -> yes. <oriansj>The later pieces that use M2libc have simple path to supporting alternate calling conventions. <danderson>Got it. And yes, I was asking about what it currently does. It's all software, so nothing's set in stone :) ***terpri is now known as robin
<xentrac>you can do without lseek if you're willing to work with files only sequentially, and without close if you're willing to close all your files by exiting (and don't support I/O redirection) <xentrac>also you could reasonably use the older wait instead of waitpid for processes spawned from a shell <stikonas>well, it's a tradeoff between convenience and fewer syscalls <xentrac>I think PDP-7 UNIX did have chdir() but didn't have pathnames, so you could only open files that were in your current directory <xentrac>which is another sort of axis of minimalism. open() isn't just one thing <xentrac>speaking of which, oriansj, what were you saying about ioctl()? ioctl() is like eight thousand different system calls, like i386-linux socketcall only worse <xentrac>well. "worse" if you're trying to figure out what a minimal kernel needs <stikonas>xentrac: I think it's only used to determine whether mes should start interactive hsell or not <xentrac>oriansj had said "Mes also needs unlink, ioctl, stat and fsync (assuming I didn't miss anything janneke )" <xentrac>oh hey, I hadn't realized that the BASIC terminology of PEEK/POKE was also used in ptrace :) <stikonas>well, unlink is simple, it's just deleting files... <xentrac>glibc isatty uses ioctl(fd, TCGETS, ...), which is actually considerably harder to implement than isatty itself <stikonas>but I mean we don't even have to implement it <stikonas>just stup it out to return false and problem solved <xentrac>close(), lseek(), and umask() are also pretty trivial <xentrac>I think there are things you can do with an interactive mes shell that are interesting from an assurance point of view <xentrac>you know how hardware Bitcoin wallets all have a little screen? <stikonas>EMV card terminals also have little screen, although that one is useless since it's the seller that controls the terminal <xentrac>if your only way to look at the source code and binary seed that your high-assurance bootstrapping kernel is going to compile is a kernel potentially controlled by Mallet, she can show you uncorrupted source code on the screen while leaving corrupted source code on disk for the actual compile <Melg8[m]>oriansj: Will it be useful if i fuzz M2-planet and will report bugs/leaks/crashes? <stikonas>the answer to the question "should I report bugs" is always yes <Melg8[m]>one thing is report bugs - other - actively do something to find them) ***roptat is now known as roptat_
***roptat_ is now known as tyreunom_
***tyreunom_ is now known as tyreunom
***tyreunom is now known as roptat