[haiku-development] Re: publish_vnode / get_vnode

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 07 Jun 2009 15:34:27 +0200

On 2009-06-07 at 16:36:27 [+0200], Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
> Ingo Weinhold wrote:
> > On 2009-06-07 at 14:22:24 [+0200], Brecht Machiels <brecht@xxxxxxxxxxx> 
> > wrote:
> >> However, from my understanding of the documentation, I do not believe
> >> publish_vnode should be called in this case (just reading a directory).
> >> This seems to be confirmed here:
> >> //www.freelists.org/post/haiku-development/Filesystem-API-documentation,4
> >> I would think that the vfs layer should call my get_vnode() in this
> >> case. Is this correct? My debug output however does not indicate that
> >> this hook is being called.
> > 
> > The get_vnode() hook is actually not triggered by POSIX API that often 
> > (or at
> > all?). It is called mostly only when your file system requests it -- i.e. 
> > you
> > call the VFS's get_vnode() function -- or when via the Be API node_refs or
> > entry_refs are resolved.
> > 
> > The more likely hook to be called during directory iteration is lookup(), 
> > which
> > resolves the entry in directory to a node. On success it does indeed have 
> > to
> > return a new vnode reference, i.e. call the get_vnode() function.
> 
> lookup() doesn't get called either. I suspect there is a bug somewhere
> in the initial setup of the volume or of the root node that is causing
> this. Userlandfs' debug output should provide more clues, I guess.

I believe pretty much the only things that can prevent the lookup() hook from 
being called, are (a) you forgot to add it to the fs_vnode_ops structure you're 
publishing the root node with, or (b) you're publishing the root node with the 
wrong type (should be S_IFDIR obviously).

> >> Ingo told me to enable debug for the userlandfs module. I added the
> >> following to my UserBuildConfig:
> >> SetConfigVar DEBUG : HAIKU_TOP src add-ons kernel file_systems
> >> userlandfs : 1 : global ;
> >> I only seem to get critical warnings in he syslog however. What did I 
> >> miss?
> > 
> > What kind of critical warnings?
> 
> Only when I kill the userlandfs_server:
> KERN: userlandfs [2360672338:  2230] Volume::ReadStat(): connection
> lost, emulating stat for the root node
> KERN: userlandfs [2360681262:  2230] Volume::WriteVNode(): connection
> lost, forcing write vnode
> 
> I seem to remember that more debug info was output when I first started
> messing around with userlandfs, but I'm not sure.

At least those are expected after terminating the server. The userlandfs is 
just 
entertaining the VFS, so it is possible to unmount the volume.

> >> I have tried to find some answers in the available documentation:
> >> * the Haiku Book
> >> * Practical File System Design by D. Giampaolo
> >> * the POSIX specifications on opengroup.org
> >>
> >> Could the Haiku Book documentation be brought up to date to reflect the
> >> recent changes in the fs API?
> > 
> > Though not as complete as it could be, it is up to date. The generated 
> > Haiku
> > Book on factory.haiku-os.org seems to be an old version, though. Just 
> > build a
> > fresh one from the sources. The FS documentation lives in
> > docs/user/drivers/fs_{modules,interface}.dox.
> 
> Sorry for not being very clear. I was referring to bringing the version
> on factory.haiku-os.org up to date. Perhaps that can be done automatically?

I thought they were generated automatically by the build factory, but 
apparently 
not anymore.

> I have now finally taken the time to generate the Haiku Book locally. It
> reads much nicer than the .dox files :)

No kidding. :-)

CU, Ingo

Other related posts: