Re: [patch 6/6] PS3: Add os-area database routines

["Ranulf Doswell" <ralf@ranulf.net>]

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On 08/10/2007, Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>
> > How do we go about claiming one of these OS_AREA_DB_OWNER_ keys? I'd
> > very much like to use this functionality in my python-ps3 games library.
>
> It sounds like you should be storing your info in the file system like
> all other applications do.


I'd agree that for large amounts of application specific data, the
filesystem is the correct approach.

However, in this case the only data required is a single identifier used to
identify one PS3 from another, and in fact this single 64-bit token can be
shared amongst many other applications that require the same function -
certainly I intend to expose it in a common way in my games library's API
for all users of the library.

In my particular case, my bootable CD image does not have any other use for
a filesystem on disk beyond the initrd image on the CD-ROM; this is
important because some PS3s may be formatted as 100% GameOS. All that is
needed is to write the standard kboot image to flash so that it is able to
bootstrap the CD image.

As the PS3 has flash available and you are adding a mechanism for storing
very small bits of data in the flash, it seems silly not to use it and
attempt instead to write my own incompatible database format to store this
in the flash memory. Your database also has the added protection of not
being overwritten when the loader is re-flashed, as it is protected by the
kernel.

If you agree in principle that one of these identifiers can be allocated to
this purpose, I'm happy to write and submit a patch that exposes the get/set
system ID functionality to userland, whilst internally using your database.
This could also allow for some of the bits to be used as check bits to
ensure data validity.

Possibly there already exists a way to obtain a hash of the serial number or
some other unique identifying token via one of the undocumented hypervisor
calls, but as I'm not privvy to that kind of information I need to roll my
own mechanism for doing this.

Ralf.

[-- Attachment #2: Type: text/html, Size: 2478 bytes --]