On Fri, 27 Sep 2013 04:35:46 +0200 Roland Mainz wrote:
> 2013/9/27 Glenn Fowler <[email protected]>:
> > On Fri, 27 Sep 2013 02:17:07 +0200 Roland Mainz wrote:
> >> 2013/9/18 Roland Mainz <[email protected]>:
> >> > 2013/9/17 Glenn Fowler <[email protected]>:
> >> >> On Tue, 17 Sep 2013 21:14:38 +0200 Lionel Cons wrote:
> >> >>> On 17 September 2013 20:49, Glenn Fowler <[email protected]> wrote:
> >> >>> >
> >> >>> > from ksh did you try
> >> >>> >
> >> >>> > getconf name ~{fd}
> >> >>> > getconf name /dev/fd/${fd}
> >> >>
> >> >>> Forwarding the feedback from a coworker:
> >> >>> It may work for AST but it is not legal: ~{fd} expands to /proc, which
> >> >>> is a filesystem, and /dev/fd is a filesystem on Solaris too. What
> >> >>> happens if I want to find the pathconf properties of /proc or /dev/fd
> >> >>> in a POSIX conforming way?
> >> >>
> >> >> if you want to do fpathconf(2) from the command line in a posix
> >> >> conforming way then you can't
> >> >> posix has neither /proc nor /dev/fd
> >> >>
> >> >> now for a useful answer
> >> >> using ~{fd} or /dev/fd will only work for builtins or on systems that
> >> >> support /proc/<pid>/fd/<fd>
> >> >> right now the ksh93 getconf builtin defers to /usr/bin/getconf for most
> >> >> path_var operands
> >> >> those would have to be instead handled by the builtin to handle fds
> >> >>
> >> >> until then something like this should work on most modern unix (with
> >> >> /dev/fd/<fd> support)
> >> >>
> >> >> getconf path_var /dev/fd/0 < ~{fd}
> >> >
> >> > Erm... this can't work (and quick testing&&looking at the Solaris and
> >> > Linux kernel sources confirms it) because |pathconf()|+|fpathconf()|
> >> > is a syscall which is directly forwarded to the matching filesystem
> >> > code in the kernel. The syscall passes the path (string for
> >> > |pathconf(), fd for |fpathconf()|) to the kernel and then the kernel
> >> > looks-up the matching filesystem and then forwards the call to that
> >> > filesystem...
> >> >
> >> > Regardless how hard we try the current getconf(1) API won't work for a
> >> > given fd, e.g. it can't work using /dev/fd/ because /dev/fd is a
> >> > separate filesystem on Solaris and /dev (covering /dev/fd/) on Linux.
> >> > The same applies to ~{fd} which expands to /proc/$currpid/fd/$fd and
> >> > therefore refers to the proc filesystem instead of the filesystem the
> >> > fd is on.
> >> >
> >> > AFAIK the only valid way is to add a --fd option to getconf(1) to deal
> >> > with that trouble because at least the Solaris test suite use
> >> > /usr/bin/getconf to test the devfs and procfs filesystems... which
> >> > means if we implement the AST intercept system to convert a /dev/fd or
> >> > /proc/self/fd/ path to a fd internally to call |fpathconf()| we break
> >> > such tests... ;-(
> >
> > can you list the explicit paths used in these tests
> Erm... Sun never published the main testsuites for Solaris. Polite
> questioning resulted in an awk'ed test run log with the paths
> extracted for _one_ of the tests:
> -- snip --
> /dev/dtrace
> /dev/dtrace/dtrace
> /dev/dtrace/helper
> /dev/dtrace/provider
> /dev/dtrace/provider/dcpc
> /dev/dtrace/provider/fasttrap
> /dev/dtrace/provider/fbt
> /dev/dtrace/provider/lockstat
> /dev/dtrace/provider/lx_systrace
> /dev/dtrace/provider/profile
> /dev/dtrace/provider/sdt
> /dev/dtrace/provider/systrace
> /dev
> /dev/fd
> /dev/fd/${boot}/rpool
> /
> /devices
> /dev
> /system/contract
> /proc
> /etc/mnttab
> /etc/svc/volatile
> /system/object
> /etc/dfs/sharetab
> /lib/libc.so.1
> /dev/fd
> /tmp
> /var/run
> /export
> /export/home
> /export/home/test001
> /rpool
> /home/test001
> /proc/$p/fd/$root/loopmount
> /proc/$p/fd/$root//kernel/
> /proc/$p/fd/$root//kernel/ipp
> /proc/$p/fd/$root//kernel/ipp/amd64
> /proc/$p/fd/$root//kernel/ipp/amd64/ipgpc
> /proc/$p/fd/$root//kernel/ipp/ipgpc
> /proc/$p/fd/$root//kernel/misc
> /proc/$p/fd/$root//kernel/misc/strplumb
> /proc/$p/fd/$root//kernel/misc/ibcm
> /proc/$p/fd/$root//kernel/misc/drm
> /proc/$p/fd/$root//kernel/misc/md_mirror
> /proc/$p/fd/$root//kernel/misc/net80211
> /proc/$p/fd/$root//kernel/misc/pci_autoconfig
> /proc/$p/fd/$root//kernel/misc/kcf
> /proc/$p/fd/$root//kernel/misc/usba10
> /proc/$p/fd/$root//kernel/misc/pcmcia
> /proc/$p/fd/$root//kernel/misc/des
> /proc/$p/fd/$root//kernel/misc/iommulib
> /proc/$p/fd/$root//kernel/misc/uwba
> /proc/$p/fd/$root//kernel/misc/idmap
> /proc/$p/fd/$root//kernel/misc/ksocket
> /proc/$p/fd/$root//kernel/misc/rpcsec_gss
> /proc/$p/fd/$root//kernel/misc/md_trans
> /proc/$p/fd/$root//kernel/misc/fctl
> /proc/$p/fd/$root//kernel/misc/fssnap_if
> /proc/$p/fd/$root//kernel/misc/qlc
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_6322
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_2200
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_2300
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_8100
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_2400
> /proc/$p/fd/$root//kernel/misc/qlc/qlc_fw_2500
> /proc/$p/fd/$root//kernel/misc/qlc/amd64
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_2400
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_8100
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_2500
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_2200
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_6322
> /proc/$p/fd/$root//kernel/misc/qlc/amd64/qlc_fw_2300
> /proc/$p/fd/$root//kernel/misc/s1394
> /proc/$p/fd/$root//kernel/misc/ibdm
> /proc/$p/fd/$root//kernel/misc/acpica
> /proc/$p/fd/$root//kernel/misc/emlxs
> /proc/$p/fd/$root//kernel/misc/emlxs/amd64
> /proc/$p/fd/$root//kernel/misc/emlxs/amd64/emlxs_fw
> /proc/$p/fd/$root//kernel/misc/emlxs/emlxs_fw
> /proc/$p/fd/$root//kernel/misc/agpmaster
> /proc/$p/fd/$root//kernel/misc/sata
> /proc/$p/fd/$root//kernel/misc/usbser
> /proc/$p/fd/$root//kernel/misc/pcihp
> /proc/$p/fd/$root//kernel/misc/scsi_vhci
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_sym_emc
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_sym
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_tpgs
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_tape
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_asym_lsi
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_asym_emc
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_tpgs_tape
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_sym
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_tpgs_tape
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_sym_emc
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_tpgs
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_tape
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_sym_hds
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_asym_sun
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_asym_lsi
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/amd64/scsi_vhci_f_asym_emc
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_sym_hds
> /proc/$p/fd/$root//kernel/misc/scsi_vhci/scsi_vhci_f_asym_sun
> /proc/$p/fd/$root//kernel/misc/dls
> /proc/$p/fd/$root//kernel/misc/gld
> /proc/$p/fd/$root//kernel/misc/md_stripe
> /proc/$p/fd/$root//kernel/misc/kmdbmod
> /proc/$p/fd/$root//kernel/misc/ctf
> /proc/$p/fd/$root//kernel/misc/bignum
> /proc/$p/fd/$root//kernel/misc/pmcs
> /proc/$p/fd/$root//kernel/misc/pmcs/amd64
> /proc/$p/fd/$root//kernel/misc/pmcs/amd64/pmcs8001fw
> /proc/$p/fd/$root//kernel/misc/pmcs/pmcs8001fw
> /proc/$p/fd/$root//kernel/misc/tlimod
> /proc/$p/fd/$root//kernel/misc/cardbus
> /proc/$p/fd/$root//kernel/misc/amd64
> /proc/$p/fd/$root//kernel/misc/amd64/strplumb
> /proc/$p/fd/$root//kernel/misc/amd64/ipc
> /proc/$p/fd/$root//kernel/misc/amd64/uathfw
> /proc/$p/fd/$root//kernel/misc/amd64/net80211
> /proc/$p/fd/$root//kernel/misc/amd64/sata
> /proc/$p/fd/$root//kernel/misc/amd64/hidparser
> /proc/$p/fd/$root//kernel/misc/amd64/ctf
> /proc/$p/fd/$root//kernel/misc/amd64/iommulib
> /proc/$p/fd/$root//kernel/misc/amd64/idmap
> -- snip --
> There are also automounter tests which do testing for /net, where
> /net/<IP-address>/remote-path can automagically mount NFS filesystems
> as plain user.
> > I can see
> > /dev/fd
> > /proc/self/fd
> > referring to the specific filesystem
> > but why would
> > /dev/fd/${fd}/foo
> > /proc/self/fd/${fd}/foo
> > stop at the fs and not resolve through ${fd} to foo
> > or why whould these stop at the fs and not the ${fd}
> > /dev/fd/${fd}/foo
> > /proc/self/fd/${fd}/foo
> > is this just an incomplete implementation of /dev/fd and /proc/${pid}/fd?
> No... I went to the Sun^H^H^HOracle people for an explanation:
> The issue is:
> ... some of the pathconf _PC_* values probe the file system itself.
> Using a file descriptor through /dev/fd or /proc/self/fd/$fd MUST -
> required by POSIX - always test the file system specified - which is
> either devfs or procfs. Link redirects, including soft- and hard links
> and NTFS/CIFS/NFSv4 reparse points, do not apply here, with the
> exception of lofs, which is a real filesystem but may pass some
> pathconf/fpathconf requests through to the parent file system ...
> -- snip --
> That's the more or less official Sun judgment.
> BTW: lofs is the loopback filesystem... it works similar to a softlink
> but can be mounted and then looks&&acts like a real filesystem. This
> is used by the automounter to maintain /home in Solaris, e.g. if you
> to to /home/foo the automounter will look at /etc/auto_home and
> figures it the real location of that home directory (for example
> /export/home/foo) and then mounts lofs as /home/foo which redirects
> requests to /export/home/foo.
> So we're basically in trouble if we only have a fd and want to do
> pathconf with that through getconf(1). The issue is actually known and
> the Solaris bug db has a bug entry for that trouble. The proposed
> solution is... erm... "... add -f <fd> to pass a file descriptor to
> fpathconf()..."
thanks
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
