Hello!
In Linux, txqueuelen (the length of the transmit queue of the device)
can be set by 'ifconfig' command. Is there a corresponding parameter or
command in BSD??
--
Zongsheng Zhang
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.
On Wed, Sep 22, 2004 at 11:43:17AM +0900, George V. Neville-Neil wrote:
> At Tue, 21 Sep 2004 22:09:57 -0400,
> Brian Fundakowski Feldman wrote:
> >
> > I've already made noise about this before, so I'll be brief. I plan on
> > committing the following fix that prevents the routing code from bein
At Tue, 21 Sep 2004 22:09:57 -0400,
Brian Fundakowski Feldman wrote:
>
> I've already made noise about this before, so I'll be brief. I plan on
> committing the following fix that prevents the routing code from being
> recursed upon such that RTM_RESOLVE causes the embryonic new route to
> be loo
I've already made noise about this before, so I'll be brief. I plan on
committing the following fix that prevents the routing code from being
recursed upon such that RTM_RESOLVE causes the embryonic new route to
be looked up again. I realize that probably no one will bother trying
to see this bug
At Wed, 22 Sep 2004 07:37:20 +0900,
(BJINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
(B> Note also that other *BSDs and Solaris use the "segfault" logic. The
(B> freeaddrinfo implementation in the "libbind" library as a part of the
(B> ISC BIND package, which many UNIX-like OS vendors adopt
> On Tue, 21 Sep 2004 23:32:33 +0200,
> Thomas Quinot <[EMAIL PROTECTED]> said:
[...snip]
It seems that all these points simply show this is a controversial
issue. I was not convinced with the argument for the no-op approach,
and still believe segfaulting is better. But at the same tim
* JINMEI Tatuya / [EMAIL PROTECTED]@C#:H, 2004-09-21 :
> (or is valid for freeaddrinfo). It's the caller's responsibility to
> ensure that this is a valid pointer. But consider the case where the
Exactly. And it is the callee's responsibility to enforce the invariants
he expects. If freeaddrinf
> On Tue, 21 Sep 2004 22:07:17 +0300,
> Valentin Nechayev <[EMAIL PROTECTED]> said:
>> As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the
>> application programmers might tend to rely on the "safety net" and
>> the uncareful coding style. This can be worse than the segfault h
Wed, Sep 22, 2004 at 03:58:05, jinmei wrote about "Re: freeaddrinfo(NULL)":
> As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the
> application programmers might tend to rely on the "safety net" and
> the uncareful coding style. This can be worse than the segfault here,
Let you try
> On Tue, 21 Sep 2004 20:07:46 +0200,
> Thomas Quinot <[EMAIL PROTECTED]> said:
>> Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553
>> nor RFC 3493. Having such an assumption is a potentially bug and
>> lose portability.
> Would there be any significant drawback for
On Tue, Sep 21, 2004 at 08:07:46PM +0200, Thomas Quinot wrote:
> * Hajimu UMEMOTO, 2004-09-21 :
>
> > Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553
> > nor RFC 3493. Having such an assumption is a potentially bug and
> > lose portability.
>
> That a construct has no defin
* Hajimu UMEMOTO, 2004-09-21 :
> Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553
> nor RFC 3493. Having such an assumption is a potentially bug and
> lose portability.
That a construct has no defined meaning does not imply that we must make
every effort to break application
Hi,
> On Tue, 21 Sep 2004 14:30:16 +0200
> Thomas Quinot <[EMAIL PROTECTED]> said:
thomas> Currently a call to freeaddrinfo (NULL) causes a segfault. Is there any
thomas> reason why we should not make that a no-op? This would make freeaddrinfo
thomas> behave in a manner consistent with fr
On Wed, Sep 22, 2004 at 02:09:11AM +0900, Hajimu UMEMOTO wrote:
> Hi,
>
> > On Tue, 21 Sep 2004 09:14:20 -0700
> > Brooks Davis <[EMAIL PROTECTED]> said:
>
> brooks> The real problem may be that KAME mistakenly gave sockaddr_union a
> brooks> general name when it isn't and such a type wou
Hi,
> On Tue, 21 Sep 2004 09:14:20 -0700
> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> The real problem may be that KAME mistakenly gave sockaddr_union a
brooks> general name when it isn't and such a type would be hell to actually
brooks> work with. A custom union that does exactly wh
On Tue, Sep 21, 2004 at 03:02:20AM -0700, Bruce M Simpson wrote:
> On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote:
> > My question now is, what would be a good place to define this? Are there any
> > fromal standarts that might define it already? (Couldn't find anything) Is
> > there a
| By Andre Oppermann <[EMAIL PROTECTED]>
| [ 2004-09-21 10:51 +0200 ]
> You are onto something. It seems tcp_output() doesn't handle the error
> cases it gets from ip_output() all too well these days. I suspect this
> is the same problem we have in kern/71
Currently a call to freeaddrinfo (NULL) causes a segfault. Is there any
reason why we should not make that a no-op? This would make freeaddrinfo
behave in a manner consistent with free(3), and also with what happens
on Linux.
Thomas.
--
[EMAIL PROTECTED]
_
| By Andre Oppermann <[EMAIL PROTECTED]>
| [ 2004-09-21 10:51 +0200 ]
> Could you please file a PR with all information you have provided so far
> and your observations etc. Just merge your emails together and submit it
> as text. Then give me the PR numbe
On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote:
> My question now is, what would be a good place to define this? Are there any
> fromal standarts that might define it already? (Couldn't find anything) Is
> there anything else that I must consider?
I think Brooks' recommendation is sou
Aragon Gouveia wrote:
>
> Hi,
>
> No, it's not that. No filtering is taking place. I've figured out the
> problem, but I'm not sure how to solve it. Here's what I think is the
> problem.
>
> >From a tcpdump transcript:
>
> 09:56:37.652907 .4185 > .80: S 487952620:487952620(0) win 57344 1460
Hi,
No, it's not that. No filtering is taking place. I've figured out the
problem, but I'm not sure how to solve it. Here's what I think is the
problem.
>From a tcpdump transcript:
09:56:37.652907 .4185 > .80: S 487952620:487952620(0) win 57344 (DF) [tos 0x10]
09:56:37.653076 .80 > .4185: S
22 matches
Mail list logo
