From: Jeremy Bingham <jbingham@gmail.com>
To: jkoolstra@xs4all.nl
Cc: brauner@kernel.org, jack@suse.cz, jbingham@gmail.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] minix: define constants for dirsize and namelen
Date: Tue, 7 Jul 2026 09:54:38 -0700 [thread overview]
Message-ID: <20260707165438.590667-1-jbingham@gmail.com> (raw)
In-Reply-To: <942891560.128364.1783370852771@kpc.webmail.kpnmail.nl>
On Mon, Jul 6, 2026 at 1:47 PM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
>
>> Op 06-07-2026 20:22 CEST schreef Jeremy Bingham <jbingham@gmail.com>:
> Hi Jeremy,
>
> Thanks for taking the time to look at minix. I have a particular fondness of the
> filesystem, so I am happy someone takes an interest.
Thanks. I think it's kind of neat to have it around too.
> However, I don't like this series. There is no reason for all this churn or the
> exorbitant amount of comments. If you can get iomap to work that would be great,
> but please don't do this.
>
> Thanks,
> Jori.
These two patch series were the only other things I had besides the iomap
patch series. This one in particular I'm not super attached to, but I had
noticed the bare numbers there while working on iomap. I wrote the minix.h
patch in this same series because checkpatch.pl kept griping about the
function declarations on the lines I had changed, and since it was a bit
of a hodgepodge of different styles I thought it might be worth doing
something about it. Changing all the function declarations was out of
scope for the iomap series, though, which is why I did it separately here.
The other RFC patch, which unifies the itree_v1.c, itree_v2.c, and
itree_common.c files, was inspired by Darrick's comment in the iomap patch
series about how the way the v1 and v2 files have specific definitions and
include the common file was "/one/ way to avoid having a geometry struct
capturing those details". That got me thinking about how not having to
worry about the different v1 and v2 definitions and just unifying those
three files into one, but since that would also be (very) out of scope
with iomap I made that RFC patch separately.
In re: the exorbitant comments, I had those in the RFC to explain what
I was doing and why. If the RFC patch was well received, I would of course
resubmit it with the comments significantly pared down. That patch would
make the iomap conversion easier, but it isn't required. Since that RFC
patch would be nice, but isn't necessary, I wanted to put it out there and
get comments on it separately rather than trying to fold it in to the
iomap patches. In the future, though, should I find myself submitting
another RFC patch I'll keep the explanations in the cover letters and
commit messages unless absolutely necessary.
Iomap and minix do work now. I just need to address Darrick's critiques of
it before submitting it again. Since these two most recent patch series of
mine were indirectly related but not required for iomap support, I broke
them out into their own patches.
Thank you for the comments, and if there's anything else you think I
should address I would love to hear it.
-j
next prev parent reply other threads:[~2026-07-07 16:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 18:22 [PATCH 0/2] minix: modernize function declarations and eliminating some magic numbers Jeremy Bingham
2026-07-06 18:22 ` [PATCH 1/2] minix: define constants for dirsize and namelen Jeremy Bingham
2026-07-06 20:47 ` Jori Koolstra
2026-07-07 16:54 ` Jeremy Bingham [this message]
2026-07-06 18:22 ` [PATCH 2/2] minix: modernize function declarations in minix.h Jeremy Bingham
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=20260707165438.590667-1-jbingham@gmail.com \
--to=jbingham@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jkoolstra@xs4all.nl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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