Re: UX/RT Architecture (was Re: Compatibility of microkernel systems with legacy OSes)

On Wednesday 29. January 2020 15.32.35 Andrew Warkentin wrote:
> 
> I've never really been a fan of multi-personality systems, and I'd say
> they are less relevant now than ever because of low diversity and
> ubiquitous hardware virtualization. There are only really two
> environments for which compatibility matters in most cases - Linux and
> Windows. Linux compatibility can be implemented in a natively
> Unix-like environment, and so can Windows compatibility (with Wine).
> If you really need to run an entire alternate OS environment it can
> just be virtualized.

Maybe my idea of personalities is somewhat less extensive than yours. For 
example, providing a filesystem with the necessary files in different places, 
with libraries looking for those files in the appropriate places, is to me 
providing a different personality. Consider, for instance, if Solaris had 
provided a BSD personality rather than putting BSD-related files in one set of 
places, SysV-related files in another, and so on.

Such lightweight personalities might not be more sophisticated than something 
supported by chroot or a limited "jail" solution in a traditional Unix-like 
system, although making such things work within those kinds of solutions can 
be easier said than done. Systems like Plan 9 might have an easier time of it, 
though.

> Having things like personality-neutral services just complicates the
> design of the system. It's far easier if you can just write servers to
> the same API as applications (under UX/RT, all servers except for the
> root server will be completely normal processes). Multiple personality
> support would almost certainly make the minimalist file-oriented
> architecture I have planned a lot more difficult to implement.

In an L4Re-based system, servers do use the same API as applications and they 
are just normal processes (but maybe I misunderstand your point). But my 
argument is that personalities would be built on generic services, not that 
anyone needs to specifically engineer services for certain personalities, or 
at least not for all functionality. There may be some special behavioural 
requirements - there was a FreeVMS project that may have had such requirements 
and had struggled to implement them - but there should be a lot of common 
facilities that most personalities share.

I can think of awkward behavioural traits that might interfere with a generic 
services approach. For example, having to support Windows-like file locking 
semantics where an open file can obstruct usage of that file by other 
processes. This would raise questions about how processes expecting Unix-like 
semantics could co-exist with such an arrangement.

As a more mundane example of a personality, consider what L4Re provides 
already: it is an elementary virtual filesystem offering files with a limited 
amount of metadata to each task. That does not preclude the development of a 
Unix personality, nor does it prevent anyone from developing these facilities 
in a way that completely ignores things like processes and users and other 
Unix concepts, offering some kind of single-user personality or environment 
for certain tasks.

So, there could be C library support like that already in L4Re which doesn't 
really support Unix concepts, whereas another C library could contain the 
necessary support for interacting with Unix-enabling infrastructure. Such 
things would presumably be feasible to explore with Linux to an extent, but it 
probably isn't a particularly interesting avenue to pursue.

To go further, I can imagine a system where notions of users and privileges 
emerge purely from the configuration of the system. At the same time, there 
may be notions of users that emerge from filesystem metadata. It is entirely 
plausible that these notions may co-exist or be orthogonal in some way. But 
this is perhaps another topic.

Paul