On Thu, 28 Dec 2000, NetBSD Bob wrote:

> I agree that balancing needs to be done, and maybe it is just the
> 1.4-1.5 jump that has caused me problems.
>
> What is left to port for in the old VAX line?  I was under the
> impression that that hardware was mostly cast in stone.  That is
> a little different than porting things on new hardware architectures.
>
	In terms of additional 'older' machines, we have the 11/730,
	11/725, MicroVAX I, and there is one other I cannot remember
	offhand (MicroVAX II CPU with single level page table, max 4MB).

	We also have X on the Microvax 2000, plus its own unique
	built in MFM controller.

	You could also include full X support for the QDSS and QVSS
	video cards, plus (optionally) virtual consoles. I'm sure NetBSD
	does not yet support all the Q-Bus, MASSBUS, and similar cards
	out there, plus the potential for the 'Q-Bus IDE' card.

	On a more general note, there is also work on a new scsi subsystem
	which should reduce the complexity of individual HBA drivers and
	improve overall performance, plus a unified buffer cache which
	should make much more effective use of memory on systems.

	Not to mention other goodies such as SMP for machines that can
	use it, a reworked LKM mechanism which should enable kernels to be
	much smaller and load less frequently used hardware support on
	demand, smbfs to mount network drives from Windows boxes, the
	ability to filter non IP network traffic, and whatever else is
	under development.

> > 	We need to define why 1.5 is slower.
> >
> > 	So far we have
> > 		- rc.d
> > 		- general code bloat
>
> add in:         - slow tcpip (25% or more slower than 1.4.3)
>                 - no suitable tapebooting system for old machines
>                 - huge kernels (I dunno if that is a function of
>                                 gcc or creeping featuritis or both)
>
	We have been using gcc since the start of NetBSD, so its not
	relevant for comparing 1.5 with other NetBSD versions.
>
> > 	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.
>
> Well, the old VAXes don't have much new hardware to support, so that is
> not much of an issue?  That was one reason for thinking that a stable
> divergent or end-of-the-line system might be appropriate for that class
> hardware, which could be optimally tuned for use only on that class
> hardware.  But, keeping a well-tuned old-machine-runnable single-code-
> line tree is better.

	That is definitely the top goal :)

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