PS3 [Research] LINK.XML information

DeViL303 said:
@aldostools : with the shortening xmls thing. Guess what?

Turns out none of the tags really matter at all. :) We can shorten every one to just one letter :D

This:
Code: 
<?xml version="1.0" encoding="UTF-8"?>
<XMBML version="1.0">
    <View id="root">
        <Attributes>
            <Table key="seg_dlna_scan">
                <Pair key="focus_priority"><>4</></Pair>
            </Table>
            <Table key="seg_screenshot">
                <Pair key="focus_priority"><>3</></Pair>
            </Table>
            <Table key="gameDir">
                <Pair key="focus_priority"><>2</></Pair>
            </Table>
            <Table key="seg_dlna_device">
                <Pair key="focus_priority"><>1</></Pair>
            </Table>
            <Table key="seg_data_device">
                <Pair key="focus_priority"><>-50</></Pair>
            </Table>
            <Table key="seg_playlist_mgmt">
                <Pair key="focus_priority"><>3</></Pair>
            </Table>
            <Table key="seg_hdd_contents">
                <Pair key="focus_priority"><>0</></Pair>
            </Table>
        </Attributes>
        <Items>
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_dlna_scan"
                attr="seg_dlna_scan"
                src="sel://localhost/isdlna?category_photo.xml#seg_dlna_scan"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_screenshot"
                attr="seg_screenshot"
                src="sel://localhost/screenshot?category_photo.xml#seg_screenshot"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_gameexit"
                src="sel://localhost/ingame?path=category_photo.xml#seg_gameexit&type=photo"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="gameDir"
                attr="gameDir"
                src="xcb://localhost/query?limit=2048&table=MMS_MEDIA_TYPE_HDD&sort=+Game:Common.stat.rating+Game:Common.timeCreated&cond=Aa+Game:Common.title+Ae+Game:Game.category AP"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_dlna_device"
                attr="seg_dlna_device"
                src="xcb://localhost/query?table=MMS_MEDIA_TYPE_SYSTEM&genre=Photo&sort=+StorageMedia:Common.titleForSort&cond=Ae+StorageMedia:StorageMedia.type %xCB_MEDIA_TYPE_DLNA"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_data_device"
                attr="seg_data_device"
                src="xcb://localhost/query?table=MMS_MEDIA_TYPE_SYSTEM&genre=Photo&sort=+StorageMedia:StorageMedia.sortOrder+StorageMedia:StorageMedia.timeInserted&cond=Ae+StorageMedia:StorageMedia.stat.mediaStatus %xCB_MEDIA_INSERTED+Ae+StorageMedia:StorageMedia.mediaFormat %xCB_MEDIA_FORMAT_DATA+AGL+StorageMedia:StorageMedia.type %xCB_MEDIA_TYPE_BDROM %xCB_MEDIA_TYPE_WM"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_playlist_mgmt"
                attr="seg_playlist_mgmt"
                src="#seg_playlist_mgmt"
                />
            <Query
                class="type:x-xmb/folder-pixmap"
                key="seg_hdd_contents"
                attr="seg_hdd_contents"
                src="sel://localhost/ex?root.view_selected.photo"
                />
        </Items>
    </View>
    <View id="seg_dlna_scan">
        <Attributes>
            <Table key="scan">
                <Pair key="icon_rsc"><>item_tex_dlna_scan</></Pair>
                <Pair key="icon_notation"><>WNT_XmbItemMediaServerSearch</></Pair>
                <Pair key="title_rsc"><>msg_scan_mediaserver</></Pair>
                <Pair key="module_name"><>dlna_plugin</></Pair>
                <Pair key="module_action"><>dlna_scan</></Pair>
                <Pair key="bar_action"><>hide</></Pair>
             </Table>
        </Attributes>
        <Items>
            <Item
                class="type:x-xmb/module-action"
                key="scan"
                attr="scan"
            />
        </Items>
    </View>
    <View id="seg_playlist_mgmt">
        <Attributes>
            <Table key="mgmt">
                <Pair key="mode"><>playlistmgmt</></Pair>
                <Pair key="type"><>photo</></Pair>
            </Table>
        </Attributes>
        <Items>
            <Item class="type:x-xmb/xmlplaylist" key="mgmt" attr="mgmt" />
        </Items>
    </View>
    <View id="seg_playlist_mgmt_psp">
        <Attributes>
            <Table key="mgmt">
                <Pair key="mode"><>playlistmgmtpsp</></Pair>
                <Pair key="type"><>photo</></Pair>
            </Table>
        </Attributes>
        <Items>
            <Item class="type:x-xmb/xmlplaylist" key="mgmt" attr="mgmt" />
        </Items>
    </View>
    <View id="seg_playlist_fixed_items">
        <Attributes>
            <Table key="make_new_playlist">
                <Pair key="icon_rsc"><>tex_add_playlist</></Pair>
                <Pair key="title_rsc"><>msg_create_new_playlist</></Pair>
                <Pair key="icon_notation"><>WNT_XmbItemPlaylistAdd</></Pair>
                <Pair key="module_name"><>playlist_plugin</></Pair>
                <Pair key="module_action"><>make_new_playlist_photo</></Pair>
                <Pair key="bar_action"><>hide</></Pair>
             </Table>
        </Attributes>
        <Items>
            <Item class="type:x-xmb/module-action" key="make_new_playlist" attr="make_new_playlist" />
        </Items>
    </View>
    <View id="seg_playlist_empty">
        <Attributes>
            <Table key="empty">
                <Pair key="mode"><>playlistempty</></Pair>
                <Pair key="id"><></></Pair>
                <Pair key="path"><></></Pair>
            </Table>
        </Attributes>
        <Items>
            <Item class="type:x-xmb/xmlplaylist" key="empty" attr="empty" />
        </Items>
    </View>
    <View id="seg_hakoniwa">
        <Items>
            <Item class="type:x-xmb/xmlhakoniwa" key="hakoniwa"    attr="hakoniwa" />
        </Items>
    </View>
    <View id="seg_screenshot">
        <Items>
            <Item class="type:x-xmb/xmlscreenshot" key="screenshot" />
        </Items>
    </View>
    <View id="seg_gameexit">
        <Items>
            <Item class="type:x-xmb/xmlgameexit" key="gameexit" />
        </Items>
    </View>
</XMBML>
is read exactly the same as this:

Code: 
<X version="1.0">
    <V id="root">
        <A>
            <T key="seg_dlna_scan">
                <P key="focus_priority"><>4</></P>
            </T>
            <T key="seg_screenshot">
                <P key="focus_priority"><>3</></P>
            </T>
            <T key="gameDir">
                <P key="focus_priority"><>2</></P>
            </T>
            <T key="seg_dlna_device">
                <P key="focus_priority"><>1</></P>
            </T>
            <T key="seg_data_device">
                <P key="focus_priority"><>-50</></P>
            </T>
            <T key="seg_playlist_mgmt">
                <P key="focus_priority"><>3</></P>
            </T>
            <T key="seg_hdd_contents">
                <P key="focus_priority"><>0</></P>
            </T>
        </A>
        <I>
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_dlna_scan"
                attr="seg_dlna_scan"
                src="sel://localhost/isdlna?category_photo.xml#seg_dlna_scan"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_screenshot"
                attr="seg_screenshot"
                src="sel://localhost/screenshot?category_photo.xml#seg_screenshot"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_gameexit"
                src="sel://localhost/ingame?path=category_photo.xml#seg_gameexit&type=photo"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="gameDir"
                attr="gameDir"
                src="xcb://localhost/query?limit=2048&table=MMS_MEDIA_TYPE_HDD&sort=+Game:Common.stat.rating+Game:Common.timeCreated&cond=Aa+Game:Common.title+Ae+Game:Game.category AP"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_dlna_device"
                attr="seg_dlna_device"
                src="xcb://localhost/query?table=MMS_MEDIA_TYPE_SYSTEM&genre=Photo&sort=+StorageMedia:Common.titleForSort&cond=Ae+StorageMedia:StorageMedia.type %xCB_MEDIA_TYPE_DLNA"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_data_device"
                attr="seg_data_device"
                src="xcb://localhost/query?table=MMS_MEDIA_TYPE_SYSTEM&genre=Photo&sort=+StorageMedia:StorageMedia.sortOrder+StorageMedia:StorageMedia.timeInserted&cond=Ae+StorageMedia:StorageMedia.stat.mediaStatus %xCB_MEDIA_INSERTED+Ae+StorageMedia:StorageMedia.mediaFormat %xCB_MEDIA_FORMAT_DATA+AGL+StorageMedia:StorageMedia.type %xCB_MEDIA_TYPE_BDROM %xCB_MEDIA_TYPE_WM"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_playlist_mgmt"
                attr="seg_playlist_mgmt"
                src="#seg_playlist_mgmt"
                />
            <Q
                class="type:x-xmb/folder-pixmap"
                key="seg_hdd_contents"
                attr="seg_hdd_contents"
                src="sel://localhost/ex?root.view_selected.photo"
                />
        </I>
    </V>
    <V id="seg_dlna_scan">
        <A>
            <T key="scan">
                <P key="icon_rsc"><>item_tex_dlna_scan</></P>
                <P key="icon_notation"><>WNT_XmbItemMediaServerSearch</></P>
                <P key="title_rsc"><>msg_scan_mediaserver</></P>
                <P key="module_name"><>dlna_plugin</></P>
                <P key="module_action"><>dlna_scan</></P>
                <P key="bar_action"><>hide</></P>
             </T>
        </A>
        <I>
            <I
                class="type:x-xmb/module-action"
                key="scan"
                attr="scan"
            />
        </I>
    </V>
    <V id="seg_playlist_mgmt">
        <A>
            <T key="mgmt">
                <P key="mode"><>playlistmgmt</></P>
                <P key="type"><>photo</></P>
            </T>
        </A>
        <I>
            <I class="type:x-xmb/xmlplaylist" key="mgmt" attr="mgmt" />
        </I>
    </V>
    <V id="seg_playlist_mgmt_psp">
        <A>
            <T key="mgmt">
                <P key="mode"><>playlistmgmtpsp</></P>
                <P key="type"><>photo</></P>
            </T>
        </A>
        <I>
            <I class="type:x-xmb/xmlplaylist" key="mgmt" attr="mgmt" />
        </I>
    </V>
    <V id="seg_playlist_fixed_items">
        <A>
            <T key="make_new_playlist">
                <P key="icon_rsc"><>tex_add_playlist</></P>
                <P key="title_rsc"><>msg_create_new_playlist</></P>
                <P key="icon_notation"><>WNT_XmbItemPlaylistAdd</></P>
                <P key="module_name"><>playlist_plugin</></P>
                <P key="module_action"><>make_new_playlist_photo</></P>
                <P key="bar_action"><>hide</></P>
             </T>
        </A>
        <I>
            <I class="type:x-xmb/module-action" key="make_new_playlist" attr="make_new_playlist" />
        </I>
    </V>
    <V id="seg_playlist_empty">
        <A>
            <T key="empty">
                <P key="mode"><>playlistempty</></P>
                <P key="id"><></></P>
                <P key="path"><></></P>
            </T>
        </A>
        <I>
            <I class="type:x-xmb/xmlplaylist" key="empty" attr="empty" />
        </I>
    </V>
    <V id="seg_hakoniwa">
        <I>
            <I class="type:x-xmb/xmlhakoniwa" key="hakoniwa"    attr="hakoniwa" />
        </I>
    </V>
    <V id="seg_screenshot">
        <I>
            <I class="type:x-xmb/xmlscreenshot" key="screenshot" />
        </I>
    </V>
    <V id="seg_gameexit">
        <I>
            <I class="type:x-xmb/xmlgameexit" key="gameexit" />
        </I>
    </V>
</X>

Not only that, but every time localhost is mentioned in XMBML, we can replace it with just 0. lol.
Click to expand...

It's a really cool news!! I was thinking about that when I found that <String> could be shortened, but I couldn't validate it.

It's very helpful to reduce the size of mygames.xml
 
Yeah it's great, now we have loads of ways to shorten XMBML. I shaved a whole MB off Ultimate Toolbox, and I have not even started looking at "include" yet. :D

The main xml now looks this:
Code: 
<X version="1.0"><V id="main_menu"><A><T key="m">
<P key="icon"><>/dev_hdd0/game/ULTOOLBOX/USRDIR/icon/Toolbox.png</></P>
<P key="title"><>Ultimate Toolbox</></P>
<P key="info"><>It only does everything!</></P>
<P key="child"><>segment</></P>
</T></A><I><Q class="type:x-xmb/folder-pixmap" key="m" attr="m" src="#i"/></I></V>
<V id="i"><I>
<Q class="type:x-xmb/folder-pixmap" key="p" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Power_Options.xml#power_options"/>
<Q class="type:x-xmb/folder-pixmap" key="b" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Backup_Utility.xml#seg_backup_utility"/>
<Q class="type:x-xmb/folder-pixmap" key="e" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/File_Manager.xml#seg_file_manager_items"/>
<Q class="type:x-xmb/folder-pixmap" key="f" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Firmware_Settings.xml#seg_firmware_settings"/>
<Q class="type:x-xmb/folder-pixmap" key="m" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Package_Manager.xml#seg_ultimate_package_manager"/>
<Q class="type:x-xmb/folder-pixmap" key="d" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/modules/Downloader_Module/Demo_Downloader.xml#seg_demo_main"/>
<Q class="type:x-xmb/folder-pixmap" key="v" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Visual_Customisation.xml#seg_visual_customisation"/>
<Q class="type:x-xmb/folder-pixmap" key="s" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Toolbox_Settings.xml#seg_toolbox_settings"/>
<Q class="type:x-xmb/folder-pixmap" key="a" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Built_In_Apps.xml#built_in_apps"/>
</I></V></X>
 
Last edited:
DeViL303 said:
Yeah it's great, now we have loads of ways to shorten XMBML. I shaved a whole MB off Ultimate Toolbox, and I have not even started looking at "include" yet. :D

The main xml now looks this:
Code: 
<X version="1.0"><V id="main_menu"><A><T key="m">
<P key="icon"><>/dev_hdd0/game/ULTOOLBOX/USRDIR/icon/Toolbox.png</></P>
<P key="title"><>Ultimate Toolbox</></P>
<P key="info"><>It only does everything!</></P>
<P key="child"><>segment</></P>
</T></A><I><Q class="type:x-xmb/folder-pixmap" key="m" attr="m" src="#i"/></I></V>
<V id="i"><I>
<Q class="type:x-xmb/folder-pixmap" key="p" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Power_Options.xml#power_options"/>
<Q class="type:x-xmb/folder-pixmap" key="b" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Backup_Utility.xml#seg_backup_utility"/>
<Q class="type:x-xmb/folder-pixmap" key="e" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/File_Manager.xml#seg_file_manager_items"/>
<Q class="type:x-xmb/folder-pixmap" key="f" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Firmware_Settings.xml#seg_firmware_settings"/>
<Q class="type:x-xmb/folder-pixmap" key="m" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Package_Manager.xml#seg_ultimate_package_manager"/>
<Q class="type:x-xmb/folder-pixmap" key="d" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/modules/Downloader_Module/Demo_Downloader.xml#seg_demo_main"/>
<Q class="type:x-xmb/folder-pixmap" key="v" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Visual_Customisation.xml#seg_visual_customisation"/>
<Q class="type:x-xmb/folder-pixmap" key="s" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Toolbox_Settings.xml#seg_toolbox_settings"/>
<Q class="type:x-xmb/folder-pixmap" key="a" src="xmb://localhost/dev_hdd0/game/ULTOOLBOX/USRDIR/xmls/Built_In_Apps.xml#built_in_apps"/>
</I></V></X>
Click to expand...

As you probably noticed "0" cannot be used in xmb://, but "0" can be used in queries with xcb://.
 
@aldostools @DeViL303

Very nice findings guys, the investment in research time paid off... ;-)

While we are talking about improvements we could make in xmbml, I have an idea I wish to submit to you.

As I mentioned before, I have been working on xai_plugin for a couple of weeks or so, a few hours here & there whenever I can.

I made CFW Settings into a separate standard sprx module (with a stub library to make it usable in either self or sprx projects) & I turned the xai_plugin sprx project into a module action parser & dispatcher.

1. Whenever an old cfw settings query is made to the new xai_plugin via module action, xai loads the new external cfw settings sprx & executes the requested tasks using the export function system before unloading the cfw settings sprx.

2. Whenever the module action query is found to be targeting webman/sMan, the query is redirected to localhost using socket programming (like wm proxy). Having to setup idle_plugin or whatever other system module as wm proxy is no longer required if you use this xai_plugin.

3. When the module action query is XML, it gets parsed to extract the list of jobs the XML describes & the jobs (if any valid jobs were extracted) are executed sequentially. The xml job lists can also be sourced in files. I also implemented dynamic arrays to remove all limitations for the xml job lists, within system constraints, you get an "unlimited" number of potential xml jobs & each xml job gets an "unlimited" number of potential xml attributes, making the job list infrastructure as flexible it can be.

The currently implemented jobs are mostly file management related for the moment but more job types will be added once I am satisfied with the testing results of the build as it stands.
I plan to add jobs such as sprx module loading/unloading, lv2 payload management functions & if I have time I may look into adding a sprx library to support userland hooking, we will see.

And here now is the idea I would like you guys to consider. What about making memory allocation/deallocation/data storage, syscalls/export functions accessible via module action?

For instance, let us say we want to call the syscall with custom arguments using module action.

Let's take tty write as an example, here is the signature.
int sys_tty_write(uint32_t channel, const void *pbuffer, uint32_t bufferlength, uint32_t *pwrittenlength);

You call it like this:
system_call_4(403, tty channel number, text string pointer, string length, written length pointer);

To execute this line of code, you would first need to create the 2 needed pointers in memory, and store the text string in memory as well.

This kind of stuff could be done with a XML job list looking something like this.
The example below is purposefully oversimplified..

Allocate & store the string in memory, allocated memory pointers get saved in xai_alloc as an array of pointers:
Code: 
<job category='memory' type='allocation' data-type='char' data-value='hello world' data-file='/dev_hdd0/tmp/xai_alloc' />

Allocate memory for the written length integer in memory, pointer gets saved in xai_alloc:
Code: 
<job category='memory' type='allocation' data-type='size_t' data-value='0' data-file='/dev_hdd0/tmp/xai_alloc' />

Execute the syscall using the right arguments:
Code: 
<job category='code' type='syscall' id='403' arg1='1' arg2='xai_alloc[0]' arg3='12' arg4='xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />

Notify written length:
Code: 
<job category='xmb' type='notify' message='written length = 0x%X' data-value='*xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />

Deallocate memory:
Code: 
<job category='memory' type='deallocation' data-file='/dev_hdd0/tmp/xai_alloc' />

Technically speaking, this could be implemented in such a way that all syscalls are supported. Vsh & vsh modules export function calls could similarly be supported too.
The objective here is only to provide basic things, typically reserved to self & sprx, using xml from XMB, but obviously not to create complex programming.

In theory, as a more solid alternative, it may be possible to implement support for a custom scripting language so we could pass code snippets for xai_plugin to interpret & execute but that's another thing altogether, setting up an interpreter for this feature would most likely be overkill in many respects..

Anyway is this idea really worth the time investment? What do you both think?
 
Last edited:
bguerville said:
As I mentioned before, I have been working on xai_plugin for a couple of weeks or so, a few hours here & there whenever I can.

I made CFW Settings into a separate standard sprx module (with a stub library to make it usable in either self or sprx projects) & I turned the xai_plugin sprx project into a module action parser & dispatcher.

1. Whenever an old cfw settings query is made to the new xai_plugin via module action, xai loads the new external cfw settings sprx & executes the requested tasks using the export function system before unloading the cfw settings sprx.

2. Whenever the module action query is found to be targeting webman/sMan, calls are redirected to the localhost using the wm proxy code. Using idle_plugin or whatever other system module is no longer required if you have this xai_plugin.

3. When the module action query is XML, it gets parsed to extract the list of jobs the XML describes & the jobs (if any valid jobs were extracted) are executed sequentially. The xml job lists can also be sourced in files.

The currently implemented jobs are mostly file management related for the moment but more job types will be added once I am satisfied with the testing results of the build as it stands.
I plan to add jobs such as sprx module loading/unloading, lv2 payload management functions & if I have time I may look into adding a sprx library to support userland hooking, we will see.
Click to expand...
Wow, that all sounds great. I kind of understand that bit, I think :) More File management possibilities is good, and it's mostly what I work with.
bguerville said:
And here now is the idea I would like you guys to consider. What about making memory allocation/deallocation/data storage, syscalls/export functions accessible via module action?

For instance, let us say we want to call the syscall with custom arguments using module action.

Let's take tty write as an example, here is the signature.
int sys_tty_write(uint32_t channel, const void *pbuffer, uint32_t bufferlength, uint32_t *pwrittenlength);

You call it like this:
system_call_4(403, tty channel number, text string pointer, string length, written length pointer);

To execute this line of code, you would first need to create the 2 needed pointers in memory, and store the text string in memory as well.

This kind of stuff could be done with a XML job list looking something like this.
The example below is purposefully oversimplified..

Allocate & store the string in memory, allocated memory pointers get saved in xai_alloc as an array of pointers:
Code: 
<job category='memory' type='allocation' data-type='char' data-value='hello world' data-file='/dev_hdd0/tmp/xai_alloc' />
Allocate memory for the written length integer in memory, pointer gets saved in xai_alloc:
Code: 
<job category='memory' type='allocation' data-type='size_t' data-value='0' data-file='/dev_hdd0/tmp/xai_alloc' />
Execute the syscall using the right arguments:
Code: 
<job category='code' type='syscall' id='403' arg1='1' arg2='xai_alloc[0]' arg3='12' arg4='xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />
Notify written length:
Code: 
<job category='xmb' type='notify' message='written length = 0x%X' data-value='*xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />
Deallocate memory:
Code: 
<job category='memory' type='deallocation' data-file='/dev_hdd0/tmp/xai_alloc' />
Technically speaking, this could be implemented in such a way that all syscalls are supported. Vsh & vsh modules export function calls could similarly be supported too.

In theory, as a more solid alternative, it may be possible to implement support for a scripting language so we could pass code snippets for xai_plugin to interpret & execute but that's another thing altogether, probably overkill in many respects..

Anyway is this idea really worth the time investment? What do you both think?
Click to expand...
If that is over simplified I would hate to see the complicated stuff :) I am the wrong person to ask here really, So I will leave this to those who know more to answer you on whether it is worth it. Most of that goes completely over my head tbh. I work fairly simply tbh with copy/paste/rename/move mostly, I would not be able to give you a great answer on that and not sure if I would be able to use any of it myself really.. Given enough time I might be able to use some of it but idk. I do not know a whole pile about syscalls and memory allocation etc.

Things I would like to be able to do would be simpler, in my head anyway. Things like toggling xreg settings directly, mixing copy/move/delete in one operation, unzipping zips, patching xmls, maybe installing pkgs, modifying the database maybe, simple RAM patches, maybe even decrypting sprxs and finding strings to patch those rather than swapping files all the time which can have issues. Patching qrc files even, Maybe some simple "if this is true then do that" type stuff.

Sorry I can not be more help but some of the experts around here will hopefully have some input on that stuff.

I am just off to bed, will catch up with this tomorrow.
 
bguerville said:
@aldostools @DeViL303

Very nice findings guys, the investment in research time paid off... ;-)

While we are talking about improvements we could make in xmbml, I have an idea I wish to submit to you.

As I mentioned before, I have been working on xai_plugin for a couple of weeks or so, a few hours here & there whenever I can.

I made CFW Settings into a separate standard sprx module (with a stub library to make it usable in either self or sprx projects) & I turned the xai_plugin sprx project into a module action parser & dispatcher.

1. Whenever an old cfw settings query is made to the new xai_plugin via module action, xai loads the new external cfw settings sprx & executes the requested tasks using the export function system before unloading the cfw settings sprx.

2. Whenever the module action query is found to be targeting webman/sMan, calls are redirected to the localhost using the wm proxy code. Using idle_plugin or whatever other system module is no longer required if you have this xai_plugin.

3. When the module action query is XML, it gets parsed to extract the list of jobs the XML describes & the jobs (if any valid jobs were extracted) are executed sequentially. The xml job lists can also be sourced in files.

The currently implemented jobs are mostly file management related for the moment but more job types will be added once I am satisfied with the testing results of the build as it stands.
I plan to add jobs such as sprx module loading/unloading, lv2 payload management functions & if I have time I may look into adding a sprx library to support userland hooking, we will see.

And here now is the idea I would like you guys to consider. What about making memory allocation/deallocation/data storage, syscalls/export functions accessible via module action?

For instance, let us say we want to call the syscall with custom arguments using module action.

Let's take tty write as an example, here is the signature.
int sys_tty_write(uint32_t channel, const void *pbuffer, uint32_t bufferlength, uint32_t *pwrittenlength);

You call it like this:
system_call_4(403, tty channel number, text string pointer, string length, written length pointer);

To execute this line of code, you would first need to create the 2 needed pointers in memory, and store the text string in memory as well.

This kind of stuff could be done with a XML job list looking something like this.
The example below is purposefully oversimplified..

Allocate & store the string in memory, allocated memory pointers get saved in xai_alloc as an array of pointers:
Code: 
<job category='memory' type='allocation' data-type='char' data-value='hello world' data-file='/dev_hdd0/tmp/xai_alloc' />

Allocate memory for the written length integer in memory, pointer gets saved in xai_alloc:
Code: 
<job category='memory' type='allocation' data-type='size_t' data-value='0' data-file='/dev_hdd0/tmp/xai_alloc' />

Execute the syscall using the right arguments:
Code: 
<job category='code' type='syscall' id='403' arg1='1' arg2='xai_alloc[0]' arg3='12' arg4='xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />

Notify written length:
Code: 
<job category='xmb' type='notify' message='written length = 0x%X' data-value='*xai_alloc[1]' data-file='/dev_hdd0/tmp/xai_alloc' />

Deallocate memory:
Code: 
<job category='memory' type='deallocation' data-file='/dev_hdd0/tmp/xai_alloc' />

Technically speaking, this could be implemented in such a way that all syscalls are supported. Vsh & vsh modules export function calls could similarly be supported too.

In theory, as a more solid alternative, it may be possible to implement support for a scripting language so we could pass code snippets for xai_plugin to interpret & execute but that's another thing altogether, probably overkill in many respects..

Anyway is this idea really worth the time investment? What do you both think?
Click to expand...

It's really nice to have a tool like that. It's very useful.

IMHO the XML syntax looks organized but very hard to read. I would prefer a scripting language syntax.
It could be a simple sequential line parser. It does not require to be a full script with structured logic or variables. That would be a plus.

For instance this is easier to read:
var[1] = (char)"hello";
var[2] = (size_t)0;
syscall(403, 1, var[0], 12, var[1]);
notify("written length = 0x%X", var[1]);

BTW could you add an option to auto-enable DLNA media server on start up or maybe make a standalone sprx for it?
Here is the post by DeViL303 about this topic:
https://www.psx-place.com/threads/cant-see-ps3-photo-gallery-on-my-cfw-ps3.2787/#post-282241
 
DeViL303 said:
Wow, that all sounds great. I kind of understand that bit, I think :) More File management possibilities is good, and it's mostly what I work with.

If that is over simplified I would hate to see the complicated stuff :) I am the wrong person to ask here really, So I will leave this to those who know more to answer you on whether it is worth it. Most of that goes completely over my head tbh. I work fairly simply tbh with copy/paste/rename/move mostly, I would not be able to give you a great answer on that and not sure if I would be able to use any of it myself really.. Given enough time I might be able to use some of it but idk. I do not know a whole pile about syscalls and memory allocation etc.

Things I would like to be able to do would be simpler, in my head anyway. Things like toggling xreg settings directly, mixing copy/move/delete in one operation, unzipping zips, patching xmls, maybe installing pkgs, modifying the database maybe, simple RAM patches, maybe even decrypting sprxs and finding strings to patch those rather than swapping files all the time which can have issues. Patching qrc files even, Maybe some simple "if this is true then do that" type stuff.

Sorry I can not be more help but some of the experts around here will hopefully have some input on that stuff.

I am just off to bed, will catch up with this tomorrow.
Click to expand...
The details are not really important & you don't need to understand all the pseudo xml I posted above.
It was only meant to illustrate how the xml job list could look like if I were to implement a feature to enable syscall calling & data storage/allocation/deallocation to give XML writers direct access to the system. Nothing more.
Using such a feature might be difficult for you at first but with proper guidance from Aldo & I, I believe you would thrive on this in no time!

Regarding that brainstormed list of things you would like to see, they are all feasible. Half of them are very easy to make actually, the other half require a bit more work. I will consider them all.
 
Last edited:
aldostools said:
It's really nice to have a tool like that. It's very useful.

IMHO the XML syntax looks organized but very hard to read. I would prefer a scripting language syntax.
It could be a simple sequential line parser. It does not require to be a full script with structured logic or variables. That would be a plus.

For instance this is easier to read:
var[1] = (char)"hello";
var[2] = (size_t)0;
syscall(403, 1, var[0], 12, var[1]);
notify("written length = 0x%X", var[1]);

BTW could you add an option to auto-enable DLNA media server on start up or maybe make a standalone sprx for it?
Here is the post by DeViL303 about this topic:
https://www.psx-place.com/threads/cant-see-ps3-photo-gallery-on-my-cfw-ps3.2787/#post-282241
Click to expand...
I agree, scripting is definitely better for sure from a user perspective, the thing being do I really want to go the extra mile for this feature?
I may just keep it the way it is now & simply add more job types...

For DLNA, the toggle is already included in CFW Settings however how could we apply it automatically at boot using xai_plugin?
xai_plugin is not meant to be loaded with boot_plugins.txt so unless we could find a way to run a module_action automatically on boot, other workarounds would need to be found. What do you think?
A separate plugin just for DLNA auto enabling is not ideal but it is easily done, I can make that for you if you wish.
It could be added to wMM too.
 
Last edited:
bguerville said:
I agree, scripting is definitely better for sure from a user perspective, the thing being do I really want to go the extra mile for this feature?
I may just keep it the way it is now & simply add more job types...

For DLNA, the toggle is already included in CFW Settings however how could we apply it automatically at boot using xai_plugin?
xai_plugin is not meant to be loaded with boot_plugins.txt so unless we could find a way to run a module_action automatically on boot, other workarounds would need to be found. What do you think?
A separate plugin just for DLNA auto enabling is not ideal but it is easily done, I can make that for you if you wish.
It could be added to wMM too.
Click to expand...

About the scripting, I'd prefer to listing DeViL303's feedback since he has been using xai_plugin.

About auto-enable DLNA I think the easier way to achieve this is with a standalone plugin that can be added to boot_plugins.txt or called from webMAN on demand.

I was trying to add the toggle_dlna to wMM, but my implementation didn't work and the XMB freeze if I enter to any setting option after call the function. So it would be great if you could make one standalone sprx.

//////////// Toggle DLNA /////////////
#define xregistry xsetting_D0261D72
static uint8_t* (*paf_AF58E756)(void);
static int (*paf_350B4536)(void *job, int(*handler1)(void), void * param1, int r6, int r7, uint8_t(*handler2)(void));
static int handler1_enabled(void)
{
return vshmain_5F5729FB(0xC);
}
static int handler1_disabled(void)
{
return vshmain_74A54CBF(0xC);
}
static uint8_t handler2(void)
{
return paf_AF58E756()[0x3C];
}
static int Job_start(void *job, int(*handler1)(void), void * param1, int r6, int r7, uint8_t(*handler2)(void))
{
paf_AF58E756 = getNIDfunc("paf", 0xAF58E756, 0);
paf_350B4536 = getNIDfunc("paf", 0x350B4536, 0);
return paf_350B4536(job, handler1, param1, r6, r7, handler2);
}
static void toggle_dlna(int dlna)
{
if(dlna >= 2)
{
xregistry()->loadRegistryIntValue(0x72, &dlna); dlna ^= 1; // toggle setting
}
int ret = xregistry()->saveRegistryIntValue(0x72, dlna);
if (ret == CELL_OK)
{
Job_start(0, dlna ? handler1_enabled : handler1_disabled, 0, -1, -1, handler2);
if(get_explore_interface())
{
exec_xmb_command2("reload_category %s", "photo");
exec_xmb_command2("reload_category %s", "music");
exec_xmb_command2("reload_category %s", "video");
}
}
}
 
TBH I can do so much already with just copy and rename etc. Most of what I will say here is probably simple enough and will be already possible in the new xai, but I will explain where I run into problems with the current extended xai POC as maybe it will help.

One thing is that I do a lot of toggles and with the current system I need to have one option for enable, and one for disable. If I could have a command that alternated between 2 options it would be nicer as then each option could just have one xmb icon. I can currently do the alternating thing with xml swaps that actually change what each option does every time it is used, but these have their own issues like an XMB reload is required to use the next option, and then if the user reinstalls CFW, then the xml used no longer makes sense.

For example I can swap the xml for a module action that disables the coldboot logo, to another xml that enables the coldboot logo, but if the user reinstalls CFW after disabling it, then it becomes enabled, but my xml mod still thinks its disabled. So this is why I currently need to have enable and disable options on every toggle.

Other places I run into issues is that I can not mix commands. So sometimes it would be nice to be able to delete one file, while copying another. An example would be enabling the gameboot audio. Enabling it is fine, I can just copy the sprx and ac3 files to resource, but when I am disabling it I can only copy the original sprx back over, so the ac3 files are left in place and unused. If I could mix commands then I could do it in a cleaner way by copying the original sprx over, and deleting the ac3 files all in one operation.

If possible I would also like the ability to interact with every xregistry setting via xai and xmbml, it's mostly debug settings I would like to mess with as some of those work on CEX CFW with xregistry mods alone. I would maybe even like to experiment with recreating the entire settings category in normal xmbml, this would allow it to be customized easily with CFW related settings added to it. Might not be possible though.

Then some simple conditional based operations, like if this file exists, then do this operation, but if it does not exist, then do this other operation. Or if this xreg value is set to this , then do that, otherwise do this instead. That kind of thing.

Not sure if this would be doable, but modifying qrc files on the console would be really nice too. This would require the first 8 bytes of the qrc to be removed, then the qrc needs to be decompressed with zlib, then we could patch values in HEX, ideally with a "find and replace" type system, but if that is not possible or easy then the ability to apply hardcoded patches at specific offsets would be great too. Then compress with zlib and put the 8 byte header back on.

This would allow unlimited patching of things like the wave colors, wave speed, background colors, wave type etc etc.
 
Last edited:
DeViL303 said:
TBH I can do so much already with just copy and rename etc. Most of what I will say here is probably simple enough and will be already possible in the new xai, but I will explain where I run into problems with the current extended xai POC as maybe it will help.

One thing is that I do a lot of toggles and with the current system I need to have one option for enable, and one for disable. If I could have a command that alternated between 2 options it would be nicer as then each option could just have one xmb icon. I can currently do the alternating thing with xml swaps that actually change what each option does every time it is used, but these have their own issues like an XMB reload is required to use the next option, and then if the user reinstalls CFW, then the xml used no longer makes sense.

For example I can swap the xml for a module action that disables the coldboot logo, to another xml that enables the coldboot logo, but if the user reinstalls CFW after disabling it, then it becomes enabled, but my xml mod still thinks its disabled. So this is why I currently need to have enable and disable options on every toggle.

Other places I run into issues is that I can not mix commands. So sometimes it would be nice to be able to delete one file, while copying another. An example would be enabling the gameboot audio. Enabling it is fine, I can just copy the sprx and ac3 files to resource, but when I am disabling it I can only copy the original sprx back over, so the ac3 files are left in place and unused. If I could mix commands then I could do it in a cleaner way by copying the original sprx over, and deleting the ac3 files all in one operation.

If possible I would also like the ability to interact with every xregistry setting via xai and xmbml, it's mostly debug settings I would like to mess with as some of those work on CEX CFW with xregistry mods alone. I would maybe even like to experiment with recreating the entire settings category in normal xmbml, this would allow it to be customized easily with CFW related settings added to it. Might not be possible though.

Then some simple conditional based operations, like if this file exists, then do this operation, but if it does not exist, then do this other operation. Or if this xreg value is set to this , then do that, otherwise do this instead. That kind of thing.

Not sure if this would be doable, but modifying qrc files on the console would be really nice too. This would require the first 8 bytes of the qrc to be removed, then the qrc needs to be decompressed with zlib, then we could patch values in HEX, ideally with a "find and replace" type system, but if that is not possible or easy then the ability to apply hardcoded patches at specific offsets would be great too. Then compress with zlib and put the 8 byte header back on.

This would allow unlimited patching of things like the wave colors, wave speed, background colors, wave type etc etc.
Click to expand...
The various "problems" you described here are fundamentally the reason why I started to consider giving you access to syscalls, exports & mem allocation.
The best way to address situations where programming is needed like for instance an if clause (if value of A is equal to value of B, do X otherwise do Y) would be to give you the ability to program basic code snippets in module action.
For instance, test whether a file exists & depending on the result do X or Y.
Or obtain a registry value & according to that value, do X or Y.

I admit that for my idea to be used, one would need some basic knowledge of certain programming features such as pointers, structures etc.. However in your case, you have been meddling around this stuff for years now & whether you believe it or not, you are in a good place to go deeper without too much bother, all you would need is guidance & a bit of reading.

Introducing a scripting engine so that xai_plugin could interpret a custom scripting language rather than xml tags that would definitely complicate the form, would be great but that's a lot more work than I bargained for when I reopened this project. At this stage I dunno whether to launch into this, xai_plugin is only one of many things I need to complete my project & none of this scripting stuff was part of the plan.
I think I am going to stick to the original plan & might consider this feature at a later time.

Without giving you access to some level of programming, it won't be possible to give you freedom of testing what you want & act according to the result.
I may be able to make new job types that could test whether a file exists or a reg value is equal/lower/higher than a reference & then have 2 possible outcomes. It won't be pretty & it will be limited but it may be enough for your most basic needs.
I will think about it & let you know.
 
Last edited:
That's all cool and sounds good. TBH the xreg stuff would just be nice to play with, but not that important. The "if X file exists then do Y" type stuff would be more useful to me, and the ability to mix commands in one operation. Those would be top of my list really. This will allow me to use files as flags, this would allow me to know if FW has been reinstalled since the last operation was done and stuff like that.

Maybe a swap file command too. Although I guess if I can mix operations and do more than 3 at a time I do not need a swap file command really, I can move the destination file to a temporary location, then move the new file over, then move the original file back to where the new file was.
 
Last edited:
DeViL303 said:
That's all cool and sounds good. TBH the xreg stuff would just be nice to play with, but not that important. The "if X file exists then do Y" type stuff would be more useful to me, and the ability to mix commands in one operation. Those would be top of my list really. This will allow me to use files as flags, this would allow me to know if FW has been reinstalled since the last operation was done and stuff like that.
Click to expand...
I had a few hours free last night so I thought about your request & I implemented 5 new job types for conditional branching.
1. If file exists do X otherwise do Y
2. If folder exists do X otherwise do Y
3. If symlink exists do X otherwise do Y
4. If any type of fs entry exists do X otherwise do Y
5. If Xregistry value is equal/not equal/lower than/bigger than then do X otherwise do Y

In each case, the X or Y branching can contain an "unlimited" amount of jobs & conditional jobs can be used recursively too, I mean you can use conditional branching within a branch within a branch etc...
The core of the code is working very well on PC but the full implementation is still untested on ps3 atm. For the filesystem related conditional branching, the implementation is straightforward & I don't expect any surprises however for the Xregistry stuff, according to the wiki, there are 3 possible output types for Xregistry value, 32bit integer, strings & boolean (0 or 1). I wrote the implementation based on the data I got from the wiki but I made assumptions along the way that may turn out to be wrong. I have used this Xregistry stuff before for specific reasons, I knew what to expect from the query but I never looked into how the other possible value types are handled. In short, I need to get more familiar with the registry reading process & possibly tweak the code if required.

To illustrate, here is an incomplete sample of a standard job list, no external xml & no branching to keep things simple.
Code: 
<jobs>
<job category='fs' type='mount' path='/dev_blind' partition='blahblah' partitiontype='blahblah' />
<job category='fs' type='copy' src='/dev_hdd0/test.xml' dest='/dev_blind/test.xml' overwrite='true' removesrc='false' />
<job category='system' type='soft_reboot' />
</jobs>
No need to tell you what the sample is supposed to do, it's self explanatory.

Here is what it looks like if you add conditional branching to the mix. This sample checks whether boot_plugins.txt exists, if it does all the jobs corresponding to the children nodes marked branch X are executed sequentially otherwise the ones marked branch Y are instead.

Code: 
<jobs>
<job category='conditional' type='file_exists' path='/dev_hdd0/boot_plugins.txt' branchX='true' >
<job branch='X' category='fs' type='mount' path='/dev_blind' partition='blahblah' partitiontype='blahblah' />
<job branch='X'  category='fs' type='copy' src='/dev_hdd0/test.xml' dest='/dev_blind/test.xml' overwrite='true' removesrc='false' />
<job branch='X' category='system' type='soft_reboot' />
<job branch='Y' category='system' type='notify' icon='3' msg='whatever message to notify' />
</job>

</jobs>
The attribute branchX='true' of the conditional job specifies that if the file_exists call succeeds, then branch X is the branch to be executed. If it had been branchX='false', when the file_exists call succeeds, then branch Y would be the branch to be executed. If the attribute is omitted, the implementation will use branchX='true' by default.

And like I said before, in a job marked branch X or Y you could add another conditional job with its own branching of jobs as children nodes etc...


DeViL303 said:
Maybe a swap file command too. Although I guess if I can mix operations and do more than 3 at a time I do not need a swap file command really, I can move the destination file to a temporary location, then move the new file over, then move the original file back to where the new file was.
Click to expand...
That's basically what the job list system is for. Jobs are building blocks that you can assemble in a list using XML hierarchy. That is why I stuck to the idea of making only the most basic job types like copy file, mkdir, delete, copy folder etc..
The conditional branching jobs obviously gives the implementation a bit more flexibility & the ability to make job lists more "dynamic".

And if you are worried about the size of the "category" system xml files in order to make complex job lists, all that xml can be externalised in separate files.

Of course, it's always possible to add new job types to the implementation that would do the tasks of 2, 3 or more existing jobs. For instance, one could create a swap file job to avoid having to write the XML to describe 2 file move jobs + 2 file rename jobs.
A move job job is a copy job with the attribute to specify whether to delete the source folder/file after successful copying.

Note:
All this xai stuff is unrelated to link.xml & should maybe be moved somewhere else..
 
Last edited:
That is truly amazing, it looks super easy to understand and use, and great features. I really couldn't ask for much more..

Well maybe a couple of small things :) One thing would be patching RAM in HEX using offset and patch fields. Ideally with ability to search a specific area and replace values. Would something like that be doable? The other would be remapping files.
 
DeViL303 said:
That is truly amazing, it looks super easy to understand and use, and great features. I really couldn't ask for much more..

Well maybe a couple of small things :) One thing would be patching RAM in HEX using offset and patch fields. Ideally with ability to search a specific area and replace values. Would something like that be doable? The other would be remapping files.
Click to expand...

Patching the memory (userland or kernel or hypervisor) is easy & creating a job type for that is no problem however keep in mind that not everything is patchable in a "permanent" kinda way, stuff like modules get loaded & unloaded automatically on request.
For those any patching should be done with Cobra using the module loading hook.
It would be great to be able to add module hooks at runtime using xai but that would most likely require making changes to Cobra stage2 which I am not sure I want to get into at this time.

As to file remappings, I am not 100% sure what you mean, I guess you are talking about the Cobra remappings, if so, yes I could add a new job type for it but the original Cobra limitations will remain.
 
Last edited:
That's ok, even temporary RAM patches would have some uses. With the file remapping I understand, that could also be useful.
 
@DeViL303
@aldostools

I am currently working on the hashing functionalities I planned for xai_plugin.
I added support for md5/sha1/sha224/sha256/sha384 & sha512 hashing.
I wrote a hasher class that can hash strings, buffers of data or files & return a string containing the calculated hash.
Unfortunately, I wasn't able to use the more efficient SPURS based hashing library as originally planned. I tried to but I cannot manage to link the hashing spurs libraries because they reference 3 libc (standard C library) function stub entries that are not valid in the case of a vsh module.
Standard C library functions are at the very core of C & C++ programming so issues with this libc library have been a recurrent pain in the ass for xai_plugin (and other vsh prx module projects) development, always having to try work around it, sometimes with success, sometimes without.
Anyway, hashing will have to be done on PPU for now as I cannot be bothered trying to look deeper into the problem to solve it.

I am telling you about this hashing feature because I wanted to ask your opinion. Would it be useful to have a new conditional job based on (file?) hashing results? What do you think? Worth the time investment?

I also started to add functions for memory patching (lv1/lv2/userland), peek poke functions basically but a little more elaborate. It made me wonder about the same thing as for hashing, whether it would be worth making a conditional job based on the value returned by a memory peek.
That would be a useful feature to have of course but again, is it worth the time investment? Would you use it?
 
Last edited:
It sounds awesome, It actually would be worth it I would say with the jobs based on hashes as it would be safer than just checking if a file exists. But that is easy for me to say and I do not know the time and work involved in something like that. With the job based on peeking, I have only just got into dumping RAM and patching it recently with these new per emulator gameboot animations. I can't think of ways I would use something like that right now but it does sound really interesting and like something I could get into if the option was there.
 
@aldostools

Do you know what the rationale is for the usage of sysPrxForUser functions over exported vsh equivalents libc functions?
sys_malloc, sys_printf etc..
First of all, are those really just duplicates? Or do they action extra locks, thread safety or whatever?

I could not find any info about this stuff anywhere. When I look at vsh module disassemblies, it's unclear what the rules are, a vsh module often uses both function types, they may use say memcpy from vsh exports but sys_memset from sysPrxForUser, or even use both duplicates like memcpy & sys_memcpy.
If I take game_ext_plugin.sprx, it uses the allocator exports for the C++ operators like new & delete but at the same time it also uses sys_malloc & sys_free from sysPrxForUser.

Obviously, I am missing something here, can you enlighten me?
 
You must log in or register to reply here.

Similar threads

Back
Top