For some time now, over 10 years anyway, the GNU world has been using
the linker to create initialized structs, viz:
static const struct cpu_driver driver __cpu_driver = {
.ops = &cpu_dev_ops,
.id_table = cpu_table,
};
(this from linuxbios)
The __cpu_driver is passed to the linker and you end up with an array
of all structs tagged with that name.
These are called linker sets. I first heard of them in 1995 or so when
freebsd moved away from generating arrays of structs from the BSD
config tool and used gld to create those same arrays.
Plan 9 takes the older style approach: a script parses a config file
and creates C code which initializes the struct arrays.
Now, I betray my age, I guess, but I prefer the plan 9 style. I am
curious: am I just out of touch with this modern world?
Why do I like the Plan 9 style?
1. you can figure out what source constitutes the
program/application/os/bios by looking at C code
2. program analysis tools can analyse C code; you don't need binaries
and linker scripts
3. Errors such as empty structs are easier to catch at build time;
we've seen cases where nobody
built a binary with, e.g., any cpu drivers and we did not know
until the BIOS tried to start
4. If you are using, e.g., Eclipse or Kscope, you can see how code is
invoked and used, which is
harder when initialized structs are created by the linker.
OK, am I just out of date or is there a real reason for linker
sets?This question just came up in linuxbios v3 and I am wondering if
I am a stubborn old coot (likely) or if there really is merit to my
dislike of linker sets.
ron
