<stikonas>pder: when rebuilding gawk, you might need my libtool commits too... <stikonas>working on binutils now, and then I think I need to rebuild libtool <fossy>stikonas[m]: pder neat!! we got mentioned! <lle-bout>how is full source bootstrap going on the various archs? <pabs3>fossy: np, I try to mention bootstrappable in every opportunity I can :) <pabs3>a comment from the subthread above leads me to ask what is the oldest x86 CPU hex0 can boot on <lle-bout>OriansJ was making ppc64le things last time, that's why I ask how it is going <gforce_d11977>pabs3: i believe an i386 / 386DX can run the bootstrap, because for now it needs >16megabyte memory, i fact ~1GB mem <fossy>stikonas[m]: shortly, gh access should be back in a sec <fossy>pabs3: i *think* i386 should work; pentium 4 is a defininitive yes <stikonas_>yeah, reusing sed from submodule is a bit unsatisfactory <fossy>yeah, i don't like it very much :/ <fossy>submodules are very temporary <stikonas_>actually, only sed is in submodule after tcc ***stikonas_ is now known as stikonas
<fossy>janneke: hm, can bootar run on mes <fossy>i guess i can try that myself <stikonas>so with sed we can switch to preunpacked tarball too <gforce_d11977>pabs3: at least the bootstrap works with qemu-system-i386, unsure how exact compares this to real hardware <OriansJ>lle-bout: To answer the question of the porting work. PPC64le now generates fully debuggable ELF binaries with hand written M1. Which means it is ready for M2-Planet use (I just need to find some time to start that work) And I've started on the PPC64 (big endian mode) and PPC32 porting efforts for mescc-tools [To determine if they are worth a full port]. <OriansJ>pabs3: to answer the question of the oldest x86 CPU supported, depends heavily on the pieces involved. For example the steps from hex0 to M2-Planet will run the oldest 386 chips. However later stages that use floating point would require a 486 (as some floating point operations were not in 386 floating point coprocesser chips) but things such as modern Linux kernels need a 586-pae or newer CPU. But I feel that is the wrong way to <OriansJ>address the question of secure silicon for bootstrapping. As libresilicon would enable us to create chips we can actually trust. <OriansJ>Buying old chips is simply not a viable long solution to bootstrap trust; The Free Software Movement needs to embrace Free Hardware designs and Processes; ideally those that can be built locally by people that we personally know and trust or in methods that allow easy audit (microscope visable transistors in glass, etc) <Hagfish>is it currently possible to emulate a 586 on a 386 to complete the steps that need modern hardware? <pder>stikonas, fossy: would it be helpful to have a simple untar implementation that can be compiled with M2-Planet? <stikonas>we either have to copy that implementation into bootstrap system, or just pre-unpack tar source... <pder>ok, I was trying to see if we could not include unpacked sed source <pder>what is the reason we patch tar? is it a reproducibility thing? <pder>It seems to compile without removing that line <OriansJ>Hagfish: well turing completeness really helps us here, assuming the system doing the emulation has enough address bits and RAM, it should be able to emulate anything newer or more complicated. <OriansJ>pder: well if one wanted to radically simplify and reduce the steps to bootstrap getting a proper scheme in blynn-compiler's haskell subset would enable the leveraging of the pieces in Guix's current bootstrap path that leverages guile but it would be considerable work. <OriansJ>stikonas: well untar should be simple enough to be a single C source file and thus would be easy to add. <OriansJ>Althought looking at the SHA256SUM tool, we probably could build it with M2-Planet+M2libc with only a handful of tweaks and remove the need for the fletcher16 <stikonas>yeah, those things (sha2 and untar shouldn't be too hard) <OriansJ>fossy: I was thinking of mescc-tools-extra and the need for the utilities for bootstrapping and the tooling required for various pieces. <stikonas>well, basically, after tcc we only need untar... <OriansJ>We could probably leverage kaem+Environmental variables to give it a proper installation path as M2libc supports chdir; which could remove the /after step <stikonas>it's a bit annoying to be in /after folder too <stikonas>need to explicitely specify all installation prefixes <stikonas>but it's just a minor inconvenience, not a bootstrapping problem <OriansJ>stikonas: also by giving mescc-tools-extra a minimal wget, untar and sha256sum, you can skip submodules and just download the tarballs (verify them and then unpack and build) <stikonas>OriansJ: that's assuming that bootstrap kernel has networking <stikonas>not sure if we want to have that assumption <pder>I was looking at possibly eliminating the need for that sed one liner in tar by using the tcc preprocessor <stikonas>pder: speaking of that getdate.y, we should also double check other packages that we are not using it... <stikonas>I just noticed that it is also present in coreutils <stikonas>in coreutils 5.0 main.mk we build lib/getdate.c <stikonas>pder: btw, for tar have you thought about defining MSDOS? <stikonas>as for coreutils, I think it is only used in date (which we don't build) and touch <OriansJ>I have an idea if you are having issues with TCC's preprocessor <stikonas>OriansJ: no, I think pder just wants to use existing defines in tar source to skip unwanted code <stikonas>pder: touch we actually use in bootstrap but only for creating empty files <stikonas>which can be done (and is done earlier in bootstrap) with catm <pder>we have the following two lines in tar.c: <OriansJ>A fully independent C macro expander buildable with M2-Planet <pder> newer_mtime_option = get_date (optarg, (voidstar) 0); <pder>We are using sed to remove the second line. I thought maybe the same could be achieved without sed using tcc preprocessor <stikonas>anyway, sounds like we should fix a few small issues in the near future, before jumping to gcc... <OriansJ>By using M2-Mesoplanet and simply defining MSDOS; those blocks will be entirely stripped and the rest will remain untouched. <pder>Unfortunately -DMSDOS fails to compile since it wants missing headers <pder>The other sed-less approach is just to include a stub for get_date and link it in <OriansJ>like M2-Planet it doesn't care about #includes at all <stikonas>can't we just define -DMSDOS command line flag? <pder>Yeah, I get In file included from src/tar_patched.c:19: <pder>src/system.h:433: error: include file 'io.h' not found <OriansJ>stikonas: also -E with -DMSDOS might produce the desired result <stikonas>pder: then OriansJ idea might work better <stikonas>if M2-Mesoplanet can preprocess just that one file <stikonas>or maybe tcc can preprocess just one file... <stikonas>hmm, no, it wants to include all files during preprocess step <pder>What about writing our own get_date() that just returns a time_t? <stikonas>pder: there is also an option to create dummy op.h and pathmax.h <stikonas>well, we can write our own get_date too... <stikonas>well, in any case I'll build newer sed 4.0.9 when we rebuild it later in the bootstrap <OriansJ>stikonas: M2-Mesoplanet can do any preprocessing behavior you desire and if not, I can change it to suit your mood. <OriansJ>as I was planning on making it a fully stand-alone C preprocessor for the M3 work <OriansJ>with enabling of #include to be entirely optional to enable it to be able to run on bare metal <fossy>I am no fan of pre untaring and pre patching <fossy>I want this to all ideally to be manually typeable into a system <fossy>pder: as such, an untar in m2-planet would be pretty great <fossy>this is why I like submodules tbh, it just means git is distribution only <fossy>we dont need to do any out of system processing <fossy><Hagfish> is it currently possible to emulate a 586 on a 386 to complete the steps that need modern hardware? ***Noisytoot is now known as [[
***[[ is now known as [[Like
***[[Like is now known as [[
***[[ is now known as Noisytoot
<OriansJ>fossy: I was wondering of what you thought of making mescc-tools-extra a full and proper thing? <fossy>OriansJ: how do you mean, whats a "full and proper thing" <OriansJ>fossy: make mescc-tools-extras an independent fork of mescc-tools with full freedomto add anything that might be helpful in system bootstrapping. <fossy>ah, I see - i would not be opposed to that :) <OriansJ>(with get_machine, M1, blod-elf and hex2 removed of course) [But not sure if kaem would betlong with it or with the mescc-tools-extra fork] <fossy>imo kaem should stay in mescc-tools. it's a pretty vital part of the bootstrap process (i.e. you basically can't do any kind of automated bootstrap without it) <OriansJ>fossy: well my question was because mescc-tools as a dependency wouldn't have to depend a kernel but kaem would but does provide that essential root for a kernel bootstrap. <fossy>i'll think about it, your point is very valid <OriansJ>fossy: ultimately it will be your choice as mescc-tools-extra is your baby and it looks like it is going to be quite impressive collection. <stikonas>well, we just need chmod cp, hashing and untaring there? <OriansJ>I'm good with both options as they both have solid reasons behind them and there isn't a clear obvious best solution that I can determine. <OriansJ>stikonas: and anything else people want to to make buildable by M2-Planet <OriansJ>wget, sed, grep, awk, etc depending on what people will think will be fun to create to make future bootstrapping easier. <stikonas>well, even GNU sed and grep are easy to build... <OriansJ>Think novelty first bootstrapping. The way to achieve the goal best isn't to try to reach the goal but rather making all possible future paths forward easier. <OriansJ>with the goal of being fun for the people doing the work. <OriansJ>There is a great talk on Picbreeder and novelty first search but unfortunately I haven't found it yet <OriansJ>ironic that the video for novelty first search might be difficult to find when not doing novelty first search. <Hagfish>but yeah, that sounds like a great philosophy/heuristic <OriansJ>or imagine if someone wrote a perl interpreter in scheme, how many steps in the bootstrap could be stripped out? <stikonas>well, some perl versions, although, not sure how would that work with more complicated perl modules that also have C code... <stikonas>but that might reduce numbre of perl versions from a lot to 1 <OriansJ>or if one thought replacing the build scripts with scheme programs was fun; then all of the autotools pieces and dependency steps could be entirely dropped. <OriansJ>or if someone really wanted a proper scheme and leveraged the Haskell subset we support with blynn-compiler to run the pieces in the guix bootstrap (like bootar, nyacc and gash-utils) and to reduce the efforts required. <OriansJ>but again that would require someone who would find such efforts fun and had the time available. <OriansJ>or perhaps I am missing something entirely obvious (yes I know about psyntax.pp but that is being worked on right now) but can TCC build guile? then we just use that (and switch to using the properly bootstrapped psyntax.pp when it is done) <OriansJ>thus leveraging bootar, nyacc and gash-utils <stikonas>although, I suspect that at least for now it will be problematic with mes libc <stikonas>I would guess that building gcc is of similar complexity <stikonas>although, somebody either has to write new build system or bootstrap autotools for guile <OriansJ>stikonas: guix runs on guile and can be used as a build system. <OriansJ>and we can skip the autotools for guile entirely <OriansJ>autotools can always be skipped with a manually made kaem script or makefile <stikonas>yeah, after all that's what we did for many package <stikonas>well, mostly makefiles, kaem scripts are more tedious <OriansJ>and once guile is built, we can leverage guix, gash, gash-utils, bootar and nyacc <OriansJ>stikonas: true but kaem scripts rarely need to be written more than once. <OriansJ>also step15 is the building of make; so I'd expect everything after that using it rather than kaem.