On Sat, 10 Aug 2013 23:22:08 +0200 Roland Mainz wrote: > 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 ? yes > > 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 ? right, it can't really because the desired semantics for open(/dev/fd/N) is to get a new file structure (i.e., separate seek pointer, flags) ast only falls back to dup() semantics when it can't do it any other way > > 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 ? :-) fair assumption but alpha is relative once things get burned into shared libs it gets messy in particular ast not being able able to re-build itself > [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). as long as the stat(1) part of readlink(1) doesn't creep in I believe we can (1) make ls a builtin (2) make readlink a builtin-in alias of 'ls --format="%(some-new-ast-id)s"' so now mount has to be a builtin too? _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
