RE: [line-devel] Hrm.

[Michael C. <mc...@ti...>]

Hi Erik,

I've been looking at the following issues:

1. Fixed an apparent bug in exec which meant command line parameters
weren't being passed properly to exec'd processes.

2. Modified exec to try adding a .exe extension to the filename so that
Linux programs could call Windows programs (or the Cygwin equivalents of
Unix utilities).

3. Prevented cygwin from VirtualAllocing in the lower 1.5GB area of
virtual memory. My executable wouldn't load because it need to mmap at
an absolute address which was stolen by Cygwin's initial VirtualAllocs.
The method I used was to call VirtualAlloc to reserve the memory before
the Cygwin DLL was fully initialized, forcing Cygwin to use a higher
address. Once in mmap_setup, this reserved memory is freed for use by
LINE.

4. Tried to maximize the amount of (contiguous) virtual memory space
available to the Linux programs. This opened up a can of worms - you
can't really control where cygwin1.dll will get loaded... I tried quite
a few schemes. Basically, if Cygwin has already been loaded before LINE
runs, you have to use the address it was already loaded at. Cygwin has
what appears to be a fairly broken scheme of allocating memory directly
after the end of where the DLL was loaded, which is very difficult to
avoid being right on top of another DLL if you try to squeeze the memory
map.

5. Added support for detecting and utilizing 4GB tuning. This gives the
Linux program an extra 1GB more virtual address space when running under
Windows 2000 Advanced Server with the /3GB boot.ini setting enabled.

6. Commented back in a few of the syscalls which #ifdef'ed out in LINE
0.5 and hacked in support for l_times.

7. Cygwin seems to number some of its signals differently to Linux (e.g
SIGCHLD). I failed to get a remapping layer in the system call handling
code to work - I never got one of my programs that relied on SIGCHLD
working.

8. rt_ signal syscalls aren't fully supported. I didn't get around to
seeing what changes needed, but I noticed that the Cygwin DLL has a
compile time option to enable them.

9. Doesn't support IPC... I tried and failed to use some IPC code
already available for Cygwin.

10. Made a few cosmetic changes to make LINE less verbose.

A bit of background - most of my work involves running Windows programs.
One of these programs is now only supported under Linux and no longer
under Windows, so my aim was to get it working under LINE to avoid
rebooting my computer all day long. In all, I got around 90% of the way
there - most of the features work perfectly under LINE. In the end, I
bit the bullet and started running it under Linux itself... I soon
discovered that Linux's VM was (and pretty much still is) broken (both
Rik's and Andrea's, both in different ways). Programs that ran perfectly
well under LINE struggled on the same machine under Linux, taking
several times longer to execute. In the end I topped up the machine to
4GB of memory. Now the only problems I'm getting are intermittent kernel
oopses and strange lockups, which I'm working on. Bring back the BSOD,
all is forgiven!

I didn't see any problems with the 64k page boundary limitation in LINE;
I only saw mmaps being made to the same file within any given 64k page,
which works in LINE by virtue of all of its rounding up and down of
pointers in mmap.c.

Hope this helps,

Michael.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of Erik
Paulson
Sent: 03 December 2001 16:14
To: lin...@li...
Subject: Re: [line-devel] Hrm.


On Fri, Nov 30, 2001 at 10:32:23PM -0000, Michael Clarke wrote:
> 
> Hi Erik,
> 
> I am... I've made quite a few modifications of my own in order to get
> program to working with LINE... I guess I should have got them into 
> the source tree somehow.

Michael, 
	What have you been working on?

Like 8 months ago, I promised to look into NtMapViewOfSection. Well,
Friday I finally did, and like the book says, it can mmap() on
page-boundries, and not just 64K boundries. I've been reading the LINE
mmap.c code, and I'm 
starting to understand what it's doing. 

Hopefully later next week, when I get back from San Diego,  I'll have a
patch 
that ditches the cygwin mmap() and lets LINE manage it internally.  

I'll also probably have to redo a lot of the memory management stuff -
it looks like memory is managed with a big array, with one byte per 64K
chunk. Maybe it's time to steal the page table code out of Linux...

-Erik
 

_______________________________________________
line-devel mailing list
lin...@li...
https://lists.sourceforge.net/lists/listinfo/line-devel