@resle

Quote:

Go on, keep thinking about kernels and drivers..

I care about drivers. That's why I can update easily my Mediator drivers without recompiling anything.

On Android you buy a phone with certain Android version and you are stuck with it even if it has enough ram and cpu power because nobody will update the drivers to work with new kernel driver interfaces. I prefer OSes designed to be modular, to keep my drivers in devs/ and update the OS and continue using my hardware without worrying about updating drivers nor recompiling anything.

I care about kernels because that causes indirectly that GUI&operations react faster or not, I don't want to wait for my computer, I want that my computer waits for me. That's why Linux feels slow and reacts like it was a 286 running Windows3.1

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Linux being a monolithic kernel design has nothing to do with why you have to recompile kernelspace drivers and everything to do with an (intentional) unstable ABI.

it's quite possible to have a closed source monolithic kernel with a stable ABI for 3rd parties to write kernel space drivers for without providing them with the kernel source.

You seem to be confused as to what a microkernel is and how it works. Traditionally microkernels have as little as possible running inside the kernel's memory space and hardware drivers run in user space.

It is also possible to have drivers running in userspace on a monolithic kernel, see for example FUSE.

@IntuitionAmiga

Quote:

IntuitionAmiga wrote: @Crumb Linux being a monolithic kernel design has nothing to do with why you have to recompile kernelspace drivers and everything to do with an (intentional) unstable ABI.

Being a monolithic kernel is quite related with the driver interface changed between different versions because if you put your drivers in kernel space you usually compile them with the kernel (I know you can put them in external modules but in practice these modules are almost useless and only are useful to reduce memory consuption because next version may be completely incompatible) and are free to change the driver interface more easily, if it wasn't monolithic they wouldn't change the driver interface much in decades. Driver ABI and monolithic are different subjects but related IMHO.

Exec is more or less a "microkernel" since you can exchange easily almost any part of the OS without recompiling anything and sometimes even without rebooting (thanks to SetFunction). You can replace easily almost any part without performance hits. (You could even protect with MMU all your libraries so they aren't overwritten once loaded). Having different memory layouts using the MMU is not mandatory, look at Minix, it's a microkernel but didn't use MMU at all.

Quote:

it's quite possible to have a closed source monolithic kernel with a stable ABI for 3rd parties to write kernel space drivers for without providing them with the kernel source.

That depends on your linux kernel, older ones didn't accept external modules, that's why I wrote that if some years ago Amiga had used a monolithic closed source linux-like kernel we would be doomed.

If your driver crashes it will bring down the entire system, no thanks. If we are looking for memory protection and trying to improve development crashing your entire system because certain driver crashed looks like a bad idea.

Quote:

You seem to be confused as to what a microkernel is and how it works. Traditionally microkernels have as little as possible running inside the kernel's memory space and hardware drivers run in user space.

Of course they do, that's the main advantage over monolithic ones: these can recover to driver crashes more easily, another advantage is that you can develop drivers without crashing your entire OS.

Quote:

It is also possible to have drivers running in userspace on a monolithic kernel, see for example FUSE.

FUSE is a filesystem, not a driver, you need a driver to use the filesystem. Running drivers on userspace wouldn't follow Monolithic kernel phylosophy. Now show me Linux running nVidia drivers in userspace and keep the drivers until Linux v5 is release and try to boot using the old drivers.

PS: Even Linus Torvalds thinks that Linux is Bloated

Last edited by Crumb on 30-Oct-2013 at 07:47 PM.
Last edited by Crumb on 30-Oct-2013 at 07:32 PM.

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Quote:

Now show me Linux running nVidia drivers in userspace

Actually quite a lot of Xorg drivers for graphics cards are running in userspace. They access the bare metal through MMIO with help of mmap system call. Funny enough, every native graphics driver I developed for AROS, was developed on AROS hosted flavor, where AROS was talking to the graphics card directly...

The only annoying thing in userspace hardware drivers is lack of standardized way of passing the information about IRQs, e.g. something like WaitForIRQ system call ;)

FYI: http://www.free-electrons.com/kerneldoc/latest/DocBook/uio-howto/

Last edited by michalsc on 30-Oct-2013 at 08:23 PM.

@michalsc

now we only have to wait to see if those drivers run unmodified in future Linux versions

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

which ones? Xorg? Sure, they use only very limited amount of features :P Or do you suggest that the POSIX-compilant mmap system call will disappear somewhere in future?

@Crumb

Filesystem's aren't drivers?

OK.

@Crumb

Quote:

OS4 (non)Shared objects won't help as multiple copies will spawn in memory. That's IMHO very inefficient and not very Amiga-like.

This is not to diffferent to linking in static libs with the C compiler. This was done a lot. But does that mean Amiga C compilers were not Amiga like?

Sharing libraries are a good idea. But they need to be included as well. So they can have the same problem as a shared library that isn't included.

I'd prefer the archive to be bloated than the software. But either way the software should work out of the archive whatever method used.

@Hypex

Quote:

This is not to diffferent to linking in static libs with the C compiler. This was done a lot. But does that mean Amiga C compilers were not Amiga like? Sharing libraries are a good idea.

The problem is, shared objects (.so libraries) on AmigaOS4 are not as "shared" as they are on linux. On linux, the code and data (hint: copy on write) are shared among the processes using the .so file, thus the memory footprint is relatively low. On AmigaOS, the .so files are wasting much much more memory. They are also not as "shared" as typical amiga libraries (.library files). That's why Crumb wrote they are not really Amiga-like.

@michalsc

Quote:

They are also not as "shared" as typical amiga libraries (.library files). That's why Crumb wrote they are not really Amiga-like.

I can understand that, thus why I compared them to static libs. The only difference seems that one is encapsulated inside the executable, the other is on disk, but both waste memory.

I had hoped by now that proper threads would have been added to AmigaOS through some type of CreateThread() function. They really should be proper threads using MMU semantics to split off data and memory. But even a basic form would do.

For example, a basic form of threads could be added by simply adding the concept of sub-tasks. That is code that runs subordinate to a task and shares resources. The sub-code would share quantum cycles with the main task. And the quantum would cover all task and code. What would happen is that the main code would execute and if it gave up it's slice the remaining pieces would be given the the sub-code which would operate the same way. So one program could be split into several mini-programs.

How would this be implemented? Very easily. All code would share the same data and memory areas. All the threads would be are seperate contexts of code. That is, a stack, registers and IP. So the thread would continue with a context switch. The current state saved to the task and the new thread state restored.

Last edited by Hypex on 01-Nov-2013 at 01:58 PM.

@Hypex

Quote:

So one program could be split into several mini-programs

You can split your program into several mini-programs.
You have CreateProc() and CreateTask(), CreateProc() creates a process whit Shell, and you are also allowed to do file IO operations while CreateTask() do not allow you do file io operations and does not have a shell, memory of parent task is shard whit the child tasks.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@All

My two cents...

Why not using an hybrid kernel like BeOS/Haiku that will allow with some modifications to use drivers in user space and will be then capable to adapt Amiga style drivers?

(actually BeOS/Haiku loads drivers in kernel space, just like Ux/Linux, but microkernels load and handle drivers in user space)

There is also a PPC version of Haiku if I remember well, so there will be possible to make the first experiments and explore possibilities of using Be/Haiku kernel in a few time and minor effort of adapting than monolithic Ux/Linux Kernel.

[EDIT]

Oh... And perhaps one of the PPC motherboards that runs Haiku PPC is SAM 460!

http://www.youtube.com/watch?v=Ldh3foPCJJw

[EDIT END]

Last edited by Raffaele on 01-Nov-2013 at 05:12 PM.
Last edited by Raffaele on 01-Nov-2013 at 05:12 PM.
Last edited by Raffaele on 01-Nov-2013 at 04:51 PM.
Last edited by Raffaele on 01-Nov-2013 at 04:50 PM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

Because alternate kernels are supporting less devices?

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@saimon69

Following your order of ideas we will never start any project!

Think just at Morphos that has a powerful microkernel and it lays unused underneath ABox that is the only active API layer...

MOS team never developed QBox Api because they are too lazy to ever made minimal drivers, a simply start GUI interface, basic QBox DOS, a first functioning QBox files system, and so on...

Not even just to run complete MorphOS QBox at least on Pegasos only motherboard and ATI graphic cards... And then evolve...

No... They are just stuck on ABox, Amigaish OS style with all its limits, including the fact it crashes entire ABox as it lacks of memory protection.

Do you want to evolve (and survive?)

First step is to migrate to new kernel even with its limited motherboard (or mobos)+cards+device already supported...

Then we can build drivers for any kind of most used devices...

Last edited by Raffaele on 01-Nov-2013 at 06:12 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:10 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:08 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:06 PM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

Is that i seem to perceive some kind of prejudice towards the linux kernel as solution; beside the floating ABI, perceived bloat, opposite philosophy and purpose, viral license, etc. what else is not liked?


[addition]
Plus the linux kernel is HERE NOW so if somebody know how to put stuff together so that will remap to Amiga/AROS API calls and drivers as mschulz said above there will be an advantage to have a system ready; once this is out if you want to fork it to use other kernels why not?

[/addition]

Last edited by saimon69 on 01-Nov-2013 at 06:19 PM.

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@saimon69

Quote:

saimon69 wrote: @Raffaele Is that i seem to perceive some kind of prejudice towards the linux kernel as solution; beside the floating ABI, perceived bloat, opposite philosophy and purpose, viral license, etc. what else is not liked?

Well, if monolithic kernels does not allow a device drivers structure just as like that we have in Amiga, why don't use hybrid kernels that are a viable existing solution?

At least hybrid kernels don't require a complete recompiling of entire kernel to support every crap piece of hardware that user add to their computers...

I remember I tried to compile Linux Kernel for my brand new PC motherboard that featured for the first time the USB ports, and USB support in Linux was only experimental and required kernel recompiling...

Well... I never managed to make it working and I was forced to wait for stable new kernel releases almost 9 months.

[EDIT]

Also Haiku PPC kernel is -HERE NOW- and it supports existing Amiga motherboard and devices related to our existing hardware...

So what?

[EDIT END]

Last edited by Raffaele on 01-Nov-2013 at 06:34 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:27 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:27 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:25 PM.
Last edited by Raffaele on 01-Nov-2013 at 06:22 PM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

[it]Calmati, solo che sta gente mi sta dando ai nervi a trovare peli nell'uovo, manco fosse un uovo di Cesare Ragazzi... :P[/it]

The people responsible for ARIX explainme the reasons behind this, however i am dispensed to say it, not by an NDA but because of secret-bondings-made-with-blood-and-some-weird-procedures-involving-floppy-disks-a-lemur-and-some-cookie-dough, AND because i like to keep the hype :P

Last edited by saimon69 on 01-Nov-2013 at 07:02 PM.

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@Raffaele

Quote:

Following your order of ideas we will never start any project!

The other side of the coin: if you start too far down the stack, you may never finish...

As long as we are proposing micro-kernels, I suggest Minux3. It has NetBSD drivers and compiles with Clang. But I still prefer Linux, since it has better hardware and software support. No-one can actually tell if they're using a micro-kernel anyway; it's a lot like endianness in that respect.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

Yes...

But why unfriendly monolithic Linux instead of the kernel you or me proposed?

Too many projects in Amiga started as a vague immediate idea by genius geeks but does not take count of the community...

Last edited by Raffaele on 01-Nov-2013 at 09:19 PM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

but what concerns aros its open, you can implement it if you consider it better solution. its not like "things going on behind the scenes", except arix probably is not far enough to be revealed, but as soon it is it may be taken as template to create bsd based counterpart. lets wait first how that spins off.