Re: seekable pipes

> In
> the anonymous case 
> (more precisely, the case of the anonymous pipe
> generated and deployed by 
> a seekable-pipe-agnostic program such as Bash), you
> can't make sure the 
> guy who makes the pipe seekable does so before the
> guy who needs it to be 
> seekable notices that it's not.

OK. This can of course be circumvented by doing
$ command_that_understands_seekable_pipes |
(command_that_checks_stdin;
command_that_requires_seekable_stdin)

But I see how this is something best done in the
shell.

In any case, you'd need some kind of ioctl to ask the
kernel to wait for the other end of the pipe to become
seekable (or be written or closed).

> The client is the 
> program that thinks he's looking at a conventional
> file, so he can seek, 
> read, and write.  The server is the guy who knows
> it's a special seekable 
> pipe file and whose job it is to make the client see
> a conventional file.

That's fine; we have no disagreement there. But I'm
not sure it's correct to return S_ISREG; Seems to me
of the two seekable file types (regular and block
device), block device is closer to the truth. I was
planning to leave the type as S_IFIFO in my original
plan, but I see how that's problematic.

--Ian


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
-
To unsubscribe from this list: send the line "unsubscribe linux-userfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html