alcinnz

alcinnz, 11 hours ago

The Graphics Compositor & SFX coprocessors would be primarily programmed by the Output Unit using compiletime constants. As would the Arithmetic Core, with the aid of a special "label" type.

To aid debugging that Arithmetic Core I'd probably end up creating a tool which has the Input Preprocessor emulate its RAM, triggered by user input or a periodic timer. So we can stepwise debug the program, and view its entire state! As well as a disassembler rendering arrows for control flow.
2/3?

alcinnz, 9 hours ago

To debug those output programs it could be useful to send them a signal ranging from low to high, to see/hear how the handle each input value.

Similarly I'd have a tool which runs an FPMA program output the results as scatterplots showing the output for each value of each input (holding other inputs to, by default, zero), verbalized as differently-pitched beeps. I've already described how its compiler would work.

And I've already described a stack of language for our "Layout Coprocessor".
3/4!

alcinnz, 9 hours ago

This Layout Coprocessor would have tool rendering its visual output for given input values, with an option to sweep an input from low to high to see how the output responds to every value.

The Output Unit (frequently combined with the Parsing Unit) would have tool that opens tabs/windows for all the outputs (including the Arithmetic Core's code) generated by running one of its programs.

And I'd give the Parsing Unit a tool which styles its input text to annotate which rules it matched.

4/4Fin

alcinnz, 14 hours ago

@ajroach42 As best as I can tell from existing examples: Community groups! Letting their best work spread beyond their community.

Still there's the problem of finding these communities, & today that tends to happen on these centralized services...

alcinnz, 14 hours ago

After validating no further args are given lsmod parses each line of /proc/modules (via LibKMod) & iterates over the linkedlist to serialize textual output. Any benefit here beyond cat /proc/modules?

After parsing commandline flags (filling in missing args with uname) depmod constructs some directory paths to consult, validates a dependency files/directory, initializes various objects, iterates over a given file (one format or another) gathering symbols to link into a hashmap, ...
2/4

alcinnz, 14 hours ago

... loads all the config files & a directory of modules OR loads the modules listed in commandline args, converts the modules hashmap into an array, parses a modules.order file consulting the hashmap, computes a topological sort of dependencies from the gathered collections, & outputs the results in a choice of format.

After parsing flags filling in missing onesmodinfo builds a KMod context & iterates over remaining args (which it validates exist) loading their modules in 1 of 3 ways.

3/4?

alcinnz, 13 hours ago

For each of those modinfos modinfo serializes various info LibKMod has parsed from device files.

After parsing commandline flags modprobe initializes logging, fills in missing parameters, initializes a LibKMod context having it parse its "resources", & runs a chosen subsubcommand.

These subcommands may output various properties of the LibKMod context, output loaded version numbers, output a module's symbols, or hand off to rmmod or insmod.

4/5?

alcinnz, 13 hours ago

After parsing commandline flags rmmod initializes a LibKMod context & iterates over remaining commandline args (validating they exist) leading each given module in 1 of 2 ways. Calling the delete_module syscall on each via a light LibKMod wrapper.

After parsing commandline flags static-nodes opens modules.devname device file directly & an output file, to parse the modules.devname to reformat into a chosen format.

5/5 Fin for today! Tomorrow: Kernel-side!