Then again, my ports, or compilations, typically used newlib, because I wasn't all that knowledgeable and it was easier for me than to try to use clib2, which apparently required changing some things.
Additionally to the obsolete, AmigaOS 0.x-3.9/m68k **4 way to get SysBase next to no AmigaOS 4.x software uses, other things you wrote are wrong as well, for example Quote:
AmigaOS 4 runs everything in supervisor.
No, it doesn't. All normal programs and tasks are running in user mode. 99% of the ExecSG kernel is running in user mode as well, only some tiny parts of it requiring it (accessing privileged special registers, MMU changes, exceptions, probably the task scheduler, etc.) are running in supervisor mode.
However, there is nothing in ExecSG preventing anything from executing some code in supervisor mode using IExec->SuperState()/IExec->UserState() or IExec->Supervisor(). And some software you might not expect to use supervisor mode could do, for various reasons. Hint: Make sure not to have any SFS partitions mounted when testing your quarantine mode
Using of `Clib2` become mandatory nowadays, otherwise porting programs from other systems becomes a nightmare...
Using clib2 with it tons of bugs would be a nightmare Anything is better than clib2, even libnix, which I ported to OS4 and used for all of my AmigaOS 4.x software before I ported newlib. The vclib C library is better as well if you use VBCC instead of GCC. @afxgroup's clib4 will probably get usable some day, or maybe even already is, but the original clib2? Avoid using it at all costs on AmigaOS 4.x.
In kickstart modules, libraries, devices, resources, etc. there are different ways to get SysBase and/or IExec, but it's never based on **4 in correctly written AmigaOS 4.x software.
Perhaps I'm missing something, but there seems to be at least one exception to that- printer drivers. Printer drivers are loaded and started by the printer device, so there is no startup code. And the only thing the printer device passes to the driver's initialization function is a pointer to a PrinterData struct.
That struct contains an embedded DeviceData struct, which in turn has a field called dd_ExecBase that seems to be just what we need. But testing shows that this field is always NULL. Maybe that's a printer device bug, but it seems to leave reading AbsExecBase as the only way to initialize SysBase.
Step 4: scheduling and Reschedule() AmigaOS exec has Reschedule()
The task scheduler in AmigaOS 0.x-3.9 m68k exec did have a Reschedule() function, but the one in ExecSG doesn't. There is a IExec->Reschedule() function for compatibility to old m68k software calling it, but IIRC it's an empty no-op function and if you need something like that the required workaround on AmigaOS 4.x is for example
IExec->Forbid();
IExec->Permit();
which triggers a reschedule.
Quote:
Step 6: the Kickstart at boot
The kernel also starts the Kickstart modules in the order the Kicklayout gives.
That would be incompatible to any AmigaOS version, 0.x-3.9/m68k as well as 4.x/PPC. Kickstart modules are executed in the order of their struct Resident rt_Pri.
Forbid/Permit is something that no one needs to use anymore
Quote:
That would be incompatible to any AmigaOS version, 0.x-3.9/m68k as well as 4.x/PPC. Kickstart modules are executed in the order of their struct Resident rt_Pri.
" I still don´t understand why everyone has to do his own thing instead of at least trying to work together."
The greatest strength, and at the same time the greatest weakness of our community, is the passionate devotion of the user base. We all want what is "Best for the Amiga", because we care. But we each have very different ideas about what is "best".
For myself, I love writing programs. Most of the time I'd rather write it myself than use someone else's code. This is how I learn, and how I grow as a programmer. Maybe I'll come up with something better, maybe not. But I'm learning all the way.
On the bigger scale (OS level), there's some stress happening. Different people have different ideas about how we go forward. I can't tell anyone else what to believe, and my opinion doesn't count for much anyway. Sure some things have happened that I don't like, but I know up front there's not a damn thing I can do about it.
So I'll stay in my private little corner, and if anyone needs help with MIDI, I hope they'll ask my help if they want it.
New Kernel? WOW. New Browser(s), BIG WOW. Hopefully I'll be able to access the rAudio UI, Google, and Amazon. (my big three needs, in order).. Arguing about what is best for the Amiga? I'll leave that to people who like to argue. I neither do it well nor enjoy it.
Forbid/Permit is something that no one needs to use anymore
Next to nothing needs m68k exec Reschedule() nor the OS 4.x Forbid()/Permit() workaround, but in some very rare cases it could be required.
Quote:
Not all modules
Some kickstart modules have more than one entry point (struct Resident), and it's not just rt_Pri but the rt_Flags are important as well: First all kickstart modules with RTF_SINGLETASK are started, some like expansion.library even before exec.library, then all "normal" ones, and last the ones with RTF_AFTERDOS. All 3 groups are sorted by rt_Pri.
That all sound interesting, but i start to have feeling, that jumping so radical from one unfinished project to another will make everything in unfinished state ever. I know it from myself, because i guilty to : i didn't finish pegasos2 rom, i didn't finish x1000 firmware, i dind't finished few game ports, i didn't finished dumbpad.. So i not the one who can point by finger, but what for sure, is that without finishing new kernel to works on x1000,x5000,sam, tabor and peg2 , to make for real, working the same (or faster) than original, and released for users , jumping to arm, sparc, x86, whatever else, kind of point that things can be unfinished.
I know its all very interesting today, we can do everything. But it will be pitty to have it all be unfinished, and upolished, and buggy because of switching to another project.
I for that reasson even if want to swith to something else very much, still hold myself on Mesa and ports over Mesa.
Welcome to the "chaos "of the open source operative systems Joking aside, I agree with you; rewriting the kernel and aiming to make it reliable, mature, and fully compatible already seems like a huge leap (both emotionally and technically), now even telling users moving to another architecture strikes me as definitely premature.
Because my plans are bigger, and all my projects are converging. And in any case Kernel is alredy working on all machine I have. I don't have any X1000, Peg2, A1, 440 so I can't work on them at moment
the required workaround on AmigaOS 4.x is for example
IExec->Forbid();
IExec->Permit();
which triggers a reschedule.
Are you sure? Permit() really should only trigger reschedule if one is pending. Like when another task was Signal()ed while in Forbid state.
Otherwise for example each and every ObtainSemaphore() call would trigger a reschedule, because I guess also in AOS4 it still is implemented using Forbid/Permit protection (no matter if slow or fast (uncontended) path).
I must agree with kas1e - too many projects prevent them from being completed and compromise their quality.
But: this new multi-core kernel looks perfect, and if it succeeds, it will be a major improvement for AmigaOS. And of course—everyone is free to develop whatever they like. Just a big thanks to @AmigaLabs for their enthusiasm!
I will be also glad if kernel will be also for X1000 and others, but.. it is not depend on me. In any case, if the kernel needs to be tested on computers such as the X1000, Sam440ep(-flex), Pegasos 2 and AmigaOne, please let me know.
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
If its open source / available someone else with X1000 hardware might try, not saying I’m going to try or not.. don’t get me wrong.. I have other things to take care of not Amiga related. Someone else might.
Irs the same for Sam460, Sam440 and so on..
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.