Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Mar 2005 19:31:41 +0400
From:      Igor Shmukler <shmukler@mail.ru>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        hackers@freebsd.org
Subject:   Re[2]: name cache (was Re[4]: vn_fullpath())
Message-ID:  <E1DFZjp-000Fvk-00.shmukler-mail-ru@f24.mail.ru>
In-Reply-To: <Pine.NEB.3.96L.1050327133659.49800A-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1DFZjp-000Fvk-00.shmukler-mail-ru>