On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
> Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline
On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote:
> On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote:
> > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote:
>
> > > Exactly. However, there are situations when you have only two options:
> > > rewrite from scratch or use -taso. Netscape vs.
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote:
> DU seems to map as low as possible, it would seem.
Yes, I've just checked, starting at 64K...
> Maybe we could just
> do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE
> appropriately?
No. I've changed in
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote:
> On Thu, 7 Jun 2001, Ivan Kokshaysky wrote:
> > Exactly. However, there are situations when you have only two options:
> > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-)
>
> Why can't mozilla be
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote:
On Thu, 7 Jun 2001, Ivan Kokshaysky wrote:
Exactly. However, there are situations when you have only two options:
rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-)
Why can't mozilla be fixed?
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote:
On Thu, 7 Jun 2001, Ivan Kokshaysky wrote:
Exactly. However, there are situations when you have only two options:
rewrite from scratch or use -taso. Netscape vs. mozilla is a
On Thu, Jun 07, 2001 at 08:28:04PM +0200, Maciej W. Rozycki wrote:
DU seems to map as low as possible, it would seem.
Yes, I've just checked, starting at 64K...
Maybe we could just
do the same for OSF/1 binaries by setting TASK_UNMAPPED_BASE
appropriately?
No. I've changed in
On Wed, 6 Jun 2001, Jeff Garzik wrote:
> There are two things you can do here, one is easy: use linker tricks to
> make sure that an application built on alpha -- with 64-bit pointers --
> uses no more than the lower 32 bits of each pointer for addressing.
> This should fix a ton of
On Wed, 6 Jun 2001, Jeff Garzik wrote:
There are two things you can do here, one is easy: use linker tricks to
make sure that an application built on alpha -- with 64-bit pointers --
uses no more than the lower 32 bits of each pointer for addressing.
This should fix a ton of applications
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
> Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address > TASK_UNMAPPED_BASE.
What do you think about following?
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address TASK_UNMAPPED_BASE.
What do you think about following?
12 matches
Mail list logo
