Date: Sat, 16 Sep 2000 10:04:47 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: current@FreeBSD.org, hackers@freebsd.org Subject: Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!) Message-ID: <20000916100447.I27034@speedy.gsinet> In-Reply-To: <200009160249.e8G2n3n02415@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Sat, Sep 16, 2000 at 03:49:02AM %2B0100 References: <phk@critter.freebsd.dk> <200009160249.e8G2n3n02415@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
using Brian's post since I don't have the original around ...
On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
>
> [ attribution missing, is it Poul-Henning Kamp's text? ]
>
> > The majority of these programs could be handled by adding
> > knowledge of "-" as a magic filename to fopen(3).
> [.....]
> > At the same time I would really love if we implemented "|.*"
> > to mean "do an popen(3)" instead.
The only reasonable way to provide this functionality to apps not
wanting to reinvent it themselves without breaking those who feel
that files should be just that - files - is a _new_ function next
to fopen(3) named some rather alerting way like superduperopen(3)
with flags like SDO_KNOWS_STDIN, SDO_CAN_PIPEFROM,
SDO_CAN_PIPEINTO and whatever other extension you can think of.
32 of these new behaviour patterns should suffice for quite a
while. :)
This will collapse the "-" recognition and handling logic in
existing programs to passing a simple flag to a different
function (with only one more int parameter compared to fopen(3))
and leave those alone who just want to fopen(3) any file. And
when the options set is extended no app will "inherit" unwanted
and unexpected features turning out to be holes. Unless there's
a SDO_DO_ANY_PRESENT_AND_FUTURE_MAGIC flag passed with a value of
0xffffffff. But authors doing so will get what they deserve. :>
One could even think of switching to the new function "to be
ready" and passing a SDO_DONT_DO_ANY_MAGIC flag.
<crazy mode on>
How much sense does it make to think about implementing tee and
select methods this way? Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"? The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames. '&' seems to be too, but could be used
rarely enough. And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.
e.g.
superduperopen("file1&file2", "a+", SDO_TEEFILES)
superduperopen("file1&file2", "r" , SDO_SELECT)
Semantics could be braindead simple: TEE will just dup any data
to every file specified and SELECT will have implicit priorities
since there's no logic doing round robing or something. This
will suffice for randomly filled input channels being fed more
alternatively rather than concurrently.
<crazy mode off>
Of course the mode parameter from fopen(3) and the magicmask
parameter from superduperopen(3) (i.e. the second and third
parameters) have to pass certain checks. Nobody should try to
read from "|command". And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.
Feel free to correct the flag's data type. I have the feeling
not all int's have 32bits. :) Some other means of storage might
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000916100447.I27034>