Date: Thu, 19 Nov 1998 09:33:58 +1100 (EST) From: John Birrell <jb@cimlogic.com.au> To: stefan@csudsu.com (Stefan Molnar) Cc: ch@adimus.de, jbg@masterplan.org, freebsd-sparc@FreeBSD.ORG Subject: Re: Starting point? Message-ID: <199811182233.JAA15319@cimlogic.com.au> In-Reply-To: <Pine.BSF.3.96.981118130309.408p-100000@c35486-a.frmt1.sfba.home.com> from Stefan Molnar at "Nov 18, 98 01:06:06 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Molnar wrote: [..] > > Well, seems that we now have a point to start from. How should we go > > on now ? I think we should divide things up so that we don't have to > > reinvent the wheel every time we write a new piece of code. What about > > a list of necessary tasks and code-chunks (have a look at the > > freebsd-alpha webpages on www.freebsd.org), where everyone can pick a > > task and work on it ? I don't think that "everyone can pick a task and work on it". Until you have enough of the basic infrastructure for the port in place, nobody can test if the bit they're working on actually works. When I started working on the Alpha port, none of the code in the tree was 64-bit clean, so much of the effort went into fixing that. I did this using a NetBSD kernel, building FreeBSD's libc with NetBSD syscalls. This allows most of the programs to work, however the ones that couldn't were those which expected particular in-kernel support for userland tasks. I think it is worth getting cross-build tools working under FreeBSD/i386 for the target architecture that you want to build. Doug used the SimOS simulator to get the FreeBSD/Alpha kernel to work. If you don't have such a simulator for the target processor, you need a development environment where you can boot test kernels simply (you'll be doing that often!). On Alpha, bootp would have been a convenient way. Once you get a minimal kernel up with serial comms, get remote gdb to work. > Well, one thing is to look at the OpenBSD code for the various > devices, like the bw2, cg6, and other cards. No matter what cpu > set, except the UltraAXi and other PCI based systesms, you need > to get the SBus devices. I recomend OpenBSD over NetBSD, mainly > Theo did a large part of the sparc port of NetBSD, so the code in > OpenBSD should be more up to date. A word of warning about adopting code from NetBSD and OpenBSD... take care to respect the copyrights. Even though you do this, you should still expect to receive "unpleasant" email from NetBSD people (and possibly OpenBSD). They will tell you that you are just turning FreeBSD into NetBSD. But since they don't _use_ FreeBSD, they can't appreciate the ways that FreeBSD differs. With FreeBSD/Alpha core was prepared to allow me to make the Alpha changes to the tree on-the-run, provided I didn't break the i386. This prevented the code from decaying in my local tree while the source tree went on it's merry (-current) way. Continually chasing changes in the source tree is a real pain. By committing the code during the porting process, others are kept up-to-date with where you're up to, and it makes sharing code easy. Just my $0.02. I don't have any Sun machines. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811182233.JAA15319>