Contributed by tj on from the vaxinating-the-tree dept.
CVSROOT: /cvs Module name: src Changes by: deraadt@cvs.openbsd.org 2016/03/09 09:28:50 Modified files: . : Makefile.cross sys : Makefile distrib : Makefile distrib/notes : Makefile distrib/sets/lists/comp: mi distrib/sets/lists/man: mi distrib/special/disklabel: Makefile distrib/special/installboot: Makefile etc : Makefile etc/examples : remote etc/mtree : 4.4BSD.dist include : Makefile lib/libc : Makefile.inc lib/libc/gdtoa : ldtoa.c lib/libc/rpc : xdr_float.c lib/libm : Makefile lib/libm/man : Makefile sbin/disklabel : Makefile sbin/newfs : newfs.c sbin/reboot : reboot.8 sbin/wsconsctl : Makefile share/man/man4 : Makefile share/man/man8 : Makefile share/mk : bsd.README bsd.own.mk usr.bin/gprof : gprof.c usr.sbin/installboot: Makefile usr.sbin/wsconscfg: Makefile Removed files: distrib/notes/vax: contents features hardware install prep upgrade whatis xfer distrib/sets/lists/base: md.vax distrib/sets/lists/comp: md.vax distrib/sets/lists/etc: md.vax distrib/sets/lists/game: md.vax distrib/sets/lists/man: md.vax distrib/vax : Makefile Makefile.inc install.md distrib/vax/cdfs: Makefile distrib/vax/common: Makefile.inc list distrib/vax/iso: Makefile distrib/vax/ramdisk: Makefile.inc list.local etc/etc.vax : MAKEDEV MAKEDEV.md Makefile Makefile.inc disktab fbtab login.conf sysctl.conf ttys lib/csu/vax : md_init.h lib/libc/arch/vax: DEFS.h Makefile.inc SYS.h lib/libc/arch/vax/gdtoa: Makefile.inc arith.h gd_qnan.h hdtoa.c strtof.c lib/libc/arch/vax/gen: Makefile.inc _setjmp.S fabs.S fpclassify.c frexp.c infinity.c isfinite.c isinf.c isnan.c isnormal.c ldexp.S modf.S setjmp.S signbit.c sigsetjmp.S udiv.S urem.S lib/libc/arch/vax/net: Makefile.inc htonl.S htons.S ntohl.S ntohs.S lib/libc/arch/vax/string: Makefile.inc bcmp.S bcopy.S bzero.S ffs.S memcmp.S memcpy.S memmove.S memset.S strchr.S lib/libc/arch/vax/sys: Ovfork.S brk.S cerror.S fork.S sbrk.S sigpending.S sigprocmask.S sigreturn.S sigsuspend.S syscall.S tfork_thread.S lib/libkvm : kvm_vax.c share/man/man4/man4.vax: asc.4 autoconf.4 cons.4 de.4 dhu.4 dz.4 fwio.4 gpx.4 ibus.4 intro.4 lcg.4 lcspx.4 le.4 led.4 legss.4 lkkbd.4 lkms.4 mbus.4 mem.4 mscpbus.4 mt.4 mtc.4 ncr.4 qe.4 qsc.4 ra.4 rx.4 sii.4 smg.4 uba.4 uda.4 vsaudio.4 vsbus.4 vxtbus.4 ze.4 share/man/man8/man8.vax: MAKEDEV.8 Makefile boot_vax.8 sys/arch/vax : Makefile sys/arch/vax/compile: .cvsignore sys/arch/vax/conf: GENERIC Makefile.vax RAMDISK files.vax sys/arch/vax/dec: dzcons.c dzinput.c dzkbd.c dzkbdvar.h dzms.c files.dec lk201_ws.c lk201reg.h lk201var.h sii.c siireg.h siivar.h vsms_ws.c vsmsvar.h wskbdmap_lk201.c wskbdmap_lk201.h sys/arch/vax/if: if_de.c if_dereg.h if_le.c if_qe.c if_qereg.h if_uba.h if_ze.c sgec.c sgecreg.h sgecvar.h sys/arch/vax/include: _float.h _types.h asm.h atomic.h bus.h cca.h cdefs.h clock.h cpu.h cvax.h db_machdep.h disklabel.h endian.h exec.h frame.h intr.h ka410.h ka420.h ka43.h ka46.h ka48.h ka630.h ka650.h ka670.h ka680.h kcore.h limits.h loadfile_machdep.h lock.h macros.h mtpr.h mutex.h nexus.h param.h pcb.h pmap.h proc.h profile.h psl.h pte.h ptrace.h reg.h reloc.h rpb.h scb.h setjmp.h sgmap.h sid.h signal.h spinlock.h stdarg.h tcb.h trap.h uvax.h varargs.h vaxfp.h vmparam.h vsbus.h sys/arch/vax/mbus: dz_fwio.c files.mbus fwio.c fwioreg.h fwiovar.h if_le_fwio.c legss.c mbus.c mbusreg.h mbusvar.h sii_fwio.c uba_mbus.c sys/arch/vax/mscp: files.mscp mscp.c mscp.h mscp_disk.c mscp_subr.c mscp_tape.c mscpreg.h mscpvar.h sys/arch/vax/qbus: dhu.c dhureg.h dl.c dlreg.h dz.c dz_uba.c dzreg.h dzvar.h files.uba qdreg.h qevent.h uba.c ubavar.h uda.c sys/arch/vax/stand: Makefile Makefile.inc sys/arch/vax/stand/boot: Makefile autoconf.c boot.c conf.c consio.c consio2.S data.h devopen.c if_de.c if_le.c if_qe.c if_ze.c mfm.c netio.c ra.c rom.c vaxstand.h version sys/arch/vax/stand/common: romread.S srt0.S str.S vaxstand.h sys/arch/vax/stand/xxboot: Makefile bootxx.c genassym.cf start.S sys/arch/vax/uba: uba_common.h uba_dma.c uba_ibus.c ubareg.h sys/arch/vax/vax: autoconf.c bus_dma.c bus_mem.c clock.c conf.c cvax.c db_disasm.c db_disasm.h db_machdep.c disksubr.c emulate.s findcpu.c genassym.cf gencons.c gencons.h ibus.c in4_cksum.c in_cksum.c ka410.c ka43.c ka46.c ka48.c ka49.c ka53.c ka60.c ka630.c ka650.c ka660.c ka670.c ka680.c led.c locore.S machdep.c mem.c mutex.c opcodes.c pmap.c scb.c sgmap.c softintr.c trap.c udiv.s unimpl_emul.s urem.s vm_machdep.c vxt.c wscons_machdep.c sys/arch/vax/vsa: asc_vsbus.c dz_ibus.c gpx.c hdc9224.c hdc9224.h if_le_vsbus.c if_ze_vsbus.c lcg.c lcgreg.h lcspx.c maskbits.h ncr.c smg.c vsaudio.c vsbus.c vsbus_dma.c sys/arch/vax/vxt: if_ze_vxtbus.c qsc.c qsckbd.c qscms.c qscreg.h qscvar.h vxtbus.c vxtbusvar.h usr.bin/gprof : vax.c vax.h usr.sbin/installboot: vax_installboot.c Log message: We are done providing support for the vax. lots of agreement.
Rest in peace (or pieces, more likely) old Vaxen. It appears 5.9 will be the last release to support these machines from the past.
And rumor has it that another platform may not be far off from discontinuation...
(Comments are closed)
By Just Another OpenBSD User (77.85.135.0) on
By Anonymous Coward (65.102.144.2) on
Comments
By billy larlad (63.140.110.241) on
If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
Comments
By Anonymous Coward (160.83.30.197) on
>
> If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
it is a pity. that f... up endianess was a good way to find potholes.
@sparc: still running the openbsd on 21 of them, from 25mhz to 175mhz. anyone else ?
Comments
By Anonymous Coward (173.203.4.162) on
> >
> > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
>
> it is a pity. that f... up endianess was a good way to find potholes.
>
> @sparc: still running the openbsd on 21 of them, from 25mhz to 175mhz. anyone else ?
I have a handful of SPARC machines (sun4c/sun4m/sun4u) that I mess with from time to time, and have run OpenBSD on them in the past.
I should fire these up.
Comments
By Anonymous Coward (188.175.124.185) on
sun4u is SPARC64, not SPARC.
By Chas (147.154.235.102) on
Which ARM platforms are in danger?
Comments
By Billy Larlad (24.237.158.5) on
>
> Which ARM platforms are in danger?
>
"OpenBSD/armish is the 3rd OpenBSD port to ARM based machines, after cats and zaurus. It is intended to support a variety of rather similar ARM-based machines:
* Certance CP3100
* Thecus N2100 (plus rebadged versions: Allnet ALL6500, Evesham SilverSTOR M-Box)
* Thecus N4100 (plus rebadged versions: Allnet ALL6400, Evesham SilverSTOR XS)
* IO-DATA HDL-Gxxx, HDL-GWxxx, and HDL-GZxxx series"
Comments
By Chas (147.154.235.102) on
By Anonymous Coward (71.80.236.218) on
>
> Which ARM platforms are in danger?
>
ARM is a relatively recent architecture, and extremely popular in the mobile and embedded space due to its power per clockcycle efficiency. The port of ARM is also considerably newer, I would not consider it at risk.
Sparcs, 68000s, DEC chips and such have not been kept current even in the hardware space in quite a long time.
Moreover, there are still new CPU architectures being developed: Power8 and RISC-V both come to mind, so there will be other viable future architectures to port to for the future (FreeBSD is actively porting to both of these platforms, even though RISC-V has not even finished tape out yet and is primarily being done in Qemu for the time being).
If you are a vintage hardware enthusiast, it also becomes obvious that the capacitors on equipment 20 years or older are starting to fail, and while there are a handful of individual globally who will replace the capacitors on such systems, the level of soldering work is painstaking and a really touchy skill set to maintain.
Moreover, if you have seen recent hardware design in mobile devices, small SoC systems and such, the capacitors have primarily moved to ceramic, which while more resilient, are also much smaller SMT parts (rather than the previous SMD iterations) so doing aftermarket soldering work on such systems is extremely challenging without specialized costly soldering robot workstations.
The hardware industry is, to some degree, designed to make itself obsolete. Languishing too far in the past is not necessarily deeply meaningful or useful, when there are still a variety of currently produced chips from a variety of vendors, which can still serve as useful cross-platform platforms for testing and finding the sorts of bugs which may not be easily exposed by merely cross compiling for other architectures without testing them (as NetBSD does for the most part; indeed, just earlier this week, I helped someone on an Amiga forum, troubleshoot a NetBSD install where the video signal was not being synced properly [turns out, his LCD could not handle the RGBHV output NetBSD was outputting after the bootloader stage properly, while resorting to an older CRT served as a workaround. That sort of glitch probably would have been caught by OpenBSD back when they still supported the Amiga platform, as they did testing on hardware; but they deprecated that hardware architecture long ago, even though it is more recent than the Vax, it was less impactful in the Unix world 「despite also running a variant of unix, and Vax systems being used in their design, it was decidedly a more consumer focused system and had a much more lightweight OS than anything that exists today」]).
Comments
By Anonymous Coward (77.6.120.231) on
In fact Qemu is a rather new (re)addition to the tools being used with RISC-V. After the new specs came out about a year ago, the modified Qemu could no longer be used and it took until February or so until somebody jumped at it and made it work again. So far primarily the "SPIKE ISA simulator" was used for development.
For those who haven't heard about RISC-V: It's basically a new ISA originally developed for research and teaching over at UC Berkeley. It was open-sourced under a license well known to each of us and will allow for fully BSD-licensed processors in the future. And no, it's unlikely that it will share the fate of the GPL'ed OpenRISC. There are already organisations adopting it which will build RISC-V chips. One of them is lowRISC founded by people who made the Raspberry Pi a global success.
The platform has the potential to become "the better ARM" some time in the future. Hopefully it'll run OpenBSD, too, one day.
Comments
By Anonymous Coward (72.95.153.12) on
What was the fate of OpenRISC? According to Wikipedia
OpenRISC has multiple hardware implementations for several different commercial applications. Are you only complaining about the (lesser) GPL that OpenRISC is licensed under?
Comments
By Anonymous Coward (95.118.139.133) on
There are commercial implementations of OpenRISC, yes. However it never gained much traction and it has basically remained a Linux-only platform, not even NetBSD supports it, as far as I know. It may work well for what it is but it is very likely to remain in a narrow niche.
Comments
By Anonymous Coward (72.95.153.12) on
I'm skeptical of these sorts of predictions. I don't see any evidence that explains why OpenRISC should "remain in a narrow niche". But I don't see any evidence why RISC-V should be a resounding success, either. There are all sorts of attempts to create open source hardware architectures nowadays, including OpenSPARC, OpenPOWER, Loongson, and SuperH. But it's very unclear whether any of these attempts will be long-lived.
Comments
By Anonymous Coward (72.95.153.12) on
Looking around, I discovered one reason why RISC-V may succeed:
A lot of industry leaders, such as Google, HP, and Oracle, are contributing to RISC-V. Nevertheless, it remains to be seen whether their "zero-royalty RAND license" will truly be "open".
By Anonymous Coward (82.68.199.130) on
There might be some interesting stuff happening with POWER hardware. Raptor Engineering are supposedly working on ATX form-factor POWER8/9 boards with fully open firmware.
By Just Another OpenBSD User (77.85.143.57) on
All of them (ARM). Start with the licensing:
https://en.wikipedia.org/wiki/ARM_architecture#Licensing
and continue with makers of chips and their policy for hardware docs release to developers, and then move on to compiler tools. Then check platform lifetimes and general chip availability time frames if you even have a chance to get this info in the open.
> ARM is a relatively recent architecture, and extremely popular in the mobile and embedded space due to its power per clockcycle efficiency. The port of ARM is also considerably newer, I would not consider it at risk.
Consider it at risk of getting any chance of completion before being thrown out by manufacturers due to obsolescence by newer fast iterating generations waiting on the production cycle. A considerable waste of scarce developer effort gone to garbage. Better used on lively platforms that don't suffer the phoenix self-incineration syndrome designed to keep small developers off the platform into the apps market.
> If you are a vintage hardware enthusiast, it also becomes obvious that the capacitors on equipment 20 years or older are starting to fail, and while there are a handful of individual globally who will replace the capacitors on such systems, the level of soldering work is painstaking and a really touchy skill set to maintain.
The electrolyte caps fail much much faster ~3-5 years, especially if running hotter than by design, even within capacitor ratings. Search online for the capacitor plague for a major fuck up industry wide (affects bulky electrolyte caps found in SSDs too):
https://en.wikipedia.org/wiki/Capacitor_plague
Degradation in quality everywhere, from universities to electronic components. Run for the cheapest, it's obsoleted by the manufacturer with software support withdrawal before the hardware fails ~1-3 years. Hooray for expensive to the consumer cheap to the producer electronic junk impossible to program and maintain at OS level for teams outside non disclosure agreements.
> Moreover, if you have seen recent hardware design in mobile devices, small SoC systems and such, the capacitors have primarily moved to ceramic, which while more resilient, are also much smaller SMT parts (rather than the previous SMD iterations) so doing aftermarket soldering work on such systems is extremely challenging without specialized costly soldering robot workstations.
Ceramics generally don't fail, if they have gone bad the board is usually toast elsewhere. This simply does not hold true, SMT re-soldering is trivial for plain discrete components. It's their value before failure that's harder to guess, especially without service and/or engineering docs. And when you have to replace chips, you better abandon the task at a small lab as you can't program them or will run into other complex problems.
> The hardware industry is, to some degree, designed to make itself obsolete.
No, not true. This statement only applies to fake consumer devices. Measuring equipment runs ~10-30 years almost maintenance free. This applies however to ARM even on chips licensing, so consider ARM in danger of adoption for real OS outside embedded / mobile hand-held devices or special use in controller boards.
https://en.wikipedia.org/wiki/Planned_obsolescence
Unless you have too many developers to throw at the miniature about to be obsoleted device, am looking at you lifeless ARM platform.
By Anonymous Coward (2620:115:15:2130:7a45:c4ff:fe3d:4ad1) on
>
> If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
>
>
Oh crap, not SGI or SPARC PLEASE!
By Anonymous Coward (77.6.110.14) on
And more platforms are about to join the discontinued ports? That's interesting news! I guess that while this might affect just a few users directly, it could have indirectly effect on all of us. With each elderly/obscure piece of hardware retired, chances increase to have things like a C11 compiler in base, finally replacing the ancient and GPL'ed GCC. (LLVM is missing support for platforms like hppa and sgi among others, I think)
Yes, I know, hoping for this to happen is probably a bit optimistic. But ever since the native hypervisor for OpenBSD was announced, almost nothing seems to be impossible anymore! So one might actually dare to dream a bit.
By Chas (147.154.235.102) on
The SRI Charon emulator for the VAX is quite expensive (>$100k) and I've seen several deployments. With all the cash that changes hands, it's a shame that OpenBSD could not find a productive niche in that ecosystem.
The "baremetal VAX" commercial product quietly runs on Linux, likely due to both familiarity and drivers.
Comments
By Ralph Siegler (63.156.247.194) on
>
> The "baremetal VAX" commercial product quietly runs on Linux, likely due to both familiarity and drivers.
running on an emulator is easier compared to the issues on real hardware with timing and other quirks of real world devices. Reading what Theo and others OpenBSD devs have written the OpenBSD project has zero interest in running on emulators, only building, testing and running on real hardware. So the claimed support for various models of each hardware is legitimate and not a wishful hope. That is wise choice.
Comments
By Anonymous Coward (147.154.235.102) on
running on an emulator is easier compared to the issues on real hardware with timing and other quirks of real world devices. Reading what Theo and others OpenBSD devs have written the OpenBSD project has zero interest in running on emulators, only building, testing and running on real hardware. So the claimed support for various models of each hardware is legitimate and not a wishful hope. That is wise choice.
I'd actually see a better fit with OpenBSD/AMD64 as the emulator host. Running Charon on Windows (the normal configuration) exposes you to demands for the quarterly patch/reboot pressures, misguided as they might be when running VMS as a client.
A great benefit to "baremetal VAX" is the removal of said pressure, but the host OS is quietly Linux, which has had some showstopper bugs (i.e. your offshore operations staff runs towelroot). OpenBSD is a much safer host, but SMP performance would likely suffer somewhat.
By phessler (phessler) on http://www.openbsdfoundation.org/donations.html
OpenBSD will never trust system builds nor package builds to an emulator. There is no interest nor trust in such a system.
By Just Another OpenBSD User (77.85.135.0) on
By deus VAX machina (24.86.249.76) on
HP, who bought Compaq, who bought Digital, could no longer find power supplies for the little gem. They searched worldwide. So much for annual support fees.
The benefits to OpenBSD were of course all the upside of little-endian machines with a beautiful but slow ISA. The downsides are basically that they've been out of production for decades.
SPARC killed VAX. Alpha was a poor ghost, unevenly supported with some killer glitches in implementation. HP finally delivered, then killed, a scalable SMP Alpha about 10 years after SGI did MIPS.
You know what still worked in VAX? The interfaces: AC power (a hundred years old); serial ports (decades upon decades); Ethernet (decades!); VGA of a sort; even SCSI in some models.
Some lessons are never learned: Digital tried proprietary BI bus and failed. HP tried proprietary 100 megabit Ethernet and failed. Hello, Docker.
Comments
By Just Another OpenBSD User (77.85.135.0) on
implausible: check your facts again