From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <36b3147aaff1d99259cb5992ee2dfc02@posteo.de> References: <46387470657debf96fb9fd2e878c90c0@felloff.net> <36b3147aaff1d99259cb5992ee2dfc02@posteo.de> Date: Thu, 5 Feb 2015 17:34:04 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bf0c39adf76c5050e5ab555 Subject: Re: [9fans] Raspberry Pi 2 Model B Topicbox-Message-UUID: 41ac7236-ead9-11e9-9d60-3106f5b1d025 --047d7bf0c39adf76c5050e5ab555 Content-Type: text/plain; charset=UTF-8 Basically, Plan 9 (kernel and applications) was designed and written for multiprocessors, and the kernel is written with pre-emptive concurrency in mind (rather than, say, retrofitting it all). That extends to the drivers and most platform-specific kernel code (except where someone slipped up, which is rare). Even on things that are currently uniprocessor, the discipline is to write the mutual exclusion code as required. Cache control is less well-developed, since most platforms so far have offered some adequate form of coherency, but explicit cache flushing and invalidation is missing from some x86 drivers, because the architecture did the work, so that DOS would run. In practice, most embedded platforms have had custom SoC devices, or different devices from x86 at any rate, so the cache flushing was included when a new driver was written (once we understood the problem). Unfortunately, it was done using different primitives, or at least primitive names, for different architectures. --047d7bf0c39adf76c5050e5ab555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Basically, Plan 9 (kernel and applications) was designed a= nd written for multiprocessors,
and the kernel is written with pre-empt= ive concurrency in mind (rather than, say, retrofitting
it all). = That extends to the drivers and most platform-specific kernel code (except = where someone slipped up,
which is rare). Even on things that are= currently uniprocessor, the discipline is to write the
mutual ex= clusion code as required. Cache control is less well-developed,
s= ince most platforms so far have offered some adequate form of coherency, bu= t
explicit cache flushing and invalidation is missing from so= me x86 drivers, because
the architecture did the work, so that DO= S would run. In practice, most embedded platforms
have had cu= stom SoC devices, or different devices from x86 at any rate,
so t= he cache flushing was included when a new driver
was written (onc= e we understood the problem). Unfortunately, it was done
using di= fferent primitives, or at least primitive names, for different architecture= s.

--047d7bf0c39adf76c5050e5ab555--