Closed ghaerr closed 4 years ago
This is a great piece of work @ghaerr! Let me know if/when I can contribute.
A few questions to start: — what is ’the B option’?
—Mellvik
- mar. 2020 kl. 04:40 skrev Gregory Haerr notifications@github.com:
I have analyzed the current layout and state of the ELKS applications directory elkscmd/, and have a number of ideas on how to improve speed, disk usage, and the overall usability of ELKS at the command line. This would include solving the problem of multiple sources of commands that don't quite do the same thing, as well as providing two config-selected shells, one oriented towards speed and small kernel buffer usage, and the other for full BASH shell scripting, capable of working together and installed separately or together, depending on user requirements.
I can work on this and will submit a detailed plan and set of PRs, but wanted to seek comments first from those that are interested. Following is a detailed illumination of the current state of elkscmd/, along with a suggestion for moving to core_utils, which solves the source duplication and shell builtin problems, but also allows for very small binaries and keeping busyelks commands identical to standalone and shell versions.
The `elkscmd/' directory definitely needs some reorganization and cleanup. I would like comments and some approval before going forward.
Config Option Directory Comments
shells
CONFIG_APP_ASH ash/ Default shell, installs as /bin/sh. Early BASH compatible. Std builtins: cd, chdir, '.', source, echo, eval, exec, exit, export, readonly, getops, hash, jobid, jobs, read, set, setvar, shift, trap, ':', true, false, umask, unset, wait Scripting builtins: break, continue, return No non-std builtins.
CONFIG_APP_SASH sash/ Not selectable when ash selected. Installs as /bin/[sh,sash]. This is not a BASH-compatible shell and does not perform std scripting. It has some standard and large number of useful builtins. Std builtins: alias, unalias, cd, exec, exit, source, setenv, prompt, umask Builtins: chown, chgrp, cp, echo, ln, ls, mkdir, mkdir, mknod, printenv, pwd, sync, rm, rmdir, sync, mv, mount, umount, dd, ed, grep, more, kill, tar, touch Other builtins: help, quit
New config option
CONFIG_APP_COREUTILS core_utils/ Core utilities, Installed in /bin. Sources moved from other directories Already included in sash (but sources to be merged): chown, chgrp, cp, echo, ln, ls, mkdir, mkdir, mknod, printenv, pwd, sync, rm, rmdir, sync, mv, mount, umount, dd, ed, grep, more, kill, tar, touch Not yet included in sash (but to be added): cat, date, env Move from sys_utils: clock, getty, init, login, mount, umount Move from file_utils: cat, chgrp, chmod, chown, cp, dd, grep, ln, mkdir, mknod, more, mv, rm, rmdir, sync, touch Move from minix1: grep Move from minix2: env Move from minix3: Move from misc_utils: ed, tar Move from sh_utils: date, echo, false, printenv, pwd, true
Selectable Application categories
CONFIG_APP_SH_UTILS sh_utils/ Shell utilities from Alistair Riddoch. Rewritten from GNU shutils 1.12 and sash. Installs in /bin: basename, date, dirname, echo, false, logname, mesg, printenv, pwd, stty, test, tr, true, which, whoami, xargs, yes Note: uname and write not compiled.
CONFIG_APP_SYS_UTILS sys_utils/ System utilities from various origins. Installs in /bin: chmem, clock, getty, init, kill, knl, login, man, meminfo, mount, passwd, poweroff, ps, reboot, shutdown, umount, who Not compiled: exitemu, insmod, min_init, rdev, utent(lib routine) Some manual pages present.
CONFIG_APP_FILE_UTILS file_utils/ File utilities from Alistair Riddoch. (B option when busyelks selected) Rewritten from GNU fileutils 3.14 and sash. Installs in /bin: cat, chgrp, chmod, chown, cmp, cp, dd, grep, l, ln, ls, mkdir, mkfifo, mknod, more, mv, rm, rmdir, sync, touch
CONFIG_APP_DISK_UTILS disk_utils/ Disk utilities from early 1990s. (B option when busyelks selected) Installs in /sbin: fdisk, fsck, mkfs, partype, ramdisk
CONFIG_APP_MISC_UTILS misc_utils/ Miscellaneous utilities from various sources, including sash. (B option when busyelks selected) Installs in /usr/bin: ed, miniterm, tar Not installed: compress, uncompress, zcat
CONFIG_APP_MINIX1 minix1/ MINIX utilities, part 1. (B option when busyelks selected) Installs in /bin: banner, cksum, cut, decomp16, du, fgrep, grep, proto, sum, uniq, wc
CONFIG_APP_MINIX2 minix2/ MINIX utilities, part 2. Installs in /bin: env, lp, pwdauth, synctree, tget Not built: eject, install, lpd, man, mt
CONFIG_APP_MINIX3 minix3/ MINIX utilities, part 3. (B option when busyelks selected) Installs in /bin: cal, diff, file, find, head, sed, sort, tail, tee
busyelks
CONFIG_APP_BUSYELKS busyelks/ Not selected by default. When selected, B options occur on: disk_utils, file_utils, minix1, minix3, misc_utils. B option currently broken. Installs /bin/busyelks, and symlinks to: basename, cal, cat, chgrp, chmod, chown, chksum, cmp, cp, cut, date, dd, diff, dirname, du, echo, ed, fdisk, find. Looks like many others coming.
Other commands
CONFIG_APP_LEVEE levee/ 1st vi editor, installs as /bin/vi CONFIG_APP_ELVIS elvis/ 2nd vi editor, Makefile broken, not built. Installs as /usr/bin/[elvis,vi,ex,view,input] CONFIG_APP_XVI xvi/ 3rd vi editor, won't compile, installs as /bin/xvi
CONFIG_APP_M4 m4/ Macro processor, including man page
CONFIG_APP_MTOOLS mtools/ Early MSDOS mtools v1.6.2 from 1989, with man pages. Installs into /usr/bin: mcopy, mdel, mdir, mkdfs, mmd, mrd, mread, mren, mtype, mwrite
CONFIG_APP_BC bc/ Calculator
CONFIG_APP_NANOX nano-X/ Nano-X Graphical Window System v0.86 from 1999. Too many programs to fit on 1440k floppy Installs /bin/landmine Builds but doesn't install: demo, demo2, nclock Doesn't build: nterm, world
CONFIG_APP_PREMS prems/ Compression library and compress/gzip lookalike. Installs /bin/pres. flparc not installed.
CONFIG_APP_PRN_UTILS prn-utils/ lpfilter print utility. Doesn't compile or install.
CONFIG_APP_SCREEN screen/ Text multi-screen support. Doesn't compile or install.
CONFIG_APP_DBG_UTILS debug_utils/ Selected by default, doesn't build or install 'mema' task viewer
CONFIG_APP_TEST test/ Various test programs, not selected by default.
Internet stack
CONFIG_APP_KTCP ktcp/ ELKS TCP/IP stack. Installs /bin/ktcp and /etc/resolv.conf CONFIG_APP_HTTPD inet/httpd/ Installs /bin/httpd and /var/www/index.html CONFIG_APP_NET_TOOLS inet/nettools/ Installs /bin/netstat, /bin/nslookup CONFIG_APP_TELNET inet/telnet/ Installs /bin/telnet CONFIG_APP_TELNETD inet/telnetd/ Installs /bin/telnetd CONFIG_APP_TINYIRC inet/tinyirc/ Installs /bin/tinyirc CONFIG_APP_URLGET inet/urlget/ Installs /bin/urlget and symlink /bin/ftpget
Unselectable
byacc/ Berkely Yacc. Not selectable so never compiles.
Other directories in elkscmd/
bootblocks/ Boot sectors for MINIX and FAT boots. Should be moved. rootfs_template/ Root filesystem template for static files not built in elkscmd/ tools/ Unused. ver.pl lib/ Unused. mktemp.c, putenv.c, sleep.c, bsd/daemon.c, bsd/err.c — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/410?email_source=notifications&email_token=AA3WGOH6LVYR7BU37GG63PTRFXETDA5CNFSM4LA2FEBKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ISHSESQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOFLE43WI2QSQSXRL2TRFXETDANCNFSM4LA2FEBA.
what is ’the B option’?
If busyELKS is selected in Config, several other application categories allow selecting as Y=build, N=don't build, or B=compile them into /bin/busyelks and produce symlinks in /bin. It isn't yet working on OSX and some Linux systems.
would it make sense to keep some of the sys-utilities in /etc or /sbin instead of /bin (like init,getty,mount,mknod …)?
Yes possibly for init and getty, maybe not for mount. There are already PATH incompatibilities between the two shells and various hard and softcoded paths within the system. For instance, root's .profile changes PATH=, but this doesn't work on FAT boots because only 8.3 filenames are currently supported. This is easily changed, but needs to be done thoughtfully and with all the areas that reference the change in mind.
are you open to the introduction of additional utilities (or deletions - like ‘l’ and ‘write’): xxd and less would be my first candidates?
Of course. Feel free to port or suggest applications needed. For existing commands, like 'more' (less), it might be worth discussing the desired feature(s) missing and adding it, rather than moving to a large version of the program.
I have a spreadsheet comparing the file sizes of busyelks commands and *_utils commands, let me know if it may be useful (I did plan to include binary sizes but couldn’t figure out why it would be useful).
Go ahead and attach that here and I'll look at it.
Do you have a process in mind for selecting which utility to pick - from busyelks or *utils ?
I'm not sure I understand your question. If you mean, which utility we should keep/use from the various places the source code is in, busyELKS source is all copies from existing commands. If you mean how deciding on which utilities should be included in core_utils, those would be commands that are capable of running standalone, as well as included in the sash
shell as a builtin (and busyELKS).
Why not put everything in /bin and symlink /sbin, /usr/bin and /usr/sbin to it for compatibility like Arch and Fedora (at least) have been doing for a while now? It'll make things quite simpler and save some bytes. The /usr split was first used for extra storage when UNIX programs became bigger (http://lists.busybox.net/pipermail/busybox/2010-December/074114.html). With Elks it's going to target machines that have one or two floppies and perhaps one fixed disk which will be more than large enough to hold everything. Then later it was used for mounting /usr from NFS. That's unlikely to ever happen with ELKS. So having /usr/bin and /usr/sbin seems not really useful. Then there's /sbin. A long time ago that was a security thing but I think it no longer makes sense either. The only issue that was raised for Linux with this scheme was that it might break compatibility with some legacy closed source programs that don't handle symlinks properly. But that never happened. And ELKS doesn't have legacy closed source programs anyway.
I have no problem with what @cjsthompson other than the fact that FAT doesn't support symlinks. FAT root fs support is a really attractive thing, but without symlinks, anything that explicitly calls out to /usr/bin/env or similar will fail. Compatibility is important, even if the current status is that "ELKS doesn't have legacy applications anyway." I have recompiled some simple software for ELKS just by changing the CC/LD/*FLAGS specs. Shameless plug of personal stuff that I did this to:
@ghaerr I personally have decided that the "busyelks" thing I started is not a good idea long-term. The amount of kernel changes required to make it practical for general use are unacceptable and will potentially drive improvements in a direction that favors the oddities of busyelks to the detriment of a traditional set of small binaries. At this point, I would like to see it removed entirely. The tools should be improved as individual tools and distributed individually as needed. The code sharing that I envisioned as the main value of busyelks is outweighed heavily by the fact that you cannot trim space by deleting individual binaries if all of your tools are in 1-3 huge binaries, plus the divergence of the source tree and additional maintenance load that is starting to be required is not acceptable, in my opinion. There simply are not enough developers involved at this stage to maintain a wonky complicated specialty source tree that spits out different binary sets depending on what the builder asks for.
One of the core tenets of this project is to keep it easy to understand for both educational and maintenence purposes. Let's stick to that.
And whoever put the "close and comment" button there has never written comments using a touchscreen phone. Grrrr.
@jbruchon: I have been looking at the repository history quite a bit lately, and was very surprised to learn that 8 years ago, there was (another) busyelks in this tree! Were you the one that put that in originally? It's all being rewritten again now...
As this open issue indicates, I am working towards getting the ELKS command set reorganized, and have started work on getting the two shells working well. sash
solves a lot of the problems that busyelks is trying to do with its large builtin command set, with no sym or hard links, and will work well also as an optional standalone shell. (busyelks is using sash
sources but it isn't integrated with BASH, so things like pipes won't work). They need to be better integrated so the user gets the benefit of small disk and kernel buffer usage, until he wants to do something more complicated, which can be made seamless. There are some minor complications if wanting to maintain BASH compatibility for shell scripting, which I'm working on and will bring up in the PRs.
The second phase, after getting the shells working well for people to try out, is to reorganize the elkscmd/ subdirectories, improving maintainability and cleaning out crud. Should the shells meet with approval, this would involve creating a core_utils
directory and cleaning up the other dirs. All of the work is focused on keeping things small and simple, and moving towards a single set of core utility sources, being small and light, and work well on MINIX and FAT.
After these two phases are done, would be a good time to determine the advantages and disadvantages of busyelks, and a decision could be made at that time. For now, it's not hurting anything, as it is pretty much self-contained.
I was the one who originally created busyelks, yes. The commits should have my name all over them. It was never integrated into the build system or elkscmd because it was an experiment.
My god, has it really been that long? I look at some of the C code and shell scripts I wrote in 2012-2013 and cringe. Anything I wrote that's shell with backticks worries me...
Hello @ghaerr,
bootblocks/ Boot sectors for MINIX and FAT boots. Should be moved.
Yes, I think that will be a good idea.
If you ask me, perhaps bootblocks/
can be in its own subdirectory directly under the top-level elks/
. (An alternative might be to place it somewhere in the kernel subtree elks/elks/
, but that may risk confusing it with the kernel image's own dummy bootloader...)
Thank you!
Hi @cjsthompson, thanks for your comments.
Why not put everything in /bin
Not a bad idea, really.
and symlink /sbin, /usr/bin and /usr/sbin to it for compatibility like Arch and Fedora (at least) have been doing for a while now?
I'd like a design that would work well on MINIX and FAT, and with the latest changes to the shell(s), there's no need for any application symlinks at all, so I'm thinking the standard distribution won't have any symlinks and work identically on MINIX/FAT.
The /usr split was first used for extra storage when UNIX programs became bigger (http://lists.busybox.net/pipermail/busybox/2010-December/074114.html).
That's an interesting post, thanks for linking it. I was around in the early v6 days and I remember seeing the proliferation, only to be extended on Vaxen with BSD.
With Elks it's going to target machines that have one or two floppies and perhaps one fixed disk which will be more than large enough to hold everything.
You're probably right. Just for the heck of it, it might be worth calculating what the performance hit really is on slow floppy systems in directory searching. For MINIX, a directory entry is 16 bytes and block size is 1024, so after 64 entries, another block needs to be read. For FAT, a directory entry is 32 bytes and block size is 512, 16 entries/block. There's currently 94 entries in /bin, 13 in /usr/bin, and 5 in /sbin. So for MINIX, 2 1k block reads would get everything. FAT would require 4k. Reading just 'usr' to get to 'usr/bin' will add another 1k or 512 byte disk read.
Now that I've looked at this more, I'd say there's not much point in keeping /usr/bin or /sbin. The original idea behind /sbin was to hide fdisk and mkfs from non-root users, but I'd say everyone uses ELKS as root. There is no /usr/sbin.
My quick conclusion is that using /bin alone only changes the path for 17 programs, reduces complexity and increases speed, so why not do it? If the core_utils programs were copied first, things could be made even faster, but it's probably not worth the effort given that the new design optionally includes all core_utils within a shell, so, no disk access required at all. The standard path in the shell(s) could stay as '/bin:/usr/bin:/sbin' for those that want different disk layouts.
Well that sounds great. UNIX may yet become better than ever on 16 bit intel machines.
I remember Slackware could install on FAT with umsdos which handled ownership, access rights and symlinks on top of FAT. But adding more layers is mostlikely not going to help with ELKS. The shell builtin utilities way sounds like a much better idea indeed.
I remember Slackware could install on FAT with umsdos which handled ownership, access rights and symlinks on top of FAT. But adding more layers is mostlikely not going to help with ELKS.
We're running an early version of UMSDOS included in our FAT filesystem that handles faking /dev now. Should we want to add symlinks or improved access rights, we'll add it in there as well. A FAT priority is getting open
and stat
to work with larger (non-8.3) filenames. readdir
works so ls can see files like /root/.profile, but programs can't use them.
What about making something like devfs
from Linux?
What about making something like
devfs
from Linux?
@jbruchon: We've already solved the problem of /dev on FAT, that's what I was trying to say. FAT also supports reading VFAT long filenames in directories, just not in open
or stat
.
Linux no longer has a devfs for many years now. It was removed in favor of udev which is a user space daemon that manages the dev nodes with notifications from the kernel on a regular filesystem (usually a tmpfs mounted over a regular /dev with minimal static nodes). Greg Kroah-Hartmann claimed that devfs on Linux could not be made race condition free in hotplugging situations despite FreeBSD and a few other OSes such as Haiku having a devfs that seems to work fine.
Well, I'm running Linux 5.4.11 and there at least is something called devtmpfs
that I'm mounting at boot to get a basic /dev
populated pre-eudev
startup.
devtmpfs is merely a specialized tmpfs filesystem for dev, perhaps to save memory.
It is more than just a special tmpfs
; it is populated by the kernel: https://lwn.net/Articles/330985/
My comment about sash
and busyelks
in https://github.com/jbruchon/elks/pull/457#issuecomment-598153848.
Another comment about sash
and busyelks
in https://github.com/jbruchon/elks/pull/457#issuecomment-598168005
I have analyzed the current layout and state of the ELKS applications directory elkscmd/, and have a number of ideas on how to improve speed, disk usage, and the overall usability of ELKS at the command line. This would include solving the problem of multiple sources of commands that don't quite do the same thing, as well as providing two config-selected shells, one oriented towards speed and small kernel buffer usage, and the other for full BASH shell scripting, capable of working together and installed separately or together, depending on user requirements.
I can work on this and will submit a detailed plan and set of PRs, but wanted to seek comments first from those that are interested. Following is a detailed illumination of the current state of elkscmd/, along with a suggestion for moving to core_utils, which solves the source duplication and shell builtin problems, but also allows for very small binaries and keeping busyelks commands identical to standalone and shell versions.
The `elkscmd/' directory definitely needs some reorganization and cleanup. I would like comments and some approval before going forward.