this will be in the next alpha as
/dev/fcntl@...
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
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
one question is should /dev/fcntl@.../dev/fd/N be allowed to modify fd N?
the current implementation does allow this
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)
background: the ast build farm is bleeding edge -- the next build uses the
results of the previous build
this includes ksh and nmake -- its sometimes crazy but has served well as the
first regression test
similarly (and not in this patch) never change macro bitmap values
always grab new high bits
even if visual sorting of the macro names/values goes out of whack
sometimes this is esthetically hard to do when members/macros seem to have
natural groupings
finally, and this relates to the "ast background work already in place comment"
there are many patches that come close to replicating features already in ast
although some of the patches may be simple and non-intrusive
they require some thought to make sure they fit in with what's already in place
sometimes this means tweaking the ast api just a bit to get the functionality
and maybe with those tweaks a big patch can change into an api veneer over the
ast api
all this takes thought to do it right
it doesn't mean a delayed patch is wrong or incorrect, but it may just need a
big picture
analysis before being taken
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? 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 (possibly with a few more %(FIELDS)) and make
readlink(1) and friends
aliases or functions or scripts on top of ls
I guess this ramble boils down to -- just because a patch works doesn't make it
right
On Fri, 9 Aug 2013 07:17:07 +0200 Roland Mainz wrote:
> --089e013a25e2d3e60a04e37ce281
> Content-Type: text/plain; charset=ISO-8859-1
> Hi!
> ----
> Attached (as "astksh20130807_devfile001.diff.txt") is a prototype
> patch for ast-ksh.2013-08-07 which adds a new "virtual device" called
> /dev/file@... which adds the ability to pass extra |O_*| flags to
> open(2).
> Example usage:
> -- snip --
> $ ksh -c 'redirect {n}</dev/file@directory/etc/profile '
> /bin/ksh: /dev/file@directory/etc/profile: cannot open [Not a directory]
> -- snip --
> This error happens because /dev/file@directory sets the |O_DIRECTORY|
> flag for the following path
> ** Notes:
> * The code explicitly sits in libast only to make sure _any_ libast
> consumer can use it (main consumers are going to be the CERN and GE
> Healthcare camps who crave for |O_DIRECT| to disable kernel-buffering
> for some I/O applications)
> * The naming scheme was inspired by ksh93's /dev/tcp&&co. and Solaris
> devfs (see http://docs.oracle.com/cd/E19963-01/html/819-3159/fgomr.html)
> which uses complex expressions with ',', ':', '@' to describe
> physical/virtual devices/device drivers under /devices
> * I've avoided using other characters than ',', ':', '@' for the same
> reasons as Sun's engineers avoided them in Solaris devfs... some of
> them like '#' are toxic to some shells, blanks/whitespaces don't mix
> with them either
> * I've explicitly used /dev/file@... as basis because using any
> relative pathname doesn't work because somehow the attributes need to
> be specified.
> * Filenames/naming scheme alternatives - what does not work:
> - The portable file name character set allows a lot of characters
> - Looking at the RPM filename database even more exotic things like
> "filename(attr)" or filename{attr}" are already in common use on
> Linux.
> - "foo;attr" doesn't work either since filename;string" is more or
> less reserved for filesystems which do versioning (see VMS, Solaris's
> samfs+CD and ISO9660 used on CDROMs).
> - The final stroke on that idea comes from Windows where users and
> applications use almost every sane/insane combination of characters
> from the whole Unicode range except '\0'.
> ** Todo:
> 1. Discuss
> 2. Test SIGPOLL
> 3. Fix any issues
> 4. Make sure something like /dev/file@async,nonblock/dev/fd/19 works,
> too (which means the matching lookup must be done recursive).
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
