Date: Mon, 8 Jul 1996 16:57:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gpalmer@freebsd.org (Gary Palmer) Cc: terry@lambert.org, wpaul@skynet.ctr.columbia.edu, joerg_wunsch@uriah.heep.sax.de, current@freebsd.org Subject: Re: Which tools can back up inodes with 32bit minor numbers ? Message-ID: <199607082357.QAA23056@phaeton.artisoft.com> In-Reply-To: <26051.836867010@palmer.demon.co.uk> from "Gary Palmer" at Jul 9, 96 00:03:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 2) You are required to have working disk drivers and FS > > mounts working to do a port to a new platform. > > I'm curious about this one. Having worked on a port of FreeBSD to > another platform (which admitedly died, but that was due to lack of > time, not entheusiasm), it seems working filesystems and disk drivers > are a fairly major priority, as once you have reached the end of > init_main(), you NEED to access a filesystem of some sort to load init > and get booting. > > Ok, so I cheated a bit, and compiled in a 1Mb MFS root filesystem just > to get going, but having a root FS in memory does NOT remove the > requirement for having a disk-based filesystem, unless you plan to > have a fairly large (say, enough to hold the bin dist :-) ) root > filesystem in core! And having devfs doesn't really remove the need at > all, as during the inital bootstrap stages when you are still working > on getting the system tied together, you can use whatever major/minor > number pairs you like, and just tweak them to be more sensible > later... > > Ok, so devfs may make it a bit easier (maybe, it's another kernel > interface to learn), but I can't see it as a plus in devfs's favour, > nor particularly cut down on development time. Try doing the port in a cross-environment, where you can't put 32 bit values as an argument for your mknod. 8-). The priorities are, in order: 1) Method of loading code in and jumping to it. This can be as a file in the root of another OS's fs (oh, for instance, AIX on the PPC). Generally bootp. 2) A working console (hello world), generally a polled UART driver. 3) A minimally working kernel... NOT including device drivers for anything but the console -- so devfs and an in-core image for sh to be executed (instead of init). [...] For most systems (non-Intel) that support netboot, you can load in any image via bootp and jump to it. I have to say in general it is easier to make a UART work in polled mode than practically anything else for console input/output. 8-). The devfs gives me the portable pseudo-devices (null, zero, etc.) without need to really support any real devices (besides tty/console). It's quite handy. I'd say the MFS and a real init were about #7 or #8 on the list. The bear is #3, since it includes a stupid VM (we should have a stupid VM in C that ignores most of the hardware to use in bootstrapping, don't you think? -- basically everything in /sys/i386 should have a nice generic C counterpart to aid rewriting. Save the assmebly crap for the no-other-way-to-do-it glue and later in the port as the system rides closer to the hardware where it can). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607082357.QAA23056>