Does make aout-to-elf still purport to work from a 2.2.8R system to
a recent (like today's) current?
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
>
> Wednesday, April 14, 1999, 10:25:11 AM, you wrote:
>
> >>I am getting problems similar to those outlined above. I don't run
> >> natd, either, but I do
> >> have a firewall enabled. (open rule) I've had to 'put' files rather than
> >> 'get' them, since my
> >> last build/installworld
Hi,
With respect to the rexec() function: From 'man 3 rexec' on a
-current system I find:
SYNOPSIS
int
rexec(char **ahost, int inport, char *user, char *passwd, char *cmd,
int *fd2p)
DESCRIPTION
This interface is obsoleted by rcmd(3). It is available from the comp
On Thursday, 15 April 1999 at 19:57:39 -0400, Michael E. Mercer wrote:
> Hello,
>
> I just recently installed freebsd 4.0 snap from 19990304.
That's FreeBSD-current, and that's where you should report problems.
I'm following up there.
> I was able to use mtools package here...
>
> Then I cvsup'd
On Apr 14, 4:40pm, Chuck Robey wrote:
} Subject: Re: swap-related problems
} On Wed, 14 Apr 1999, Anthony Kimball wrote:
} > Well, it's only needed if you want to be able to reliably execute ANSI
} > C code according to spec. I personally don't care. I'd be surprised
} > if core didn't though.
On Apr 15, 12:14pm, Peter Jeremy wrote:
} Subject: Re: swap-related problems
} Mikhail Teterin wrote:
} > Worse then that,
} >it may be possible to use it at malloc time, but unless your program
} >runs and touches every page, the memory may not be available later.
}
} If you run and touch every
Just a quick note... I've heard 'vfork' and 'fork' mentioned twice now.
I think there is some confusion. fork() does not really eat that
much memory if all you are doing is fork/exec. The only difference
between fork and vfork from a resource point of view is around 32 KBytes
Hello Tim,
Wednesday, April 14, 1999, 10:25:11 AM, you wrote:
>>I am getting problems similar to those outlined above. I don't run natd,
>> either, but I do
>> have a firewall enabled. (open rule) I've had to 'put' files rather than
>> 'get' them, since my
>> last build/installworld. (Y
:Mmm, that's how they use(d) it then... But can we have a way for an
:admin to control the amount of overcommited memory? Ranging from 0 -- no
:overcommitment to the entire addressable space less the phisical storage
:(the current situation)... And this is different from the per-user class
:limit.
Chuck Robey once wrote:
> This is the part that gets me. You keep claiming ANSI C
> non-compliance, and we are compliant. If you want to claim
> non-compliance, then get out the spec and quote chapter and verse.
> There is nothing in the spec that says how the underlying OS has to
> treat processe
On Thu, 15 Apr 1999, Mikhail Teterin wrote:
> > I think they finally got rid of vswap in later IRIX's after they
> > fixed the core swapping code to 'overcommit'. The reality behind
> > the virtual swap concept w/ IRIX is based on issues with the original
> [...]
>
> Mmm, that's how
Matthew Dillon once wrote:
> :On Irix, each swap area has the following parameter (from swap(1M)):
> :
> : vswap The size the system believes the area can hold. This is
> : always greater than or equal to pswap and maxswap.
> :
> :This way, an administrator can control the amount of overc
Mike Smith once wrote:
> > >A signal handler is not guaranteed to work. It must be written
> > >such that it does not require a new page of memory. Some possible
> > >problems here are the stack growing, writing on a new page in the
> > >data segment, etc.
> >
> > man sigaltstack
> That doesn't
:On Irix, each swap area has the following parameter (from swap(1M)):
:
: vswap The size the system believes the area can hold. This is
: always greater than or equal to pswap and maxswap.
:
:This way, an administrator can control the amount of overcommited
:memory (making it 0 if necce
Mike Smith writes:
> > Jim Bloom wrote:
> > >
> > >A signal handler is not guaranteed to work. It must be written such that
> > >it
> > >does not require a new page of memory. Some possible problems here are the
> > >stack growing, writing on a new page in the data segment, etc.
> >
> > man si
> Jim Bloom wrote:
> >
> >A signal handler is not guaranteed to work. It must be written such that it
> >does not require a new page of memory. Some possible problems here are the
> >stack growing, writing on a new page in the data segment, etc.
>
> man sigaltstack
That doesn't help; there is
On Irix, each swap area has the following parameter (from swap(1M)):
vswap The size the system believes the area can hold. This is
always greater than or equal to pswap and maxswap.
This way, an administrator can control the amount of overcommited
memory (making it 0 if neccessary)
( Sitting in the bleachers )
Ra! Ra! Ra!
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Quoth Daniel C. Sobral on Thu, 15 April:
:
: FreeBSD executes ANSI C code reliably according to spec, as long as
: there is enough memory in the system. If there isn't, FreeBSD
: doesn't run reliably, much less executes any kind of code reliably.
:
I understand this. I concieve the purpose of th
:Hi,
:
:At 20:12 14/04/99 -0700, Matthew Dillon wrote:
:>[dire warning]
:>This patch is currently under test. To use it, undo any previously
:patches
:[etc]
:
:OK, I'll try it out this evening (BST). Does this patch affect client side
:behaviour, server side or both (ie how many machines do I
Jim Bloom wrote:
>
>A signal handler is not guaranteed to work. It must be written such that it
>does not require a new page of memory. Some possible problems here are the
>stack growing, writing on a new page in the data segment, etc.
man sigaltstack
Tony.
--
f.a.n.finch d...@dotat.at f.
On Wed, Apr 14, 1999 at 05:37:37PM -0700, David O'Brien wrote:
> Some have gotten -aout to work. When was your last CVSup and non-a.out
> `make world' ?
Yesterday around 9pm MEST.
--
Jos Backus _/ _/_/_/"Reliability means never
_/
Hi,
At 20:12 14/04/99 -0700, Matthew Dillon wrote:
>[dire warning]
>This patch is currently under test. To use it, undo any previously
patches
[etc]
OK, I'll try it out this evening (BST). Does this patch affect client side
behaviour, server side or both (ie how many machines do I have to ba
Brian Feldman wrote:
>
> mlock()? BTW, why can't anyone explain why the old behavior WAS THAT
> the process would get NULL? Now it's this...
Maybe the login class was changed, and now has no limits, or a high
enough limit that the resources are exhausted.
--
Daniel C. Sobral
Anthony Kimball wrote:
>
> Quoth Poul-Henning Kamp on Wed, 14 April:
> :
> : 1. Demonstrate the need.
>
> Well, it's only needed if you want to be able to reliably execute ANSI
> C code according to spec. I personally don't care. I'd be surprised
> if core didn't though. I would suspect that i
Anthony Kimball wrote:
>
> Quoth Daniel C. Sobral on Thu, 15 April:
> :
> : As soon as this application grabs all the memory, the next thing to
> : request more memory (not a malloc!) will cause the application to be
> : killed (largest application criteria). Change the criteria, and
> : *another*
>> Sorry FreeBSD doesn't support resource reservation for memory.
>
>mlock()? BTW, why can't anyone explain why the old behavior WAS THAT
>the process would get NULL? Now it's this...
Implementation quirks (bugs) and races.
brk(2) used to fail when memory (real+swap) is running short, instead
of
27 matches
Mail list logo
