On Sat, 29 Jun 2013 00:37:11 +0200 Cedric Blancher wrote:
> 2013/6/28 Glenn Fowler <[email protected]>:
> >
> > the AT&T Software Technology ast alpha 2013-06-28 source release
> > has been posted to the download site
> > http://www.research.att.com/sw/download/alpha/
> > the package names and md5 checksums are
> > INIT eddbf89d061348519d86f2618b708a94
> > ast-base a745a7d4ce6f53c2e4134af4cc835ff7
> > ast-open fdb74839ff041e34c800c333188a050e
> > ast-ksh 8f22428cf30af7146bd210664c2fd166
> > the md5 sums should match the ones listed on the download page
> The release is unusable. The new "API" - if it can be called like that
> - added wrappers to all syscalls via #define, which breaks down on
> OpenBSD or other platforms which already use #defines for security
> wrappers. It's also undebuggable by adding yet another layer of hidden
> complexity. I wouldn't mind if if the code would call _ast_open() and
> friends directly but hiding it via #define open _ast_open collides
> with too many other things, including system libraries and the ability
> of normal minds to grok it.
> So this won't fly.
thanks for the feedback
unfortunately we don't have acces to bsd machines anymore
bsd *never* did headers right
e.g., if posix says
#include <foo.h>
bsd takes it on itself to demand
#include <sys/hack.h>
#include <sys/hackier.h>
#include <foo.h>
so I'm not surprised that we hit macro clashes
send me offlist the files named by
bin/package results path
and if you did more than one build
bin/package results path old
we knew the intercepts would be controversial, especially the varargs ioctl()
but this is the best way we could think of to flesh out EINTR problems
that arose from the recent signal/queue storm tests
as far as we can tell few system calls in all ast libraries and commands are
immune from EINTR error returns, including surprising ones like close() and
stat()
there is no way we could do the edit to wrap syscalls with restart logic,
possibly just for debugging purposes, in a timely manner
so we did it by default for all ast code via macro black magic
knowing that we may run afoul of others doing similar black magic
as the problems arise we'll address them
for now the default is to always intercept
but there is a way to build with intercepts disabled
-D_AST_INTERCEPT=0
*but don't do this for ast code*
in the future the default could change
the intercept approach addresses many issues
* adding restart logic, macros or not, to every piece of ast code would be fugly
and I would not like editing, debugging or maintaining that code on a daily
basis
so please don't submit patches to restartify ast code
* whos to say some other issues like EINTR won't arise tomorrow -- with
intercepts
we may have a much easier pathway to address those issues
* any user code that expects to be used in ksh builtins or ast plugins must
do the restart logic -- its much easier to instruct builtin developers to
"#include <ast.h>" than to "wrap each syscall with foomacro() barmacro()"
and the latter would have to be bullet proof -- not that easy to say months
later
"oops, we should have said foomacro(special arg) barmacro(another special
arg)";
if the user code doesn't do syscall macro intercepts it should go smoothly,
otherwise the users will have to "-D_AST_INTERCEPT=0" and examine the user
or 3rd party code for EINTR restartedness
* although syscall restart on interrupt is part of posix, no 2 unix
implementations
apply restart in the same way on the same set of syscalls -- e.g., the
intesection
between the ast intercepts and any unix implementation != ast intercepts
* intercepts can now portably handle O_* and F_* extensions like O_SEARCH and
F_DUPFD_CLOEXEC using standard macro names (with the help of iffe) and
emulate those
features not supported in any particular implementation
* we now have a mechanism to trace and track down all EINTR probs and address
them
as the signals are handled, including the possibility of adding interrupt
handler
logic that can determine if a particular call should be restarted or is
really hung
the crystal ball shows that roland will submit patches to handle some of the
build issues, so hopefully this will be a non-issue and the alpha debugging and
testing
can proceed
I have to say that I was surprised at how hard it is to get non-threaded code
to work
correctly in the face of signal storms, especially code like vmalloc that
maintains
complex internal state -- in many cases its much more difficult to make
signal-safe code
than thread-safe code
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
