Proposal: Active "dirty" files

When Klipper detects modified or added files in it’s code, it reports the Klipper version as dirty. While this can help to catch certain manufacturer-broken Klipper versions, I think this has the unintended side effect of making it hard to get support when even a single file is added (not modified).

While some extras are fairly simple to uninstall and reinstall, more extensive extras, like Happy Hare, are fairly involved to uninstall and reinstall, while commenting out the related lines in printer.cfg is very straightforward and easily reversible.

Currently, the klippy.log prints out the following information on startup (taken from the KB article):

Git version: 'v0.12.0-439-g1fc6d214-dirty'
Untracked files: klippy/extras/autotune_tmc.py, klippy/extras/gcode_shell_command.py, klippy/extras/motor_constants.py
Modified files: klippy/chelper/serialqueue.c
Branch: master
Remote: origin
Tracked URL: https://github.com/Klipper3d/klipper

I propose to add another two lines to show which extras modules are actually active and which are inactive. Since inactive extras (ones without a section in printer.cfg) are never imported or executed, they don’t have any effect on Klipper’s functionality.

Active untracked extras: klippy/extras/autotune_tmc.py, klippy/extras/motor_constants.py
Inactive untracked extras: klippy/extras/gcode_shell_command.py

The new proposed startup lines:

Git version: 'v0.12.0-439-g1fc6d214-dirty'
Untracked files: klippy/extras/autotune_tmc.py, klippy/extras/gcode_shell_command.py, klippy/extras/motor_constants.py
Active untracked extras: klippy/extras/autotune_tmc.py, klippy/extras/gcode_shell_command.py, klippy/extras/motor_constants.py
Inactive untracked extras: klippy/extras/gcode_shell_command.py
Modified files: klippy/chelper/serialqueue.c
Branch: master
Remote: origin
Tracked URL: https://github.com/Klipper3d/klipper

Here, the only active untracked extras are TMC autotune, which can be commented out in the config. Since gcode_shell_command is inactive, it can have no affect on Klipper.

Feedback on this idea is appreciated.

1 Like

Can you elaborate on what the benefit would be?

In my opinion:

  • “Dirty” sounds a bit harsh. The Linux kernel calls it tainted, which is not really much nicer. Its explanation can be found here: Tainted kernels — The Linux Kernel documentation
  • The flags give an early warning that something has been modified. What and with which consequences remain to be evaluated.
  • Someone who can read the klippy.log is very well able to distinguish between the modifications and also able to assess if issues and modifications are related.
  • There is only one single extra that is deemed generally harmless, and this is gcode_shell_command.py. However, even this can be used to crash Klipper by executing not-so-harmless shell commands.
  • The proposed differentiation just for one single extra and to avoid situations like MCU 'mcu' shutdown: Move queue overflow Nr.2 - #5 by hcet14 seems not justified.

Just my 2 cents.