On 10/29/25 16:09, BALATON Zoltan wrote:
On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
On 10/29/25 15:28, BALATON Zoltan wrote:
On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
+ Thomas
Hi BALATON,
I am unable to fetch it with b4 am, and I do not see it appear on
lore also, not sure if its due to the binary size.
harshpb:patches$ b4 am [email protected]
Looking up
https://lore.kernel.org/r/20251028151923.10DBB5972E5%40zero.eik.bme.hu
Grabbing thread from
lore.kernel.org/all/20251028151923.10DBB5972E5%40zero.eik.bme.hu/t.mbox.gz
Server returned an error: 404
harshpb:patches$
I guess you may need to send a PULL SUBSYSTEM req like Thomas did
for slof:
https://lore.kernel.org/qemu-devel/[email protected]/
Hi Harsh,
You should be able to download mbox from
https://patchew.org/QEMU/[email protected]/
and git am that. This was tested by somebody else and worked.
Yes, git fetch from there seems to work, thanks.
If needed
I could try to split the binary into another patch or send you the
patch again. Maybe lore does not store large files?
Having only binary file update into its own separate patch may be better
as a best practice, so other patch gets non-binary changes for easy
review.
Also, maintaining the date stamp may also be helpful in some cases.
Let me know if you think otherwise.
Which date stamp maintaining are you referring to? I can split the patch
in two later today or tomorrow if you want and send a v2 but not right
now. For that to compile and work after each patch it would need to add
the new binary in one patch then remove the old one after changing its
usage. Or maybe even 3 patches: first updating submodule, then adding
binary rebuilt from that then changing usage and removing old one. I
think this would make the series larger as git now seems to contain
binary diff between old and new versions but if these are in different
patch it may still add the removed binary as a binary patch. So this
only works if the old and new binary is the same name or renamed in one
patch but then that would break if the usage is not updated in the same
patch. So maybe patch one to update submodule, patch 2 to add binary
with old name and patch 3 to rename the binary could work but does that
worth the hassle and any better than this single patch?
I was referring to the version number in binary name as date stamp which
is being removed, but that's fine. I think we can take this patch as-is
for now as split doesn't add much value and also we are close to freeze.
regards,
Harsh
Regards,
BALATON Zoltan
