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/24/2007 11:13:17
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 24, 2007 at 01:05:55AM -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 [...]
> >> 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?
> Yes. Did *you* read the text *you* quoted?
Yes I did. Obviously not the same way you did.
> > 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).
> Because arranging that files always have a path, and, what's more, have
> a "the path", is a very fundamental change to filesystem semantics, one
> that as far as I can see is incompatible with FFS on disk. Regardless
> of the means by which this end is achieved. (He can't possibly create
> the ability to "always get the path for a file" without, at the very
> least, breaking the ability to have files with no paths naming them, no
> matter what he is or isn't hacking on.)
> > There are a number of times (see the stuff that got this thread
> > started for instance) where we really need to be able to get a path
> > for a file.
> Well, I'm sorry, then you want something that is not very much like
> Unix. Unix simply does not support that operation, and never has; it
> has always been possible to have files that have no paths at all that
> name them.
> > 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.
> Anything that satisfies the desire described - to always be able to get
> "the path" for a file - implies a very deep change to the filesystem
> semantics, and one that's incompatible with, at least, FFS - since in
> FFS files don't have names; rather, links to files have names, and
> there is no way quicker than searching the entire filesystem to find
> another link if the one you have is unlinked, nor does the concept of
> "the path" for a file make sense unless it happens to have exactly one
> Perhaps Jason meant "find a [not `the'] path for a file, provided it
> hasn't been unlinked or renamed yet". But that's not what he wrote,
> and, based on what you write, it's not what you want, nor is it what he
> wants (to be pedantic, what you think he wants; I assume you're
> correct). Perhaps Jason meant "find the path via which an open file
> was opened". Perhaps Jason meant "find the path to a file in almost
> all cases, and we choose to let the facility using this break in the
> cases where it doesn't work". But those aren't what he wrote either.
> What he *did* write seems to me to be fundamentally incompatible with
> Unix filesystem semantics, including the basic design of the on-disk
> data structures for what is probably our most popular filesystem.
Wow. You sure ran that into a corner.
I don't see the incompatability in what Jason said. I also don't take what=
Jason said to be what you read into what he said. You read a lot of detail=
into what he said and what you feel he didn't say. I didn't take his=20
comment as trying to be that precise, thus the level of detail you are=20
splitting hairs over wasn't on the table.
So how about we wait for actual code before trying to shoot it down?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----