From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Sun, 25 Mar 2007 11:40:03 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] factotum/802.1x catch 22? In-Reply-To: <5d375e920703250512w3cd9f51ftbf8259302653962a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 30d443dc-ead2-11e9-9d60-3106f5b1d025 the bootstrap process is *supposed* to be rigid. it's only job is to start enough stuff so one can connect to the fileserver. services that can start after one has a filesystem are started by cpurc or termrc. for most machines, this means setting up the network and authentication. if one is running fossil(+venti) locally as a root fs, there is a bit more configuration. one needs to do setup the loopback and interact with sd. perhaps i suffer from myopia, but could you give an example of a situation where a scriptable bootstrap would be helpful? i don't think the suplicant/factotum interaction is one of them. if code needs to be added to the bootstrap process to feed factotum wireless keys and to later point factotum at the secstore server, then that code needs to be added. flexable security code seems oxymoronic to me. in addition, all the files used as part of the bootstrap process need to be built into the kernel. if one wants to use rc, you need to build rc, rcmain and the script into the kernel. if you want to call an executable like grep or test from from a bootstrap script these also need to be built into the kernel. btw, even linux has a static, compiled-in boot process until the root filesystem is mounted. if you use initrd, it is your root filesystem until you pivotroot. regardless, the kernel just mounts the root fs and runs /sbin/init. the linux and plan 9 boot process are very similar until the first user process is started, which shouldn't be suprising. - erik On Sun Mar 25 09:56:01 EDT 2007, uriel99@gmail.com wrote: > Replacing /sys/src/9/boot/boot.c and friends with a set of shell > scripts has been in my TODO for a while now, the current code is too > rigid and inflexible, and expanding it would make it too complex, > replacing it with easily customizable shell scripts would solve many > problems. > > Best wishes > > uriel