Re: XBOX Linux Parralel project

David Pye <[email protected]> Sat, 11 Dec 2004 14:15:37 +0000
Newsgroups gmane.linux.ports.xbox.devel
Message-ID <[email protected]>
On Saturday 11 December 2004 13:34, Karim Liman-Tinguiri wrote:
> Greetings,
>
> I'm a developer interested in launching an alternative to the OpenXDK
> project while using Linux.
>
> My goal is to create a compiling toolchain that would create a single XBE
> file with (a slightly modified version of) Xromwell inside + (towards the
> end of the file) a minimum filesystem, a kernel and X (no need for a
> complete windows manager, just graphic card support; i know there's no
> accelerated drvier yet).

You know that xbeboot already lets you link kernel+initrd into itself, to 
produce a single xbe, right?

The reason I ask is because you refer to xromwell, rather than xbeboot.
In addition, because xbeboot uses the MS kernel APIs to do things, it's 
probably more 'xdk-ish'.  

> At boot time, the following would occur:
>
>
>    Xromwell boots then copies to ram the file system, the initrd etc stored
> within the XBE Xromwell booted from It gunzips everything and handles
> control over to the kernel
>    the kernel loads X, the extra modules, the drivers etc.
>    It then gives control to the user program.

Yes, that isn't a problem already.  The problem is, imho, the initrd size - as 
it lives entirely in RAM, you run out of memory pretty fast once your 'user 
program' begins to run, as the initrd takes up a fair whack of the available 
RAM.

I'd say it's smarter to have a .dat file bundled with the xbe, which is a 
rootfs, that the kernel can mount as a roofs via loopback. That way, your 
initrd can be far more minimal, and thus reduce loading time, as well as 
available free RAM at runtime.

> The main obstacle I'll have to face within this project is to reduce to the
> minimum possible the XBE overhead (the Xbeboot + the kernel + the
> filesystem + X) for example by compiling the kernel only with XBOX-specific
> supports, using agressive kernel optimization (I'll strip out lot of
> hardware-safe procedures since we know precisely on what hardware the
> program will run), rewriting lots of routines in the drivers for exemple in
> assembly, optimizing X only for the XBOX hardware etc... 

Ick. I think stripping the kernel via compile time options is obviously 
prudent, but I'm not confident that the kernel is a large percentage of your 
overall size. At least, not to the level that you need to hack the source 
directly, for most things anyway.  Not including support for hardware that 
obviously won't be present e.g. ISA bus, is obviously sensible.

 A reasonable general purpose kernel is 1MB or so.  Your initrd with a mini X 
environment will be at least several times that.  Hence my suggestion about 
having a generic xbeboot with kernel+initrd in, that mounts a rootfs ".dat" 
file, and runs a file in a specific location within that rootfs is probably 
more manageable. Plus, it means you only need to provide the tools to 
generate the rootfs, and not waste time building kernel+initrd+xbeboot each 
time.


> That way we could ship small versions of mplayer for example in a single
> small XBE that doesn't need any Linux installed on the box to run since it
> comes packed with it. We could finally have some legal binaries for
> media-players, dashboards (amongst other)...
>
> Sincerly yours,
>
> PS: What I'm looking for are coders, webmasters, documentalists and anybody
> who can help throughout the achievement of this project. I aim to have it
> run in parallel with the xbox-linux project. It could be called for example
> the LinuXDK - or LinXDK to show it's really binded with Xbox-Linux.

Good luck - I'm sure you'll find a few people around that would be interested 
in such a project.

Cheers,

David

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s-: a-- C++ UL++++ P L+++ E--- W++ N+ o+ K- w---
O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+
G+ e++ h--- r++ y++
------END GEEK CODE BLOCK------


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/