On 5/22/19 1:53 PM, Johannes Lundberg wrote: > On 5/22/19 11:03 AM, Alan Somers wrote: >> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <johalun_at_freebsd.org> wrote: >>> On 5/22/19 10:51 AM, Konstantin Belousov wrote: >>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote: >>>>> Hi >>>>> >>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing >>>>> to a file, >>>>> >>>>> this works: # echo 1 >> /path/to/file >>>>> >>>>> but this does not: # echo 1 > /path/to/file >>>>> >>>>> "Operation not supported." is returned before the pseudofs code is even >>>>> entered. >>>>> >>>>> Is this expected behavior? (if so, why?) >>>> Does the file exist ? >>>> >>>> Pseudofs does not implement VOP_CREATE(), which is reasonable. >>> Yes, it exists and my custom write function is receiving the call for >>> ">>". (which is for example used by drm driver debugfs to do certain >>> things on demand by accepting write to a debugfs file) >> First, you need to try ktrace to see exactly which system call is not >> supported. If the problem still isn't obvious, then you can try >> dtrace to see exactly which VOP isn't suppoted. Do it like this: >> >> sudo ktrace /bin/sh -c "echo 1 > /path/to/file" >> sudo kdump >> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c >> 'echo 1 > /path/to/file/'" >> >> The dtrace command will show you which function returned EOPNOTSUPP. >> However, it will also show a lot of functions that coincidentally >> return 45 even though it's not an errno, and even functions that >> return void. >> >> -Alan > > Thanks! > > It seems, a single '>' will cause it to try to create the file (even > though it already exists) and that fails (kern_openat). > I would guess because of https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042 struct vop_vector pfs_vnodeops = { ... .vop_create = VOP_EOPNOTSUPP, ... }Received on Wed May 22 2019 - 18:57:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC