From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: colyli@suse.de, linux-raid@vger.kernel.org
Subject: Re: [PATCH 2/3] mdadm: refactor ident->name handling
Date: Mon, 9 Jan 2023 11:51:16 +0100 [thread overview]
Message-ID: <20230109115116.00005862@linux.intel.com> (raw)
In-Reply-To: <20221229103931.00006ff0@linux.intel.com>
On Thu, 29 Dec 2022 10:39:31 +0100
Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> wrote:
> On Wed, 28 Dec 2022 10:07:22 -0500
> Jes Sorensen <jes@trained-monkey.org> wrote:
>
> > On 12/21/22 06:50, Mariusz Tkaczyk wrote:
> > > Move duplicated code for both config.c and mdadm.c to new functions.
> > > Add error enum in mdadm.h. Use MD_NAME_MAX instead hardcoded value
> > > in mddev_ident. Use secure functions.
> > >
> > > In next patch POSIX validation is added.
> > >
> > > Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
> >
> > Hi Mariusz,
> >
> > I appreciate the work to consolidate duplicate code. However, I am not a
> > fan of new typedefs, in addition you return status_t codes in functions
> > changed to return error_t, which is inconsistent.
>
> Hi Jes,
> Indeed, initially I named it as error_t and I forgot to update that part.
> I'm surprised that compiler didn't catch it. Thanks!
>
> About typedef, I did it same for IMSM already:
> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/super-intel.c#n376
> I can change that but I wanted to define a common solution propagated later to
> other mdadm parts.
>
> >
> > I would prefer if we move towards standard POSIX error codes instead of
> > trying to invent new ones.
> >
>
> The POSIX errors are defined for communication with kernel space and
> unfortunately they are not detailed enough. For example "undefined" or
> just "general_error" statuses are not available.
> https://man7.org/linux/man-pages/man3/errno.3.html
> It the approach I proposed we are free to create exact errors we need.
> Later we can create a map of error values to string and create dedicated
> error print functions.
>
Hi Jes,
Should I drop this enum in v2?
Thanks,
Mariusz
next prev parent reply other threads:[~2023-01-09 10:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 11:50 [PATCH 0/3] Validation for names during creation Mariusz Tkaczyk
2022-12-21 11:50 ` [PATCH 1/3] mdadm: create ident_init() Mariusz Tkaczyk
2022-12-28 15:05 ` Jes Sorensen
2022-12-21 11:50 ` [PATCH 2/3] mdadm: refactor ident->name handling Mariusz Tkaczyk
2022-12-28 15:07 ` Jes Sorensen
2022-12-29 9:39 ` Mariusz Tkaczyk
2023-01-09 10:51 ` Mariusz Tkaczyk [this message]
2023-03-02 14:52 ` Jes Sorensen
2023-03-03 12:04 ` Mariusz Tkaczyk
2023-03-08 19:04 ` Jes Sorensen
2023-03-09 8:02 ` Mariusz Tkaczyk
2023-03-10 14:43 ` Jes Sorensen
2022-12-21 11:50 ` [PATCH 3/3] Limit length and set of characters allowed of devname Mariusz Tkaczyk
2023-03-13 14:22 ` Jes Sorensen
2023-03-14 8:14 ` Mariusz Tkaczyk
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=20230109115116.00005862@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=colyli@suse.de \
--cc=jes@trained-monkey.org \
--cc=linux-raid@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.