On Wed, Sep 07, 2011 at 09:00:26PM -0400, Mouse wrote:
And I am not aware of a solution where you can have two ... in a C
function.
You can't actually _write_ something like
void foo(const char *, ..., int, const char *, const char *, ...);
But you can do:
void foo(const char *,
On Thu, Sep 08, 2011 at 02:42:18AM +0200, Jean-Yves Migeon wrote:
Yep; the big downside with the fmt as string literal is that it can
inflate the code by a good margin for no real purpose -- it creates a
string for each KASSERTMSG().
Having the ability to specify the format string is why
You can't actually _write_ something like
void foo(const char *, ..., int, const char *, const char *, ...);
But you can do:
void foo(const char *, va_list, const char *, ...)
if you need to add some extra args.
Yeah, but then you have to pass a va_list, not separate args. Of
course, for
On 08.09.2011 03:00, Mouse wrote:
And I am not aware of a solution where you can have two ... in a C
function.
You can't actually _write_ something like
void foo(const char *, ..., int, const char *, const char *, ...);
but, except for -Wformat issues, you can get that effect with
On Thu, Sep 08, 2011 at 02:06:29PM +0200, Jean-Yves Migeon wrote:
I can't expect the kernel to be in a good shape when it calls panic(9)
so allocating/copying strings is not possible. So it has to be done at
compile time, or the use of panicstr has to be changed.
There is no reason to allocate
Hello,
I've been wondering if it was possible to change the pty(4) internal
buffer size, as I noticed that ppp tunnels cannot use a larger frame
size. Because of this, it seems that the optimal MTU be 856, which is
so small that context switches become the bottleneck.
It would be nice to for
On 08.09.2011 14:27, Joerg Sonnenberger wrote:
On Thu, Sep 08, 2011 at 02:06:29PM +0200, Jean-Yves Migeon wrote:
I can't expect the kernel to be in a good shape when it calls panic(9)
so allocating/copying strings is not possible. So it has to be done at
compile time, or the use of panicstr
On Thu, Sep 08, 2011 at 06:41:54PM +0200, Jean-Yves Migeon wrote:
On 08.09.2011 14:27, Joerg Sonnenberger wrote:
There is no reason to allocate a string, just reserve e.g. 160 Bytes or
so and use snprintf to that. But yes, the current usage is suboptimal.
So let's make it a little bit more
Can you please expand PUD and explain what blktap2 does and is used for?
can't tell the actors without a playbill,
Erik f...@netbsd.org
I wonder if the pty buffer size is what is limiting my pastes in xterms.
I notice them when pasting more than a few text lines (about 23 medium
filled lines is the limit in a quick test I just did; wc tells me 1025
characters including an extra newline to terminate the final partial
line) into vi
On Thu, Sep 08, 2011 at 11:26:29AM -0400, Matthew Mondor wrote:
It would be nice to for instance be able to use an MTU of 3000 so that
there are less context switches, but unfortunately tracing the
processes show that 1024 bytes are read from the pty devices at most.
Are you sure using an
I've been wondering if it was possible to change the pty(4) internal
buffer size, as I noticed that ppp tunnels cannot use a larger frame
size. Because of this, it seems that the optimal MTU be 856, which is
so small that context switches become the bottleneck.
It would be nice to for
In article 201109081526.p88fqt1q002...@ginseng.pulsar-zone.net,
Matthew Mondor mm_li...@pulsar-zone.net wrote:
Hello,
I've been wondering if it was possible to change the pty(4) internal
buffer size, as I noticed that ppp tunnels cannot use a larger frame
size. Because of this, it seems that
13 matches
Mail list logo
