[Top] [All Lists]

Re: kernel bug in socketpair()

To: Glenn Fowler <gsf@xxxxxxxxxxxxxxxx>
Subject: Re: kernel bug in socketpair()
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 23 Jul 2003 10:31:35 -0700
Cc: gsf@xxxxxxxxxxxxxxxx, dgk@xxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200307231724.NAA90957@xxxxxxxxxxxxxxxxxxxxxxx>
References: <200307231428.KAA15254@xxxxxxxxxxxxxxxxxxxxxxx> <20030723074615.25eea776.davem@xxxxxxxxxx> <200307231656.MAA69129@xxxxxxxxxxxxxxxxxxxxxxx> <20030723100043.18d5b025.davem@xxxxxxxxxx> <200307231724.NAA90957@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, 23 Jul 2003 13:24:36 -0400 (EDT)
Glenn Fowler <gsf@xxxxxxxxxxxxxxxx> wrote:

> /dev/fd/N is the underlying mechanism for implementing the bash and ksh
>       cmd-1 <(cmd-2 ...) ... <(cmd-n ...)


I looked at the bash code, and it uses pipes with /dev/fd/N, and for
/dev/fd/N which are pipes the open should work under Linux.

This is what David Korn said in his original report.

I guess the part that is left is the fchmod() issue which exists
because one inode is used to implement both sides of the pipe under

Was the idea to, since fchmod() on pipes modified both sides,
to use UNIX domain sockets to implement this?  And that's how
you discovered the /dev/fd/N failure for sockets?

Another idea is to use named unix sockets.  Can that be
sufficient to solve your dilemma?

<Prev in Thread] Current Thread [Next in Thread>