Date: Mon, 26 Mar 2001 20:00:51 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Coleman Kane <cokane@FreeBSD.ORG> Cc: bv@wjv.com, freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <20010326200051.B76693@rohrbach.de> In-Reply-To: <20010326121540.B83061@cokane.yi.org>; from cokane@FreeBSD.ORG on Mon, Mar 26, 2001 at 12:15:40PM -0500 References: <20010226221132.C20550@prism.flugsvamp.com> <200102270620.XAA13824@usr05.primenet.com> <20010227084658.D20550@prism.flugsvamp.com> <20010227101911.A88501@wjv.com> <20010325060752.A28058@rohrbach.de> <20010326121540.B83061@cokane.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Coleman Kane(cokane@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. >=20 > 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) =2E..and you do not have to worry about implemnting filesystem readaccess for every new fstype in /boot/loader. does that make sense? /k >=20 > Karsten W. Rohrbach had the audacity to say: > >=20 > > Bill Vermillion(bill@bilver.wjv.com)@Tue, Feb 27, 2001 at 10:19:11AM -0= 500: > > > 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. =20 > > yeah afaik there is a separate partition/slice/whatsoever that holds the > > boot files. > >=20 > > >=20 > > > 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=20 > > cd /bootstage && find .|cpio -o /dev/bootdevice > > now the loader has to grok cpio or tar format. > > </asbestos suit> > >=20 > > 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. > >=20 > > cheers, > > /k > >=20 > > --=20 > > > LET Jesus be YOUR anchor! When Satan rocks your boat, THROW Jesus ove= rboard! > > KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de > >=20 > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-fs" in the body of the message > >=20 --=20 > Booze is the answer. I don't remember the question. KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6v4PTM0BPTilkv0YRAjkgAJ44dvROca6/F5XJwX2EFMkEInsvXgCgtGpU hy2xHY9q2jEfUcNiWNAD4LU= =vm57 -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010326200051.B76693>