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

[Johannes Berg]

Tom Lord said:
> 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.

The vu_ layer certainly could contribute to this solution; however I do
think it is -- as is -- too heavy-weight. We'd also need to consider the
"deployment" of vu_ in existing apps/libs like libz, "libpatch", ...

For this to be really useful, a simple vu_ layer must exist that libraries
can trivially link, and which provides no functionality loss to start
with, except by providing an exported function that can be used to push a
different vu layer for use by the application.

As a side note -- your following points all seem to imply that you want
the library to basically have the same interface as the application. I
don't think that really is a useful idiom, ideally a library would provide
a much richer interface than an application, also allowing access to
partial functionality.

> 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?

And what if these two come from different libraries?
But I think at this point you're not going to gain much from libraries as
opposed to fork&exec.

>    ~ 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?

I don't really see any need for this.

>    ~ 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?

This is possibly the hardest problem.

>    ~ 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.

Isn't SWIG trying to solve a different problem? Afaik SWIG will try to
wrap a library within a scripting language, while (as I understand it) we
are discussing a C library that exports functions.

> 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.

[...]
I'll try to finish some more thoughts, but right now have to do some work.

johannes