aboutsummaryrefslogtreecommitdiffstats
path: root/templates
AgeCommit message (Collapse)Author
2015-09-04Add return value printing to wrappersPeter Seebach
I never did this because how could you do it generically, then a friend who is better at Python gave me an idea for a way to do it, and now wrapper debugging prints return values, not just errno values, in most-to-all cases. Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
2015-08-20Drop the allocation in pseudo_fix_path/pseudo_root_path/etc.Peter Seebach
Instead of allocating (and then freeing) these paths all the time, use a rotating selection of buffers of fixed but probably large enough size (the same size that would have been the maximum anyway in general). With the exception of fts_open, there's no likely way to end up needing more than two or three such paths at a time. fts_open dups the paths since it could have a large number and need them for a while. This dramatically reduces (in principle) the amount of allocation and especially reallocation going on. Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
2015-08-20Initial profiling implementation.Peter Seebach
A partially-implemented profiler for client time, which basically just inserts (optional) gettimeofday calls in various places and stashes data in a flat file containing one data block per pid. Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
2014-04-21Automatic dependency checking for wrappersPeter Seebach
Ports can provide pseudo_wrappers.c or portdefs.h, and individual functions have implementations. These dependencies aren't known until post-configure. Make the Makefile include two sub-Makefiles which can be updated by makewrappers. Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
2013-06-25Change debugging to use flags rather than levelsPeter Seebach
This is a moderately intrusive change. The basic overall effect: Debugging messages are now controlled, not by a numeric "level", but by a series of flags, which are expressed as a string of letters. Each flag has a single-letter form used for string specifications, a name, a description, a numeric value (1 through N), and a flag value (which is 1 << the numeric value). (This does mean that no flag has the value 1, so we only have 31 bits available. Tiny violins play.) The other significant change is that the pseudo_debug calls are now implemented with a do/while macro containing a conditional, so that computationally-expensive arguments are never evaluated if the corresponding debug flags weren't set. The assumption is that in the vast majority of cases (specifically, all of them so far) the debug flags for a given call are a compile-time constant, so the nested conditional will never actually show up in code when compiled with optimization; we'll just see the appropriate conditional test. The VERBOSE flag is magical, in that if the VERBOSE flag is used in a message, the debug flags have to have both VERBOSE and at least one other flag for the call to be made. This should dramatically improve performance for a lot of cases without as much need for PSEUDO_NDEBUG, and improve the ability of users to get coherent debugging output that means something and is relevant to a given case. It's also intended to set the stage for future development work involving improving the clarity and legibility of pseudo's diagnostic messages in general. Old things which used numeric values for PSEUDO_DEBUG will sort of continue to work, though they will almost always be less verbose than they used to. There should probably be a pass through adding "| PDBGF_CONSISTENCY" to a lot of the messages that are specific to some other type.
2013-02-16allow pseudo to force asynchronous behaviorPeter Seebach
The openembedded build, at least with RPM or SMART, is heavily affected by the cost of calling fsync or fdatasync on package databases all the time. Gosh, wouldn't it be nice if we could suppress that without making dozens of highly intrusive and risky changes into RPM, various database packages, and so on? Yes, yes it would. If only there were a program which could intercept system calls and change their behavior! Enter --enable-force-async. There are now wrappers for fsync, fdatasync, and a few related functions. If --enable-force-async is set, these wrappers instantly return 0, even if PSEUDO_DISABLED is set. And with any luck, bitbake will now perform a bit better. Credit for this insight goes to Richard Purdie. I've reimplemented this to add the configure option, and make the fsync suppression work even when PSEUDO_DISABLED is set.
2011-06-09Fix realpath(name, NULL) when PSEUDO_DISABLED=1Peter Seebach
On some Linux systems, dlsym("realpath", RTLD_NEXT) prefers for reasons of its own to give a symbol that is also known as old_realpath, which fails and yields EINVAL when called with a null pointer as the second argument. This can be avoided, on some systems, by using dlvsym() to request the GLIBC_2.3 version of the symbol. The wrapper logic is enhanced to allow for specifying versions, although this currently only works for Linux (Darwin has no dlvsym, apparently?). The test case is a trivial program which calls realpath(name, NULL) run with PSEUDO_DISABLED=1.
2011-04-21Fix hangs on Fedora 13 et al.Peter Seebach
2011-03-25Merge in ports workPeter Seebach
This is a spiffied-up rebase of a bunch of intermediate changes, presented as a whole because it is, surprisingly, less confusing that way. The basic idea is to separate the guts code into categories ranging from generic stuff that can be the same everywhere and specific variants. The big scary one is the Darwin support, which actually seems to run okay on 64-bit OS X 10.6. (No other variants were tested.) The other example given is support for the old clone() syscall on RHEL 4, which affects some wrlinux use cases. There's a few minor cleanup bits here, such as a function with inconsistent calling conventions, but nothing really exciting.
2010-12-16Restructure wrapfuncs.cMark Hatle
Restructure wrapfuncs.c in an attempt to improve PSEUDO_DISABLED=1 performance. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2010-12-13Further amend the system to enable/disable sudo during fork/exec.Mark Hatle
2010-12-09: * (mhatle) Add doc/program_flow to attempt to explain startup/running * (mhatle) guts/* minor cleanup * (mhatle) Reorganize into a new constructor for libpseudo ONLY pseudo main() now manually calls the util init new / revised init for client, wrappers and utils * (mhatle) Add central "reinit" function * (mhatle) Add manul execv* functions * (mhatle) rename pseudo_populate_wrappers to pseudo_check_wrappers Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2010-12-07This is a merge of several commits from a tree which turned out toPeter Seebach
be out of sync in a very inconvenient way. Changes include: * Some whitespace fixes, also move the pseudo_variables definition into pseudo_util.c since it's not used anywhere else. * Further improvements in the fork() support: We now recognize both positive and negative forms of PSEUDO_DISABLED, so we can distinguish between "it was removed from the environment by env -i" (restore the old value) and "it was intentionally turned off" (the new value wins). * clone(2) support. This is a little primitive, and programs might still fail horribly due to clone's semantics, but at least it's there and passes easy test cases. Plus a big patch from Mark Hatle: Cleanup fork/clone and PSEUDO_DISABLED guts/fork.c: * cleanup function and make it more robust * be sure to call pseudo_setupenv prior to pseudo_client_reset to match exec behavior pseudo_wrappers.c: * fix mismatched type in execl_to_v call via typecast * Simplify fork call via single call to wrap_fork() * be sure to save pseudo_disabled * be sure to call pseudo_setupenv prior to pseudo_client_reset to match exec behavior tests: * Add a test of whether pseudo can be disabled/enabled on a fork. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2010-10-25Clean up makewrappers a bit.Peter Seebach
2010-10-11Major change: Replace the shell-based makewrappers with a PythonPeter Seebach
one. There's a long story here, but to abbreviate it: The shell script was annoying at best to maintain and starting to show signs of not really being the right tool for the job. For various reasons, we have some other Python stuff in our build system, so we picked Python as the language we were already using for other stuff. We think this works with anything reasonably recent (around Python 2.4 through 2.6). There's a little bit of cleanup, also, of the wrapper templates.