Portability

[mmondor%pulsar-zone.net@localhost]

- "Of all the architectures NetBSD supports, it works on maybe 5
   of them"

Knowing a bit the author of the statement from previous IRC
encounters, I however know that this was a metaphorical statement,
not an attack.  It however also appeared to me like a "NetBSD is
dead" kind of statement, and it started to be vehiculated on IRC
in the quit message of someone else who barely knows NetBSD, so I
thought I would reply (and I'll send the link to this message to
both).  Since this is the advocacy list, and that I had some time
to write a message this morning, I thought it would be the proper
place to preach a bit :)

I hope that the following can highlight the merits of having a number
of supported ports.


The main reasons why NetBSD is considered portable:

- Effort required to create a new port is lower than with most
  other full-featured multi-purpose OSs (this is what portability
  really is about).
- Even if some ports could be enhanced, all supported ones are
  maintained in the main repository.  I.e. they are not forks, nor
  bunches of third party patches.
- When a port boots, most features you would expect out of the OS
  are still working.  This is because of the fact that the
  architecture-dependent software is minimized, only found in
  parts of the kernel, boot loader and libc (a minimal part of
  libc), and that we're dealing with an integrated OS, not
  sections maintained by third parties.

Moreover, many of the ports which are not popular on mainstream
desktop or servers can happen to be precious for particular systems
such as embedded applications.  Even if in some perception they
aren't "working" ports, a minimal amount of effort is required by
someone with a clue to make it do exactly what is required for the
intended application.  The fact that most embedded-type ports can
be cross-compiled easily on a fast development box is also of value,
and the software license is ideal to allow working with NetBSD.

Having and maintaing many ports in the main respository becomes a
proof of this portability, and forces the developers to keep the
code portable.  Most of the ports are bulk cross-built regularily,
although it admitedly would be even better if unit testing could
also be automated for each cross-built port (this is another complex
matter, however, and part of this might actually require full
fledged emulators).  Some ports which are still in use (i.e. arm,
mips or m68k based) can also surprisingly run at decent speed today,
so bloat also had to often be considered to remain this portable
(and I mean the OS, not only the kernel).

Considering what NetBSD achieves despite the low resources it has,
while lately working on optimizations for the most mainstream
architectures, this is impressive in my opinion.  Nearing the
scalability of very corporate-supported OSs such as Linux and
FreeBSD even appears like a great luxury to have.  Likewise for
the ongoing work on power management features.  More great luxury
is our packaging system which even affords to care about other OSs,
and that binary compatibility exists with other operating systems.
Also great is the late work done on security affecting all ports
(other than the arch-specific work which was also important to
support non-executable stack and heap where hardware permits).
Thanks to the people who are working hard on NetBSD (and BSD).
It also helps greatly to have a compiler which supports a number
of architectures (GNU CC/GCC).

To the author of the quote:
If you lately had the opportunity to try NetBSD on less mainstream
hardware which is listed in the supported list, and it did not
work, you are welcome to send patches (or at least fill a PR) so
that the quality of the port could be maintained and/or enhanced,
and to use the mailing list of that port to contact the port
maintainer and other users of that port.
Unfortunately, there are a number of platforms for which bootstrapping
is non-trivial, and this of course does not mean that the port is
nonfunctional or worthless.

Finally, some interesting technical links related to portability:

bus_space(9)
bus_dma(9)
uvm(9)
dmover(9)
disk(9)
firmload(9)
ioctl(9)
linedisc(9)
evcnt(9)
intro(9)

Machine dependent:
/usr/src/sys/arch/
/usr/src/lib/libc/arch/

Contrasted with machine independent:
/usr/src/sys/dev/

http://ezine.daemonnews.org/200008/portability.html
http://netbsd.org/ports/#ports-by-cpu


End Of Advocacy preaching on my part for now :)

-- 
Matt