Have usb drive, usb_hid and the rest of the things that can be enabled/disabled during boot be configurable from settings.toml

[bill88t]

Currently to toggle the usb filesystem, usb hid and midi, we need to have to edit boot.py.

However, if you want to toggle it frequently it becomes quite annoying.
And it's hard for applications to just set it for the next boot in a clean manner, since there is no such ready-made api.

For ljinux, from 6.x I had implemented a config.json which stored stuff for boot.py and the os to read/write.
But during 8.x I switched to using settings.toml and the os just set the values with my standard toml library.

A typical ljinux settings.toml looks like this currently:

CIRCUITPY_PYSTACK_SIZE = 12288

[LJINUX]
setup = true
serial_console = true
usb_access = false
usb_hid = false
leden = -1
ledtype = "neopixel"
led = 33
DEBUG = false
root_SCLK = -1
root_SCSn = -1
root_MOSI = -1
root_MISO = -1

[IWD]
#Network1 = "password1"
#Network2 = "password2"

[IWD-AP]
SSID = "fastest_wifi"
PASSWD = "example ap password"

And I was wondering, wouldn't it be more practical to just have the toggles implemented in the core?
It would be so much simplier for users to configure this stuff with one line inside the toml, than in boot.py.

I don't think we should remove the existing api, but we should just edit the default state (what's set before boot.py runs) to be what settings.toml says.

If this idea is something you want to see implemented, I can probably go ahead and do it myself.
I just want to know if it's something the project would like.

[dhalbert]

A lot of the configuration is either complicated (HID report descriptors), or you want it to be conditional, such as hiding the CIRCUITPY drive, but only if a button is not pressed, etc. So, yes, you could conditionalize the boolean things, or set their default values, but it would be a subset of what you can do in boot.py.

(The title of this issue says "only", but it seems like that's not what you said in your post.)

[bill88t]

I should have given a tl;dr:

CIRCUITPY_USB_FS = bool
CIRCUITPY_USB_HID = bool
CIRCUITPY_USB_MIDI = bool

I don't think we should move all the options into settings.toml.
I just think we should have a default state setter in it, for ease of use.

Yep the title is wrong.

[dhalbert]

And it's hard for applications to just set it for the next boot in a clean manner, since there is no such ready-made api.

This could be done with micrcontroller.nvm, and tested in boot.py, or by SleepMemory (if applicable).

A higher level view on this:

We provided settings.toml, and before that .env, to provide settings that needed to be specified before any Python codee ran. This addition is a convenience, but is not really required. Code in boot.py already can do what this can, and settings.toml can be read by os.getenv() in boot.py and then acted upon, if you'd like to make these settings accessible via settings.toml. So I'm still thinking about whether this is worth the code space and the increased documentation. I know this is not necessarily what you want to hear.

[bill88t]

This could be done with micrcontroller.nvm, and tested in boot.py, or by SleepMemory (if applicable).

Now that I think about it, nvm could just work.
But it's something the user doesn't know how to toggle if the application breaks.
It's much less straightforward than a toml config.

So I'm still thinking about whether this is worth the code space and the increased documentation.

I am not sure either, this is why I opened an issue before a PR.

I know this is not necessarily what you want to hear.

I don't mind. Feedback is incredibly important.
If anything I would like to hear your thoughts regarding what /settings.toml might become.

Imagine, let's say, in CircuitPython 15.0, right as support for the brand new ESP64 is added, we have about 400 possible CIRCUITPY_ strings settable via /settings.toml and boot.py is no longer used for any configuration.
In that hypothetical release 15.0, we can configure storages and sdcards to mount during early boot, configure security stuff, etc. all from /settings.toml.

The file would look like the average linux kernel config file.. (look at line count)

Is this there future we are heading towards? Or are we just going to add as few things as possible in there?
(Only things that are needed before boot.py is ran)

This should be our deciding factor as to if we actually go ahead with this.

[dhalbert]

Is this there future we are heading towards? Or are we just going to add as few things as possible in there?

A big advantage of boot.py is that it does not require extra firmware space to change settings that already have an API. Also, it can make settings decisions programmatically. The only reason we added .env/settings.toml was because we could not set those settings in boot.py. It was for necessity, not convenience.

One thing I have seen over the years is the tendency to invent new (usually weak) programming languages unnecessarily, often as part of some kind of configuration setup. So here we are adding a new, really weak, declarative language. It has its own syntax, but not much else. We already have a perfectly good programming language available. If we could could start up a Python VM to do the settings, then we just would use Python, and we wouldn't need settings.toml. That's what boot.py is for most of the time.

You see the same thing in CPython. Nearly everything can be set up at run time. A few things can be set by environment variables (which is basically just what settings.toml is), and some of those have to be known before the Python interpreter starts.

It's true that not providing a fuller language reduces the security exposure, but that's not really the issue here.

So I am not inclined to add these settings if all they are is a minor convenience that is addressed just fine in boot.py. If you want ljinux to be configurable in many ways, feel free to use settings.toml or a json file or ljinux_init.py or whatever. Then you can fine-tune all that in Python code.

[bill88t]

Yea, i do think I agree with you now that I see the pros and cons better.

This should stay out of the core. Closing issue & PR.