Hey,
Just checking my understanding of what’s going on when we patch the getty binary: when the device boots the kernel loads and mounts the filesystems from the flash chip into memory, we’re patching this version of getty on the in-memory filesystem which then in turn will get loaded ‘into-memory’ when it gets mapped as part of being executed when we login.
This is not memory mapped IO talking to the flash chip directly, and will not persist.
Is all that accurate?
Thanks!
Correct - we’re not talking to the MMIO flash storage, and nothing will persist - but - we are modifying the in-memory execution copy, not a ramdisk or filesystem-in-memory copy if there is one.
When the system boots, it spawns a getty process that sits and listens on the console - the program execution has started, code is paged into memory, waiting for a connection that will context switch to that process and start running. We modifiy it then, while it’s sitting there in memory.
If the getty process restarts, we lose the changes.
If the getty process is paged out to disk because of low memory- we may lose the changes if there’s already a copy in the pagefile that wasn’t modified.
If there are multiple instances of getty running on the system - we may have two copies in two different places in memory.
Make sense?
It does thanks, so the filesystem is not loaded into memory at all but mounted and accessed via MMIO, and as squashfs is RO we can’t edit the stored version.
I also assume for a lot of IOT devices paging to disk isn’t an issue as it won’t be enabled if there’s only FLASH storage? Using a pagefile sounds like it’d burn out the storage quickly much like the FAT32 example.