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.
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) h
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 yo
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 th
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 document
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 sma
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 s
[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 - t
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
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> if (sigsetjmp(env) == -1) {
Blah, this should be
if (sigsetjmp(env, 1) == -1) {
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
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 "p
> 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.
http://
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 portabl
[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,
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
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 availabl
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 r
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
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 the
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 mai
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 i
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.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
[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.
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
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 possibl
> The "md" problem should really be solved by adding
> #define MD_NAME "md"
> to and using this in both the driver and the mdconfig
> program.
>
> Can I get you to incorporate that in your patch ?
Certainly! The updated patch is at
http://www.unixfreak.org/~dima/home/md-list4.diff (it's
> 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 cor
On 25-Feb-01 [EMAIL PROTECTED] wrote:
> yes the crux of the problem, so does anyone have patches
> to the kernel so that linux binaries dump in linux core
> file format?
Not that I know of :(
> > You can still attach to processes etc though I think.
> If I can keep the program running. The
>
> Ahh.. Recompile it? Or is it binary only?
Yep binary only.
- JimP
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
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
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(
> "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 d
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 s
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 (
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.
>Notic
42 matches
Mail list logo
