Date: Mon, 17 Mar 1997 18:08:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni) Cc: terry@lambert.org, jb@cimlogic.com.au, srn@flibble.psrg.cs.usyd.edu.au, freebsd-platforms@freebsd.org Subject: Re: Some one working on a SPARC version? Message-ID: <199703180108.SAA08717@phaeton.artisoft.com> In-Reply-To: <332DC006.6D3C@fps.biblos.unal.edu.co> from "Pedro Giffuni" at Mar 17, 97 02:04:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The assumption implicit in your statement (and reiterated here) is > > that "there are significant differences between these systems". I > > disagree. The differences are of level of integration, not ones of > > technology incompatability, and therefore they are significant only > > in the political sense. Politics is a bad perspective from which... > > I agree the technological differences are not imposible to overcome, but > if they are not significant why aren't we using their features and > viceversa? We want to become multiplatform so is not a just a political > issue. My opinion is that it is an artifact of: 1) Not Invented Here 2) Not enough duplicate warm bodies to do the work 3) Lack of incentives for new warm bodies relative to similar (eg: Linux) projects 4) Loss of creative/editorial control #2 is a pseudo-argument without merit: it stems from #3, which is a purely organizational issue, not a techinical one. > > > NetBSD doesn't want our ports tree > > > > Unlikely... what benefit could they perceive in this? > > I don't know why, perhaps they like building their things the old way > (that is not too different), anyway if they'd wanted it, they could have > adopted it long ago, like OpenBSD did. Ports tree; not build tree. Arguably, their build tree is superior to FreeBSD's, since it handles multiplatform... they would be insane to take FreeBSD's and lose that. > > > and they probably don't want our VM either. > > I also doubt this is true, but it's an interesting doubt that I wanted > to leave in the air. They haven't adapted our VM because of a technical > issue, but this issue was caused by a philosophical issue: they have > always been multiplatform because it was *their* objective. FreeBSD's > objective was not having a multiplatform OS from the start, but rather > having a sophisticated (386) port. The VM, as John Dyson has pointed out in the past, is not irretrievably architecture specific. I don't believe there is a technical issue at all... I have had FreeBSD's VM code working on Alpha and, more recently, PPC hardware, with only minor changes. > > > evident we are diverging each day. > > > > This is an issue of kingdom building breeding kindom building; I defy > > you to demonstrate the merit of encouraging duplication of effort this > > way. > > I don't understand the (proposed) challenge, maybe I wasn't clear. Every > effort in standarizing our systems will bring nearer the final objective > of having advances benefit both parties. My challenge can be restated as: "provide conclusive technical arguments pro divergence" I maintain that there are no good technical reasons for divergence, only political ones. > You were around somewhere in > the discussion about defining _BSD44_ (or was it _4_4BSD ?): how can we > work together if we don't even agree on what makes us different or what > makes us alike? I wasn't involved in the discussion because I believe the "date method" is sufficient for all but kernel interface dependent code. For that code, I would version based on the kernel interface, not based on a globally effective preprocessor symbol. Either way, there is no need to draw a distinction between the BSD platforms unless you are writing kernel interface dependent code: by definition, a bad practice that should be proscribed for all but debug tools, and many times there as well. The kernel interface dependent code itself is subject to interpretation: I believe the externalization of kernel dependent interfaces is inherently bad. There are two soloutions to this problem: 1) Genercize the interface by moving the dependence into a defined interface distinct from externalization of kernel data structures; in three words: delete libkvm now. OR 2) Genericize the interface by moving the depndence into code which is inherently associated with the active kernel, but which is not *of* the active kernel. The code for a given kernel would be in the given kernel's object file, but not part of the kernel proper. This will ensure dynamic versioning, and unlike the first soloution, not require that ps and friends potentially break when used on system dumps; in three words: ELF segment coloring. Both of these soloutions make the 'ps', 'w', 'netstat', 'ifconfig', 'route', and all other code that depends on externalization of kernel data, and make them independent of the format of that data. In the second case, the kernel debugger could use the same code, as necessary. Either soloution totally invalidates the "_BSD44_/_4_4BSD" arguments. Regards, 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?199703180108.SAA08717>