archive mirror
 help / color / mirror / Atom feed
From: Al Viro <>
To: Martin Steigerwald <>
Cc: Cedric Blancher <>,
	linux-fsdevel <>,
	Linux Kernel Mailing List <>
Subject: Re: identifiers
Date: Fri, 24 Nov 2023 18:21:37 +0000	[thread overview]
Message-ID: <20231124182137.GX38156@ZenIV> (raw)
In-Reply-To: <>

[search bait removed from subject]
On Fri, Nov 24, 2023 at 10:36:05AM +0100, Martin Steigerwald wrote:
> Al Viro - 24.11.23, 08:48:57 CET:
> > To elaborate a bit: what that function does (well, tries to do - it has
> > serious limitations, which is why there is only one caller remaining and
> > that one is used only when nothing else can access the filesystem
> > anymore) is "kill given dentry, along with all its children, all their
> > children, etc."
> I never got why in the context of computers anything is ever being killed. 
> It does not live to begin with.

Simple - one deals with objects that have complex lifecycle, with very
different possible behaviour at various stages.  And about the only
example of such that would be well-covered in natural languages is
just that - both in adjectives for states and verbs for transitions between

Note that the word "lifecycle" itself is rather commonly used outside
of biological context.

> You can stop something, remove it, delete it, destroy it, pause it, resume 
> it, overwrite it and you can do it really quickly or (almost) instantly or 
> slowly or recursively or some combination of those, but kill? You cannot 
> kill what does not live. 

Why?  "Do something that changes the state of target into one in which
the target gradually becomes incapable of normal activity until it goes
completely inert and eventually disappears, with its parts recycled for
unrelated objects" vs. "kill the target", with associated transitional
state being refered to as "dying"?

Your suggestions all refer to operation rather than state transition.

> d_delete/destroy/remove_recursively() could be a suitable function name. 
> Pick one.

Thanks, but no thanks.  d_delete() already exists and refers to rather
different operation; "destroy" in such contexts would be loaded with
an existing technical meaning, and that would be actively confusing;
"remove_recursively"?  Guess what the better-behaving replacement (far
too heavy-weight for the only remaining use) is called?  "simple_recursive_removal".
It does more than this one, though.

> Similar it is with the term children or parent. There are no children in 
> computer software. Period.

Well-asserted.  Unfortunately, the statement is wrong - "parents" and
"children" have specific meanings when applied to nodes of directed graphs.
And there's a plenty of those dealt with by software.  Directory tree, in

  reply	other threads:[~2023-11-24 18:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24  6:05 [PATCHES] assorted dcache stuff Al Viro
2023-11-24  6:06 ` [PATCH 01/20] selinux: saner handling of policy reloads Al Viro
2023-11-24  6:06   ` [PATCH 02/20] ovl: stop using d_alloc_anon()/d_instantiate_anon() Al Viro
2023-11-24  6:06   ` [PATCH 03/20] struct dentry: get rid of randomize_layout idiocy Al Viro
2023-11-24  6:06   ` [PATCH 04/20] get rid of __dget() Al Viro
2023-11-24  6:06   ` [PATCH 05/20] DCACHE_... ->d_flags bits: switch to BIT() Al Viro
2023-11-24  6:06   ` [PATCH 06/20] DCACHE_COOKIE: RIP Al Viro
2023-11-24  6:06   ` [PATCH 07/20] kill d_{is,set}_fallthru() Al Viro
2023-11-24  6:06   ` [PATCH 08/20] dentry.h: trim externs Al Viro
2023-11-24  6:06   ` [PATCH 09/20] [software coproarchaeology] dentry.h: kill a mysterious comment Al Viro
2023-11-24  7:37     ` Amir Goldstein
2023-11-24  8:11       ` Al Viro
2023-11-24  8:26         ` Al Viro
2023-11-24  8:29           ` Christian Brauner
2023-11-24  6:06   ` [PATCH 10/20] kill d_backing_dentry() Al Viro
2023-11-24  6:06   ` [PATCH 11/20] kill d_instantate_anon(), fold __d_instantiate_anon() into remaining caller Al Viro
2023-11-24  6:06   ` [PATCH 12/20] d_alloc_pseudo(): move setting ->d_op there from the (sole) caller Al Viro
2023-11-24  6:06   ` [PATCH 13/20] nsfs: use d_make_root() Al Viro
2023-11-24  6:06   ` [PATCH 14/20] simple_fill_super(): don't bother with d_genocide() on failure Al Viro
2023-11-24  6:06   ` [PATCH 15/20] d_genocide(): move the extern into fs/internal.h Al Viro
2023-11-24  6:35     ` d_genocide()? What about d_holodomor(), d_massmurder(), d_execute_warcrimes()? " Cedric Blancher
2023-11-24  6:57       ` Al Viro
2023-11-24  7:48         ` Al Viro
2023-11-24  9:36           ` Martin Steigerwald
2023-11-24 18:21             ` Al Viro [this message]
2023-11-24  6:06   ` [PATCH 16/20] get rid of DCACHE_GENOCIDE Al Viro
2023-11-24  6:06   ` [PATCH 17/20] d_alloc_parallel(): in-lookup hash insertion doesn't need an RCU variant Al Viro
2023-11-24  6:06   ` [PATCH 18/20] __d_unalias() doesn't use inode argument Al Viro
2023-11-24  6:06   ` [PATCH 19/20] kill DCACHE_MAY_FREE Al Viro
2023-11-24  6:06   ` [PATCH 20/20] dcache: remove unnecessary NULL check in dget_dlock() Al Viro
2023-11-24 21:41 ` [PATCHES] assorted dcache stuff Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231124182137.GX38156@ZenIV \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).