Experimental OS development using D

[BCS]

Harry Vennik wrote:
> BCS wrote:
> 
>>Put the security in stetting up the shared buffers and that should do
>>it I'd think.
>>Read access lets you map it in in a read only page, read/write... etc.
>>
>>One thought I had on this issue is that it allows much of the IO to
>>run without system calls/context switches if the stream access and
>>whatnot is all run as part of the standard system lib. Plus, while you
>>can mess with your stream meta data, it only hoses you.
> 
> 
> I have been thinking that way too, but it is difficult to see how much it really
> prevents context switches. It may just obscure them by having them occur only in
> response to certain events (which may occur regularly), instead of having the
> predictable context switch for every read/write/whatever you do.
> Memory-mapping the file will prevent this, but is costly for bigger files, so this
> needs some thought. Anyway, if a way is found to have a reliable shared-buffer
> implementation that will not compensate its lower number of context switches by
> having more of another unwanted side-effect (e.g. excessive memory usage), than
> that would certainly be the way to go.
> 
> Harry

The appropriate snide response here is "memory is cheap". But I've never 
bought into that one. If the IO system allowed arbitrary mapping of 
memory pages to disk blocks:

sysCallMapPage2Block(int fd, size_t block, void* page, uint count = 1);

this might not be fairly fast as far as the OS side goes.

if(fd.good && fd.size >= block &&
	user.pageCount + count < suer.pageLimit)
	MapPage();

The other side would be totally up to the stdlib ("not your problem" :-)

This would have some other cool effects like use this under malloc (fd 
== -1 indicates blank pages)