On 13.07.2025 19:29, Sergii Dmytruk wrote: > On Tue, Jul 08, 2025 at 08:52:36AM +0200, Jan Beulich wrote: >> On 07.07.2025 19:31, Sergii Dmytruk wrote: >>> On Mon, Jul 07, 2025 at 10:29:46AM +0200, Jan Beulich wrote: >>>>>> ... then isn't used right here, instead requiring a cast somewhere >>>>>> (presumably, >>>>>> as code using this isn't visible in this patch). >>>>> >>>>> As was mentioned earlier: because size of a pointer between Xen and a >>>>> bootloader doesn't necessarily match. What you're proposing can break >>>>> under certain conditions. >>>> >>>> But the header isn't shared with a bootloader's code base. It's private to >>>> Xen. >>> >>> Yes, but sources of Xen be compiled with different size of a pointer >>> which messes up the interpretation of the data. I tried using >>> BUILD_BUG_ON() to enforce the pointer is 64-bit and early code stopped >>> compiling. The structures must not vary like that. >> >> Hmm. Does early code actually need to have this struct exposed to it? > > It doesn't use this particular structure, but it uses some other ones in > the header (also SLRT entries, but of different types). Making a > separate header just to get rid of a cast doesn't seem to be worth it.
Which I also didn't suggest. Didn't I see an EARLY_<something> #define-d somewhere? Couldn't you key exposure of the structure to that not being defined? Jan
