Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
152 user(s) are online (87 user(s) are browsing Forums)

Members: 3
Guests: 149

FlynnTheAvatar, walkero, Templario, more...

Headlines

 
  Register To Post  

« 1 (2)
Re: Lsof AmigaDOS?
Just popping in
Just popping in


See User information
@joerg

Quote:
Actually we have at least 2 of them.
However, my "top" can't be used in DOS or ARexx scripts since it running infinitely until you stop it with Ctrl-C, but maybe Capehill's "Tequila" can be used that way.


That thread was mostly discussion then I found some links on the end.

But what I meant was a command or tool built in. It's becoming common that I find or rather don't find what I thought would be an obvious tool built into the OS. It's likely using what other OS has and then I realise something so obvious like even a basic process monitor doesn't come with OS4.

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information
@Hypex
Quote:
But what I meant was a command or tool built in. It's becoming common that I find or rather don't find what I thought would be an obvious tool built into the OS. It's likely using what other OS has and then I realise something so obvious like even a basic process monitor doesn't come with OS4.
Most of what an Unix top does is impossible on AmigaOS:
- Each Unix task has it's own virtual address space and it's always know which, and how much, memory is allocated/used by it. On AmigaOS 99% of the memory is shared between all tasks instead and even the OS doesn't know which task owns/uses how much and which parts of the memory. (There are some exceptions in AmigaOS 4.x like MEMF_PRIVATE and the extended memory system, but such new parts of the OS are rarely used.)
- Unlike the old AmigaOS 1.x-3.x/m68k Exec task scheduler the AmigaOS 4.1 ExecNG/PPC one does track the CPU usage of each task, but only on CPUs with the required hardware support, which is used for example by performancemonitor.resurce as well. A system legal way, if you have access to the internal ExecNG includes, is possible - but it can't work on all systems/CPUs supported by AmigaOS 4.x, only the ones with CPU support for performancemonitor.resource.

As a result all what's possible for tools which can be used on all systems running AmigaOS 4.x are hacks, like my top and Capehill's tequila.

On AmigaOS 3.x similar tools like Scout, SysMon, etc., which could display some system internals, incl. CPU usage per task, did exist as well, and even extreme hacks like Executive which reimplemented and (nearly) completely replaced the m68k exec task scheduler where available. But they had a lot of problems, more than tools like top and tequilla on AmigaOS 4.x, especially Executive broke much more software than it could improve.

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information
@Hypex

AROS on Linux seems to come with a task monitor. Not sure how portable it is (didn't check yet).

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information
@Capehill
Quote:
AROS on Linux seems to come with a task monitor. Not sure how portable it is (didn't check yet).

The main development goal of AROS seems to be being intentionally as incompatible as possible to anything, and that's not just limited to AmigaOS 3.x/m68k and AmigaOS 4.x/PPC, but even to other AROS versions. Not only incompatible to big-endian native AROS versions like m68k, PPC or efika in the little-endian versions, but AFAIK even native AROS x64 versions can't use any code nor data from native AROS x86 versions.
Hosted versions like the Linux one even more so, AFAIK the AROS tasks are simply host tasks in such hosted versions (for example Linux tasks), i.e. there is 0% compatibility to any AmigaOS exec task scheduler and a Linux hosted AROS task monitor is probably just a Linux task monitor (maybe filtering out non-AROS tasks) and there is nothing at all which could be ported to neither AmigaOS nor native AROS versions.
The big advantage of hosted AROS versions is that they don't have to implement any hardware drivers, they can simply use the ones of the host OS instead.

Go to top
Re: Lsof AmigaDOS?
Just popping in
Just popping in


See User information
@joergQuote:
joerg wrote:@Capehill
Hosted versions like the Linux one even more so, AFAIK the AROS tasks are simply host tasks in such hosted versions (for example Linux tasks), i.e. there is 0% compatibility to any AmigaOS exec task scheduler.


No, that's wrong. Linux does not see or know about Exec tasks inside AROS hosted. Everything is still basically the same as AROS native. What AROS hosted does is to basically emulate/implement interrupts using Unix signal handlers. And for task switches in the Unix signal handler it simply pokes the sigcontext (containsing cpu/fpu context state) structure, so that after the return from the signal handler, the Linux process "AROS" continues executing code from a different AROS Exec task.

A bit like early Linux user lever threading libraries.

Disable()/Enable() for example then works by simply blocking/unblocking Unix signals.

Quote:

The big advantage of hosted AROS versions is that they don't have to implement any hardware drivers, they can simply use the ones of the host OS instead.


Btw, it's really "can use", but does not mean "has to use" at the same time. Some native gfx drivers were developed under hosted version.

Btw2: there are several other big advantages.

It "boots" extremely fast, takes up almost no host cpu time/resources. You could run big number of instances at the same time (https://vimeo.com/191163338 - each blue amiga-style window appearing is a newly booted/running AROS instance, running intermixed with Linux windows). Then if you run one (big) program in once instance, and other (big) programs in other instance, you basically get some kind of memory protection/resource tracking/etc. for free.

You can do symbolic debug of the whole OS including all system libs/tasks and app tasks/libs with gdb, as if it was one single application.

// run AROS through gdb, later press ctrl-z

(gdbp IntuitionBase->ActiveWindow
$= (struct Window *) 0xe9429c10
(gdbwatch IntuitionBase->ActiveWindow->LeftEdge
Hardware watchpoint 1
IntuitionBase->ActiveWindow->LeftEdge
(gdbcont
Continuing
.

Thread 2.1 "AROSBootstrap" hit Hardware watchpoint 1IntuitionBase->ActiveWindow->LeftEdge

Old value 
353
New value 316
DoMoveSizeWindow 
(targetwindow=0xe9429c10NewLeftEdge=316NewTopEdge=207NewWidth=318NewHeight=340send_newsize=0IntuitionBase=0xe8b3fee0at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:445
445             targetwindow
->TopEdge     += pos_dy;
(
gdbthistask
Task     SigWait  SigRecvd StkSize   StkUsed Pri Type Name
-----------------------------------------------------------------------------
0xe8b31640 0x3f0000 0x400000    51200      832  20    1 input.device
(gdbbt
#0  DoMoveSizeWindow (targetwindow=0xe9429c10, NewLeftEdge=316, NewTopEdge=207, NewWidth=318, NewHeight=340, send_newsize=0, IntuitionBase=0xe8b3fee0)
    
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:445
#1  0xe7a5cd42 in int_movewindow (msg=0xe8b3d9a0, IntuitionBase=0xe8b3fee0) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./movewindow.c:89
#2  0xe7a869b5 in DoASyncAction (func=0xe7a5ccb3 <int_movewindow>, msg=0xe8b3d9a0, size=32, IntuitionBase=0xe8b3fee0)
    
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:653
#3  0xe7a5ccb0 in Intuition_28_MoveWindow (window=0xe9429c10, dx=-37, dy=-1, IntuitionBase=0xe8b3fee0)
    
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./movewindow.c:75
#4  0xe7a7db79 in __inline_Intuition_MoveWindow (__arg1=0xe9429c10, __arg2=-37, __arg3=-1, __IntuitionBase=0xe8b3fee0)
    
at /home/georg/aros/arosdeadwoodaltabiv0/alt-abiv0-linux-i386-d/bin/linux-i386/gen/rom/intuition/intuition/include/inline/intuition.h:366
#5  0xe7a7f2e8 in DragBarClass__GM_GOINACTIVE (cl=0xe8b69fa0, g=0xe8b6a10c, msg=0xe8b3daf0)
    
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./windowclasses.c:886
[...]
#

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information
@Georg
Quote:
Btw2: there are several other big advantages.
Yes, reading AROS sources is always good for having a lought, and a great inspiration for how things should not be implemented, for example the funny AROS file system API 🤣
Of course the ancient TRIPOS/AmigaOS 1.x-3.x BCPL packet file system API is crap and should be replaced, the AmigaOS 4.x dos.library did that as well - but using a better solution.
The AROS developers somehow managed to make it even worse, by using the exec device API instead 😮

Go to top
Re: Lsof AmigaDOS?
Just popping in
Just popping in


See User information
@joergQuote:
for example the funny AROS file system API 🤣


Was removed and replaced with std. AOS classic packet filesystem API long ago.

Quote:
the AmigaOS 4.x dos.library did that as well - but using a better solution.


It's easy to get into trouble when trying to replace something old/bad even if intentions are good. For example are there rules in the "better solution", when filesystems now run stuff in app task which used to run in filesystem task, for things like signal/msgport alloction (app is allowed to theoretically use up all the dynamically allocatable ones). Or stack usage? Are filesystems now supposed to check for potential low free stack and then stackswap?).

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information
@Georg
I don't use the new FileSystem API in my AmigaOS 4.x file systems (SFS, JXFS, CDFS, etc.), the new FS API was only implemented several years after I implemented my own FS API for SFS, etc. (it's similar, but not compatible), therefore I can't comment on the official OS4 FS API but only my own one.
- Allocating signals for device I/O used by the FS code running in an application tasks isn't required, and may fail if all signals are used already, but you can use SIGF_SINGLE or SIGF_DOS instead.
- My file systems just check the available stack size. If it's too small for executing the FS code inside the application task it's simply forwarding the commands to the still existing priority 10 FileSystem task, i.e. it's slowed down to the old TRIPOS/AmigaOS 1.x-3.x method, but using StackSwap() instead should usually be the better solution.

Go to top
Re: Lsof AmigaDOS?
Not too shy to talk
Not too shy to talk


See User information
@daveywQuote:
daveyw wrote:

Need something I can integrate into a script.

Working on a small project that monitors a file download and performs an action when completed. Currently looking for the file comment to be entered but would prefer a more robust solution.


Well, I got my Arexx script working, but thanks to Tequila, I can see it is grabbing all the CPU bandwidth and killing performance.

How can I change the task priroity of a arexx script?

I'm going to look into WaitNotify, it might be more helpful.

Otherwise, I will finally have to learn a proper programming language... have been eyeing PortablE for a while.

Go to top
Re: Lsof AmigaDOS?
Just can't stay away
Just can't stay away


See User information

Go to top
Re: Lsof AmigaDOS?
Not too shy to talk
Not too shy to talk


See User information
@Capehill

Awesome, thanks, I was struggling to understand what Pragma does, now I have a usecase for it I get it.

Go to top

  Register To Post
« 1 (2)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project