On 3 January 2017 at 16:18, Sean Bruno <sbr...@freebsd.org> wrote: > I'm pondering where to start with getting FreeBSD's bsd-user code into > shape so it could actually be reviewed and accepted now that its sort of > working again (signal handling fixed finally). > > I almost feel like the existing code should be purged, except that it > gives a good history (and this seems lazy to me). > > As a first pass, I guess, I'd like to at least make i386 user run on > x86_64. What would you folks like to see in a first pass?
So, here's my thoughts on this. I think our goals here are * get the out-of-tree code into the tree, over time * help you get to a point where you're maintaining and fixing the FreeBSD code with us upstream, rather than deploying downstream patches and the primary obstacle is this big pile of non-upstreamed code. From my end I don't think it really matters too much what order we try to tackle things in, as long as the chunks that arrive for upstream review are not too large and seem at least vaguely coherent. If i386-on-x86_64 seems like you can extract it sensibly then I think it's as good a place to start as anything else (though of course it's of pretty much zero practical utility :-)). Whether you want to keep the sparc support or delete it is I think up to you as the maintainer -- if it's broken and nobody cares about it I think we can happily delete it. On the other hand if you want to fix it up and keep it around then that's fine too. At some point it would be good to get the BSDs into the set of things we test when merging code, so we don't regress them. That would ideally require hardware we can access though (the only real-hw setup in the gcc compile farm is an ancient NetBSD 5.1 install). I guess instructions-for-BSD-novices on how to setup a VM on a Linux box would do in a pinch. (We should also try to avoid breaking bsd-user on the other BSDs in the course of fixing up FreeBSD -- do you know how many of the other BSD hosts work right now?) thanks -- PMM
