On Sun, Aug 27, 2017 at 04:09:22PM -0400, Adam Jensen wrote: > On Sun, 27 Aug 2017 14:59:43 -0400 > Adam Jensen <[email protected]> wrote: > > > What would be involved in building the most recent OpenAFS release (1.6.21) > > on the latest release of OpenBSD (6.1, x86-64)? The README file suggests > > this platform might have been abandoned long ago. > > > > sysname > > ------- > > i386_obsd31, i386_obsd32, i386_obsd33, i386_obsd34, i386_obsd35, > > i386_obsd36, i386_obsd37, i386_obsd38, i386_obsd39, i386_obsd40, > > i386_obsd41 > > ------- > > I neglected to mention that I am interested in a complete OpenAFS solution on > OpenBSD - client + server + tools. That platform is such a hassle to deal > with, a half-measure probably isn't worth the effort, IMO.
It's worth mentioning, yes. The server is a pretty portable POSIX application and should build without much trouble, but the client (kernel module) is where the difficulty is likely to lie. The last commit in the tree working on OpenBSD client support is e1d0342326d11a14e1fb0075fb62cc6be9389b97, from 2014, which added support for OpenBSD 5.4, which is quite a few releases behind. So, someone would need to look at the VFS- and VM-layer changes in OpenBSD between 5.4 and 6.1, and make the necessary (conditional!) adjustments in the OpenAFS source tree to match up. In FreeBSD, there are usually not too many such changes in a given point release (though major releases can have large changes), and usually the points of breakage become visible at compile time (but not always). There's also enough runtime assertions in debug kernels that finding the other places that need changing is also not too hard. Unfortunately, I don't follow OpenBSD closely enough to know whether the situation is similar there. -Ben _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
