doc/data/alpha/current.sgml

89 lines
3.1 KiB
Text

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-07-14 18:54:33 $">
<!ENTITY title "FreeBSD/Alpha current">
<!ENTITY email 'freebsd-alpha'>
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: current.sgml,v 1.1 1998-07-14 18:54:33 wosch Exp $ -->
<html>
&header;
<pre>
From: John Birrell &lt;jb@cimlogic.com.au>
Message-Id: <199803270127.MAA01315@cimlogic.com.au>
Subject: Re: what's a good way to help?
To: nmanisca@vt.edu (nm)
Date: Fri, 27 Mar 1998 12:27:10 +1100 (EST)
Cc: freebsd-alpha@FreeBSD.ORG
nm wrote:
> i have an axppci33 based system here with 64 megs of ram
> and a 2 gig scsi disk...
>
> ill soon be connected to the net via 10baseT (to multiple t3's)
>
> i look forward to seeing freebsd running on alpha and so i am
> asking what is there to be done that can be accomplished with
> a slow machine and not a great deal of intimate knowledge of
> either the alpha architecture or the bsd?
Do you have an Intel machine that you can use to run -current?
This is important because you need to be able to check that anything
you do doesn't affect the mainstream FreeBSD.
[you may already know this stuff, but I'll point it out anyway 8-)]
On the Intel machine, setup cvsup to use release=cvs and src-all.
After the initial cvsup, plan to run daily.
Learn to use cvs on the cvs files that cvsup creates/updates.
Learn to `make world' on the Intel machine.
Install NetBSD 1.3 on the alpha. Configure it to give you telnet/rlogin
access from the Intel machine. Setup both machines as NFS client & server.
NFS mount the checked out source tree (on the Intel machine) as
/usr/src on the alpha. Create a symlink for /usr/src to the _same_ tree
on the Intel. That way you build exactly the same source on both
machines at the same time.
Learn to `make -m /usr/src/share/mk buildworld' on the alpha. Most of
the code is already committed. There are a few files that I can send you
when you let me know you need them. You'll know that when the build
bombs. And you'll need to tell me how it bombs to prove that you have
got that far (and are serious about working on this). 8-)
Try running the programs that get created in /usr/obj/usr/src/tmp/usr.bin
and compare their behaviour to the Intel ones. You'll find lots of things
that don't work "quite right". Finding fixes to any of these would be
a constructive way to help.
--
John Birrell - jb@cimlogic.com.au; jb@freebsd.org
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
Starting with NetBSD 1.3, /etc/group needs the following additional
groups added manually:
man:*:9:
uucp:*:66:
xten:*:67:xten
network:*:69:
The build of libc needs a temporary patch for vfprintf.c that I don't
want to commit. I'm note sure how best to distribute this info.
There is a problem with optimization in gcc/gas so I set CFLAGS in
/etc/make.conf to remove the default -O.
Also, it's worth noting that NetBSD uses /etc/mk.conf whereas
FreeBSD uses /etc/make.conf. The bootstrap builds make very early on
so there is no point adding anything to /etc/mk.conf.
</pre>
&footer;
</body>
</html>