All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Ni <xni@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Jes Sorensen <jsorensen@fb.com>, Coly Li <colyli@suse.de>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: [PATCH] mdadm: split off shared library
Date: Tue, 14 Sep 2021 15:08:58 +0800	[thread overview]
Message-ID: <CALTww29nZV4A1BM_ShrmL1ud4YZC2YTG8q4LvW8pfhZwb=MhVQ@mail.gmail.com> (raw)
In-Reply-To: <7461b27b-2a4b-fbbb-5cfd-8fab416cbc9f@suse.de>

Hi Hannes

Thanks for these patches. It's a good idea to make codes more clearly
that which codes belong to which file.
There are many efforts that move codes from mdadm.c and mdadm.h to
specific files. Is it better to put these
patches together? For example, the patches(6, 11, 12, 16, 19, 20, 27,
28) try to clean mdadm.c. Could you put
similar patches together? And there are some rename patches too, they
are sporadic.

For patch03, the argument is name, but it uses optarg in the function
mdadm_get_layout. Is it an error?

By the way, are there some other users who use the library besides mdadm/mdmon?

And it's good for me if you send patches directly by email to
linux-raid mail list.

Best Regards
Xiao

On Wed, Aug 25, 2021 at 10:35 PM Hannes Reinecke <hare@suse.de> wrote:
>
> Hi all,
>
> this is, contrary to the subject, not a patch, but rather a question on
> how to submit a patchset.
> I've been working on splitting off a shared library from mdadm, with the
> aim that it can be included from other programs.
> Reasoning behind it that I've written a monitor program
> (github.com:/hreinecke/md_monitor) and found it a major pain having to
> exec() mdadm, and then keep fingers crossed that things succeed; error
> recovery from _that_ turned out to be a major drag. And so I figured
> that a shared library is possibly the best way to go.
>
> (And, as a side note: having a shared library would also allow to build
> a python binding, which possibly will have even more use-cases ...)
>
> So I've build a patchset to split off a shared library from mdadm, and
> build mdadm against that:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hare/mdadm.git
> branch shlib
>
> But as it turns out, these are 30+ patches, and I didn't want to flood
> the mailinglist with that.
> So what are the procedures here?
>
> Are you okay with having the entire patchset on the mailing list?
> Or are there other ways?
>
> Thanks for your help.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                        Kernel Storage Architect
> hare@suse.de                                      +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
>


  parent reply	other threads:[~2021-09-14  7:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25 14:35 [PATCH] mdadm: split off shared library Hannes Reinecke
2021-08-26 16:28 ` Coly Li
2021-10-01 10:44   ` Tkaczyk, Mariusz
2021-10-05  9:24     ` Paul Menzel
2021-09-14  7:08 ` Xiao Ni [this message]
2021-09-14  7:26   ` Hannes Reinecke
2021-09-14  7:56     ` Xiao Ni
2021-10-06 10:58     ` Jes Sorensen

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='CALTww29nZV4A1BM_ShrmL1ud4YZC2YTG8q4LvW8pfhZwb=MhVQ@mail.gmail.com' \
    --to=xni@redhat.com \
    --cc=colyli@suse.de \
    --cc=hare@suse.de \
    --cc=jsorensen@fb.com \
    --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.