|Zhiui Zhang||Feb 6, 2001 1:15 pm|
|Sam Leffler||Feb 6, 2001 1:46 pm|
|Alfred Perlstein||Feb 6, 2001 1:52 pm|
|Zhiui Zhang||Feb 6, 2001 6:20 pm|
|Terry Lambert||Feb 7, 2001 1:47 pm|
|Jack Rusher||Feb 7, 2001 1:56 pm|
|Terry Lambert||Feb 7, 2001 2:09 pm|
|Terry Lambert||Feb 7, 2001 3:22 pm|
|Zhiui Zhang||Feb 7, 2001 3:39 pm|
|Russell Cattelan||Feb 8, 2001 11:05 pm|
|Russell Cattelan||Feb 8, 2001 11:12 pm|
|Terry Lambert||Feb 9, 2001 12:56 am|
|Zhiui Zhang||Feb 9, 2001 9:24 am|
|Russell Cattelan||Feb 9, 2001 10:08 am|
|Karsten W. Rohrbach||Feb 9, 2001 11:23 am|
|Russell Cattelan||Feb 9, 2001 11:37 am|
|Julian Elischer||Feb 9, 2001 11:58 am|
|Russell Cattelan||Feb 12, 2001 11:37 am|
|Zhiui Zhang||Feb 12, 2001 12:34 pm|
|Russell Cattelan||Feb 12, 2001 12:50 pm|
|Zhiui Zhang||Feb 12, 2001 1:21 pm|
|Terry Lambert||Feb 12, 2001 3:06 pm|
|Zhiui Zhang||Feb 12, 2001 4:27 pm|
|Russell Cattelan||Feb 12, 2001 4:49 pm|
|Adrian Chadd||Feb 13, 2001 2:07 am|
|Russell Cattelan||Feb 15, 2001 1:50 pm|
|Robert Clark||Feb 20, 2001 7:27 pm|
|Terry Lambert||Feb 20, 2001 8:03 pm|
|Russell Cattelan||Feb 20, 2001 11:23 pm|
|Daniel C. Sobral||Feb 26, 2001 3:51 am|
|Terry Lambert||Feb 26, 2001 5:31 am|
|Terry Lambert||Feb 26, 2001 5:34 am|
|Jamie Bowden||Feb 26, 2001 7:35 am|
|Bill Vermillion||Feb 26, 2001 9:55 am|
|Daniel C. Sobral||Feb 26, 2001 11:17 am|
|Brad Knowles||Feb 26, 2001 11:41 am|
|Terry Lambert||Feb 26, 2001 7:42 pm|
|Terry Lambert||Feb 26, 2001 7:46 pm|
|Daniel O'Connor||Feb 26, 2001 7:51 pm|
|Terry Lambert||Feb 26, 2001 8:06 pm|
|Jonathan Lemon||Feb 26, 2001 8:11 pm|
|Daniel O'Connor||Feb 26, 2001 8:12 pm|
|Brett Glass||Feb 26, 2001 8:16 pm|
|Terry Lambert||Feb 26, 2001 10:20 pm|
|Daniel C. Sobral||Feb 27, 2001 12:29 am|
|Doug Rabson||Feb 27, 2001 1:45 am|
|Doug Rabson||Feb 27, 2001 1:46 am|
|Jonathan Lemon||Feb 27, 2001 6:46 am|
|Bill Vermillion||Feb 27, 2001 7:18 am|
|Brad Knowles||Feb 27, 2001 9:48 am|
|Peter Wemm||Feb 27, 2001 10:43 am|
|Terry Lambert||Feb 27, 2001 11:44 am|
|Terry Lambert||Feb 27, 2001 12:19 pm|
|Rik van Riel||Feb 27, 2001 12:41 pm|
|Terry Lambert||Feb 27, 2001 11:13 pm|
|Russell Cattelan||Feb 28, 2001 3:49 pm|
|Karsten W. Rohrbach||Mar 24, 2001 8:07 pm|
|Coleman Kane||Mar 26, 2001 9:15 am|
|Karsten W. Rohrbach||Mar 26, 2001 10:00 am|
|Subject:||Re: Design a journalled file system|
|From:||Karsten W. Rohrbach (kars...@rohrbach.de)|
|Date:||Mar 26, 2001 10:00:29 am|
Coleman Kane(cok...@FreeBSD.ORG)@Mon, Mar 26, 2001 at 12:15:40PM -0500:
All those things that intel systems are expected to conform to are just BIOS restrictions. The nice thing about IBMs, Suns, and many other non-PC workstations is that they have a nice BIOS system designed to handle such things as the ipldevice, etc. Intel systems, without BIOS, simply just start executing whatever is at 0xffff0 (i think that's it, towards the end of memory anyway), which typically is where the BIOS chip is mapped/wired. If PC BIOSes weren't so brain-dead we could have all sorts of useful features (e.g.: 386 and 486 hardware does have the ability to boot from ATA CD, but the BIOS doesn't know how to find it).
yup, but you can get around those problems like all the bootloaders do. in stage2 where yup replace the rotten biso stuph with code that makes more sense - an that is loaded from disk.
Anyway, many linux-based distro's use a seperate small partition to boot the kernel, typically if the driver for the boot device is not compiled in the kernel. The loading mechanism is pretty different though, and I don't really see the advantage in the BSD's. At least, not until we run into the problem where our loader can't get the kernel off the boot device. That's what all the _ROOT macros in config are for.
linux' way of booting with lilo is a little strange on redhat and other distributions. it is kind-of statically wired, tho, but without the need to recompile the kernel. i do not think that this is the way of bootloader config the bsd community wants.
lilo works as follows: - bios posts and gets the mbr excutable code from the first disk it finds a partition on. - mbr bootcode gets the stage1 loader via directly mapped sectors on the device - stage1 gets stage1.5 (sometimes, i am not really into this anymore since linux kernel 0.99.15) also via sectormapping method - stage2 finally is the linuxloader and when it runs it actually knows the sectormappings of the files it needs - on redhat it loads some gzipped kernel image and a gzipped root fs image in ramdisk format
there are a lot more intelligent approaches to this, like grub or the freebsd loader. the main difference i want to point out with that is, that those loaders actually know about the filesystems they're dealing with. lilo afaik does not do this.
when it comes to something like ipldevice, the approach is a different one. say you got a bios that boots an mbr or active partition bootblock, then you can execute a secondary loader (that on pc finally just fulfills the task of let's say ibm's openboot firmware on rs6k). this loader does not know about an actual filesystem but it knows the partitioning schemata (dos partition tables, bsd disklabels) and this one finds a flagged partition in a bsdlabel that sits on the raw disk or in a dos compliant partition. now theres the interesting point that this loader does not understand any real filesystem but let's say tar format and it expects to find a tar archive sitting at the beginning on this partition the contains a prepared "ready-to-boot" imagefile or more of them, then it just has to display some options to select the right image, load it in ram and bang: there you go. the actual loader process, inserting kld's and the like, is put to the point where init starts before actual rc processing begins. with the right stripped-down kernel that accepts being linked to a minimal set of bio modules to accomplish just this task it is no problem. thats my understanding of what ibm does. - small kernel gets linked against the appropriate modules with mkboot and gets shoved into /dev/ipldevice - after booting the kernel, modules are loaded
interesting scenarios would be possible like - booting with the root fs on vinum - booting with the root fs being something different ;-) - booting without the need for a fully fedged /boot/loader - booting stuff on raid adapters - booting a rootfs that sits in a file on an arbitrary filesystem (if the basic fs support for the kernel is there)
...and you do not have to worry about implemnting filesystem readaccess for every new fstype in /boot/loader.
does that make sense?
Karsten W. Rohrbach had the audacity to say:
Bill Vermillion(bi...@bilver.wjv.com)@Tue, Feb 27, 2001 at 10:19:11AM -0500:
On Tue, Feb 27, 2001 at 08:46:58AM -0600, Jonathan Lemon thus spoke: Is my mind playing tricks on me? I seem to recall that on an SGI there is a separte boot file system then the XFS. It's been a couple of years now - but I convertned several from the 5.x to the 6.x Irix with the new XFS.
yeah afaik there is a separate partition/slice/whatsoever that holds the boot files.
Why does the boot file system have to be the same as a running file-system. I know that in some of the Sys V.x Intel variants, there is a separate booting file system conforming to the old s51 file system because the newer file systems they use wont boot in an iNTEL environment.
i know some people will ignite their flamethrowers now but <asbestos suit> i like the idea behind /dev/ipldevice on ibm aix. its just container for some very simple structure that holds the files needed to boot as far as devices and other drivers are loaded to get into the next stage and kinda kldload(8) the other drivers and stuff before commencing the real rc stuff. this means -- in the simplest implementation -- having a partition, lets say /dev/da0e with approx. 10 mb size and symlinking it to /dev/bootdevice. then some administration model like linux' lilo has to be run where the image of the boot file system gets assembled somehow. dirty hack: having a directory /bootstage where all the files (loader, rcfiles, kernel, modules) are copied in and cd /bootstage && find .|cpio -o /dev/bootdevice now the loader has to grok cpio or tar format. </asbestos suit>
very stable and convenient way. to be suitable for production use there has to be some kind of selection mechanism for the old setup but that's not a big point in discussion i guess.
LET Jesus be YOUR anchor! When Satan rocks your boat, THROW Jesus overboard!
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Booze is the answer. I don't remember the question.