On Wed, Jul 16, 2003 at 08:42:27AM -0700, Remco Treffkorn wrote: > > So, what happens when you boot? > Something gets loaded into memory and executed. What does this piece do? > Some initialization... and then what? Presenting a prompt and waiting for... > what? i presume you are talking about yaboot itself. yaboot will be executed by OF (the exact details of how this occurs is implementation defined, it will vary on various machines). yaboot will first get the bootpath (fully qualified device specifier used to boot the machine, which may or may not point directly to the yaboot binary), it will also get the boot arguments. the arguments will be parsed (yaboot might support some command line options). yaboot will then attempt to derive the boot device from the bootpath provided by OF (which could well be crap since some OF is broken in that case i suppose we can warn, and try to use the value of boot-device). once the boot device has been established we figure out if its a whole disk or a specific partition, if its the whole disk we need to look at its partition table and determine the partition yaboot came from, if its a partition then that step is already done for us. once we know our bootstrap partition we open() it and read a control block, this control block will contain a couple basic peices of information, such as where the root partition is and what config path should be used. if we are booted from a network then we use the bootp/dhcp vendor tag 150 protocol to get the config. special case like a CDROM needs some other method, CD booting varies so drastically across various machines that its not simple. yaboot will then open() its config file, directly out of the specified root filesystem (usually /etc/yaboot.conf, but this path could be overridden at ybin invokation). the config file is then parsed, using the same code as used by ybin to parse the config (which is not yet written, and will be in NO way derived from the pile of dung thats in yaboot 1.x). there will be a new option in the yaboot 2 config which will specify the UI behavior desired, so far i plan on at least: menu: text based menu of kernel/OS options configured into yaboot.conf. perhaps also a basic menu structure including some simplified commands to make certain changes. lilo: traditional text lilo interface, very much like the existing yaboot 1 UI, except the boot: prompt will ONLY accept valid labels in the config, rather then being overloaded by allowing arbitary filenames, if one needs to boot something other then specified in the config they must exit the lilo UI and enter the shell. (yaboot's current overloaded lilo UI just confuses people, and nobody ever realizes the hidden functionality there anyway, so i may as well just move it out and make this UI code much simpler). macos: no UI at all, turn the screen gray and boot the default image, unless a snag key is detected (say if S is held down boot the default image with a `-b' argument (single luser mode), or similar). if the host OF has a working draw-logo method i would consider drawing a small icon in the center of the screen. despite popular misconception this is and always has been the macos bootloader `UI'. that thing you get when holding down the option key on newwer macs is generated by OF and has nothing whatsoever to do with the OSX or OS9 bootloader. shell: drop into the yaboot shell. if no config file is found the default will be to drop into the yaboot shell immediatly. if a config is found, and its bogus, yaboot will immediatly drop into the shell. if a config is found, and is sane (defines at least one kernel) the default UI will be either lilo, or menu, probably determined by general consensus of the user community. there will NOT be a fully pointy clicky GUI. OF is not made for this, and any attempts to do it would be a giant unstable mess. and attempting to use the undocumented, non-standard extensions in Apple OF would be unportable (apples extensions are rather haphazard and not too stable either). > Does there need to be a shell-like command interpreter? Is the 'boot' command > just one of many? What other commands are there? 'ls'? What about scripting? we will need a basic shell infrastructure, i doubt we can use GNU readline outright, but we may be able to borrow some of its code to do things like completion, and command line editing (which i very much want to be there, shells which lack this cause me to go into loud swearing spells quite rapidly). im not quite sure if i want to go quite as fancy as a unix style shell in regards to stuff like variables and substitutions, thats probably overboard. as for commands i haven't decided on all of them, grub has too many things that i think really dont' belong in bootloaders (like a partitioner). some commands that will be there (some inspired by grub-shell): (note this is not set in stone yet, while some of it will resemble grub, i don't intend to copy grub just because grub does something a certain way, i think grub is goofy in many respects and i won't be copying anything i find goofy). kernel: specify a kernel image to boot, this command may take an argument to specify the kernel type, if it turns out impossible to auto-detect all forms of kernel images (im not yet sure if we will be able to detect a bsd kernel and do the proper bootstrap proceedure or not). grub allows you to specify the kernel arguments after the image name, i think this is reasonable. kernel-args: specify kernel arguments, i think this would replace any args you specified with kernel. my reasoning for this is to avoid forcing you to type a single long command line if you need several kernel args, and a way to change your args without having to retype your kernel image name (which might need to be a fully qualified devspec which can be quite long). initrd: load initial ramdisk for specified kernel type (if kernel type supports initrd). boot: boot either image specified by most recent kernel: command, or if no kernel command has been executed the default image defined in yaboot.conf, if no default image is known this command will print an error. ls: basic unix ls command, probably only the -l option would be supported, maybe one or two others. cat: need i explain? zcat: cat gzipped files, only available if zlib support is enabled. find: basic find command. cd: change current directory within a filesystem. to be discussed, but this should probably also allow a fully qualified device specifier in which case the default device and partition would also be changed. loadcfg: attempt to open() specified file and parse it as a yaboot config, if it parses reset configuration and load the values in this file. the only difference between the config loading done at boot and this command is the UI would not be automatically started, the user would remain in the shell, but all the configuration values would reflect the loaded config. this command is the answer to all the lame excuses for trying to futz with the bootstrap partition from macos, with this command you can load a fixed config from anywhere, any readable partition, tftp, nfs, whatever. (and configs won't live in the bootstrap partition anymore anyway). bootp: configure network via bootp (probably a yaboot provided one, since OF's is often broken). see grub docs on thier version. dhcp: configure network via dhcp (probably yaboot provided one since OF's is often broken, or unavailable). see grub docs on thier version. rarp: (maybe) configure network via rarp. see grub docs on thier version. ifconfig: configure network manually. terminal: switch interface to another tty, from serial to console and such. (this is actually quite easy with OF, and can even be done right on the OF command line). chainloader: chainload another bootloader. this one is a tad bit iffy, but should be generally doable. halt/shutdown: shutdown the computer. reboot: reboot the computer. module: load multiboot module (GNU/Hurd stuff). note the multiboot spec appears to need work for non-x86, eventually we should try to contact the Hurd people working on non-x86 ports for thier input on how this should be handled, presumably by fixing the multiboot spec. module-args: arguments for module. partitions: print partition table of specified device, show size, type, label (if applicable), and detected filesystem type (if any). disks: (maybe) print out available disk devices. i think this is doable by recursing the device-tree and checking device_type. though this implementation is OF specific. set: usage: set CONFIG_VAR VALUE. reset individual configuration variable to specified value. for single keyword options this behaves as boolean, eg set KEYWORD true. i think this would only work for global options, if you want to do a custom kernel load use kernel/kernel-args as per above. interpret: (not sure on the name) hand string to OF interpretor. suspend/^Z: suspend yaboot execution and enter the OF command line. yaboot can be resumed with the OF word `go'. debug: enable certain levels of debugging output (if compiled with this support). exit/^D: exit yaboot shell and return to the configured UI, assuming the shell was entered from a UI, and a ui other then `shell' is currently configured, otherwise print an error, or perhaps ask if the user wishes to exit yaboot entirely. version: (not sure on name) print yaboot version, and prom-libc version, and perhaps compile time configuration. help: online help (if enabled at compile time), print available commands and one line summary of thier usage/function. help CMD would be the same as CMD --help, which would explain the command in more detail. auth: (not sure on name) become privileged. if yaboot security functions are enabled the shell will be quite restricted, entering this command would prompt for the superviser password and if correct enable full privileges. unauth: (not sure on name) drop superviser privileges. date: print date and time, and allow to set date and time in rtc. quit: (not sure on name) exit yaboot entirely and return to OF. there might be more, thats what i have in mind now. > You have been thinking about this for a long time. Share! the general design is layed out above, in more detail once the boot stage is hit yaboot will open() the kernel image and attempt to determine its type (unless told explicity), if its a plain gzipped image it will be ungzipped (if zlib support is enabled), otherwise once identified the appropriate kernel loader will be run, kernel loaders will be architecture and firmware dependent since they will perform low level operations to bootstrap the kernel. the kernel loader functions should be run by a generic execk() style function called from the various UIs. most everything in yaboot should use only generic libc functions, and none of the direct OF calls, except where unavoidable, but such cases should be restricted to kernel loaders, and probably some parts of some shell commands. anything PROM or ARCH dependent will be separated off into a sysdep/ or arch/ style hierarchy in the source tree, this will make it quite obvious where porting efforts need to occur. > My personal goal is to have this finished by next Wednesday :-) um, finsh what exactly? surely not the entire thing. right now we need to finish prom-libc, i don't want to start any yaboot work until we have prom-libc finsihed, and booting a test program. then we can start yaboot. and right now the main missing peice of prom-libc is the filesystem/open()/vfs thing, and then filesystem drivers. > ... With a buglist a mile long! > > What I mean by this is: I would like to understand your vision and have it put > into a frame work that is easy to grasp. This way volunteers like me can > easily see what needs to be done. sounds good. im fairly casual about describing my design ideas, i have no experience writing formal things like white papers or design specs. > I have been thinking about this for a few days now, and am getting some weird > ideas. You might want to set me straight, before I wander too far off your > path ;-) yup. > Oh, and I think there is a general interest in this. Other people might want > to know too. i have posted this to the list, as should be obvious. > If there is information that I have missed, just point me to it. same here, if you have questions about the above, ask. > According to some, fwrite is still an inferior implementation ;-) It has two > 'early returns', and according to gospel, that must be avoided. I just don't > care enough. hmm, what do you mean here? -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp00028.pgp
Description: PGP signature