On Fri, Aug 9, 2013 at 6:58 PM, Glenn Fowler <[email protected]> wrote: > > this will be in the next alpha as > /dev/fcntl@...
See http://lists.research.att.com/pipermail/ast-developers/2013q3/003070.html ... last sentence... > because it works on all types of paths, even /dev/fd > > the patch happened quickly because the background work in pathdev() and > syscall restart intercepts (both part of the stability/debugging flurry this > summer) > were already in place > > it handles relative paths like this > /dev/fcntl@direct/./file_in_pwd Mhhh... I would prefer to use /dev/fcntl@direct/dev/fd/AT_CWD/file_in_pwd ... but that would require to teach /dev/fd/ to honor "AT_CWDFD" as input value... > recursion not needed, pathdev() just loops back after peeling off > /dev/fcntl@... and setting dev.oflags > the O_ASYNC checks were moved to the ast_openat() intercept Ok... ... did you move the |fcntl()| calls for Linux there, too ? > one question is should /dev/fcntl@.../dev/fd/N be allowed to modify fd N? > the current implementation does allow this Erm... how should that work ? > a few points about ast patches > always add new struct members to the end of the struct, just before > _FOO_PRIVATE_ members if any > this will maintain binary compatibility for the apis that return struct to > the caller > this is really important for maintaining integrity in shared lib builds > (in particular, dev.oflags should be at the end) Erm... I put the flag near the field where it logically belongs to because we're still in alpha mode... right ? :-) [snip] > like for instance the readlink(1) proposal -- its based on a stat(1) command > that is already > covered in a more natural/readable way by ast ls(1) and tw(1) > if we take readlink(1) as it is -- what are we trying to do? See below... readlink(1) has a special purpose... > emulate every api, good or bad > although there are bad apis in ast, the march forward is to make them better > and not > bloat with additional bad apis > the thought that needs to go into readlink(1) and similar builtins is: > maybe make ls(1) a builtin ... that would be a very good idea because "ls" usually ranks high in the logs of a system's accounting system > (possibly with a few more %(FIELDS)) and make readlink(1) and friends > aliases or functions or scripts on top of ls Erm... the readlink(1) patch was there because there is the (urgend) demand for it to make it possible that ksh93(1) can replace busybox ... the issue is that at system boot some weired and unusual stuff has to be done... like booting from a so-called "miniroot" (e.g. UFS filesystem filled with a mini-system loaded over tftp which then mounts the real root filesystem (ZFS-, NFS-, UFS-based etc.) later). At a certain point you need to process a set of symlinks _without_ having a '/' filesystem (don't ask... it only works with busybox because readlink(1) and mount(1m) are shell builtins). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
