On Fri, 29 Jul 2022, Boyoun Park wrote: > I really appreciate all the comments and reviews. > I understand that it is hard to add this patch without any usage. > > On Fri, 29 Jul 2022, Stefano Stabellini: > > On Thu, 28 Jul 2022, Jan Beulich wrote: > > > On 28.07.2022 11:22, Boyoun Park wrote: > > > > Hello, > > > > > > > > This patch added late_initcall to deal with > > > > > > > > some init functions which should be called > > > > > > > > after other init functions in start_xen. > > > > > > > > If this patch is added, > > > > > > > > then the original initcall in xen will be treated > > > > > > > > as early_initcall and the late_initcall > > > > > > > > which is added by this patch will be > > > > > > > > called sequentially. > > > > > > > > I cannot send patches through git send-email > > > > > > > > due to some security issues in my work. > > > > > > > > So intead, I just send the patches manually. > > > > > > Which is fine, but you want to configure your mail client such that it > > > doesn't mangle the patch. Albeit I see that to cover for that at least > > > you've also attached both the patch and a cover letter. For a single > > > patch a cover letter can normally be omitted, but if you don't then > > > even if you're sending without "git send-email" you will want to send > > > both as separate mails, with the patch being a reply to the cover > > > letter thread root. > > > > Yeah. Boyoun, if you only have a couple of patches then it is fine to > > send them manually. Otherwise, if you have many patches, you can send > > them in attachment as tarball and I'll send them all to xen-devel using > > git-send-email for you (of course keeping you as original author and > > retaining all Signed-off-bys). > > You're awesome. Thanks you so much. I'm still requesting approvals to use git > send-email. > I'll let you know if I have to send many patches wihout git send-email. > > > > > Subject: [PATCH v1] xen: add late init call in start_xen > > > > > > > > This patch added late_initcall section in init.data. > > > > > > > > The late initcall would be called after initcall > > > > > > > > in the start_xen function. > > > > > > > > Some initializing works on priority should be run > > > > > > > > in do_initcalls and other non-prioritized works > > > > > > > > would be run in do_late_initcalls. > > > > > > > > To call some functions by late_initcall, > > > > > > > > then it is possible by using > > > > > > > > __late_initcall(/*Function Name*/); > > > > > > > > Signed-off-by: Boyoun Park <boyoun.p...@samsung.com> > > > > > > So I could imagine this patch to be in a series where a subsequent > > > patch then adds an actual use of the new functionality. Without > > > that what you're proposing is to add dead code. > > > > Yeah, I think it would be cool to have late initcalls but it makes sense > > to add them if we have someone that makes use of them. > > I totally agree with your comments. Some drivers that I'm developing now and > use this function are specific to my hardware environment. > Thus, it seems difficult to arrange them in the near future. > I will update patches if I can suggest an actual use.
I totally understand custom setups and non-upstreamable configurations and I have certainly some of them myself. However, I just wanted to let you know that we are fine with accepting platform specific drivers in Xen where it makes sense, for instance: - Renesas IPMMU-VMSA found in R-Car Gen3/Gen4 SoCs (an IOMMU driver) xen/drivers/passthrough/arm/ipmmu-vmsa.c - Xilinx EEMI firmware interface "mediator" in Xen (power management) xen/arch/arm/platforms/xilinx-zynqmp-eemi.c Cheers, Stefano
