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).Received on Wed May 22 2019 - 18:53:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC