Re: Linker error (multiple definition) during LD_STAGE 2 with custom scheduler

[Тимофей Масленников <sewas1399%gmail.com@localhost>]

Hello Martin, Hello Valery,

Sorry that the previous email was in HTML format; I've already changed
it to plain text.
I've already read the csf(9) and config(5) manuals and configured the
options and configurations for building the scheduler.

In order for the scheduler algorithm to work with the entire OS
kernel, I need to follow the sched.h template, right? Implement
functions with the same names, arguments, and return values.

However, this creates a 'multiple definition of' problem: my kernel
functions are compiled alongside the base implementation in
kern_runq.c, and they conflict, causing linking to fail.

The conflicts aren't limited to specific functions, but rather all
implemented functions (except for static ones, which are needed to
simplify code reading and algorithm maintenance). sched_init,
sched_cpuattach, sched_enqueue, sched_dequeue, sched_lwp_fork,
sched_lwp_collect, sched_tick, sched_nice.
I definitely need to implement these functions because my scheduler
works differently than classic MLFQ, and I need to add support for my
additional structures in each of them.

I also wanted to ask about the function set. sched_4bsd and sched_m2
don't implement the full set of functions declared in sys/sys/sched.h.
So where do the definitions of the missing functions come from? From
that same kern_runq.c?

Perhaps I'm missing something.


сб, 20 июн. 2026 г. в 16:43, Valery Ushakov <uwe%stderr.spb.ru@localhost>:
>
> On Fri, Jun 19, 2026 at 22:42:19 +0300, sewas1399%gmail.com@localhost wrote:
>
> > Could someone please explain how the NetBSD build system and linker
> > handle symbol overriding for alternative schedulers? How does
> > sched_m2.c avoid multiple definition conflicts with kern_runq.c, and
> > what is the proper way to hook a custom scheduler into the kernel to
> > avoid this collision?
>
> Read up on config(5).  Schedulers are not dynamically pluggable, so
> you need to select which one you are compiling in.  If you look at the
> history of sys/conf/files you can see:
>
>   revision 1.868
>   date: 2007-10-09 23:00:13 +0400;  author: rmind;  state: Exp;  lines: +3 -1;
>   Import of SCHED_M2 - the implementation of new scheduler, which is based
>   on the original approach of SVR4 with some inspirations about balancing
>   and migration from Solaris.  It implements per-CPU runqueues, provides a
>   real-time (RT) and time-sharing (TS) queues, ready to support a POSIX
>   real-time extensions, and also prepared for the support of CPU affinity.
>
>   The following lines in the kernel config enables the SCHED_M2:
>
>   no options SCHED_4BSD
>   options SCHED_M2
>
>   The scheduler seems to be stable.  Further work will come soon.
>
> You need to do similar song and dance to get your scheduler compiled
> into the kernel instead of the default 4BSD or M2.
>
> -uwe