Draft: systm.h: Remove unused <sys/kpilite.h>

[olce]

Summary

It only contains sched_pin_lite() and sched_unpin_lite(), which are
redundant with the already existing sched_pin() and sched_unpin() in
<sys/sched.h> (all are inline functions) and are unused (they were only
briefly used in-tree between 6573d7580b85 ("epoch(9): allow preemptible
epochs to compose") and a760c50c9ea7 ("With epoch not inlined, there is
no point in using _lite KPI. (...)").

The only difference is that using sched_*_lite() would not need the full
definition of 'struct thread'. This is going to be fixed once and for
all by moving 'struct thread' to a separate, minimal <sys/_thread.h>.

[olce]

In passing, I noticed that <sys/kpilite.h> is not used in the tree (and only was for a couple of weeks). Was wondering if we should remove it. Doing so, however, removes a capability (that is not used, and could be restored later), so not too sure about it.

More broadly, this is also to ask whether there would be value into moving struct thread outside of <sys/proc.h>. I've started (but not finished) the exercise, just to see what that entails. Given the number of includes/declarations that must go into the new header, it does not look to be worth the trouble (not even speaking about the churn). So genassym/genoffset mechanisms seem to be here to stay.

[glebius]

There was a period of time when Mr. Macy was committing a lot of his draft ideas right into svn HEAD. Most of them were never finished or continued. This is one of them.

[glebius]

I'm not a voting srcmgr member, so not putting my approval here.

I always have been in favor of removing unused stuff, including unused APIs/KPIs. But today I'm doubling down on it. The reason are LLMs. Declaring unused stuff we just invite LLMs to use it. We should aim at declaring only what we want to be used and nothing beyond that.

[olce]

In D60404#1385645, @glebius wrote:

I'm not a voting srcmgr member, so not putting my approval here.

Well, you can always put your approval if you want to. I put srcmgr as that seems the obvious reviewer.

I always have been in favor of removing unused stuff, including unused APIs/KPIs.

I agree in general. There are probably some cases where some not-yet-used-but-planned-to-be-used code, or some probably-used-outside-tree code could be kept, so that's why I'm asking. I guess we can already safely rule out the first case, 8 years after the last use of the facility...

[imp]

offset.inc was a huge mistake and should die in a fire, but it's used can't be killed easily.

sys/sys/systm.h

100

kill it!

179

I really wish we could kill this super-duper-ugly kludge that buys us nothing.