AFA Setup help - morelibspace

[Piru]

@bernd_afa

A user report me that before 3-4 days blitzkick dont work with blitzkick.

...

I hear that blitzkick can add resident Programs.Not sure if this is release for public or not.

 BlizKick.lha

I give the User the suggestion to ask the blitzkick coder or remus coder to add morelibspace feature to blitzkick or remus.

Just make your resident module such that once loaded by LoadSeg it will appear as full-blown resident tag. Then it can be used as BlizKick and remus as-is.

[code...]

Eeek, what a hack.

Frankly I don't know why it would only break with BlizKick, but I surely hope rest of AFA isn't that bad.

Some bugs in it:

- It's non re-entrant: Two simultanous (matching) callers and the thing will explode and crash the system.

- If some matching library should already have more than 350 functions, the routine will overwrite the whole system memory and crash the system. Separately: If there are at least 411 functions, the old MakeLibrary funcptr is trashed and system will crash aswell.

- KickTags should be placed to MEMF_KICK memory.

- The routine patching the kicktag to system doesn't look correct (it doesn't maintain the linked list properly).

- The KickTagPtr memory is allocated using AllocAbs, which means that the first 8 bytes can be trashed. If that'd happen, it would nuke the kicktag linkage.

- It will patch unrelated libraries which happen to match the 6 possizes compared. Nukes the system if the library in question has more than 350 functions (see above).

- If any library possize is different from the hardcoded values used to catch the specific libraries, the library will not be patched. I can see this causing problems with some diskfont.library versions for example (though assuming patching is not critical for other parts, this might not be fatal).

- Weird: Why is every patched library negsize expanded to include fixed number of 350 slots? That sounds rather excessive for certain libraries.

- Weird: Why is the every patched library possize expanded to 10KB? I can't possibly see any reason for that (surely AFA isn't doing any dirty tricks with library possize area?).

[Piru]

@klesterjr

So why didn't you email or send private message to me then?

But hey don't worry, you don't need to work with me.

Anyhow, if you would have followed my earlier posts to any coding related threads, you'd noticed that I'm rather pedantic about coding. I am quite direct when pointing out errors, too. I was quite apalled to find out how broken this particular code was, so my comments probably were even stronger than usual.

If someone feels offended, well I'm sorry I hurt your feelings. The bugs are real though, and should be fixed.

[Piru]

@bernd_afa

Well, morelibspace should be after BlizKick to avoid excessive rebooting at power up (you should get 2 reboots then, instead of 3). In this case KEEPEXEC isn't required either.

To work reliably, the bugs should be fixed aswell.

also you can try the
loadresident C:morelibspace
command in your blitzkick dir.

This will not work with the current morelibspace. The morelibspace should have the resident tag inside it for this to work (just like any regular library or device). With this the morelibspace would work:

a) as blizkick module
b) with loadresident
c) as remus module

[Piru]

@quenthal

What would be cool, is that all libraries of AFA_OS could be "ROMmable" modules, is this possible someday?

Well, if they're regular libraries/devices/etc, then in theory it should be possible to just include them as BlizKick modules (this works for the EXTRESBUF area is it's actually RAM, not ROM).

I doubt the modules are truly (remus) "ROM"able though, for that the modules should not contain any static variables (all static variables should be in the library base). It is well possible to fix the modules to be truly "ROM"able, but might require quite a bit of adjustment of the existing AROS code.

[Piru]

@bernd_afa

morelibspace do no reboot when you dont use the parameter REBOOT.Only OS3.1 users must use REBOOT.

Yes I noticed that.

morelibspace add a resident module after load.When setpatch on OS > 3.1 do the reboot then after the reset in the early bootphase at priority 70 it change the exec Funktion MakeLibrary.

Yes, that is obvious.

That Exec is not kill after every reset is a document AOS Feature. Exec is only create when switch on the amiga, if the checksum is wrong or *exec\KickCheckSum is wrong.

Or if the exec version changes. And this can happen when you use BlizKick.

Thus, to use it with BlizKick, there are couple of options:
1) Create BlizKick compatible version of the patch, so it can be used as a module. Just adding the resident structure inside the binary is enough.

2) Instruct users to start the program after BlizKick, with REBOOT option.

Obviously the bugs listed still need to be fixed, too.

makelibrary must patch so early because AOS create intuiton layer graphics etc libraries.

If you want to patch the libraries to include new functions, then yes, obviously.

blitzkick seem use priority 0 (same as amiga rom update)or i am wrong ?

You are wrong. The BlizKick source code is included btw, you don't need to guess.

BlizKick can add any priority resident modules to system. It's just like expanding the ROM. BlizKick does not use KickTagPtr or KickMemPtr at all, either.

When blitzkick do exec not kill, then the Boot check for resident tags, find the morelibspace resident
and patch Makelibrary long time before blitzkick do any action.So all must work

It will work just fine. There will be two reboots though, but that is the only option (2) if you insist in not doing the simple thing and adding the resident structure.

here is complete source

The complete source is what I commented earlier. See the earlier post about the bugs.

>What would be cool, is that all libraries of AFA_OS could be "ROMmable" modules, is this possible someday?

I dont know. blitzkick must support the increase of library space to have room for additional OS functions

With BlizKick you could replace the whole ROM resident module with a new one, without need to patch anything. Then obviously there would be no need to increase any library function table.

If you don't want this, the easy step of adding the resident structure to the binary (+fixing the bugs) would make it BlizKick compatible.

[Piru]

Can you please show me a blitzkick compatible source that can use with loadresident ?

Like I've explained twice already, just a regular resident tag like in any library/device:

Code: [Select]

#include <exec/nodes.h>
#include <exec/resident.h>

void Init(void);

struct Resident res =
{
    RTC_MATCHWORD,
    &res,
    &res + 1,
    RTF_COLDSTART,
    1,
    NT_UNKNOWN,
    70,
    &quot;whatever&quot;,
    &quot;whatever 1.0 (26.5.2007)\r\n&quot;,
    Init
};

void Init(void)
{
}


Regarding the bugs you don't consider bugs: Well it's your choice. IMO those are potentially fatal bugs, but if you don't see them as such, I can't possibly force you to fix them.

Regarding number of functions in a library: Yes I've seen a library with more than 250 functions. Arbitrary limitations suck: Just because you don't know of a library with x functions doesn't mean that such a thing can't exist. It's good coding practice to be ready for unexpented, and don't blow up the whole system when the unexpected arrives. This is especially true when patching OS functions, since then you have no control of the potential input.

[Piru]

@bernd_afa

Hm, it looks like you made a mistake when translating the C code to assembler:

Code: [Select]

Dc.l ROMTag+1 ; APTR RT_ENDSKIP
is wrong, it should be:

Code: [Select]

Dc.l ROMTag+RT_SIZE ; APTR RT_ENDSKIP

The actual amount added doesn't matter much, as long as it's >0, even and within the module. If it can be arranged easily, it should point to the end of this particular module.

Odd endskip is rather bad, as it causes further modules to be missed (and crashes 68000/68010).

[Piru]

I modify now my code endresi is the label at end of code.

Yeah, it looks good now.

but release soon is not important ?

Well for BlizKick support (for use as blizkick module) it is. The previous odd endskip causes troubles (read the previous post).

You told a simple resident structur for libraries is enough.But a library look diffrent to your example

Well, obviously because it is for a library. Such resident will work ok with BlizKick too, but obviously it should be used with libraries, not simple executed functions.