On Sun, Oct 08, 2023 at 12:41:42PM +0200, Milan Broz wrote: > On 10/6/23 20:44, Alan Stern wrote: > > Okay, this one is a bit of a mess. Unavoidably so, I'm afraid. > > yes. What I need to know if it is acceptable approach (I spent quite > a lot of time on it and still have no better idea... At least with > a patch that is not too invasive). Yes, the basic idea is acceptable (subject to the comments in my earlier email). In fact, it's probably the best we can do, given the constraints we face. > Here I compared generated tables with old pre-processor generated > and it looks the same. (Also I keep it on kernel.org branch, so > 0-day bot reports obvious mistakes.) > > ... > > > > This translation is unnecessary for a 64-bit system, but I keep it > > > in place for simplicity. > > > (Also, I did not find a reliable way a host-compiled program can detect > > > that the target platform has 32-bit unsigned long (usual macros do not > > > work here!). > > > > How about testing CONFIG_64BIT? Would that not do what you want? > > Yes, that was my last idea too, but I am not sure if it correct (and I have > no longer access to more exotic platforms to check it). I'm reasonably sure that it's the right thing to check. > Also using kernel config defines in host-compiled code is tricky, but > it should be possible. Yeah; I'm not certain about how to do it. One possibility is simply to parse the .config file directly at runtime, if the Kbuild system doesn't provide the CONFIG_* macros when compiling a host program. > I will try to ask my former colleagues, though. > > > However, I agree that it's better to keep things simple by using the > > same code base for 32-bit and 64-bit kernels. > > Yes, that was my plan for now. So you want to keep it as it is? > > We can add optimization for 64-bit with additional patch later, it should be > pretty easy once I know how to detect that target platform really has > 64-bit unsigned long so no translation is needed. Yes, I agree that this is the approach we should take. Alan Stern
