www.anubis-os.org finally open

[Trev]

Ehm, IIRC AmigaOS uses a Round Robin scheduler (the most basic pre-emptive scheduler), with which scheduling starvation does not exist.

Yes, but when a task's time slice expires, it's Enqueue()'d on the task ready list based on priority. If that task has the highest priority in the list, the scheduler will continue to schedule the task until it switches to a different state.

So, there's no guarantee that every task will make progress regardless of its priority. That's part of the reason why modern schedulers have some form of priority boosting. "Fairness" in a scheduler is really about making sure that all tasks get at least some CPU time. Completely fair schedulers sacrifice some aspects of prioritization to improve the user experience. ("User" doesn't necessarily mean a person. It could be anything that consumes foo produced by a task.) At least, that's my take on it. I'm not a computer scientist.

[Trev]

I didn't read the article until just now. :-) As we all know, Amiga computers have a lot of special purpose harware that does things the CPU just can't do on its own.

Fast forward to present day, and we have special purpose hardware for just about everything but decoding of audio data. Yes, you get DMA to/from the sound card, but the CPU still has to put the data in a format recognized by the hardware. While decoding the data, the CPU also has to do all the other stuff its supposed to do, so you end up starving the audio interface of data, hence the skips.

Sound cards have DSPs, so you'd think it would be possible to write a decoder in the DSP itself and pump the data via DMA. I really don't know enough about audio hardware and various operating systems' audio subsystems to say.

In any case, there are always trade-offs when it comes to task scheduling. In the case of AmigaOS, which is effectively landlocked in single CPU land, the trade-offs are pretty much the same as they were in 1985.

I haven't read the Anubis stuff yet, but if they're planning on effective memory protection and multiple CPU support--one would assume so, using the Linux kernel as a base--it should be pretty cool.

[Trev]

Why label Anubis a Linux distribution? Is Mac OS X a BSD/Mach distribution?

[Trev]

Philosophy and supposition be damned then, I guess. ;-) My point was that Linux is a kernel. All the other bits make up the operating environment. The gestalt of a Linux distribution doesn't encompass every operating environment based on a Linux kernel.

[Trev]

Well, his razor, maybe. :-P Is it Linux? Yes. Will you be able to compile a Gnome-based X application and run it natively on Anubis? Probably not. There's no reason why Anubis can't host an Amiga-like API on X and Linux without providing support for all the libraries and interfaces normally associated with a Linux and X Window System based operating environment.

[Trev]

@persia

If the operating environment doesn't expose any of the interfaces to X or the Linux kernel, how would you even know (without probing) that you're running on Linux? Is Amithlon a Linux distribution? By the "Linux kernel equals Linux distribution" definition it is, but it doesn't behave anything like a Linux distribution in the traditional sense.

I haven't been keeping up with the specifications, so I'm likely biased by my own opinions about how such an Amiga-like system should be designed.

[Trev]

Well, everything does (or should) start with a design. Whether or not it exists isn't really relevant to a discussion of the design (which I should read again). ;-) Some pseudocode:

Code: [Select]

/* static */ int open(const char *path, int oflag, ... )
{
}

BPTR Open(STRPTR name, LONG accessMode)
{
  int fd;

  fd = open(name, ...);
  ...
  return /* BPTR */;
}

If all files are opened via Open(), is it Linux or dos.library?

[Trev]

linux. open() doesn't do amiga like paths, nor does it pop up requesters when needed etc.

Which is why I labeled it pseudocode. An Amiga-like subsystem could do the necessary translation between Amiga paths and Linux paths, or the kernel and underlying file systems could be modified to use them natively. It could be as simple as translating Device: to /device or as complicated as necessary to support all Amiga path and assignment semantics.

Requesters don't belong in the kernel. I should have included more elipsese in my pseudocode. ;-)