name cache (was Re[4]: vn_fullpath())

Igor Shmukler shmukler at mail.ru
Sun Mar 27 07:31:43 PST 2005


> On FreeBSD, this occurs because devfs doesn't use the name cache.  Two
> easy solutions are:
>
> - Use the name cache in devfs.  This would have to be done carefully in
>   the context of cloning, etc, but should work out.
>
> - Add a VOP/VFS operation to help figure out a pathname with the help of
>   the file system, and implement it for devfs.  This would avoid having to
>   deal with cache invalidation issues in devfs.

I would prefer whatever would be a lowest impact uniform (for different FSs) 
solution. I will start looking into this issue.

> I'm not familiar with this issue specifically.  Normally these descriptors
> point to tty's (unnamed due to devfs issues above) and pipes (no name),
> which would generally explain the issues.  However, the >my.file case is a
> bit concerning.  Could you confirm that the file descriptor in that case
> is definitely pointed at a vnode?

I will do this. I would like to point out ( guess I was not clear the first time). 
That even if std[in/out/err] is VREG, not VCHR after child process inhereted this 
descriptor vn_fullpath() does not work.

I understand that this sounds fishy, because fd simply points to vnode, but that the 
impression for now. If one closes a "standard" descriptor then opens a file, it does 
work, but seems not to survive through inheritance.

I will follow-up with more information on this. Maybe, files issue for 0..2 is a 
just a product of imagination :)

> Linux does something a little different in how they maintain references to

I am aware that Linux dentry/inode/cache are different, but I was asking this for a 
simple (selfish) reason. If there is a concesus that d_path() like functionality [in 
a black-box way i.e. let's forget how it is implemented] would be very helpful, then 
I think if a patch was made it might be committed before 5.5 is out. In that case, I 
would try to work on this and/or even ask my colleagues to help with coding/testing. 
If this is viewed as an obscure feature that will not be included anytime soon, I 
would remove from my agenda for now.

I thank you Robert and everyone else who spent time reading this thread and thinking 
about this whole issue.

Thank you,

Igor


More information about the freebsd-hackers mailing list