Quote:

Tomas wrote: @cdimauro Quote: There's no difference, in fact. A Linux distro is an o.s. which uses Linux as the kernel. The userland and/or the window manager has no relevance in this. With that logic Mac OSX is nothing but a BSD distro

As I said before, the Linux distro definition was born with and applied to the Linux kernel set as the basis.

There was not and there's no MacOS X distribution. Anyway, OS X is not based on BSD, but on Mach, which is its micro-kernel.

Quote:

and android on our smart phones is just another linux distro as well.

Exactly, definition at the hand. Android started as a Linux (kernel) fork and developed independently, but some time ago it re-joined again the mainstream code.

Quote:

The kernel has very little to say about how the user experience is. I would have agreed if it was a linux distro just with a different window manager/theme slapped ontop.

I don't care about the user experience.

When I started using Linux at the university (the Slackware distro, if I remember correctly), about 20 years ago, there was no windows manager neither a theme: it was all just a command line o.s.. Only after some time the PCs were upgraded, and typing the new startx command from the bash the X-Server started with his Desktop Environment...

Quote:

I am still worried though since linux does not have a microkernel which i fear might affect things like how responsive the the system is.

It will, of course, since there's another kernel to which send the requests for some services. How it will affect the overall performance is difficult to be defined.

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @Tomas Quote: I am still worried though since linux does not have a microkernel which i fear might affect things like how responsive the the system is. In theory, monolithic kernels should offer slightly better performance - all other things being the same.

The Amiga o.s. has showed the contrary: a microkernel with excellent performance, better than monolithic kernels.

Quote:

Microkernels are more secure(most mission-crtitical (RT)OSes are mikrokernel).

Unfortunately here the Amiga o.s. has showed the contrary too...

@cdimauro

Quote:

The Amiga o.s. has showed the contrary: a microkernel with excellent performance, better than monolithic kernels

When AmigaOS gets the overhead of resource tracking, memory protection, SMP and such... then we'll talk about comparing it to Linux.

_________________

Quote:

Arko wrote: AmigaOS Some people here might respond by a sentence starting with "But the Amigas ...." The AmigaOS is irrelevant when it comes to micro- vs. macro-kernels, because it uses a shared address space.

It's relevant, because the Amiga o.s. IS a micro-kernel. The fact that it uses a shared address space doesn't change its nature.

Quote:

Passing pointers between the kernel and the drivers is impossible in micro kernel systems, data has to be copied, this will results in lower performance.

Where is stated that a micro-kernel should copy the messages? Modern micro-kernels avoid as much as possible the message copy.

Anyway, you can even pass data by reference, like Amiga o.s. does.

In the famous controversy between Torvalds and Tanenbaum regarding the performance of monolithic and micro kernels, the Amiga o.s. was explicitly mentioned by the micro-kernels defenders as an example of high performance micro-kernel, in spite of the offending statements of Linus against them...

Quote:

So it has the advantages of a micro and a makro kernel because it does not know the difference between user and kernel kernel code.

It doesn't make sense. Both micro and monolithic kernels can have kernel and user code.

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @cdimauro Quote: The Amiga o.s. has showed the contrary: a microkernel with excellent performance, better than monolithic kernels When AmigaOS gets the overhead of resource tracking, memory protection, SMP and such... then we'll talk about comparing it to Linux.

Except for the SMP which CAN improve the performance, the other things SLOWS the execution...

@cdimauro

I agree, but for me the overheard of MP is worth it.

_________________

Quote:

michalsc wrote: Pretty correct. This gives us universal IO layer - some of you who tried native AROS surely noticed how vendor-fragile the IDE/SATA drivers are. This is due to all the vendor-specific (and sometimes product specific) "quirks" in the driver code which linux kernel implements already and native AROS doesn't. Plus, we can use the caching mechanism of linux's IO layer. But don't worry, the caches are flushed automatically after certain period of IO inactivity.

Hum. That's a pretty bad thing, since it can give data loss, especially without a journaled filesystem.

Is there any chance to enable the forced writes?

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @cdimauro I agree, but for me the overheard of MP is worth it.

For me too, and I also like resource tracking.

Nowadays there's enough computing power that we drop some of it for the sake of a more solid platform.

@cdimauro

Quote:

Hum. That's a pretty bad thing, since it can give data loss, especially without a journaled filesystem.

The flush (CMD_FLUSH) occurs automatically after one second of IO write inactivity. Sure, a support for adjustable timeout can be added either on device or filesystem level.

Last edited by michalsc on 19-Nov-2013 at 10:58 PM.

@michalsc

Quote:

Hey, not bad!

Heh blimey.

Quote:

A process, yes :)

One advantage here is that you can "reboot" the Amiga side nice and fast!

I'm curious to know how the CreateProcess() implementation works. Presumably you have a scheduler implemented as well. Have you considered using Linux NPTL threads as AmigaOS tasks? Would that work? That might be a cheap way to do SMP as well, though I'm not sure how aggressively the Linux scheduler puts threads of the same process on different cores.

EDIT: Using Linux threads as AmigaOS tasks is obviously what you've done (just spotted the CPU load monitor). That way Forbid() and Permit() can be implemented with a mutex. Nice job. It would be interesting to see how much time a typical Amiga system spends with multitasking disabled - probably not much. Of course since device drivers are threads, you'd probably end up with one thread for all disk IO but that's ok.... :)

Quote:

Indeed, the libc is one of very few linux components available on the tiny ramdisk (invisible and unaccessible for ARIX anyway). Actually, due to the size of libc and small amount of functions used by ARIX I was going to replace it with a smaller library which provides an interface to kernel syscalls. See it as a CPU-agnostic interface to the old "int $0x80" or its equivalent.

Yes, you don't need most of the Linux C lib because you already have your own in AROS. Maybe you could look at uClibc? glibc/eglibc is certainly a massive body of software....

Quote:

Pretty correct. This gives us universal IO layer - some of you who tried native AROS surely noticed how vendor-fragile the IDE/SATA drivers are. This is due to all the vendor-specific (and sometimes product specific) "quirks" in the driver code which linux kernel implements already and native AROS doesn't. Plus, we can use the caching mechanism of linux's IO layer. But don't worry, the caches are flushed automatically after certain period of IO inactivity.

Yeah the Linux disk cache is awesome. Just think, you'll actually be able to do reasonable size compile jobs without it taking an age! (This was one of my shocks about OS4, and I'm not trying to start a fight here.... All that RAM going to waste, ughh).

Even with a very *narrow* list of supported chipsets, getting it working on all the variants is going to be absolute pain. So yeah, leveraging Linux for things like disk drivers seems very sensible.

Networking...
Quote:

Work in Progress - sorry for disappointment...

I can see that being tricky. Have you decided if you will use AROSs TCP/IP stack? Is it even possible to send frames looking like TCP/UDP via raw sockets through the kernel API? Probably yes, since nmap etc do it. Pretty weird, but probably simpler to implement then a translation layer since it would involve tracking Linux file (socket) descriptors through to the Amiga layer, something your filesystem mechanism avoids very nicely indeed.

EDIT: Apparently this is possible. You can reduce Linux to simple packet stuffing. Of course you then loose the better Linux TCP/IP stack but for ease it'll work with the least effort.

Quote:

Quote: Audio. Presumably a AHI frontend with an ALSA-lib backend. Yep.

USB headsets? All those fun things are now available.... I assume your using udev for your device detection?

Quote:

Indeed. This is a part which needs to be worked on in nearest future. Indeed Linux FB is used right now. In future 3D will be provided (still without X11 - even if we would like to use X11, but we don't, there is no place for it on the initrd image).

Yeah graphics is going to be, probably, the biggest challenge. Especially when you start looking at compositing... Hmm. I assume native AROS is 2D only?

Quote:

ARIX PCI driver (AKA pci.hidd known from AROS) allows you to enumerate PCI devices and map their resources (memory or MMIO) to ARIX address space. The only missing things to implement a HW driver running entirely on ARIX side is to route IRQs from kernel to ARIX kernel. This is being worked on and I see at least two ways of doing that.

Right. This is what I meant by "banging the hardware" .... had no idea you could implement a PCI driver in Linux userspace though. Pretty cool, but deadly at the same time! ;)

Quote:

I hope I didn't disappoint you with my answers... ;)

Nah! Your project is actually quite fascinating..... Looking forward to learning more about it. :)

Last edited by Aslak3 on 20-Nov-2013 at 05:59 PM.
Last edited by Aslak3 on 20-Nov-2013 at 12:41 PM.

_________________
Blog

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @cdimauro Quote: The Amiga o.s. has showed the contrary: a microkernel with excellent performance, better than monolithic kernels When AmigaOS gets the overhead of resource tracking, memory protection, SMP and such... then we'll talk about comparing it to Linux.

On modern desktop class systems, all those things are worth having. In fact to 99% of computer users today they are essential to their daily lives (SMP perhaps notwithstanding).

On my old 2GB SAM460 machine I found the performance, responsiveness, whatever you want to call it to be.... dreadful. Only if the machine was completely idle was it pleasant to use. Give it a bit of disk load, graphics load, or pure CPU-bound load and it was horrible. This is down to the simplistic scheduling and lack of basic things like any kind of disk cache. AmigaOS[3,4,reimplemenations etc] is efficient in RAM for what it does, yes. But it is let down by the dire scheduling, which hasn't improved even slightly since Sasenrath wrote the Exec back in 84. Memory management (and I'm not talking about MP) is also shocking when compared to modern systems.

Not trying to start an argument, just trying to present some truth. I loved my A1200. Back in the 90s it was "my computing life", but I refuse to listen to the same old falsehoods.

_________________
Blog

@Aslak3

Well I used my A1200 with Imagine 3D and while rendering I find its responsiveness dreadfull, but once its priority was set bellow the remaining tasks It was as if it was not there, without any significant penalty on render times ( perhaps some seconds more in a multiple hours render)

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

You just proved the point though. In twiddling with priorities you are doing the schedulers job....

_________________
Blog

@cdimauro

Quote:

cdimauro wrote: The Amiga o.s. has showed the contrary: a microkernel with excellent performance, better than monolithic kernels.

I will explain it again:
The Amiga might have something like a micro kernel but since there is no difference between user moder or kernel mode you can call it a monolithic kernel.

[code]
A monolithic kernel is an operating system architecture
where the entire operating system is working in kernel
space and is alone in supervisor mode.
[/code]
Source: http://en.wikipedia.org/wiki/Monolithic_kernel

[code]
By contrast, exec function calls are made with the library
jump table, and the kernel code normally executes in user
mode.
[/code]
Source: http://en.wikipedia.org/wiki/Exec_%28Amiga%29

Talking about micro- or monolithic-kernel in Amiga is totally stupid because the Amiga doesn't know the difference between user and supervisor mode.

It is about what parts of the OS are running in the same mode like the OS but AmigaOS doesn't know the difference between user and supervisor mode.

Discussion about micro- vs monolithic-kernel in the Amiga is like people discussing what type of jet propulsion was used in a Ford-T.

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@Arko

Again, "stupid"? Do you know how to discuss without insulting who thinks differently? Or is it a natural defense because you cannot sustain the discussion?

I know very well what is a micro and monolithic kernel, thank.

Read this: http://oreilly.com/catalog/opensources/book/appa.html

Talks about all this stuff and... Amiga to.

EDIT. And yes, even Amiga o.s. runs some part of its code in supervisor mode, and some on user mode. It even provides an ad hoc API to switch to supervisor mode...
So, even for this, you're totally wrong.
You better have to study how Amiga o.s. works...

Last edited by cdimauro on 20-Nov-2013 at 06:55 AM.
Last edited by cdimauro on 20-Nov-2013 at 06:32 AM.

Thank you @michalsc and @Aslak3 for the very informed technical discussions! Such an interesting and nice read!

Can't wait for more

_________________
Tygre
Scientific Progress Goes Boing!

@cdimauro

Thanks for the pointer on The Tanenbaum-Torvalds Debate, I hadn't read it, shame on me! No excuse tonight

_________________
Tygre
Scientific Progress Goes Boing!

@cdimauro

Quote:

cdimauro wrote: @Arko Again, "stupid"?

Talking about micro- or monolithic-kernel in Amiga is totally stupid ...

Last edited by Arko on 20-Nov-2013 at 09:01 AM.

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@Aslak3

Well to be fair I also had the same kind of problems on Windows, only much worse!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@tygre

+1

indeed interesting read

A really innovative design