linux-kernel - Re: PROPOSAL: extend pipe() to support NULL argument.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Jul 2009 12:08:58 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Amerigo Wang <xiyou.wangcong@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: PROPOSAL: extend pipe() to support NULL argument.

On Fri, Jul 3, 2009 at 11:00 AM, Amerigo Wang<xiyou.wangcong@...il.com> wrote:
>
> When I said 'pipe', I meant *anonymous* pipe, definitely!
> There is nothing related with *named* pipe here.
>
Pipe means *anonymous* pipe? Who defined that? What the difference
between an anonymou pipe and a named pipe? Two ends or one ends? I
don't think so. Having explicit name is the right difference between
them.

And when I said 'kernel buffer handler', I means it is not a
traditional pipe, and I just extend and reuse the pipe API to create a
kernel buffer handler for splicing use.

> You are going to a *wrong* direction.
>
What is the right direction you think? Keep the pipe() API unchanged
and keep two fds refering to the same kernel buffer? If you want to
keep the API unchanged just for compatiblity with POSIX, I agree with
you, and maybe a new system call is needed.

>
> If you repeat your (pipe,splice,splice,close,close) sequence for
> thousands times, it is still the same, nothing saves...
>
You means that?

while (<condition>) {
 pipe/splice/splice/close/close?
}

You don't know my meaning. As a proxy server, there maybe lots of
connections to maintain, and these connections will keep open for a
long time. If the data received can be sent in a relay cycle, the
kernel buffer can be reused. If not, the kernel buffer must be
reserved. When there are lots of these kinds of connections, lots of
kernel buffers must be reserved. At this time, whether two fds per
kernel buffer or one fds per kernel buffer matters.


-- 
Regards，
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/