On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
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.
As I wrote in the commit message it seems having that in binary name would
just cause problems when updating it so I use this opportunity to get rid
of it. Other binaries don't seem to have such version either. (Also the
old one was named with date stamp upstream but the new one is version
2015.c which was changed upstream so it would be changing anyway).
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.
Thanks. I'll try the split patches when the firmware is updated next time
in the future but not having to redo it now saves me some time.
Regards,
BALATON Zoltan
