Kenneth Wayne Culver [EMAIL PROTECTED] writes:
FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever
support cardbus in 4.x. If you are daring you can get -CURRENT, but from
what I hear right now, it's not working very well.
It works just fine, thank you very much, but it
[EMAIL PROTECTED] (Peter Seebach) writes:
In message [EMAIL PROTECTED], Farooq Mela writes:
How do you guys feel about this?
It is a mistake to believe that you "don't have to worry about running
out of memory". You should always check, every time, and exit as gracefully
as you can.
This
In message [EMAIL PROTECTED], Dima Dorfman write
s:
2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that
it would also match any other device name that might begin with md, which
potentially might not be provided by the md driver. This is currently (I
suspect)
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
This is all academic since FreeBSD does memory overcommit, so unless
you run out of address space for your process before you run out of
actual memory and/or swap (not likely, but quite possible) malloc()
will never return NULL and you
I'm searching for a good book (or site/tutorial) about Unix socket
programming, preferably FreeBSD specific.
Any hints?
Marco van de Voort ([EMAIL PROTECTED] or [EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Thus spake Marco van de Voort ([EMAIL PROTECTED]):
I'm searching for a good book (or site/tutorial) about Unix socket
programming, preferably FreeBSD specific.
Socket programming shouldn't be FreeBSD specific.
Unix Network Programming Vol.1 by W. Richard Stevens is a good choice.
After
On Sat, Feb 24, 2001 at 08:17:03PM +0100, Alexander Langer wrote:
Thus spake Marco van de Voort ([EMAIL PROTECTED]):
After that you probably want to read some kqueue documents, which is
FreeBSD specific, but shall be quite fast (faster than select/poll)
Other than the manpage, what documents
Thus spake Brian Reichert ([EMAIL PROTECTED]):
Other than the manpage, what documents about kqueue are there?
I read this:
http://www.flugsvamp.com/~jlemon/fbsd/internals.txt
http://people.freebsd.org/~jlemon/ has a slideshow on kqueue.
http://www.flugsvamp.com/~jlemon/fbsd/ has also some
I'm preparing to commit these changes in the next few days; when
committing the last set of changes to top, there were some comments about
sysctl namespace allocation, and so I'm looking for a bit more code review
this time around since I'm not sure it got all the coverage it needed
(other than
[EMAIL PROTECTED] (Peter Seebach) writes:
Is there any hope that, some day, a setting could be provided where a program
could request that malloc *NOT* overcommit? There are programs which would
rather know in advance, and clean up, than be killed abruptly.
Malloc() does not overcommit - the
On Sat, 24 Feb 2001, Brian Reichert wrote:
On Sat, Feb 24, 2001 at 08:17:03PM +0100, Alexander Langer wrote:
Thus spake Marco van de Voort ([EMAIL PROTECTED]):
After that you probably want to read some kqueue documents, which is
FreeBSD specific, but shall be quite fast (faster than
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
Malloc() does not overcommit - the kernel does. Malloc() doesn't know
and doesn't care.
But it could still probably force the behavior.
None of these solutions are portable, however;
Well, no, but the sole available definition of
On Sat, 24 Feb 2001 20:04:50 +0100
"Marco van de Voort" [EMAIL PROTECTED] said:
marcov I'm searching for a good book (or site/tutorial) about Unix socket
marcov programming, preferably FreeBSD specific.
I recommend address family independent socket programming.
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
Malloc() does not overcommit - the kernel does. Malloc() doesn't know
and doesn't care.
But it could still probably force the behavior.
None of these solutions are portable, however;
[EMAIL PROTECTED] (Peter Seebach) writes:
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
Malloc() does not overcommit - the kernel does. Malloc() doesn't know
and doesn't care.
But it could still probably force the behavior.
Barring kernel changes, not easily, and only for
In message 9402.983047348@critter, Poul-Henning Kamp writes:
Well, no, but the sole available definition of "portable" says that it is
"portable" to assume that all the memory malloc can return is really
available.
No, this is not a guarantee.
Yes, it is. If the memory isn't available, malloc
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9402.983047348@critter, Poul-Henning Kamp writes:
Well, no, but the sole available definition of "portable" says that it is
"portable" to assume that all the memory malloc can return is really
available.
No, this is not a guarantee.
In message 9469.983047707@critter, Poul-Henning Kamp writes:
The guarantee is "If malloc returns NULL there is no memory you can use".
No, it's "if the memory is not available, malloc returns NULL".
That doesn't mean that just because != NULL is returned that memory
will in fact be available.
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9402.983047348@critter, Poul-Henning Kamp writes:
Well, no, but the sole available definition of "portable" says that it is
"portable" to assume that all the memory malloc can return is really
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9469.983047707@critter, Poul-Henning Kamp writes:
The guarantee is "If malloc returns NULL there is no memory you can use".
No, it's "if the memory is not available, malloc returns NULL".
No it is not and it never was.
See RFC748
We have an application which is precompiled, for linux, and stupid.
It uses (at times large) scratch files. We want to run this on our
diskless machines (CPU farm) to cut the per-cpu cost of the
computation ($200/drive starts getting significant at a few hundred
machines).
Anyways, I've tried:
In message 9631.983048712@critter, Poul-Henning Kamp writes:
No it is not and it never was.
The C committee believes it is.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9631.983048712@critter, Poul-Henning Kamp writes:
No it is not and it never was.
The C committee believes it is.
The C committee doesn't deal with operating systems or the real world
for that matter. They only interest them selves
In message 9820.983050024@critter, Poul-Henning Kamp writes:
I think there is a language thing you don't understand here.
No, I just disagree. It is useful for the OS to provide a hook for
memory which is *known to work* - and that is the environment C specifies.
-s
To Unsubscribe: send mail
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9820.983050024@critter, Poul-Henning Kamp writes:
I think there is a language thing you don't understand here.
No, I just disagree. It is useful for the OS to provide a hook for
memory which is *known to work* - and that is the
[EMAIL PROTECTED] (Peter Seebach) writes:
In message 9877.983050267@critter, Poul-Henning Kamp writes:
And just how will the OS know that a particular memory chip will not
generate an uncorrectable ECC error ?
It can't, but that's no reason for the OS to *add* reasons for failures.
It
Alexander Langer wrote:
Thus spake Marco van de Voort ([EMAIL PROTECTED]):
I'm searching for a good book (or site/tutorial) about Unix socket
programming, preferably FreeBSD specific.
Socket programming shouldn't be FreeBSD specific.
Unix Network Programming Vol.1 by W. Richard Stevens
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
It doesn't (and I'm very close to using expletives here). On the
contrary, it tries to always satisfy the application's requests and
hopes for the best.
Yes, but it could provide a stronger guarantee than it does.
It's quite possible
On 22-Feb-01 Greg Lehey wrote:
/compat/linux/
/usr/bin/gdb, it says the core file is in the wrong format:
Couldn't fetch registers from core file: File in wrong format
Couldn't fetch register set 2 from core file: File in wrong format
So what is the correct procedure for
At 3:49 PM + 2/15/01, Steve Roome wrote:
Is there any chance someone could take a look at the patch
I supplied for pciconf and perhaps let me have some feedback
on it?
It's just to clean up the output a little and add the ability
to identify better any non supported chipsets. I thought that
On Sat, Feb 24, 2001 at 04:08:04PM -0500, David Gilbert wrote:
We have an application which is precompiled, for linux, and stupid.
It uses (at times large) scratch files. We want to run this on our
diskless machines (CPU farm) to cut the per-cpu cost of the
computation ($200/drive starts
Peter Seebach wrote:
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
This is all academic since FreeBSD does memory overcommit, so unless
you run out of address space for your process before you run out of
actual memory and/or swap (not likely, but quite possible) malloc()
will
"Bernd" == Bernd Walter [EMAIL PROTECTED] writes:
Bernd You have to raise MAXDSIZE and DFLDSIZ in your kernel config.
Bernd You may also want to try MD instead of MFS.
Well... I was reading about md and the man page seemed to imply that
it was _very_ dependant on what malloc(9) could do ...
Must not be cardbus then.
=
| Kenneth Culver | FreeBSD: The best NT upgrade|
| Unix Systems Administrator | ICQ #: 24767726 |
| and student at The | AIM: muythaibxr |
| The
:On Sat, Feb 24, 2001 at 04:08:04PM -0500, David Gilbert wrote:
: We have an application which is precompiled, for linux, and stupid.
: It uses (at times large) scratch files. We want to run this on our
: diskless machines (CPU farm) to cut the per-cpu cost of the
: computation ($200/drive
In message [EMAIL PROTECTED] Peter Seebach writes:
: In message 9631.983048712@critter, Poul-Henning Kamp writes:
: No it is not and it never was.
:
: The C committee believes it is.
I do not believe you. Such a "believe" does not appear to be embodied
in the C-99 standard.
The standard (well
In message [EMAIL PROTECTED], Warner Losh writes:
I do not believe you. Such a "believe" does not appear to be embodied
in the C-99 standard.
It's somewhat debated, but it has come up in discussions, and the consensus
is that, if malloc returns a pointer, the memory has to be usable.
Notice
37 matches
Mail list logo
