[uml-devel] Re: [uml-user] filemap feature 2.4.19-46um

[Steve S. <ste...@ho...>]

jd...@ka... wrote:
> > Patch #2 modifies the create_mem_file() routine to support 'vm' 
>filemaps.
>
>The jump around the make_tempfile call is rather strange.

I didn't want to cloud the intent of the patches with changes in whitespace 
(that an if/else wrapper would have done by creating lots of indenting 
noise).

> > Patch #3 does some house-cleaning to UML in preparation for 'file' 
>filemaps.
>
>This can go in independently of everything, and probably will.  I don't 
>like
>the uml_stat thing.

Sorry, a necessary evil. :)  At least until that magical abstraction layer 
is fleshed out.

>If we're going to have a OS abstraction layer, you have
>to be able to ask it higher-level questions, like "how big is this file?" 
>and
>"can I write this file?".  These are pretty OS-independent questions.

Could you explain this more?  I don't understand how an abstraction layer 
ties together across different platforms.  Take a hypothetical abstracted 
function like um_size_file("filename") (and the companion function 
um_size_fd(fd)).  What does um_size_file() do?  Is it a wrapper for 
os_size_file()?  If so, what work is being accomplished by not calling 
os_size_file() directly?   Does um_size_file() call os_stat_file() and parse 
the returned struct?  If so, does os-Windows/file.c emulate the stat() call?

> > Patch #4 modifies os-Linux/file.c to support 'file' filemaps.
>
>I'm not going to accept this.  I want filemap above the OS layer, not 
>inside
>it.

I'd disagree especially since there is no layer currently above the OS layer 
for me to put it in. :)   But I could argue that filemapping is an 
os-centric feature and filemap.c *should* live in os-Linux.  For example, I 
am sure, filemapping file descriptors is pointless in a chroot-less Windows 
environment.  Hmmm, actually, an os-Windows version of filemapping might be 
useful if it did this:

   filemap=xlate,C:\request.dat,D:\uml\returned.dat

in otherwords, on that OS, filemap is tailored to map fileNAMES around.

>You can either redo this part of it, or I will when I merge it.  Feel
>free to change my mind on this, but the last round of argumentation was
>unconclusive and came down to a matter of taste.  And on matters of taste,
>I win, because the main UML source pool is on my laptop, not yours :-)

No argument there:  you write the abstraction layer, you merge the code, you 
fix the bugs - works for me. :)

>I also don't like the dup-ing of file descriptors, because it's 
>unnecessary,
>and so is a waste of resources.

Another necessary evil until there is an IO abstraction layer.  As it 
stands, here's a frightful scenario if you don't use dup(): a wayward use of 
the system close() call (and there are many instances of close() in UML that 
have yet to be wrapped) on a filemapped fd could result in that fd being 
reused by the system.  Filemap would continue to hand out the stale fd, not 
knowing it has been closed and reopened, and now points to some other file.  
I shudder to think the mess that could cause.

Steve Schmidtke

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus