Date: Sat, 14 Apr 2001 12:19:42 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Robert Drehmel <robert@gizmo.quizbot.org> Cc: freebsd-sparc@FreeBSD.org Subject: Re: just some questions on the port status Message-ID: <XFMail.010414121942.jhb@FreeBSD.org> In-Reply-To: <3AD89D01.E1313429@gizmo.quizbot.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-Apr-01 Robert Drehmel wrote: >> > 4) The port will be split up into sparc[v8] and sparc[v9|64], right? >> >> *shrug* Depends on what code we get. Some people would prefer that we just >> do >> sparc64 and not even bother with sparc 8. If you want to work on the port, >> go >> for it. :) It simply needs people to work on it. > > There *really* should be two ports. In the archives I read > that the FreeBSD project isn't interested in `hobby-ports'. > I agree with this, but it doesn't hurt to let people provide > their `hobby-ports' as long as the rest of the kernel is > designed without respect for older hardware. > > I'd port for/to V9, but I don't have a UltraSparc to develop > on right now. > ( I'm trying to get one, but they aren't cheap here in Germany. ) > > Another point is code sharing and storage. Few to none people > actually write code at the moment, so the port gets rather > puzzled together. A (separate) CVS repository would be great, > (we use one for documentation translation in the FreeBSD German > Documentation Project) as this offers several advantages: > > 1) One could commit code that is far from being usable and > someone else completes this work then. > 2) Nobody screams when the changes are backed out many times > or the repository is bloated in other ways. Actually, you could do this in the main tree once you have more than a small change. In the early work of SMPng we had to keep up with patches between all of us and sync htem up with -current every couple of days. This made things much more painful than they needed to be. Since you would mostly be in sys/sparc64 or (sys/sparc32 or whatever) it wouldn't be quite as bad, but it would be painful even if you use CVS for your local patches to try and keep things in sync. Note that the ia64 port doesn't even boot right now (it panics in the pmap code early on around SI_SUB_KMEM or thereabouts) but it's in the tree. :) Having this stuff in the main tree can actually serve as a good reference for people doing other ports in the future as well. > 3) People that aren't commiters on freefall can commit stuff > that is collected by a commiter and checked into the > FreeBSD repository regularly. I'm sure if someone starts churning out sparc code that a commit bit can be granted without any difficulties. :) > 4) There would be a code base on which people could work and > submit code to. You don't have to guess where the > current code can be found. If it's in the main tree it's even easier, you just cvsup -current, you don't have to go cvsup -current and then try to mix and match some other repo with it. I think with smpng I ended up with 6 or 8 trees checked out to deal with the headache of merging in essentially 2 lines of development. > Assuming nobody started with that, I'll play around with the > pmap module (pmap.c). Go for it. > ciao, > -robert > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-sparc" in the body of the message -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010414121942.jhb>