linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Cedric Blancher <cedric.blancher@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: d_genocide()? What about d_holodomor(), d_massmurder(), d_execute_warcrimes()? Re: [PATCH 15/20] d_genocide(): move the extern into fs/internal.h
Date: Fri, 24 Nov 2023 10:36:05 +0100	[thread overview]
Message-ID: <10399078.nUPlyArG6x@lichtvoll.de> (raw)
In-Reply-To: <20231124074856.GA581958@ZenIV>

Al Viro - 24.11.23, 08:48:57 CET:
> On Fri, Nov 24, 2023 at 06:57:59AM +0000, Al Viro wrote:
> > > > +extern void d_genocide(struct dentry *);
> > > 
> > > Seriously, who came up with THAT name? "Genocide" is not a nice
> > > term,
> > > not even if you ignore political correctness.
> > > Or what will be next? d_holodomor()? d_massmurder()?
> > > d_execute_warcrimes()?> 
> > kill_them_all(), on the account of that being what it's doing?
> 
> 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.

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. 

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

Similar it is with the term children or parent. There are no children in 
computer software. Period. But here it may be more difficult to find 
alternative wording. Would still be good to find something, cause I was 
quite taken aback by the wording of the OOM killer. (Actually I was taken 
aback that an operating system could even have something that forcefully 
quits a process without saving data. It never matched my expectations of 
reliability and stability.)

So how about stopping to put meaning into computer software source code 
that simply is not there to begin with? How about starting to use terms 
that describe what is actually being done and what is actually there?

-- 
Martin



  reply	other threads:[~2023-11-24  9:41 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 [this message]
2023-11-24 18:21             ` identifiers Al Viro
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=10399078.nUPlyArG6x@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=cedric.blancher@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).