[TUHS] SunOS code?

[Andy Kosela]

On Saturday, September 1, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela <akosela at andykosela.com> wrote:
>
>>
>>
>> On Saturday, September 1, 2018, Steve Mynott <steve.mynott at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
>>>
>>> The BSDs have a less than optimal VM system.  Having SunOS opened up
>>>> would at least let people see what they are missing.  Maybe I have
>>>> rose colored glasses on but it was the only kernel that came into
>>>> focus for me and you could see the architecture from the code.
>>>> Everything else seems like a mess to me.
>>>>
>>>
>>> That may have been true in the late 80s and even early 90s but I'd have
>>> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.
>>>
>>> I've vague recollections that these all originally used the VM from Mach
>>> which did have problems at first.
>>>
>>
> Yes. CSRG used Mach VM because it was available, not because it was
> awesome. The folks at CSRG approached Sun to have them donate their VM to
> BSD, and there were serious talks about doing this until the lawyers got
> involved and explained that would require a serious write down on their
> quarterly report so that nixed the whole thing.
>
>
>> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994
>>> or so.
>>>
>>
> It used to be downright aweful.
>
>
>> I think the latter two use UVM and FreeBSD improved their Mach one (which
>>> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD.
>>>
>>
> OpenBSD and NetBSD both moved to uvm.
>
>
>> Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in
>> the mid-late 90's?  And then further improved by Matthew Dillon.
>>
>> Unfortunately they are not affiliated with the project anymore.  All
>> three had exceptional coding skills.
>>
>
> With the exception of David, it's not unfortunate at all. Although they
> were good for the project's code, they weren't good for the project. They
> didn't work well with others and caused much more grief than the code they
> contributed. There comes a time when there's just too much drama and the
> rest of the code gets much much better when you aren't always fighting
> drama :(. It was a tough decision to make when I was on the core team to
> show Dillon the door. One not made lightly, nor without a lot of effort to
> work through the issues. In the end, though, we had to part ways. Dillon
> has done well with DragonFly, however.
>

Well, there are certainly as many sides to this story as there are people
involved.  Same with NetBSD/OpenBSD split.  Let's leave it as that as I
don't believe we have mentioned people on this list so they can't defend
themselves.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180904/dcff6886/attachment.html>