Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > Date: Thu, 11 Jun 2020 17:29:44 +0200 > > From: Christian Weisgerber <na...@mips.inka.de> > > > > Paul Irofti: > > > > > > Paul, that tk_nclocks addition isn't useful. You need to do the > > > > bounds checking against the number of clocks you have implemented in > > > > libc. How many clocks the kernel has implemented doesn't matter. > > > > > > What you are saying is that we could be in a situation where the kernel > > > might expose 3 clocks but we only have 2 entries in libc? Why would we get > > > to that point? When someone changes the clock in the kernel, that means it > > > is also changed in libc. I don't think we can decouple the two parts. > > > Right? > > > > But we do: make kernel; install kernel; reboot; make build. > > > > To cross from nclocks to nclocks+1, you need to run the new nclocks+1 > > kernel with an nclocks userland. > > > > I keep coming back to the idea that we need an <machine/timetc.h> > > header with > > > > #define TC_FOO 1 > > #define TC_BAR 2 > > #define TC_NUM 3 /* or TC_LAST or whatever */ > > > > Mark may have a better idea how to name this. > > I think <machine/timetc.h> is fine. Architectures without exportable > timecounters could just do > > #define TC_LAST 0 > > (I do think TC_LAST is a bit better for this reason).
What is the cause of all this complex versioning? We'll have architectures which will use this, and they have one clock. We'll have architectures which can't export clocks and won't use this. We'll have architectures with 1 or 2 clocks, and need to make a choice. If we can't make a choice, the old code is used. So the safe choice always remains. The complexity of this proposal is so people can build through the ABI break if the structure changes, but I argue, it should *not get changed ever* because it should be properly designed for *all needs* from the getgo. Once an architecture supports this method, why does it ever need to change? If this solution was MD, we wouldn't even be having this discussion about versioning. amd64 would switch over, and the work would be done. And if something needs a tweak, we would handle it as regular ABI break, something we understand. Per-architecture. But it is being built MI. So the only reason I see for this complexity, is if the MI design didn't anticipate the needs of some architecture. And then adding support, means the MI structure has to change. So this argument is because the diff *does not try to support all architectures yet* and *fails to ancicipate their needs* The diff is growing complexity to support a future which wouldn't exist if attempts at *supporting all* architectures received priority. Then, the structure would be correct on the day it gets commited. Instead, deckchairs are being staged.
