3 ms·

- he's figured out the KVM issues, their lack of support for some mandated hypervisor APIs and other bugs - then found the existing powerpc pmap (physical memo

by bch 12y ago

- he's figured out the KVM issues, their lack of support for some mandated hypervisor APIs and other bugs - then found the existing powerpc pmap (physical memory management) code wasn't very SMP friendly - also found the PS3 hypervisor layer isn't thread-safe These are some of the reasons that I care about NetBSD (which runs on some 56 architectures with its single codebase) so much -- the real-world work supporting real-world architectures can pay off everywhere -- it's not just academic work or nostalgia/eccentricity.

yellowapple 12y ago
Being highly-portable also helps to make sure that your code has a maximum of cleanliness and correctness; this is one of the primary reasons why OpenBSD, for example, emphasizes the importance of being portable to everything from x86 and POWER systems to Zaurus PDAs and VAXen, even though portability isn't an explicit objective of OpenBSD like it is for NetBSD.
- tiffanyh 12y ago
  I love NetBSD, don't get me wrong, but inevitably you will end up with a messing subsystem if managing multiple architectures because you won't be able to avoid situation like this: if (x86) // do ... else (Power) // do ... else (PPC) // do ...
  - bch 12y ago
    From http://www.netbsd.org/about/portability.html http://www.netbsd.org/about/portability.html: > Every effort is made to keep everything cleanly split into 'Machine Dependent' (MD) and 'Machine Independent' (MI) areas. For example, an Ethernet chipset would have a single MI core hardware driver, which would be matched with appropriate MD bus attachment code for a given platform. Not all drivers are as clean as we would like for historical reasons, but any new driver will be, and old drivers are in the process of being converted across. Machine dependent parts are built to a hardware abstraction layer (HAL)[1] interface, so that spec gives a single abstraction that the hardware-dependant code is built against, and can operate w/ the rest of the OS. As I understand it, this is facilitated by the _build system_ (not a mess of if/then in code) like this[2]: .if ${ARCHSUBDIR} == "mips64" ARCHSUBDIR= mips .endif .if ${ARCHSUBDIR} == "powerpc64" ARCHSUBDIR= powerpc .endif These are also the sorts of problems that are addressed by considering "lots and lots" of targets -- it'd be unmaintainable otherwise. [1]: http://en.wikipedia.org/wiki/NetBSD#Portability http://en.wikipedia.org/wiki/NetBSD#Portability [2]: /usr/src/sys/arch/Makefile EDIT: ws s/it's be/it'd be/ s/that spec give/that spec gives/

by bch 12y ago

yellowapple 12y ago

Being highly-portable also helps to make sure that your code has a maximum of cleanliness and correctness; this is one of the primary reasons why OpenBSD, for example, emphasizes the importance of being portable to everything from x86 and POWER systems to Zaurus PDAs and VAXen, even though portability isn't an explicit objective of OpenBSD like it is for NetBSD.

tiffanyh 12y ago
I love NetBSD, don't get me wrong, but inevitably you will end up with a messing subsystem if managing multiple architectures because you won't be able to avoid situation like this: if (x86) // do ... else (Power) // do ... else (PPC) // do ...
- bch 12y ago
  From http://www.netbsd.org/about/portability.html http://www.netbsd.org/about/portability.html: > Every effort is made to keep everything cleanly split into 'Machine Dependent' (MD) and 'Machine Independent' (MI) areas. For example, an Ethernet chipset would have a single MI core hardware driver, which would be matched with appropriate MD bus attachment code for a given platform. Not all drivers are as clean as we would like for historical reasons, but any new driver will be, and old drivers are in the process of being converted across. Machine dependent parts are built to a hardware abstraction layer (HAL)[1] interface, so that spec gives a single abstraction that the hardware-dependant code is built against, and can operate w/ the rest of the OS. As I understand it, this is facilitated by the _build system_ (not a mess of if/then in code) like this[2]: .if ${ARCHSUBDIR} == "mips64" ARCHSUBDIR= mips .endif .if ${ARCHSUBDIR} == "powerpc64" ARCHSUBDIR= powerpc .endif These are also the sorts of problems that are addressed by considering "lots and lots" of targets -- it'd be unmaintainable otherwise. [1]: http://en.wikipedia.org/wiki/NetBSD#Portability http://en.wikipedia.org/wiki/NetBSD#Portability [2]: /usr/src/sys/arch/Makefile EDIT: ws s/it's be/it'd be/ s/that spec give/that spec gives/