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