Subject: Re: code to store the path of the executable in struct proc...
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 09/23/2007 22:02:47
Content-Type: text/plain; charset=us-ascii
On Sun, Sep 23, 2007 at 07:41:03PM -0400, der Mouse wrote:
> > I've been thinking of rewriting the name cache. The changes I have
> > in mind would allow you to always get the path for a file.
> That sounds like a very drastic change to the traditional Unix model,
> in which files don't have names; rather, links to files have names, and
> links can come and go without disturbing the files they are links to.
> If files always have paths, and, worse, there is a "*the* path" for a
> file, something very fundamental has changed.
> Will you also be providing replacements for existing filesystems? FFS,
> at least, has the "names are attached to links, not files" model wired
> fairly deeply into its on-disk data structures.
I'm sorry, but did you read the text you quoted? Jason described a desire
to re-write the name cache, which is an in-kernel entity. I fail to see
how changing it translates into changing (or needing to change) the
on-disk format(s) of our file system(s).
There are a number of times (see the stuff that got this thread started=20
for instance) where we really need to be able to get a path for a file.=20
Being able to get the paths (i.e. correctly handling hardlinks both in the=
kernel side of this and in the libraries that use it) is best, but just=20
being able to get a path is important.
So we have a need now. We have a developer expressing a desire to address
that need. I suggest we wait for code to be offered before reacting to
details the not-yet-offered implementation may or may not posess.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----