From jrh29 at alumni.cwru.edu  Sat Aug 19 11:53:18 2006
From: jrh29 at alumni.cwru.edu (Justin Hibbits)
Date: Sat, 19 Aug 2006 11:53:18 -0400
Subject: Request to increase the size of the SystemRequest structure
Message-ID: <5BA00FAD-BC36-404D-AF91-6C41C8CA8C76@alumni.cwru.edu>

Been looking at the system interfaces for LSD, and I've concluded  
that there are some system requests, namely commit, that require more  
than 64-bytes to account for both the payload and bookkeeping.  Thus,  
I recommend we increase the length to 128 bytes. I know we have the  
extra payload option, but I'm not certain how much trouble that will  
be.  This method keeps as much inline as possible, and still offers  
32 system requests possible at once, which is far more than can be  
generated at any given time (time slice doesn't really allow for much  
more than 8 requests, from what I can tell, given the speed of an x86  
CPU).

Also, today I came upon an optimization that would would also  
simplify things a great deal, and that requires embedding a function  
callback and arbitrary data (in this case 2 pointers) into the  
request structure (extra payload).

Currently the userspace system is designed only for objective-C,  
which completely removes any chance for using straight C as  
callbacks, unless wrapped in objective-C wrappers.  This optimization  
and simplification is greatly desirable, for James and the system  
runtime environment.

Thoughts?

- Justin


From adam at fsl.cs.sunysb.edu  Tue Aug 22 22:44:02 2006
From: adam at fsl.cs.sunysb.edu (Adam Martin)
Date: Tue, 22 Aug 2006 22:44:02 -0400
Subject: [lsd-devel] Request to increase the size of the SystemRequest
 structure
In-Reply-To: <5BA00FAD-BC36-404D-AF91-6C41C8CA8C76@alumni.cwru.edu>
References: <5BA00FAD-BC36-404D-AF91-6C41C8CA8C76@alumni.cwru.edu>
Message-ID: <51c5e5b6506b3aa6ab9d4f5d8bf9e861@fsl.cs.sunysb.edu>


On 2006 Aug 19 , at 11:53, Justin Hibbits wrote:

> Been looking at the system interfaces for LSD, and I've concluded that 
> there are some system requests, namely commit, that require more than 
> 64-bytes to account for both the payload and bookkeeping.  Thus, I 
> recommend we increase the length to 128 bytes. I know we have the 
> extra payload option, but I'm not certain how much trouble that will 
> be.  This method keeps as much inline as possible, and still offers 32 
> system requests possible at once, which is far more than can be 
> generated at any given time (time slice doesn't really allow for much 
> more than 8 requests, from what I can tell, given the speed of an x86 
> CPU).

	This is fine.  With this, we should perhaps remove the extended 
payload option.  That extension was causing me much ire anyhow.


> Also, today I came upon an optimization that would would also simplify 
> things a great deal, and that requires embedding a function callback 
> and arbitrary data (in this case 2 pointers) into the request 
> structure (extra payload).

	Well, that's up to you.  You can use payload data as anything you 
want.  If you like, we can make an option for systemcalls which return 
some kind of user-defined data.  This sounds reasonable.

> Currently the userspace system is designed only for objective-C, which 
> completely removes any chance for using straight C as callbacks, 
> unless wrapped in objective-C wrappers.  This optimization and 
> simplification is greatly desirable, for James and the system runtime 
> environment.

	How is the proposal above, for that idea?

Regards,

--
Adam David Alan Martin