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()..."
----
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
