On Wed, May 22, 2019 at 12:03:00PM -0600, 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. You can also trace VOPs with vfs::vop_*:return. The return value is in args[2].Received on Wed May 22 2019 - 19:04:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC