06_ESOS_Development

Contributing to the ESOS Project

Please read through the information below on what's currently needed in the ESOS project. ESOS uses a text-based user interface (TUI), which utilizes the CDK widget library and ncurses and is written in C. ESOS is itself a specialized Linux distribution, so help is always needed updating packages and adding utilities. Please email the esos-users Google Group if you're interested in contributing to the ESOS project via development efforts.

---

What's Needed

Here is a wish-list of improvements that need/should be done, or potential issues that need addressing; possible implementation ideas are also listed for some (in no particular order). Items that are crossed-out have already been implemented in the current release branch.

• Add support for Emulex FC HBAs; waiting on Emulex for updated lpfc to SCST shim (lpfc_scst) to work with newer kernels.
• Speed up the ESOS build process. Possibly use the GNU make '--jobs' option to help.
• Rework the conf_sync.sh script so its a bit more flexible; possibly sync. all of /etc and /var or something similar.
• We use the device identification VPD page from devices for unique identifiers, but not all devices support this.
• Newer Linux kernel releases no longer have updated firmware blobs; the driver references a version that does not exist in firmware/ and the user is expected to use the linux-firmware package for these referenced versions. This will need to be addressed in the next ESOS kernel version bump as some driver's firmware blobs are not compatible with the GPL, which means we probably can't re-distribute a binary ESOS image with these drivers. We will likely need to be more selective on what hardware/drivers can be used.
• The current version of the kernel-side code for bcache does not pass any useful uevents. In linux-next, CACHED_UUID and CACHED_LABEL are uevents sent and then we can parse this in mdev setup and create unique sym. links for each bcache device.
• We need a Windows installer (package) for ESOS; that is, we should have another install package download for Windows operating systems (1 for Linux, 1 for Windows). This should be relatively straight forward as ESOS is really just a disk image that we're writing to a USB flash drive.... but, the install script also adds in the proprietary RAID CLI tools (MegaCLI, etc.) so we'd need to extract tarballs, RPM archives, etc. in Windows. For the implementation I envision a install.vbs (VBScript) with the same flow as install.sh; we could put GPL'd binary tools for extracting tars, zips, RPM files, etc. into SVN and then the pkg_dist recipe will create a second distribution file for Windows that includes the VBScript installer, image, and binary tools.
• ESOS needs a web interface for storage provisioning functions. The TUI works, but is very limited, and likely deters many users from ESOS. The web application framework should be high quality, and light-weight. The TUI will continue to exist for system management tasks (eg, adding users, network configuration, etc.) and the web interface should only handle storage provisioning functions. We can also put a dialog in the TUI for enabling/disabling the web UI as not all users may wish to have it enabled.
• ESOS configuration file management: Currently we have no process for upgrading the ESOS configuration cleanly. An idea (no details worked through yet) would be to somehow use Git to manage the configuration in /etc and /var/lib like a Git repo under each directory. Then make the default ESOS configuration a patch, and then merge it on boot. Just an idea, but we need something.
• Currently, the "esos_conf" file system uses the ext2 file system type. We store the proprietary RAID CLI tools on this file system, and doing so causes some special things to be needed when installing ESOS to USB flash drive using the Windows and macOS platforms. We should look at using a different file system that may be better supported natively on all platforms (something like UDF possibly). The other option is to radically change how the RAID CLI tools are installed, but due to the licensing agreements of those tools, we probably can't automate it too much.