:>
:> The reason is that rfork(RFMEM) does not give the new process a new
:> stack, so both the old and new processes wind up on the same original
:> stack and stomp all over each other.
:
:There is an implementation of clone() in the linuxthreads port, written by
:Richard Seaman.
:
On Tue, Jan 11, 2000 at 09:56:58PM -0800, Matthew Dillon wrote:
>
> :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> :> memory - current AND FUTURE. You could use minherit() before fork() to
> :> share current memory, but not future memory.
> :
> :BTW, concerning rfo
:> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
:> memory - current AND FUTURE. You could use minherit() before fork() to
:> share current memory, but not future memory.
:
:BTW, concerning rfork(RFMEM). Could somebody explain me, why the
:following simple program is c
In article <1d5c01bf5c42$1409d990$[EMAIL PROTECTED]> you wrote:
> You've got that backwards - fork() and vfork() can easily be implemented in
> terms of rfork() [in fact, I believe all three are implemented in terms of
> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> m
> > So -- does FreeBSD work with RCC chipsets? Is the chipset robust &
> > reliable? We've been badly burned a few times by buggy DEC PCI
> > chipsets & we're hoping to not repeat the experience with an x86 ;-)
>
> It doesn't currently seem to boot with the RCC chipset. I get
> the following:
On Tue, Jan 11, 2000 at 03:23:13PM -0800, Scott Hess wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > A better solution may be to shift to FreeBSD4.0 (when it's released -
> > wait for it to become good and stable), and then use the native
> > linuxthreads port (/usr/ports/devel/
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> A better solution may be to shift to FreeBSD4.0 (when it's released -
> wait for it to become good and stable), and then use the native
> linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD.
After a number of hours hacking around w
Jonathan Lemon writes:
>
> Uh, I didn't say that this was a PowerEdge 2400, just that it's a
> Dell box with a RCC chipset.
If you don't mind me asking, what is it?
> > Can you do me a huge favor & run the lmbench bw_mem_cp benchmark from
> > the lmbench or Hbench-OS benchmark suites ple
On Tue, Jan 11, 2000 at 02:56:51PM -0500, Andrew Gallatin wrote:
> Damn. I was hoping that the Dell docs were something approaching
> correct. The claim is one 7890 & one 7880 on-board.
>
> What is it really? a 7880 & a 7899, or something else?
Uh, I didn't say that this was a PowerEdge 240
A friend of mine pick one up for his home...fbsd 3.3 installed with minimal
effort. He's now married to it, like it's his second wife...:)
Andrew Gallatin wrote:
> We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a
> bit nervous because the 2400 uses a non-Intel server chipse
Jonathan Lemon writes:
> On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote:
> > > It doesn't currently seem to boot with the RCC chipset. I get
> > > the following:
> > >
> > > pci unknown vendor = 0x9005, dev = 0x00cf
> >
> > That's an Adaptec vendor ID. (They've got
On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote:
> On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote:
> > > It doesn't currently seem to boot with the RCC chipset. I get
> > > the following:
> > >
> > > pci unknown vendor = 0x9005, dev = 0x00cf
> >
> > That's an A
On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote:
> > It doesn't currently seem to boot with the RCC chipset. I get
> > the following:
> >
> > pci unknown vendor = 0x9005, dev = 0x00cf
>
> That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not
> sure what d
On Tue, Jan 11, 2000 at 13:31:23 -0600, Jonathan Lemon wrote:
> On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote:
> >
> > We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a
> > bit nervous because the 2400 uses a non-Intel server chipset made by a
> > company call
Recently I discovered a bug in DEVFS which I gonna try to fix. I
have core dump which has been traced and analyzed, so that the
place, where page fault occurs, and the way it came to death is
known. And the only problem left: I have only few bits of
informat
On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote:
>
> We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a
> bit nervous because the 2400 uses a non-Intel server chipset made by a
> company called RCC Reliance.
>
> The chipset is called the "LE-64 ver 3.0". and I
On Tue, Jan 11, 2000 at 12:49:32PM -0600, Richard Seaman, Jr. wrote:
> On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote:
> > The naming
> > approach I'm taking is:
> >
> > fwrite() <-- Alternate entry point that is used externally unless
> >another library ove
On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote:
> I'm working on adding alternate entry points to libc now.
Good.
> The naming
> approach I'm taking is:
>
> fwrite() <-- Alternate entry point that is used externally unless
>another library overrides it.
>
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> It's my impression that glibc uses a three (four?) tiered naming
> convention. The "pure" syscall (in our case, eg. _write()). Then
> there is the version used internally in glibc (eg. _libc_write().
> And finally, the versio
We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a
bit nervous because the 2400 uses a non-Intel server chipset made by a
company called RCC Reliance.
The chipset is called the "LE-64 ver 3.0". and I cannot seem to find
any info about it. The most I've been able to turn up i
> > Almost all of the flags it accepts seem like functionality that can easily
> > be implemented in userspace around fork() (and maybe vfork()).
>
> nope. This whole issue is about (let me check :-) ) 4.5 years old. I did
> the first rfork for freebsd ca. 9/1994, and I can tell you that you can
On Tue, 11 Jan 2000, Michael Bacarella wrote:
> I'm sorry I missed the discussion on rfork()... but I say this only
> because I want to understand.
>
> What were you thinking? rfork()? Why is it a system call?
>
> Almost all of the flags it accepts seem like functionality that can easily
> be im
Michael Bacarella <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Jan 2000, Alfred Perlstein wrote:
> > I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should
> > work fine
>
> I'm sorry I missed the discussion on rfork()... but I say this only
> because I want to understand.
>
> What wer
On Mon, Jan 10, 2000 at 03:36:23PM -0800, Matthew Dillon wrote:
> A better solution may be to shift to FreeBSD4.0 (when it's released -
> wait for it to become good and stable), and then use the native
> linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD.
>
> The linux
On Mon, 10 Jan 2000 22:21:32 MST, John and Jennifer Reynolds wrote:
> So, I made a quick hack to mergemaster so it would recognize a new
> "rc" variable called IGNORE_FILE. This file is a list of files
> mergemaster should ignore, or not compare. One filename per line.
I've been meaning to do
25 matches
Mail list logo
