Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless

[Tom Lord]

    > From: Johannes Berg <address@hidden>

    > address@hidden said:
    > > But nevermind librifying patch has it's benefits. Just convince the
    > > patch maintainer (hence the cc: to Paul) to accept it in the main patch
    > > distribution then other tools like tla (or the patch command itself)
    > > could link to libpatch then.

    > For this to be really useful, libpatch would have to provide
    > hooks to allow replacing _all_ input/output functions (ie.
    > open,close,read,write,chdir,....) like libz allows (though libz
    > is much easier since it doesn't do as much with files as patch).
    > Only in that case could we use hackerlab as a backend and
    > achieve what we need -- a vu aware patch.

I think that there may be a silver bullet or two for punning apps and
libs.  I think that vu_ is a plausible choice for part of that silver
bullet.

Overall, it's a hard problem that I think needs to be solved with a
bunch of strict conventions for both apps and library functions,
ideally automatically verifiable, convering at least these issues:


   ~ as you say: stream handling.   For example, what does the
     the std{in,out,err} convention mean for two app-like 
     routines being connected in a pipe-like way within a single
     process?

   ~ flow control and stack handling.  If I have app-like library
     routines, can I "run" two of them concurrently in one process?
     Do they share a C stack?   Can they use setjmp/longjmp in a 
     coordinated way?

   ~ signal handling.  Some apps want to use signals in special ways
     (e.g., timers, sigstop handling, etc.)   How can two separately
     developed app-like library modules both do this, in a single
     process, in a coherent way?

   ~ memory management.  An old coding guideline for GNU says
     something along the lines of "if your app will only allocate
     around 1MB of memory, just do that -- don't worry about freeing
     memory".    But 10 runs of that app in the form of an app-like
     library routine would leak 10MB of memory.   Also, some modules
     might want to use something different from malloc --- do these
     app-like routines ever share allocated blocks of memory?   
     How can they coordinate their use of the allocator?

   ~ argument and return types.   Apps take the primary parameters:

        char * environ[];
        char * argv[];
        int argc;

      and "return" an exit status.   Interesting, but, in library
      routines, don't we want a more strongly typed interface?
      And what about "indirect parameters" like file contents?

      A SWIG-like approach might be helpful here although it is
      not easy (imo) to define an appropriate one.

There is a brute-force answer that would maximize the reusability of
existing code: some unholy mix of vu and vu-like wrappers around other
system calls, plus Posix threads, all giving a 95% approximation of
a separate process to a library module.

Perhaps, though, by using a slightly different programmign model, 
the problems can be solved in a less brute-force way, with less
"cognative overhead".   For example, if the details of flow of control
took a back seat to automatically computable data dependencies, the
run-time system could do a lot in the areas of flow control and stack
handling (at least).

One problem with the brute force way is that, although it works fine
in theory, a programmer must know an aweful lot about unix (or else
follow a lot of otherwise inexplicable coding conventions) before they
can correctly write even the simplest app-like library module.

-t