On Thu, 28 Dec 2000, NetBSD Bob wrote:

> IFF, for the sake of discussion, this kind of testing indicated that
> there really was a hurdle/bloat/crawl/whatever in the code, then, as
> Isildur suggested, and apparently some others thought might be of
> merit, perhaps a fork into a cast-in-stone end-of-the-line stable
> final (or whatever) lean/mean/trimmed-to-the-bone OT-NetBSD-VAX
> suite ought to be seriously considered.
>
	I think that would be a pity. NetBSD continues to be ported
	to more machines, including many CPU and memory limited
	systems such as arm26, and keeping the older machines
	running well acts as a balance to the excesses of designing
	for "bigger, better, faster, more" hardware. 1.5 does not
	seem to have the right balance, hopefully we can regain it
	for 1.6

	As another example the disk performance on mac68k has dropped
	considerably between 1.4 and 1.5, but someone has sat down,
	worked out why, and initial signs indicate that the next version
	will be faster than 1.4.

> We know the old machines are not going to get any faster.
>
> We know the code and bloat (for whatever modernization reasons)
> is only going to get greater (and that may not improve efficiency
> any at all, especially on the old machines).
>
	Some things will - such as softdep for filesystems, and UBC
	for more efficient memory usage.

> We know there is a problem, and it really ought to be fixed.
>
> Since the VAXentoyz are such an independent, yet viably historic
> lot of creatures, there may be a good case for going ahead and
> finalizing, or stabilizing, or cannonizing (if one looks at it
> from a ``religious'' point of view), the system, and then, after
> that point, merely keep minor bug fixes and CERT advisory fixes
> and that kind of thing going in the tree of this particular line.
> The SOLE purpose of such a divergent line would be to optimize
> NetBSD on the OldTyme machines such as MVII's and 11/750's, etc.
> Also, one could make the case that a certain set of OldTyme VAX-
> specific ports should be maintained, to flesh out the OldTyme
> systems into something compatible with modern gear.
>
> The dividing line of this seems to be from 2 areas that are not
> exactly the same, but similar in points.
>
> I sense there is a real end of the line in the 1.4.3 vs 1.5
> jump.  Isildur seems to be of the opinion that that line falls
> from 1.4T (which includes some DMA scsi fixes but retains the
> traditional monolithic rc script).  I have no problem accepting
> either as a point of divergence.  I DO have a problem if nothing
> is done to help rectify the situation on the older machines.
> I DON'T know what the solution is or should be, as might concern
> all hands aboard the good ship NetBSD, but, I AM of the opinion
> that some kind of an end-of-the-line stable traditional VAX-specific
> fork needs to be done, specifically tuned for the 1.0VUP and under
> type of machines.  That would include the MVII, the 11/780, 11/750,
> and maybe if a port might someday happen, the 11/725 machines.
>
> Whether at some time, such action should include the early 3100
> line machines, because of their inherent slowness, is an open
> point.  There is pro and con for including them, since there are
> a lot of them about, and we know they are also slow.  In my
> hands, the 3100/M38 and 3100/M76 machines seem to handle 1.5
> just fine, and for those class machines and faster, there really
> is no need for a change at this point.  But, the MVII and down
> machines really do need some help, before we wind up making them
> last-class citizens of NetBSD.
>
> Yeah, I know, get a faster VAX.... (I do have a lead on a big 7000
> box, so maybe that might follow me home, someday).  But, many folks
> don't have a faster VAX, and we need to not make those folks second
> class citizens of NetBSD.  They will jump ship if we do, wringing
> their hands in the air, in despair.
>
> Anyway, those that might have an interest in a traditional VAX specific
> NetBSD port suitable for the OldType VAXentoyz, do holler, and let's
> see if there is enough critical mass to really make something work.
> I know, I am a nobody in the crewe, and swing no weight, but, I do
> raise the issue..... and it needs to be fixed.

	We need to define why 1.5 is slower.

	So far we have
		- rc.d
		- general code bloat

	The first could be handled by having an optional single rc
	script drop in replacement for rc.d. That way people can continue
	to benefit from other NetBSD enhancements, we do not split
	development effort, and people with bigger vaxes, or even
	non vax boxes who 'Just Want The BSD rc' can also use it.

	Of course, it requires people ready to commit to the time and
	effort to maintain such an rc setup, and to track changes made
	to the standard rc.d

	As for code bloat... code bloat is a perennial issue, but again
	it needs is for people to step up to work on it. Since 1.5 we have
	gained the options to not-inline vop calls, and include NFS2
	without NFS3, both saving in space.

	Release engineering is also continuing to process pullup requests
	for NetBSD 1.4 - I don't know if its planned to make any more full
	releases in the 1.4 line, but the release branch is still (for the
	moment) being maintained, so the insfrastructure is in place. Its
	unlikely however to gain any more hardware support.

		David/absolute		-- www.netbsd.org: No hype required --