@derfs
Quote:

OK. I misunderstood the description of the “QEMU/KVM” requirements.

I did a little test on Arm64 - Asahi Linux Fedora and macOS.
I checked it on Peg2 and A1 with bboot. Unfortunately, it doesn't work for me.
The only line from the AOS4 kernel debug is that the driver is loading. You can see it in the screenshot.



To be sure, I also checked if my qemu compilation works correctly with virtio on A1 with *Linux.
Everything works fine there.



My line: -device virtio-scsi-pci,id=scsi0 -drive file=smtest.hdf,if=none,id=hd0 -device scsi-hd,drive=hd0,bus=scsi0.0

*) Don't pay attention to my startup with “nvme”. I checked without it (removed from Kicklayout), clean command lines, etc...
I added the screen because it was my last attempt.

I hope this will be helpful to you.

@derfs
Can't test now, but so you can mount some part of the windows's hdd inside of qemu without needs of "fat32 sticks" mount and transfer in fast manner any amount of data and have it appears in both win32 and qemu at the same time ?

@smarkusg

This was built and tested using QEMU running on Win11 x64.

@Maijestro

You can try to run mounter manually, but you will have to change the tooltypes to point it to the correct device.

Most of my time has gone into checking it loads as a kickstart module, so DEVS: installation method may have an issue still. I will check over the weekend.

@Maijestro
QEMU/KVM is required. You need to run Qemu on PPC. For example, you would need to install *Linux on your PPC machine and run QEMU there.

@derf

I tested it with Qemu/Pegasos, but it seems that I cannot get this driver to work.

I chose method 1 for the installation.

Method 1: Standard (copy to DEVS:)

1. Copy virtioscsi.device to DEVS: on your AmigaOS system.
2. Reboot.
3. The driver loads automatically at startup and announces all
discovered disks to mounter.library.

I start Qemu with the additional configuration

“-device virtio-scsi-pci,id=scsi0 -drive file=/Volumes/Data/AmigaOs4.1BackUp/GameBackUpHD/hd2SFS.img,format=raw,if=none,id=hd0 -device scsi-hd,drive=hd0,bus=scsi0.0”

It doesn't seem to work for me, and Mounter or MediaToolBox don't show me anything either.

@derf

Thanks again for the update and for providing this HD/SSD benchmark tool.

What I forgot to mention in my first post above is that my NVME SDD (Download) is called, just for the sake of completeness.

The new Version 1.1.0 including Cloud sync is ready for release. I will compile 0S3, MorphOS, Linux, Android and Windows version over the next days/weeks. Everything will then be published at least on Aminet.net, morphos-storage.net and os4depot.net...

For now, you can already download the final OS4 Version.
This includes new Icons and a pdf manual explaining the setup of 3 different ftp servers in detail incl. screenshots.

Ticklish_ppc-amigaos.lha

Ticklish_ppc-Linux.lha

@thread

Shader stack on OS4 is too rudimentary for QtQuick3D to render anything. Sorry guys, had hoped for that victory.

Great utility, thank you!

@OlafS25

Quote:

Well you have that problem on Linux as well..
everything is installed with sudo so everything you install can over write everything else.. the solution to incompatible packages is docker and kubernetes..

When it comes to Linux packages, security is maintained by the repositories not by the OS

@derfs

thanks for the update

@derfs

Amazing work..

New version of https://os4depot.net/?function=showfil ... chmark/amigadiskbench.lha is currently in the upload queue.

I have upload the latest version of this device driver to https://os4depot.net/?function=showfil ... er/storage/virtioscsi.lha for everyone to try out.

Follow the installation guide in the link and have fun!

@LiveForIt

For security and stability reasons system components need to be protected much more than now. Currently you can easily overwrite system components like libraries with a bad written installer. So a modernized OS would also need mechanism to secure the system. -Also you would have different software running in system without affecting each other like 68k programs, 32bit and 64bit software, running in different environments without directly affecting each other. The central instance would be exec as kernel propably, and different sandboxes running upon it. The kernel also would need to detect the hardware and manage the different cores and what process is started where. So there must be a tight integration between kernel and the environments running on it. How that works in context of OS4 with different teams and ownerships I do not know. Normally all is i one hand.

@OlafS25

I can’t comment on what is not official or is not released..

I can merely comment on issue with SMP, and cache concurrency, from the information, I looked up or find lectures about it..

if it’s possible or not to do x/y/z, comes down to problem solving abilities, and what solution was chosen. Something can be hard to do, when you have a lot of stuff running in background tripping all over the place.

So far from what I have lookup, it’s normal for cores to have their own MMU, so a exception should not affect other cores. something some people suggests that’s not case, but as pointed out by Gemini, it won’t be possible for threads to have its own virtual memory maps if that was the case.

cache concurrency has hardware solution, and software solutions, there are different ways this can be implemented, as outlines in YouTube lectures I have pointed to..

I can’t comment on the AROS solution.

If it is possible or not to run Petunia inside a sandbox, my guess is that’s its possible, however I do not know implementation, so I can’t say for sure..

I can say for sure that it is not possible to add 64bit support without a sandbox for 32bit programs..

My opinion about AmigaOS4.1 API is that is fragile and can need improved security, regarding stack, API’s and structurally.. and that major changes can require a sandbox solution.

I guess that a lot of AmigaOS libraries are not cache concurrency safe, and might need to be sandboxed. its far better if programs fail to open a library, then bring down the system

Cleaned up some weird stuff in this thread.

Stay away from the crazy stuff please, and continue the interesting discussion you're having here.

@LiveForIt

On AROS there is a experimental version with SMP support. As I understand it the concept is one core runs the system processes, apps are automatically started on other cores or can be started on a own core. Advantage, system is more stable and expeciaslly more resposnsive

But this of course needs changes in exec that affect compatbility. No problem if your software base is limited and mostly sources available and adaptable, a problem if most software is closed and cannot be recompiled. The same is true for 68k.

Another topic is migration to 64bit. You have software that is 32bit and cannot be reompiled. Solution is a runtime where 32bit software works on 64bit system..

68k can be solved by UAE of course, for example Amiberry.

So in short you need to modernize to drop compatibility to the old 68k amigaos and also to the existing PPC base and solve it by runtime/VM for PPC software (QEMU?), perhaps runtime for closed 32bit software, integration of 68k using UAE (as transparent as possible). Petunia will no longer work