[K42-discussion] What is the correct version of gcc, glibc, binutils, linux and linuxthreads required for a successful K42 build ?

[Orran Y Krieger]

"Elvis John Dowson" <elvis_dowson at hotmail.com> wrote on 12/20/2005 
01:04:21 PM:

> Hi Orran,
>                  Oh, I get the picture now. When you mention the use
> of virtual function tables and IDL, am I correct in guess that you 
> have attempted to create a sort of fast, binary level specification,
> similar to COM and CORBA, to facilitate RPC like calls for remote 
> method invocation, within the operating system environment and 
> achieve location transparency for all the software components in 
thesystem ? 
> 
> And for some reason, the glue logic is not portable across compiler 
> versions ? 

In a sense. We are not striving for location transparency.  We are 
striving to automatically generate all the marshalling/demarshallign code 
as well as all the security checking code in the target.  That way we can 
introduce new objects, and have them export their interface to 
applications.  If you look at a traditional OS, there is a very limited 
number of system calls.  In K42 you decorate methods you want exported 
from an object and run the same header file as you use for your object 
definition in the kernel (or servers) and the stub object that clients can 
invoke is automatically generated.  To get this to work, the stub compiler 
has to know how the virtual function table is layed out... which is 
specific to each compiler version. 


> Now, I?ll take your word for it and download the binary only version
> of the toolchain and attempt to build the K42 sources.

great!
 
> Here is my overall plan and some of the tasks I would like to 
> complete within a time frame of one year :
> 
> 1. To develop a CBE UML Profile for the IBM Cell Broadband 
> Processor, to support full automatic code generation from real-time 
> UML models, with support for target based animation and debugging of
> the UML models from the host. I should have some preliminary 
> documents and example ready before the end of February 2006. 
> 2. Porting of the K42 OS to the CBE platform, first onto the 
> simulator, and then running it on an actual CBE Blade Platform, when
> it becomes available.
> 3. Adapting the CBE UML Profile and enhancing it to support K42 OS 
> specific optimizations, to primarily facilitate dynamic 
> addition/management of CBE processing units, for large 
computationalclusters. 

I don't actually know anything about UML, although getting K42 on Cell 
would be cool.  I don't really understand why the primary thing you are 
focused on, i.e., having a way to generate SPU code from UML really 
relates to K42.  I don't object, mind you, for people to use K42, I love 
it, but I hate to add pure overhead to your primary goal?
 
> I haven?t estimated the effort for points 2 & 3, but I will spend 
> some time with the K42 sources, after I complete the first step. I 
> need to be sure, if I can do the work for points 2 and 3, and if so,
> the effort involved, etc, and possibly get some more people to join 
> in the effort, to cut down the time required to complete steps 2 and 3.
> 
> So, to summarize, I will attempt to use the binary versions of the 
> K42 toolchain and then attempt a K42 OS build and then visit tasks 2
> & 3, by the end of February 2006, to determine if its something that
> I should be getting into, based on the effort, resource availability
> in terms of people actually willing to participate in this effort 
> and the final schedule assessment.
> 
> Best regards,
> 
> Elvis John Dowson
> 
> 
> From: Orran Y Krieger [mailto:okrieg at us.ibm.com] 
> Sent: Tuesday, December 20, 2005 10:40 PM
> To: Elvis John Dowson
> Cc: 'Andrew Baumann'; 'Jimi Xenidis'; k42-discussion at ozlabs.org; 
> k42-discussion-bounces at ozlabs.org; 'Andrew Baumann'; 'Jimi Xenidis';
> k42-discussion at ozlabs.org; k42-discussion-bounces at ozlabs.org
> Subject: RE: [K42-discussion] What is the correct version of gcc, 
> glibc, binutils, linux and linuxthreads required for a successful K42 
build ?
> 
> 
> Elvis, 
> 
> There is perhaps some confusion here.  K42 is intimate with a 
> particular toolchain version (e.g., we know how virtual function 
> tables are laid out for our stub compiler), and that toolchain has 
> to be built a specific way to be able to build K42.   Its a pretty 
> major project to build the toolchain, its got nothing whatsoever to 
> do with building the K42 kernel, and most people that want to hack 
> on K42 want to know nothing about building the toolchain.  Once you 
> have the toolchain, building K42 is relatively straightforward.   We
> have tried to do a reasonable job of documenting how to build K42 
> itself.   If you want to work/play on the OS, really the best bet 
> today is to just use the binary version of the toolchain that is 
> distributed at UNM and Toronto.   If you want to build your own 
> version... its digging into a big pit. 
> 
> Unfortunately, the toolchain problem is agrevated by the fact that 
> we are locked into an older version of the toolchain.  With more 
> recent vesions the kind of scripts that the Cell guys use would work
> for us as well.  Someone at the university of new mexico agreed a 
> while back to work on upgrading us to a new version of the 
> toolchain, but have not heard anything about that recently?  Any 
> progress on this guys? 
> 
>          -- Orran 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20051220/bfd1951f/attachment.htm