On Sat, 10 Aug 2013 23:12:02 +0200 Roland Mainz wrote: > On Sat, Aug 10, 2013 at 6:00 PM, Irek Szczesniak <[email protected]> > wrote: > > On Sat, Aug 10, 2013 at 5:47 PM, Glenn Fowler <[email protected]> wrote: > >> > >> On Sat, 10 Aug 2013 17:43:25 +0200 Irek Szczesniak 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@... > >>> > 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 > >> > >>> I don't like the name. It implies that all fcntl operations are > >>> possible which is not the case. For example, how do you pass the > >>> return value of fcntl() back to the user and what does it mean? How do > >>> you implement locks, shares, leases with /dev/fcntl? The name is > >>> misleading. > >> > >> fair enough > >> how about "oflags" > > > > apropos oflag yields nothing. /dev/file was better than that one. > > /dev/open would be a choice but that's already taken: > > ls -l /dev/open > > lrwxrwxrwx 1 root root 46 Apr 5 2010 /dev/open -> > > ../../devices/pci@0,0/pci1022,1102@18,2:mc-open
> Grumpf... that's why I proposed /dev/file@ ... all other similar stuff > in /dev is already used-up by Solaris or Linux devices. Crazy enough > there is a /dev/ioctl but no /dev/fcntl ... but I don't like > /dev/fcntl very much because the *only* purpose is to open _files_ > with extra flags (remember the only reason we have this was to get > access to |O_DIRECT| and |O_SYNC| for HPC (=high performance > computing) purposes to circumvent/bypass limitations in other > applications which don't have special flags to use this flags > directly. > |O_DIRECTORY| was later tacked-on because I tought it's usefull and > prevents mishaps in the #ifdef logic of the _original_ prototype patch > (before I added |ENOSYS|/|EINVAL| later) since it assumed that at > least one |O_*| flag must be there. > Can we stick with /dev/file@, please ? fine _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
