From: Hannes Reinecke <hare@suse.de> Date: 2021-08-25 14:35:47
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
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?
Hi Hannes,
It is fine for me to receiving a series with 30+ patches in linux-raid
mailing list. And I also can help to review all the patches when they
are posted out.
Hi Jes,
If you are too busy to take care of mdadm, and you are glad, it is OK
for me to take the mdadm maintenance. I can be long term stable for the
maintenance task.
Thanks.
Coly Li
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 [off-list ref] 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
From: Hannes Reinecke <hare@suse.de> Date: 2021-09-14 07:26:47
On 9/14/21 9:08 AM, Xiao Ni wrote:
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.
Sure. Wasn't sure how you'd like to handle it; some prefer smaller
patches, some prefer less patches overall ...
For patch03, the argument is name, but it uses optarg in the function
mdadm_get_layout. Is it an error?
Have to check.
By the way, are there some other users who use the library besides mdadm/mdmon?
Not yet, but there is a program I wrote some time ago
https://github.com/hreinecke/md_monitor.git
which currently does an 'exec' on mdadm, and error handling _that_ is a
major pain. Having a shared library will make life easier there.
And I've some projects planned which would need to leverage mdadm
functionality, so for those a mdadm library would be ideal.
And it's good for me if you send patches directly by email to
linux-raid mail list.
Sure.
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
On Tue, Sep 14, 2021 at 3:26 PM Hannes Reinecke [off-list ref] wrote:
Sure. Wasn't sure how you'd like to handle it; some prefer smaller
patches, some prefer less patches overall ...
Sorry for not describing clearly. I want to say these patches are good
for me. It's better to
put the patches together. For example, patch03, patch04, patch10,
patch20 -> patch01,
patch02, patch03, patch04(The numbers are just examples, not real patch)
Regards
Xiao
Hi Hannes,
It is fine for me to receiving a series with 30+ patches in linux-raid mailing
list. And I also can help to review all the patches when they are posted out.
Hi Jes,
If you are too busy to take care of mdadm, and you are glad, it is OK for me to
take the mdadm maintenance. I can be long term stable for the maintenance task.
Hi Jes,
We have around 40 to 50 patches waiting. We are also waiting for official
4.2 release (it was proposed by me in Jan'21 but it was initially mentioned in
Jul'20!). My preposition for stable release plan was also ignored[1].
I understand that you are busy and mdadm is not in your mind right now.
Coly comes with offer to take care of mdadm, could you answer?
Current model doesn't work, we definitely need to find new solution.
If there any other folk interested in this position, please
speak up loudly!
I will be pleased to cooperate with Coly, or any other maintainer which is
active and responsible. Naturally, VROC team will give support,
especially with external management issues.
It is a time to change something, we shouldn't wait more.
Thanks,
Mariusz
[1]
https://lore.kernel.org/linux-raid/de867ab3-9942-77a0-c14d-dbfc67465888@linux.intel.com/
From: Paul Menzel <hidden> Date: 2021-10-05 09:24:28
Dear Coly, dear Mariusz,
Am 01.10.21 um 12:44 schrieb Tkaczyk, Mariusz:
On 26.08.2021 18:28, Coly Li wrote:
[…]
quoted
Hi Jes,
If you are too busy to take care of mdadm, and you are glad, it is OK
for me to take the mdadm maintenance. I can be long term stable for
the maintenance task.
Hi Jes,
We have around 40 to 50 patches waiting. We are also waiting for official
4.2 release (it was proposed by me in Jan'21 but it was initially
mentioned in
Jul'20!). My preposition for stable release plan was also ignored[1].
I understand that you are busy and mdadm is not in your mind right now.
Coly comes with offer to take care of mdadm, could you answer?
Current model doesn't work, we definitely need to find new solution.
If there any other folk interested in this position, please
speak up loudly!
I will be pleased to cooperate with Coly, or any other maintainer which is
active and responsible. Naturally, VROC team will give support,
especially with external management issues.
It is a time to change something, we shouldn't wait more.
Can you please start a new thread with the offer to become maintainer,
so it does not get lost/buried?
Kind regards,
Paul
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.
Sure. Wasn't sure how you'd like to handle it; some prefer smaller
patches, some prefer less patches overall ...
Sorry I missed this mainly because it had PATCH in the title and I
didn't feel the shared library subject was an urgent issue. I am not
opposed to splitting things into a shared library, in fact I believe I
suggested this to Neil many years ago. I don't remember why it didn't
happen at the time.
That said, I don't think it's something that is appropriate for 4.2, but
rather something to target for 5.0.
For something like this I would prefer smaller patches so it's possible
to bisect our way back if something broke in the process. Jumbo patches
are always wrong.
Cheers,
Jes