diff options
| author | Andreas Baumann <mail@andreasbaumann.cc> | 2024-01-14 19:50:06 +0100 |
|---|---|---|
| committer | Andreas Baumann <mail@andreasbaumann.cc> | 2024-01-14 19:50:06 +0100 |
| commit | 310cee3e339eee800121e57069b5a771a1060e1a (patch) | |
| tree | 54fdefd03083d68ba62f8876860753f1f6893d9c | |
| parent | 8bfe0419a6ed355d36a50c0416c4278016572621 (diff) | |
| download | i486tcc-linux-310cee3e339eee800121e57069b5a771a1060e1a.tar.gz i486tcc-linux-310cee3e339eee800121e57069b5a771a1060e1a.tar.bz2 | |
updated docu and todos
20 files changed, 8550 insertions, 10 deletions
@@ -81,9 +81,11 @@ patches * disabled IPv6 * fixed some missing IPv6 conditionals * added conditional for FamilyServerInterpreted ("si:") -- meh - * disabled external libraries for gif, png, jpeg, imagemagick - * fixed dependency generator +- image viewer + - meh + * disabled external libraries for gif, png, jpeg, imagemagick + * fixed dependency generator + - feh as alternative? - slock * fixed for missing setgroups in musl * disabled XRandr extension @@ -229,6 +231,7 @@ The starting point of the Linux kernel configuration is 'make tinyconfig'. - for 32-bit time parameter as in pselect (this of course made the whole thing non-2038-safe) "vis: mainloop function not implemented", needs 'pselect' + "pselect, function not implemented SYS_pselect6_time64" - CONFIG_MSDOS_PARTITION - for fdisk @@ -487,6 +490,8 @@ EOF timing), this might be because we use musl? Xfbdev builds, vesafb only works when started at boot time (not as module) which is annoying. +- minimize fonts +- Xfbdev :0 -fp /share/X11/fonts - "Could not init font path element ../share/X11/fonts/, removing from list" https://www.x.org/releases/X11R7.5/doc/libXfont/fontlib.html => the pathes must be absolute and no errors in any file whatsover! @@ -533,7 +538,8 @@ Segmentation fault - wordgrinder: segfaults in luapeg on first script, probably a static linking issue or a tcc issue? - rxvt: 2.7.10 doesn't link statically and has a rxvt-2.7.10 additionally to - rxvt. we use rxvt-2.6.4, why exactly? + rxvt. + TODO: we use rxvt-2.6.4, why exactly? - real hardware (Unisys): softirq kernel panic Starting network via DHCP.. ne ne.0 (unnamed net_device) (uninitialized): NE*000 ethercard probe at 0x300: @@ -578,6 +584,15 @@ Call Trace: results in warnings when issuing 'man xxx' - too big 6x13-ISO8859-1.pcf.gz: 4k on host, 64k in root.img. Most likely we package too many charset variants +- "Linux as a Boot Loader - Peter Chubb", kernel assumes to have space after + it for decompression in address space and overwrites the ramdisk, explains + our fiddling with loading addresses and random crashes till they no longer + overlap sessions. +- suckless: + - sup: not really suckless, sha256 summing and listing, daemonizing should be + separate binaries in Unix sense + - sandy: not really stable and maintained, it seems + - static: minial cgit version with static pages tools ----- @@ -637,7 +652,18 @@ to abase). Their definition of micro is quite different from mine in terms of size and library dependencies) I also doubt it works with tcc, needs python3 on the host to build - + +Some todos to sort out +---------------------- + +- zlib + - use libz or zlib-ng +- st/rxvt + - https://opensource.com/article/19/10/why-use-rxvt-terminal +- tmux/screen +- joe/vis +- vesa/frambuffer + other approaches ---------------- @@ -693,6 +719,7 @@ user land. oasis ----- +by Michael Forney, author of cproc statically linked, the Lua build thing is weird. He also rewrote ninja as samurai in C (which is nice). Also with QBE and cproc the user land can be built with a small C @@ -772,11 +799,14 @@ links - https://github.com/landley/aboriginal - https://github.com/landley/mkroot - https://landley.net/aboriginal/documentation.html + - http://landley.net/aboriginal/history.html - Morpheus - https://git.2f30.org/morpheus/ - Oasis - https://git.sr.ht/~mcf/oasis + - https://github.com/oasislinux/oasis - Stali + - https://sta.li - https://pub.nethence.com/xen/guest-stali - Graylinux - https://github.com/marmolak/gray386linux @@ -786,7 +816,8 @@ links - http://sabo.xyz/ - https://sabotage-linux.neocities.org/ - https://sabotage-linux.neocities.org/blog/11/ - - others: + - https://github.com/scanlime/avc-edge-linux (disappeared) + - others minimal linux: - https://www.glaucuslinux.org/ - https://github.com/ZilchOS/bootstrap-from-tcc: this is more for having a minimal tcc-based binary core for bootstrapping @@ -812,10 +843,27 @@ links - https://github.com/firasuke/mussel (Firas Khalil Khana) - https://github.com/pikhq/bootstrap-linux - https://www.glendix.org/: Plan9-like distro - - Minimal Linux Live - - https://github.com/ivandavidov/minimal + - https://github.com/ivandavidov/minimal: Minimal Linux Live + - https://github.com/yeokm1/gentoo-on-486 + - https://distr1.org/: Michael Stapelberg, alternative package management for Linux + - https://kisslinux.org/ + - https://git.sdf.org/midfavila/musl-tcc + - other minimal floppy system + - https://github.com/gotoco/PE_Bootloader_x86 + - https://github.com/fysnet/FYSOS/ (smallc, boot loader in C for unreal mode) + - https://github.com/alexfru/BootProg + - http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html + - https://wiki.osdev.org/Disk_access_using_the_BIOS_(INT_13h) + - https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH=08h:_Read_Drive_Parameters + - https://stanislavs.org/helppc/dbt.html + - http://vitaly_filatov.tripod.com/ng/asm/asm_024.9.html + - https://web.archive.org/web/20160619063203/http://www.ctyme.com/intr/rb-0621.htm + - https://students.mimuw.edu.pl/SO/Linux/Kod/arch/i386/boot/bootsect.S.html + - other minimal toolchains + - https://github.com/pts/pts-tcc - C Compilers - https://repo.or.cz/w/tinycc.git + - https://blog.stephencleary.com/2010/10/implementing-gccs-builtin-functions.html: on __builtin_clz - C Libraries - https://www.fefe.de/dietlibc (https://www.monperrus.net/martin/compiling-tcc-with-dietlibc: sadly @@ -834,12 +882,15 @@ links - https://github.com/martanne/vis - https://joe-editor.sourceforge.io/ - https://ex-vi.sourceforge.net/ + - https://git.sdf.org/midfavila/mse - Kernel - Tinification - https://weeraman.com/building-a-tiny-linux-kernel-8c07579ae79d - https://tiny.wiki.kernel.org/ - http://events17.linuxfoundation.org/sites/events/files/slides/tiny.pdf - https://z49x2vmq.github.io/2020/12/24/linux-tiny-qemu/ + - http://elinux.org/Kernel_Size_Reduction_Work + - https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de - Boot process - ramdisks - https://linuxlink.timesys.com/docs/startup_overview @@ -847,6 +898,7 @@ links - https://firasuke.github.io/DOTSLASHLINUX/post/booting-the-linux-kernel-without-an-initrd-initramfs/ - https://docs.kernel.org/admin-guide/initrd.html - https://landley.net/writing/rootfs-programming.html + - https://github.com/chris-se/tiny-initramfs - device management - https://git.suckless.org/smdev - init systems @@ -855,6 +907,8 @@ links - https://github.com/hut/minirc - https://omaera.org/wlog/tech/runit_init - https://forums.gentoo.org/viewtopic-t-1000292-start-0.html + - https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using + - https://github.com/shiftypenguin/uinit - service/daemon management - http://r-36.net/scm/svc/log.html - minimal userland @@ -879,6 +933,7 @@ links - https://github.com/leahneukirchen/obase - https://beastiebox.sourceforge.net/ - https://www.fefe.de/embutils/ + - https://heirloom.sourceforge.net/ - gopher://bitreich.org - https://git.2f30.org/hbase/log.html: Heirlom - https://www.glendix.org/: we could also go into the direction of using @@ -886,8 +941,13 @@ links - git://git.9front.org/plan9front/plan9front - git://git.suckless.org/9base - https://github.com/ecki/net-tools.git + - https://www.reddit.com/r/suckless/comments/n14xnq/can_sbase_replace_busybox/ + - https://exactcode.com/opensource/minised/ (Eroc S. Raymond, maintained by Rene Rebe) + - https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading - minimalism - https://wiki.installgentoo.com/wiki/Software_minimalism + - https://suckless.org/philosophy + - https://github.com/173duprot/harm-less - Link collections of interesting software - https://suckless.org/rocks/ - https://suckless.org/other_projects/ @@ -909,8 +969,12 @@ links - https://virtuallyfun.com/2020/07/31/using-qemu-in-2020/ - nbd - https://patchwork.kernel.org/project/linux-block/patch_20190612163144.18486-2/roman.stratiienko@globallogic.com/ + - http://patraulea.com/nbd-http/ + - https://github.com/NetworkBlockDevice/nbd/ + - https://patchwork.kernel.org/project/linux-block/patch/20190612163144.18486-2-roman.stratiienko@globallogic.com/ - debugging - https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html + - https://ja.nsommer.dk/articles/linux-and-tiny-c-compiler-in-the-browser-part-one.html - X - tiny X - https://github.com/idunham/tinyxserver and @@ -921,6 +985,12 @@ links - alternatives: - https://github.com/michaelforney/velox, https://github.com/michaelforney/swc: but this is wayland + - http://www.microwindows.org/ + - KDrive (Tiny X, TinyX): Keith Packard + - https://www.pps.jussieu.fr/~jch/software/kdrive.html + - https://github.com/Earnestly/sx: alternative xinit/startx + - http://www.microwindows.org/ + - http://forum.tinycorelinux.net/index.php?topic=16299.0: fork of tinyx for tinycorelinux - X terminal - xterm: bloat - st, requires Xft, requiring fontconfig, freetype2, etc. can eventually @@ -941,6 +1011,63 @@ links this is all a little bit too much - ion1: more suckless, maybe patchable to do what we want https://github.com/apenwarr/ion1 +- debugging + - automatic serial without getty + - https://github.com/Angstrom-distribution/meta-linaro/blob/master/recipes-core/auto-serial-console/auto-serial-console/auto-getty +- suspend/hibernate + - https://docs.kernel.org/power/s2ram.html +- philosophical stuff + - 1983 Rob Pike made a presentation titled ‘UNIX Style, or cat -v Considered Harmful’ + - http://harmful.cat-v.org/cat-v/ +- hardware-specific stuff + - Unisys CWD-4002 + - http://www.dosdays.co.uk/topics/Manufacturers/cirrus_logic.php: graphic chip +- graphic programming + - https://www.svgalib.org/ + - https://benpfaff.org/projects.html: BOGL graphics library for framebuffers + +performance +----------- + +Building i486tcc-linux + +5 minutes userland including cross-toolchain +15 minutes kernel +1 minute ramdisk/floppy creation + +framebuffer +----------- + +insmod /lib/modules/drivers/video/fbdev/core/cfbcopyarea.ko +insmod /lib/modules/drivers/video/fbdev/core/cfbfillrect.ko +insmod /lib/modules/drivers/video/fbdev/core/cfbimgblt.ko +insmod /lib/modules/arch/x86/video/fbdev.ko +insmod /lib/modules/lib/fonts/font.ko +insmod /lib/modules/drivers/video/fbdev/core/fb.ko +insmod /lib/modules/drivers/video/fbdev/cirrusfb.ko + +insmod /lib/modules/drivers/video/vgastate.ko +insmod /lib/modules/lib/fonts/font.ko +insmod /lib/modules/drivers/video/fbdev/vga16fb.ko + +mknod /dev/fb0 c 29 0 +cat /sys/class/graphics/fb0/name + +Unsorted links +-------------- + +- framebuffer + - https://higfxback.github.io/ + - https://github.com/rothgar/awesome-tuis + - https://dev1galaxy.org/viewtopic.php?id=5400 + - https://directfb2.github.io/ + - https://github.com/directfb2/DirectFB2 + - https://github.com/8l/fbui + - https://manpages.ubuntu.com/manpages/xenial/man1/fbi.1.html + - https://kevinboone.me/linuxfbc.html?i=1 + - https://benpfaff.org/projects.html: vga16fb +- fonts + - https://github.com/ntwk/vga-font Real hardware ------------- @@ -953,3 +1080,4 @@ insmod 8390p.ko insmod ne.ko io=0x300 irq=10 ifconfig eth0 up sdhcp + diff --git a/docs/The KDrive Tiny X Server.txt b/docs/The KDrive Tiny X Server.txt new file mode 100644 index 0000000..0b24b4d --- /dev/null +++ b/docs/The KDrive Tiny X Server.txt @@ -0,0 +1,264 @@ + The KDrive Tiny X Server + + This page is obsolete; the howto information contained herein does not + apply to recent X.Org releases. It may still be of interest if you want + to understand what KDrive is about. + + KDrive (Tiny X, TinyX) is an X server written by Keith Packard that was + designed for low memory environments. On Linux/x86, a KDrive server + with RENDER support but without support for scalable fonts compiles + into less than 700 KB of text. KDrive tends to avoid large memory + allocations at runtime, and tries to perform operations "on the fly" + whenever possible (but this is also true of recent versions of the + stock XFree86 server). + + Unlike the usual XFree86 server, a KDrive server is completely + self-contained: it does not require any configuration files, and will + even function if no on-disk fonts are available. All configuration is + done at compile time and through command-line flags. + + At the time of writing, KDrive is for Linux only, although it could + probably be ported to other Unix-like systems with little effort. + + Disclaimer: This text was written by an incompetent amateur (J.Ch.), + and does not carry the imprimatur of Keith Packard. I am not intimately + familiar with all of the KDrive code, and this document is probably + wildly inaccurate. I am sole responsible for any errors or omissions in + this document. + + The information contained herein is offered in good faith, but with no + warranty of any kind. No kidding. + +The Xfbdev KDrive server + + The default KDrive server, Xfbdev, is designed for a Linux installation + with a working /dev/fb and any common PC mouse on /dev/mouse. It + includes the following drivers: + * Linux OS support; + * generic Linux keyboard; + * generic mouse; + * Linux fbdev display (unaccelerated). + + Xfbdev includes support for BDF and PCF bitmap fonts only. In addition, + it hardwires a number of standard fonts, notably cursor and fixed, + which will therefore be available even when there are no on-disk fonts. + By default, it does not contain support for local scalable fonts in any + format. + + Xfbdev also includes support for a number of server extensions, + including the ubiquitous SHAPE and the soon-to-be ubiquitous RENDER. + + In order to compile Xfbdev, you need a clean XFree86 tree; I recommend + version 4.0.2 or later. Put the following lines in your host.def file: + + #define BuildServersOnly YES + #define KDriveXServer YES + #define TinyXServer YES + #define XfbdevServer YES + + Now make World as usual; if the compilation proceeds without errors, + you should have an executable xc/programs/Xserver/Xfbdev. + + You may now make install or make install.man. + + For information on running the Xfbdev server, please see the + [1]Xfbdev(1), [2]Xkdrive(1) and [3]Xserver(1) manual pages. + +The Xvesa KDrive server + + The Xvesa server is for x86 hardware only, and includes an + unaccelerated display driver that will support any card with a VESA, + VGA or even EGA BIOS (VESA 1.1 is the earliest supported version; + VESA 2.0 will give better performance). Except for the display driver, + the Xvesa server is identical to Xfbdev. + + Unless you're using an original Hercules Graphics chipset or + compatible, your hardware is most probably supported. In addition, the + video driver in Xvesa will automagically do any initialisation of your + chipset that your BIOS knows about but that might be undocumented, and + thus not present in the stock XFree86 drivers. Xvesa is therefore an + excellent choice for laptops, and until recently I was using Xvesa as + the primary X server on mine. + + God protect us from copper money and CGA cards. + + In order to build the Xvesa server, include the following lines in your + host.def file: + + #define BuildServersOnly YES + #define KDriveXServer YES + #define TinyXServer YES + #define XvesaServer YES + + For information on running the Xvesa server, please see the + [4]Xvesa(1), [5]Xkdrive(1) and [6]Xserver(1) manual pages. + +Other standard KDrive servers + + The KDrive makefiles include building recipes for a number of other + servers, some of which use accelerated display drivers. These servers + are not currently documented. + + Any volunteers? + + Fore more information, please see the [7]Xkdrive(1) manual page and the + file [8]xc/config/cf/kdrive.cf. + +Custom KDrive servers + + A KDrive server does not include multiple drivers. In order to run + KDrive on your hardware, you need to compile a KDrive server with the + proper os, keyboard, mouse and display drivers. In addition, you will + need to select the set of font renderers and server extensions that you + want to compile. + + OS support + + At the time of writing, the publicly-available KDrive server only + supports Linux. As most of KDrive is OS-agnostic, porting to a + different Unix-like system should not be difficult. + + Some bits of the source hint at support for certain proprietary + systems, but it seems incomplete. + + If you port KDrive to a different OS, I'd be glad to hear from you (and + I am sure so would Keith). BSD should be easy. Minix-VMD might be more + challenging, as it lacks a standard socket library; but then, earlier + versions of XFree86 used to run on Minix-VMD, and KDrive uses the same + XTrans layer. Stock 32-bit Minix doesn't have a poll/select equivalent. + + I want to see KDrive on stock Minix. Please. + + Keyboard support + + At the time of writing, the KDrive server only has support for a + generic Linux keyboard; the keyboard mapping is copied from the Linux + kernel tables at startup. As X11 has richer keyboard information than + Linux, and furthermore KDrive's mapping tables are incomplete, the + results are not always perfect; I have found it necessary to fix my + keyboard using xmodmap. + + Mouse support + + Since XFree86 4.2.0, KDrive automatically detects the type of mouse on + /dev/mouse, which should be a link to the correct mouse device. Most + common types of mice (including, of course, PS/2, Microsoft and + Logitech serial, and Microsoft "bus") are supported by the mouse + driver; if yours is not, your best bet is probably to use gmp in + repeater mode. + + Display drivers + + KDrive includes a fairly large selection of display drivers. Two are + fully generic but unaccelerated: fbdev (included in the Xfbdev server) + and vesa (included in the Xvesa server). The other drivers are + partially accelerated, and support specific video hardware. + + The generic drivers are documented in the [9]Xfbdev(1) and [10]Xvesa(1) + manual pages. The accelerated drivers are currently undocumented; the + only source of information about them is the source. Please see the + directories under hw/kdrive/ and enjoy your read. + + Font renderers + + KDrive should be able to support all the font renderers supported by + XFree86. You may add any of the following to your host.def file: + + #define BuildSpeedo YES + #define BuildType1 YES + #define BuildCID YES + #define BuildFreeType YES + #define FontServerAccess YES + + In XFree86 4.3.0 and later, the FreeType backend includes support for + all common scalable font formats (including Type 1). For most uses, it + is the only one that you will need. + + Some of these renderers are rather large; you may want to think twice + before including them in your "tiny" server. + + As noted above, KDrive includes a number of hardwired, compiled-in + fonts. There is no good reason to disable support for these "built-in" + fonts; however, if you insist, you may use + + #define BuildBuiltinFonts NO + + Server extensions + + KDrive might or might not be able to support any server extension + supported by XFree86 that is not directly related to hardware. Use the + usual incantations in your host.def file, for example, + + #define BuildDBE YES + + There is no good reason to disable the RENDER extension. + + Additional defines + + Any additional options that you want to pass to the C compiler should + be put in KdriveServerExtraDefines: + + #define KdriveServerExtraDefines -DPIXPRIV + +Building against uClibc + + At least the Xvesa server appears to build and run when linked against + [11]uClibc; note, however, that I haven't done any extensive testing. + + You will first need to add two trivial functions to uClibc; this is + simply done by relinking uClibc with [12]uclibc-missing-math.c. Then, + assuming that your uclibc toolchain is invoked by i386-uclibc-cc, add + the following to your host.def file: + + #define CcCmd i386-uclibc-cc + + If you haven't recompiled libz against uClibc, you will also need to + add the following line to your host.def: + + #define HasZlib NO + + This will have the side-effect of disabling all support for compressed + fonts. + + Is the uclibc-missing-math.c hack still necessary with recent uClibc + releases? + +Download + + Binary KDrive servers for GNU/Linux/x86 might be available from [13]my + KDrive download directory. + + These binaries are offered in good faith, but really with no guarantee. + Not even of any kind. + +References + + [14]Handhelds Org and Jim Gettys' page about [15]cross-compiling + KDrive. + + [16]Keith Packard, the primary author of KDrive. + + [17]Back to my software page. + + [18]Juliusz Chroboczek, <jch@pps.jussieu.fr> + +References + + 1. http://www.xfree86.org/current/Xfbdev.1.html + 2. http://www.xfree86.org/current/Xkdrive.1.html + 3. http://www.xfree86.org/current/Xserver.1.html + 4. http://www.xfree86.org/current/Xvesa.1.html + 5. http://www.xfree86.org/current/Xkdrive.1.html + 6. http://www.xfree86.org/current/Xserver.1.html + 7. http://www.xfree86.org/current/Xkdrive.1.html + 8. http://cvsweb.xfree86.org/cvsweb/xc/config/cf/kdrive.cf + 9. http://www.xfree86.org/current/Xfbdev.1.html + 10. http://www.xfree86.org/current/Xvesa.1.html + 11. http://www.uclibc.org/ + 12. https://www.pps.jussieu.fr/~jch/software/uclibc-missing-math.c + 13. https://www.pps.jussieu.fr/~jch/software/kdrive/ + 14. http://www.handhelds.org/ + 15. http://www.handhelds.org/minihowto/building-x.html + 16. http://www.keithp.com/ + 17. https://www.irif.univ-paris-diderot.fr/~jch/software/ + 18. https://www.irif.univ-paris-diderot.fr/~jch/ diff --git a/docs/blog.stephencleary.com_2010_10_implementing-gccs-builtin-functions.txt b/docs/blog.stephencleary.com_2010_10_implementing-gccs-builtin-functions.txt new file mode 100644 index 0000000..12bcb9a --- /dev/null +++ b/docs/blog.stephencleary.com_2010_10_implementing-gccs-builtin-functions.txt @@ -0,0 +1,157 @@ + #[1]Stephen Cleary (the blog) [2]Cleary Search + + (BUTTON) Toggle navigation + [3]Stephen Cleary + + * [4]Blog + * [5]Book + * [6]Projects + * [7]Publications + * [8]Contact + * [9]Hire Me + * + * + +Implementing GCC's Builtin Functions + + Oct 18, 2010 o [10]Comments + + GCC has a number of [11]useful builtin functions, which translate + directly to the appropriate assembly instruction if the processor + supports it. A certain algorithm I was coding made use of a few of + these: __builtin_ffs (find first set bit), __builtin_clz (count leading + zero bits), and __builtin_ctz (count trailing zero bits). + + In theory, if the target processor does not support these instructions + (like mine), then the gcc library for that target should implement them + in software. Unfortunately, mine did not. + + The solution was surprisingly simple: I just had to implement the + [12]expected functions myself. The mapping is fairly obvious (e.g., + __builtin_clz is implemented by __clzsi2). + + By adding the following code to the project, I was able to build the + algorithm using __builtin_clz, __builtin_ctz, and __builtin_ffs: +// Returns the number of leading 0-bits in x, starting at the most significant b +it position. +// If x is zero, the result is undefined. +int __clzsi2(unsigned x); +int __clzsi2(unsigned x) +{ + // This uses a binary search (counting down) algorithm from Hacker's Delight. + unsigned y; + int n = 32; + y = x >>16; if (y != 0) {n = n -16; x = y;} + y = x >> 8; if (y != 0) {n = n - 8; x = y;} + y = x >> 4; if (y != 0) {n = n - 4; x = y;} + y = x >> 2; if (y != 0) {n = n - 2; x = y;} + y = x >> 1; if (y != 0) return n - 2; + return n - x; +} + +// Returns the number of trailing 0-bits in x, starting at the least significant + bit position. +// If x is zero, the result is undefined. +int __ctzsi2(unsigned x); +int __ctzsi2(unsigned x) +{ + // This uses a binary search algorithm from Hacker's Delight. + int n = 1; + if ((x & 0x0000FFFF) == 0) {n = n +16; x = x >>16;} + if ((x & 0x000000FF) == 0) {n = n + 8; x = x >> 8;} + if ((x & 0x0000000F) == 0) {n = n + 4; x = x >> 4;} + if ((x & 0x00000003) == 0) {n = n + 2; x = x >> 2;} + return n - (x & 1); +} + +// Returns the index of the least significant 1-bit in x, or the value zero if x + is zero. +// The least significant bit is index one. +int __ffsdi2 (unsigned x); +int __ffsdi2 (unsigned x) +{ + return (x == 0) ? 0 : __builtin_ctz(x) + 1; +} + + Presumably, this same approach would work for the many other GCC + builtins. + + Has this been helpful? You can show your appreciation by [13]leaving a + "coffee" tip. Thanks! + * [14]<- Previous Post + * [15]Next Post -> + + About Stephen Cleary + [Me-large.jpg] + Stephen Cleary is a [16]Christian, husband, father, and programmer + living in Northern Michigan. + [17][MVP.png] + My book + [18][Book-2nd-small.jpg] + Available from [19]Amazon (print/Kindle), [20]O'Reilly (Safari), or + [21]eBooks.com (PDF/epub). + Also available in [22]Russian, [23]Chinese, and [24]Korean. + Advertisement + [25]Hire me if you need in-depth assistance! + [INS: :INS] + This page may contain affiliate links. + Popular Posts + * [26]Async/await Intro + * [27]There Is No Thread + * [28]Don't Block on Async Code + + Series + * [29]React/Redux TodoMVC + * [30]A Tour of Task + * [31]Task.Run Etiquette + * [32]Task.Run vs. BackgroundWorker + * [33]Async OOP + * [34]TCP/IP .NET Sockets FAQ + * [35]Managed Services + * [36]IDisposable and Finalizers + * [37]Option Parsing + +References + + Visible links: + 1. https://feeds.feedburner.com/NitoPrograms + 2. https://stephencleary.com/opensearch.xml + 3. https://stephencleary.com/ + 4. https://blog.stephencleary.com/ + 5. https://stephencleary.com/book/ + 6. https://stephencleary.com/projects/ + 7. https://stephencleary.com/publications/ + 8. https://stephencleary.com/contact/ + 9. https://stephencleary.com/contract/ + 10. https://blog.stephencleary.com/2010/10/implementing-gccs-builtin-functions.html#comments + 11. http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Other-Builtins.html + 12. http://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html + 13. https://github.com/sponsors/StephenCleary?frequency=one-time&amount=5 + 14. https://blog.stephencleary.com/2010/10/firmware.html + 15. https://blog.stephencleary.com/2010/10/grand-rapids-day-of-dotnet-slides.html + 16. https://stephencleary.com/god/ + 17. http://mvp.microsoft.com/en-us/mvp/Stephen%20Cleary-5000058 + 18. https://stephencleary.com/book/ + 19. https://www.amazon.com/dp/149205450x/ref=as_li_ss_tl?&ref=pd_sl_a04BABB1D18C7F2658168FF785&linkCode=sl1&tag=stepheclearys-20&linkId=fb22bb126d6e60f305fecddf3d4ecbd8 + 20. https://learning.oreilly.com/library/view/concurrency-in-c/9781492054498/ + 21. https://www.ebooks.com/cj.asp?IID=209766469&cjsku=209766469 + 22. https://www.labirint.ru/books/745595/ + 23. https://item.jd.com/12769567.html + 24. https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=270818316 + 25. https://stephencleary.com/contract/ + 26. https://blog.stephencleary.com/2012/02/async-and-await.html + 27. https://blog.stephencleary.com/2013/11/there-is-no-thread.html + 28. https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html + 29. https://blog.stephencleary.com/2016/02/react-redux-todomvc.html + 30. https://blog.stephencleary.com/2014/04/a-tour-of-task-part-0-overview.html + 31. https://blog.stephencleary.com/2013/10/taskrun-etiquette-and-proper-usage.html + 32. https://blog.stephencleary.com/2013/05/taskrun-vs-backgroundworker-intro.html + 33. https://blog.stephencleary.com/2013/01/async-oop-0-introduction.html + 34. https://blog.stephencleary.com/2009/04/tcpip-net-sockets-faq.html + 35. https://blog.stephencleary.com/2013/10/managed-services-roundup.html + 36. https://blog.stephencleary.com/2009/08/how-to-implement-idisposable-and.html + 37. https://blog.stephencleary.com/2011/02/option-parsing-introduction.html + + Hidden links: + 39. http://feeds.feedburner.com/NitoPrograms + 40. https://stephencleary.com/search/ diff --git a/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt b/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt new file mode 100644 index 0000000..b9085a5 --- /dev/null +++ b/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt @@ -0,0 +1,1168 @@ + [1]busybox@busybox.net + Discussion: + Custom initrd using busybox + Moot Account + 2006-11-05 16:30:01 UTC + [2]Permalink + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + Here are my arguments to the kernel: + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + This is the custom linuxrc that does _not_ work: + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + Thanks for any help. + Luciano Miguel Ferreira Rocha + 2006-11-05 16:52:52 UTC + [3]Permalink + [4]Post by Moot Account + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + And this stops linuxrc from continuing? + Try: + ... + cd /new_root + exec < dev/console &> dev/console + pivot_root . initrd + ... + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://busybox.net/lists/busybox/attachments/20061105/78ae3c9d/attachme + nt.pgp + Moot Account + 2006-11-05 17:09:43 UTC + [5]Permalink + Thanks! I'll try this when I get to the board (Soekris net4801) + tomorrow. + But I have another question. How is /sbin/init ( ->busybox ) accessed. + When I use: + exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1 + the usage of init is printed. This probably means that init is not run + as PID 1. Also, when I use /linuxrc it seems to be stuck. + Any ideas? + Thanks again. + -Lenmarc + [6]Post by Luciano Miguel Ferreira Rocha + [7]Post by Moot Account + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + And this stops linuxrc from continuing? + ... + cd /new_root + exec < dev/console &> dev/console + pivot_root . initrd + ... + Luciano Miguel Ferreira Rocha + 2006-11-05 17:20:31 UTC + [8]Permalink + [9]Post by Moot Account + Thanks! I'll try this when I get to the board (Soekris net4801) + tomorrow. + But I have another question. How is /sbin/init ( ->busybox ) accessed. + exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1 + the usage of init is printed. This probably means that init is not run + as PID 1. Also, when I use /linuxrc it seems to be stuck. + Any ideas? + Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init + (pid + isn't 1). You're supposed to set the real root device writing to a + /proc + file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts + the real root device and executes init. + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + Other option you could check out would be using initramfs instead of + old + initrd: + 1. name your script /init instead of /linuxrc; + 2. call exec switch_root instead of pivot_root (and switch_root isn't + supposed to return, it calls init by itself); + 3. create the new "initrd" as a new-format cpio file: + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + More information about initramfs and initrd can be found in a kernel + source tree: + - Documentation/initrd.txt + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + - Documentation/early-userspace/README + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://busybox.net/lists/busybox/attachments/20061105/32f2f1f3/attachme + nt-0001.pgp + Bernhard Fischer + 2006-11-05 18:07:30 UTC + [10]Permalink + [11]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + Jason Schoon + 2006-11-05 18:49:19 UTC + [12]Permalink + [13]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root00 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + By convenience vars, do you mean such as /dev/ram0? If so, turning of + sysfs + support will get rid of them. In many embedded scenarios sysfs doesn't + buy + you much anyway. If you are hotplugging or something similar though, + the + space savings are not likely to be worth not having sysfs. + -------------- next part -------------- + An HTML attachment was scrubbed... + URL: + http://busybox.net/lists/busybox/attachments/20061105/8a59f7e3/attachme + nt.html + Jason Schoon + 2006-11-05 18:55:15 UTC + [14]Permalink + [15]Post by Jason Schoon + [16]Post by Luciano Miguel Ferreira Rocha + [17]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + [18]Post by Luciano Miguel Ferreira Rocha + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root00 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + By convenience vars, do you mean such as /dev/ram0? If so, turning of + sysfs support will get rid of them. In many embedded scenarios sysfs + doesn't buy you much anyway. If you are hotplugging or something + similar + though, the space savings are not likely to be worth not having sysfs. + Nevermind, I figured out what you were really asking. I have never seen + a + scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were + not + available via /proc/cmdline. I'm guessing that means there isn't + currently + a way to get them out of memory. + If anything, the linux-tiny guys might have a config option to do that. + -------------- next part -------------- + An HTML attachment was scrubbed... + URL: + http://busybox.net/lists/busybox/attachments/20061105/68741ca9/attachme + nt.htm + Bernhard Fischer + 2006-11-05 19:11:15 UTC + [19]Permalink + [20]Post by Jason Schoon + [21]Post by Bernhard Fischer + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + I have never seen a + scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were + not + available via /proc/cmdline. I'm guessing that means there isn't + currently + a way to get them out of memory. + If anything, the linux-tiny guys might have a config option to do that. + Yeah, thought so too. Sounds like __user_init along with something like + sysctl (or better, putting it into a /del_usermem fops.flush or the + like). hm.. + Bernhard Fischer + 2006-11-05 19:11:15 UTC + [22]Permalink + [23]Post by Jason Schoon + [24]Post by Bernhard Fischer + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + I have never seen a + scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were + not + available via /proc/cmdline. I'm guessing that means there isn't + currently + a way to get them out of memory. + If anything, the linux-tiny guys might have a config option to do that. + Yeah, thought so too. Sounds like __user_init along with something like + sysctl (or better, putting it into a /del_usermem fops.flush or the + like). hm.. + Jason Schoon + 2006-11-05 18:55:15 UTC + [25]Permalink + [26]Post by Jason Schoon + [27]Post by Luciano Miguel Ferreira Rocha + [28]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + [29]Post by Luciano Miguel Ferreira Rocha + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + By convenience vars, do you mean such as /dev/ram0? If so, turning of + sysfs support will get rid of them. In many embedded scenarios sysfs + doesn't buy you much anyway. If you are hotplugging or something + similar + though, the space savings are not likely to be worth not having sysfs. + Nevermind, I figured out what you were really asking. I have never seen + a + scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were + not + available via /proc/cmdline. I'm guessing that means there isn't + currently + a way to get them out of memory. + If anything, the linux-tiny guys might have a config option to do that. + -------------- next part -------------- + An HTML attachment was scrubbed... + URL: + http://lists.busybox.net/pipermail/busybox/attachments/20061105/68741ca + 9/attachment-0001.htm + Jason Schoon + 2006-11-05 18:49:19 UTC + [30]Permalink + [31]Post by Bernhard Fischer + [32]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + By convenience vars, do you mean such as /dev/ram0? If so, turning of + sysfs + support will get rid of them. In many embedded scenarios sysfs doesn't + buy + you much anyway. If you are hotplugging or something similar though, + the + space savings are not likely to be worth not having sysfs. + -------------- next part -------------- + An HTML attachment was scrubbed... + URL: + http://lists.busybox.net/pipermail/busybox/attachments/20061105/8a59f7e + 3/attachment.htm + Rob Landley + 2006-11-05 20:19:40 UTC + [33]Permalink + [34]Post by Luciano Miguel Ferreira Rocha + Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init + (pid + isn't 1). You're supposed to set the real root device writing to a + /proc + file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts + the real root device and executes init. + Using initramfs and switch_root is way more straightforward than this. + And + doesn't have the magic behind the scenes stuff (like reparenting every + running process whose ".", "..", or "/" points to the old root, yes + including + kernel threads). + Just sayin'... + Rob + [35]Post by Luciano Miguel Ferreira Rocha + Other option you could check out would be using initramfs instead of + old + 1. name your script /init instead of /linuxrc; + Or supply the kernel the "rdinit=/blah" argument to tell it what you + called + it. + [36]Post by Luciano Miguel Ferreira Rocha + 2. call exec switch_root instead of pivot_root (and switch_root isn't + supposed to return, it calls init by itself); + Don't forget the "exec". Common mistake. If it's not PID 1, it'll + abort. + [37]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + The kernel can do this for you, if you prefer. And even build it into + the + bzImage. + [38]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + I also wrote a couple articles for TimeSys, earlier this year. It's a + little + long-winded, but might help: + http://www.timesys.com/timesource/march_06.htm + http://timesys.com/timesource/initramfs.htm + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Luciano Miguel Ferreira Rocha + 2006-11-05 23:34:31 UTC + [39]Permalink + [40]Post by Rob Landley + [41]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + Information about the rdinit parameter would be nice. :) + It is in kernel-parameters.txt but I never searched for such an option. + Also, it reads "The program run by the old initrd (which was called + /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing + /initrd anywhere else. + And finally, could you add some bigger warnings about rootfs being + ramfs, a non-swappable device? The file does say that initramfs is + extracted to rootfs, an instance of ramfs. But I didn't read the file + that carefully the first time... + I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, + moves all remaining files to the tmpfs, and executes the new init, if + anyone is interested. + Regards, + Luciano Rocha + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://busybox.net/lists/busybox/attachments/20061105/6bd4039f/attachme + nt.pgp + Rob Landley + 2006-11-05 23:43:52 UTC + [42]Permalink + [43]Post by Luciano Miguel Ferreira Rocha + [44]Post by Rob Landley + [45]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + Information about the rdinit parameter would be nice. :) + I think the current version (2.6.18 and up) mentions it? + [46]Post by Luciano Miguel Ferreira Rocha + It is in kernel-parameters.txt but I never searched for such an option. + Also, it reads "The program run by the old initrd (which was called + /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing + /initrd anywhere else. + Yeah, that's linuxrc. + [47]Post by Luciano Miguel Ferreira Rocha + And finally, could you add some bigger warnings about rootfs being + ramfs, a non-swappable device? + There are patches floating around to make it tmpfs if you have tmpfs + built + into the kernel. I keep thinking they've been integrated. (This is the + point of tmpfs.) + [48]Post by Luciano Miguel Ferreira Rocha + The file does say that initramfs is + extracted to rootfs, an instance of ramfs. But I didn't read the file + that carefully the first time... + It should be possible for this to be tmpfs. When did this last crop + up... + http://lkml.org/lkml/2006/7/30/120 + Dunno if it got integrated or not, but there's a start... + [49]Post by Luciano Miguel Ferreira Rocha + I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, + moves all remaining files to the tmpfs, and executes the new init, if + anyone is interested. + The proper thing to do is patch the kernel so initramfs is a tmpfs. + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Luciano Miguel Ferreira Rocha + 2006-11-06 00:20:07 UTC + [50]Permalink + This post might be inappropriate. Click to display it. + Moot Account + 2006-11-06 20:07:15 UTC + [51]Permalink + Hi all, + Thanks all for the help, it's working now! Apparently, Ive been doing + the right initrd and initramfs for the past few days. The problem is + with my real rootfs (the one in /dev/hda2). + Please pardon a newbie. My question is: what's the _difference_ + between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz + if I enable the gzipped output? I know this is related to buildroot + but please answer if it's trivial. =) + The working setup NOW is rootfs.i686.ext2.gz which is my initrd and + also my real rootfs. The NON-working setup is rootfs.i686.ext2.gz as + my initrd and "buildroot/build_i686/root" folder as my real rootfs, + which I copied to /dev/hda2. + Again, thanks all for the tips! + -Lenmarc + Rob Landley + 2006-11-07 21:48:09 UTC + [52]Permalink + [53]Post by Moot Account + Please pardon a newbie. My question is: what's the _difference_ + between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz + The difference is that this is the BusyBox mailing list, and the + buildroot + mailing list is buildroot at uclibc.org. Your question is about + buildroot, not + busybox. + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Rob Landley + 2006-11-07 21:48:09 UTC + [54]Permalink + [55]Post by Moot Account + Please pardon a newbie. My question is: what's the _difference_ + between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz + The difference is that this is the BusyBox mailing list, and the + buildroot + mailing list is buildroot at uclibc.org. Your question is about + buildroot, not + busybox. + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Moot Account + 2006-11-06 20:07:15 UTC + [56]Permalink + Hi all, + Thanks all for the help, it's working now! Apparently, Ive been doing + the right initrd and initramfs for the past few days. The problem is + with my real rootfs (the one in /dev/hda2). + Please pardon a newbie. My question is: what's the _difference_ + between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz + if I enable the gzipped output? I know this is related to buildroot + but please answer if it's trivial. =) + The working setup NOW is rootfs.i686.ext2.gz which is my initrd and + also my real rootfs. The NON-working setup is rootfs.i686.ext2.gz as + my initrd and "buildroot/build_i686/root" folder as my real rootfs, + which I copied to /dev/hda2. + Again, thanks all for the tips! + -Lenmarc + Luciano Miguel Ferreira Rocha + 2006-11-06 00:20:07 UTC + [57]Permalink + This post might be inappropriate. Click to display it. + Rob Landley + 2006-11-05 23:43:52 UTC + [58]Permalink + [59]Post by Luciano Miguel Ferreira Rocha + [60]Post by Rob Landley + [61]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + Information about the rdinit parameter would be nice. :) + I think the current version (2.6.18 and up) mentions it? + [62]Post by Luciano Miguel Ferreira Rocha + It is in kernel-parameters.txt but I never searched for such an option. + Also, it reads "The program run by the old initrd (which was called + /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing + /initrd anywhere else. + Yeah, that's linuxrc. + [63]Post by Luciano Miguel Ferreira Rocha + And finally, could you add some bigger warnings about rootfs being + ramfs, a non-swappable device? + There are patches floating around to make it tmpfs if you have tmpfs + built + into the kernel. I keep thinking they've been integrated. (This is the + point of tmpfs.) + [64]Post by Luciano Miguel Ferreira Rocha + The file does say that initramfs is + extracted to rootfs, an instance of ramfs. But I didn't read the file + that carefully the first time... + It should be possible for this to be tmpfs. When did this last crop + up... + http://lkml.org/lkml/2006/7/30/120 + Dunno if it got integrated or not, but there's a start... + [65]Post by Luciano Miguel Ferreira Rocha + I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, + moves all remaining files to the tmpfs, and executes the new init, if + anyone is interested. + The proper thing to do is patch the kernel so initramfs is a tmpfs. + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Luciano Miguel Ferreira Rocha + 2006-11-05 23:34:31 UTC + [66]Permalink + [67]Post by Rob Landley + [68]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + Information about the rdinit parameter would be nice. :) + It is in kernel-parameters.txt but I never searched for such an option. + Also, it reads "The program run by the old initrd (which was called + /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing + /initrd anywhere else. + And finally, could you add some bigger warnings about rootfs being + ramfs, a non-swappable device? The file does say that initramfs is + extracted to rootfs, an instance of ramfs. But I didn't read the file + that carefully the first time... + I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, + moves all remaining files to the tmpfs, and executes the new init, if + anyone is interested. + Regards, + Luciano Rocha + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://lists.busybox.net/pipermail/busybox/attachments/20061105/6bd4039 + f/attachment-0002.pgp + Rob Landley + 2006-11-05 20:26:42 UTC + [69]Permalink + [70]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + Now _that_ is an ugly set of command line options (for cpio). Let's + see, that + should equate to: + cpio -0 -o -H newc + I'm interested in this because I'm about halfway through writing + toybox's + get_optflags(), which doesn't use getopt() so I have to parse all this + myself. It's not actually that hard, but the tricky case is where some + of + your arguments have no dash, ala ps or tar. Then you can wind up with + stuff + like: + tar xjfCv filename.tbz dirname blah + Which is equivalent to: + tar -x -j -f filename.tbz -C dirname -v blah + And _not_ equivalent to: + tar -x -j -f C -v filename.tbz blah + Which is what you get with the getopt() in uClibc 0.9.28. (I realize + this is + a funky corner case, but it's one that bit me and I want to get it + _right_ + this time.) + It looks like the nodash mode and the dash mode of the option parser + have + different sequencing requirements. Ok, I can do that... + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Luciano Miguel Ferreira Rocha + 2006-11-05 23:02:12 UTC + [71]Permalink + [72]Post by Rob Landley + [73]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + Now _that_ is an ugly set of command line options (for cpio). + Thank you. :) + I used to use -0oc. But after wasting a coule of hours trying to make a + kernel + recognize a cpio archive, I found that -c doesn't mean exactly the same + thing everywhere. So now I use -Hnewc everywhere. + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://busybox.net/lists/busybox/attachments/20061105/fb8660e1/attachme + nt.pgp + Luciano Miguel Ferreira Rocha + 2006-11-05 23:02:12 UTC + [74]Permalink + [75]Post by Rob Landley + [76]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + Now _that_ is an ugly set of command line options (for cpio). + Thank you. :) + I used to use -0oc. But after wasting a coule of hours trying to make a + kernel + recognize a cpio archive, I found that -c doesn't mean exactly the same + thing everywhere. So now I use -Hnewc everywhere. + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://lists.busybox.net/pipermail/busybox/attachments/20061105/fb8660e + 1/attachment-0002.pgp + Bernhard Fischer + 2006-11-05 18:07:30 UTC + [77]Permalink + [78]Post by Luciano Miguel Ferreira Rocha + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + resp. root=0100 which wastes less memory ;) + btw, is there a way to flush all or some of these convenience vars out + of + the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i + admit.. + Rob Landley + 2006-11-05 20:19:40 UTC + [79]Permalink + [80]Post by Luciano Miguel Ferreira Rocha + Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init + (pid + isn't 1). You're supposed to set the real root device writing to a + /proc + file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts + the real root device and executes init. + Using initramfs and switch_root is way more straightforward than this. + And + doesn't have the magic behind the scenes stuff (like reparenting every + running process whose ".", "..", or "/" points to the old root, yes + including + kernel threads). + Just sayin'... + Rob + [81]Post by Luciano Miguel Ferreira Rocha + Other option you could check out would be using initramfs instead of + old + 1. name your script /init instead of /linuxrc; + Or supply the kernel the "rdinit=/blah" argument to tell it what you + called + it. + [82]Post by Luciano Miguel Ferreira Rocha + 2. call exec switch_root instead of pivot_root (and switch_root isn't + supposed to return, it calls init by itself); + Don't forget the "exec". Common mistake. If it's not PID 1, it'll + abort. + [83]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + The kernel can do this for you, if you prefer. And even build it into + the + bzImage. + [84]Post by Luciano Miguel Ferreira Rocha + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + I wrote that one. If it's missing something, let me know. + I also wrote a couple articles for TimeSys, earlier this year. It's a + little + long-winded, but might help: + http://www.timesys.com/timesource/march_06.htm + http://timesys.com/timesource/initramfs.htm + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Rob Landley + 2006-11-05 20:26:42 UTC + [85]Permalink + [86]Post by Luciano Miguel Ferreira Rocha + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + Now _that_ is an ugly set of command line options (for cpio). Let's + see, that + should equate to: + cpio -0 -o -H newc + I'm interested in this because I'm about halfway through writing + toybox's + get_optflags(), which doesn't use getopt() so I have to parse all this + myself. It's not actually that hard, but the tricky case is where some + of + your arguments have no dash, ala ps or tar. Then you can wind up with + stuff + like: + tar xjfCv filename.tbz dirname blah + Which is equivalent to: + tar -x -j -f filename.tbz -C dirname -v blah + And _not_ equivalent to: + tar -x -j -f C -v filename.tbz blah + Which is what you get with the getopt() in uClibc 0.9.28. (I realize + this is + a funky corner case, but it's one that bit me and I want to get it + _right_ + this time.) + It looks like the nodash mode and the dash mode of the option parser + have + different sequencing requirements. Ok, I can do that... + Rob + -- + "Perfection is reached, not when there is no longer anything to add, + but + when there is no longer anything to take away." - Antoine de + Saint-Exupery + Luciano Miguel Ferreira Rocha + 2006-11-05 17:20:31 UTC + [87]Permalink + [88]Post by Moot Account + Thanks! I'll try this when I get to the board (Soekris net4801) + tomorrow. + But I have another question. How is /sbin/init ( ->busybox ) accessed. + exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1 + the usage of init is printed. This probably means that init is not run + as PID 1. Also, when I use /linuxrc it seems to be stuck. + Any ideas? + Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init + (pid + isn't 1). You're supposed to set the real root device writing to a + /proc + file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts + the real root device and executes init. + You can change that behaviour by booting your kernel with + "init=/linuxrc + root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). + Other option you could check out would be using initramfs instead of + old + initrd: + 1. name your script /init instead of /linuxrc; + 2. call exec switch_root instead of pivot_root (and switch_root isn't + supposed to return, it calls init by itself); + 3. create the new "initrd" as a new-format cpio file: + find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img + More information about initramfs and initrd can be found in a kernel + source tree: + - Documentation/initrd.txt + - Documentation/filesystems/ramfs-rootfs-initramfs.txt + - Documentation/early-userspace/README + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://lists.busybox.net/pipermail/busybox/attachments/20061105/32f2f1f + 3/attachment-0002.pgp + Moot Account + 2006-11-05 17:09:43 UTC + [89]Permalink + Thanks! I'll try this when I get to the board (Soekris net4801) + tomorrow. + But I have another question. How is /sbin/init ( ->busybox ) accessed. + When I use: + exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1 + the usage of init is printed. This probably means that init is not run + as PID 1. Also, when I use /linuxrc it seems to be stuck. + Any ideas? + Thanks again. + -Lenmarc + [90]Post by Luciano Miguel Ferreira Rocha + [91]Post by Moot Account + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + And this stops linuxrc from continuing? + ... + cd /new_root + exec < dev/console &> dev/console + pivot_root . initrd + ... + Moot Account + 2006-11-05 16:30:01 UTC + [92]Permalink + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + Here are my arguments to the kernel: + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + This is the custom linuxrc that does _not_ work: + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + Thanks for any help. + Luciano Miguel Ferreira Rocha + 2006-11-05 16:52:52 UTC + [93]Permalink + [94]Post by Moot Account + Hi, + This is a bloated idea but it's just an exercise. The idea is to use + the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). + This initrd should mount the _real_ rootfs using pivot_root. The real + rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs + built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. + Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first + by the kernel after mounting the initrd. Instead of pointing it to + /bin/busybox, I'm going to create a custom linuxrc. + My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 + and execute the /linuxrc, which is still pointed /bin/busybox. I need + to chroot because /linuxrc will initialize my rootfs and put up the + login (ie /etc/inittab getty). + linux /boot/bzImage console=ttyS0,9600 + (since it's a serial console) + #!/bin/sh + echo "linuxrc execute" + mount -t proc /proc /proc + mkdir new_root + mount -t ext2 /dev/hda2 /new_root + umount proc + cd /new_root + pivot_root . initrd + mount -t proc proc proc + mount -t devfs devfs dev + exec /usr/sbin/chroot . 'exec /linuxrc' \ + <dev/console >dev/console 2>&1 + I'm stuck after the execution pivot_root. It seems that dev/console is + busy. + And this stops linuxrc from continuing? + Try: + ... + cd /new_root + exec < dev/console &> dev/console + pivot_root . initrd + ... + -- + lfr + 0/0 + -------------- next part -------------- + A non-text attachment was scrubbed... + Name: not available + Type: application/pgp-signature + Size: 189 bytes + Desc: not available + Url : + http://lists.busybox.net/pipermail/busybox/attachments/20061105/78ae3c9 + d/attachment-0002.pgp + 31 Replies + 147 Views + [95]Permalink to this page + [96]Disable enhanced parsing + Thread Navigation + Moot Account 2006-11-05 16:30:01 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 16:52:52 UTC + Moot Account 2006-11-05 17:09:43 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 17:20:31 UTC + Bernhard Fischer 2006-11-05 18:07:30 UTC + Jason Schoon 2006-11-05 18:49:19 UTC + Jason Schoon 2006-11-05 18:55:15 UTC + Bernhard Fischer 2006-11-05 19:11:15 UTC + Bernhard Fischer 2006-11-05 19:11:15 UTC + Jason Schoon 2006-11-05 18:55:15 UTC + Jason Schoon 2006-11-05 18:49:19 UTC + Rob Landley 2006-11-05 20:19:40 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 23:34:31 UTC + Rob Landley 2006-11-05 23:43:52 UTC + Luciano Miguel Ferreira Rocha 2006-11-06 00:20:07 UTC + Moot Account 2006-11-06 20:07:15 UTC + Rob Landley 2006-11-07 21:48:09 UTC + Rob Landley 2006-11-07 21:48:09 UTC + Moot Account 2006-11-06 20:07:15 UTC + Luciano Miguel Ferreira Rocha 2006-11-06 00:20:07 UTC + Rob Landley 2006-11-05 23:43:52 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 23:34:31 UTC + Rob Landley 2006-11-05 20:26:42 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 23:02:12 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 23:02:12 UTC + Bernhard Fischer 2006-11-05 18:07:30 UTC + Rob Landley 2006-11-05 20:19:40 UTC + Rob Landley 2006-11-05 20:26:42 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 17:20:31 UTC + Moot Account 2006-11-05 17:09:43 UTC + Moot Account 2006-11-05 16:30:01 UTC + Luciano Miguel Ferreira Rocha 2006-11-05 16:52:52 UTC + + [97]about - [98]legalese + + Loading... + +References + + Visible links: + 1. https://busybox.busybox.narkive.com/ + 2. https://narkive.com/PBeyeZOM.1 + 3. https://narkive.com/PBeyeZOM.2 + 4. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1 + 5. https://narkive.com/PBeyeZOM.3 + 6. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2 + 7. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1 + 8. https://narkive.com/PBeyeZOM.4 + 9. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3 + 10. https://narkive.com/PBeyeZOM.5 + 11. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 12. https://narkive.com/PBeyeZOM.6 + 13. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 14. https://narkive.com/PBeyeZOM.7 + 15. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6 + 16. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 17. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 18. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 19. https://narkive.com/PBeyeZOM.8 + 20. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7 + 21. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5 + 22. https://narkive.com/PBeyeZOM.24 + 23. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7 + 24. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5 + 25. https://narkive.com/PBeyeZOM.23 + 26. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6 + 27. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 28. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 29. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 30. https://narkive.com/PBeyeZOM.22 + 31. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5 + 32. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 33. https://narkive.com/PBeyeZOM.9 + 34. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 35. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 36. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 37. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 38. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 39. https://narkive.com/PBeyeZOM.12 + 40. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9 + 41. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 42. https://narkive.com/PBeyeZOM.13 + 43. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 44. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9 + 45. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 46. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 47. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 48. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 49. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 50. https://narkive.com/PBeyeZOM.14 + 51. https://narkive.com/PBeyeZOM.15 + 52. https://narkive.com/PBeyeZOM.16 + 53. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15 + 54. https://narkive.com/PBeyeZOM.32 + 55. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15 + 56. https://narkive.com/PBeyeZOM.31 + 57. https://narkive.com/PBeyeZOM.30 + 58. https://narkive.com/PBeyeZOM.29 + 59. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 60. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9 + 61. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 62. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 63. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 64. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 65. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 66. https://narkive.com/PBeyeZOM.28 + 67. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9 + 68. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 69. https://narkive.com/PBeyeZOM.10 + 70. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 71. https://narkive.com/PBeyeZOM.11 + 72. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10 + 73. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 74. https://narkive.com/PBeyeZOM.27 + 75. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10 + 76. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 77. https://narkive.com/PBeyeZOM.21 + 78. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 79. https://narkive.com/PBeyeZOM.25 + 80. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 81. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 82. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 83. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 84. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 85. https://narkive.com/PBeyeZOM.26 + 86. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 87. https://narkive.com/PBeyeZOM.20 + 88. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3 + 89. https://narkive.com/PBeyeZOM.19 + 90. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2 + 91. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1 + 92. https://narkive.com/PBeyeZOM.17 + 93. https://narkive.com/PBeyeZOM.18 + 94. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1 + 95. https://narkive.com/PBeyeZOM + 96. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using?parse=disable + 97. https://narkive.com/about + 98. https://narkive.com/legalese + + Hidden links: + 100. https://narkive.com/ + 101. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1 + 102. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2 + 103. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3 + 104. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4 + 105. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5 + 106. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6 + 107. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7 + 108. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post8 + 109. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post24 + 110. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post23 + 111. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post22 + 112. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9 + 113. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12 + 114. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post13 + 115. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post14 + 116. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15 + 117. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post16 + 118. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post32 + 119. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post31 + 120. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post30 + 121. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post29 + 122. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post28 + 123. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10 + 124. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post11 + 125. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post27 + 126. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post21 + 127. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post25 + 128. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post26 + 129. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post20 + 130. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post19 + 131. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post17 + 132. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post18 diff --git a/docs/docs.kernel.org_power_s2ram.txt b/docs/docs.kernel.org_power_s2ram.txt new file mode 100644 index 0000000..1113b00 --- /dev/null +++ b/docs/docs.kernel.org_power_s2ram.txt @@ -0,0 +1,202 @@ + #[1]Index [2]Search [3]Interaction of Suspend code (S3) with the CPU + hotplug infrastructure [4]Runtime Power Management Framework for I/O + Devices + +[5]The Linux Kernel + + 6.7.0 + +Quick search + + ____________________ Go + +Contents + + [X] + * [6]A guide to the Kernel Development Process + * [7]Submitting patches: the essential guide to getting your code + into the kernel + * [8]Code of conduct + * [9]Kernel Maintainer Handbook + * [10]All development-process docs + + * [11]Core API Documentation + * [12]Driver implementer's API guide + * [13]Kernel subsystem documentation + + [14]Core subsystems + o [15]Core API Documentation + o [16]Driver implementer's API guide + o [17]Memory Management Documentation + o [18]Power Management + o [19]Scheduler + o [20]Timers + o [21]Locking + + [22]Human interfaces + + [23]Networking interfaces + + [24]Storage interfaces + * [25]Locking in the kernel + + * [26]Linux kernel licensing rules + * [27]How to write kernel documentation + * [28]Development tools for the kernel + * [29]Kernel Testing Guide + * [30]Kernel Hacking Guides + * [31]Linux Tracing Technologies + * [32]fault-injection + * [33]Kernel Livepatching + * [34]Rust + + * [35]The Linux kernel user's and administrator's guide + * [36]The kernel build system + * [37]Reporting issues + * [38]User-space tools + * [39]The Linux kernel user-space API guide + + * [40]The Linux kernel firmware guide + * [41]Open Firmware and Devicetree + + * [42]CPU Architectures + + * [43]Unsorted Documentation + + * [44]Translations + +This Page + + * [45]Show Source + +How to get s2ram working[46]¶ + + 2006 Linus Torvalds 2006 Pavel Machek + 1. Check suspend.sf.net, program s2ram there has long whitelist of + "known ok" machines, along with tricks to use on each one. + 2. If that does not help, try reading [47]swsusp/S3 tricks and + [48]Video issues with S3 resume. Perhaps problem is as simple as + broken module, and simple module unload can fix it. + 3. You can use Linus' TRACE_RESUME infrastructure, described below. + +Using TRACE_RESUME[49]¶ + + I've been working at making the machines I have able to STR, and almost + always it's a driver that is buggy. Thank God for the suspend/resume + debugging - the thing that Chuck tried to disable. That's often the + _only_ way to debug these things, and it's actually pretty powerful + (but time-consuming - having to insert TRACE_RESUME() markers into the + device driver that doesn't resume and recompile and reboot). + + Anyway, the way to debug this for people who are interested (have a + machine that doesn't boot) is: + + * enable PM_DEBUG, and PM_TRACE + * use a script like this: +#!/bin/sh +sync +echo 1 > /sys/power/pm_trace +echo mem > /sys/power/state + + to suspend + * if it doesn't come back up (which is usually the problem), reboot + by holding the power button down, and look at the dmesg output for + things like: +Magic number: 4:156:725 +hash matches drivers/base/power/resume.c:28 +hash matches device 0000:01:00.0 + + which means that the last trace event was just before trying to + resume device 0000:01:00.0. Then figure out what driver is + controlling that device (lspci and /sys/devices/pci* is your + friend), and see if you can fix it, disable it, or trace into its + resume function. + If no device matches the hash (or any matches appear to be false + positives), the culprit may be a device from a loadable kernel + module that is not loaded until after the hash is checked. You can + check the hash against the current devices again after more modules + are loaded using sysfs: +cat /sys/power/pm_trace_dev_match + + For example, the above happens to be the VGA device on my EVO, which I + used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out + that "radeonfb" simply cannot resume that device - it tries to set the + PLL's, and it just _hangs_. Using the regular VGA console and letting X + resume it instead works fine. + +NOTE[50]¶ + + pm_trace uses the system's Real Time Clock (RTC) to save the magic + number. Reason for this is that the RTC is the only reliably available + piece of hardware during resume operations where a value can be set + that will survive a reboot. + + pm_trace is not compatible with asynchronous suspend, so it turns + asynchronous suspend off (which may work around timing or + ordering-sensitive bugs). + + Consequence is that after a resume (even if it is successful) your + system clock will have a value corresponding to the magic number + instead of the correct date/time! It is therefore advisable to use a + program like ntp-date or rdate to reset the correct date/time from an + external time source when using this trace option. + + As the clock keeps ticking it is also essential that the reboot is done + quickly after the resume failure. The trace option does not use the + seconds or the low order bits of the minutes of the RTC, but a too long + delay will corrupt the magic value. + + ©The kernel development community. | Powered by [51]Sphinx 5.0.1 & + [52]Alabaster 0.7.12 | [53]Page source + +References + + 1. https://docs.kernel.org/genindex.html + 2. https://docs.kernel.org/search.html + 3. https://docs.kernel.org/power/suspend-and-cpuhotplug.html + 4. https://docs.kernel.org/power/runtime_pm.html + 5. https://docs.kernel.org/index.html + 6. https://docs.kernel.org/process/development-process.html + 7. https://docs.kernel.org/process/submitting-patches.html + 8. https://docs.kernel.org/process/code-of-conduct.html + 9. https://docs.kernel.org/maintainer/index.html + 10. https://docs.kernel.org/process/index.html + 11. https://docs.kernel.org/core-api/index.html + 12. https://docs.kernel.org/driver-api/index.html + 13. https://docs.kernel.org/subsystem-apis.html + 14. https://docs.kernel.org/subsystem-apis.html#core-subsystems + 15. https://docs.kernel.org/core-api/index.html + 16. https://docs.kernel.org/driver-api/index.html + 17. https://docs.kernel.org/mm/index.html + 18. https://docs.kernel.org/power/index.html + 19. https://docs.kernel.org/scheduler/index.html + 20. https://docs.kernel.org/timers/index.html + 21. https://docs.kernel.org/locking/index.html + 22. https://docs.kernel.org/subsystem-apis.html#human-interfaces + 23. https://docs.kernel.org/subsystem-apis.html#networking-interfaces + 24. https://docs.kernel.org/subsystem-apis.html#storage-interfaces + 25. https://docs.kernel.org/locking/index.html + 26. https://docs.kernel.org/process/license-rules.html + 27. https://docs.kernel.org/doc-guide/index.html + 28. https://docs.kernel.org/dev-tools/index.html + 29. https://docs.kernel.org/dev-tools/testing-overview.html + 30. https://docs.kernel.org/kernel-hacking/index.html + 31. https://docs.kernel.org/trace/index.html + 32. https://docs.kernel.org/fault-injection/index.html + 33. https://docs.kernel.org/livepatch/index.html + 34. https://docs.kernel.org/rust/index.html + 35. https://docs.kernel.org/admin-guide/index.html + 36. https://docs.kernel.org/kbuild/index.html + 37. https://docs.kernel.org/admin-guide/reporting-issues.html + 38. https://docs.kernel.org/tools/index.html + 39. https://docs.kernel.org/userspace-api/index.html + 40. https://docs.kernel.org/firmware-guide/index.html + 41. https://docs.kernel.org/devicetree/index.html + 42. https://docs.kernel.org/arch/index.html + 43. https://docs.kernel.org/staging/index.html + 44. https://docs.kernel.org/translations/index.html + 45. https://docs.kernel.org/_sources/power/s2ram.rst.txt + 46. https://docs.kernel.org/power/s2ram.html#how-to-get-s2ram-working + 47. https://docs.kernel.org/power/tricks.html + 48. https://docs.kernel.org/power/video.html + 49. https://docs.kernel.org/power/s2ram.html#using-trace-resume + 50. https://docs.kernel.org/power/s2ram.html#note + 51. http://sphinx-doc.org/ + 52. https://github.com/bitprophet/alabaster + 53. https://docs.kernel.org/_sources/power/s2ram.rst.txt diff --git a/docs/elinux.org_Kernel_Size_Reduction_Work.txt b/docs/elinux.org_Kernel_Size_Reduction_Work.txt new file mode 100644 index 0000000..81d7130 --- /dev/null +++ b/docs/elinux.org_Kernel_Size_Reduction_Work.txt @@ -0,0 +1,292 @@ + #[1]eLinux.org (en) [2]eLinux.org Atom feed + +Kernel Size Reduction Work + + From eLinux.org + Jump to: [3]navigation, [4]search + + This page has a list of of recent (as of 2014) ideas and projects for + Linux kernel size reduction. + + As of June, 2014, [5]Linux Tiny was no longer maintained. However, new + efforts to support Linux as a viable option on micro-controllers and + deeply embedded systems have led to renewed interest in extreme size + reduction of the kernel. Some good projects were described at ELC 2014. + +Contents + + * [6]1 Recent work + * [7]2 List of recently used techniques + + [8]2.1 Vitaly Wool's project + + [9]2.2 micro-yocto project + o [10]2.2.1 instrumentation + + [11]2.3 auto-reduce + + [12]2.4 Kernel string refactorization + * [13]3 Ideas for new reductions + * [14]4 People or groups interested in size reductions + + [15]4.1 individuals + + [16]4.2 companies + * [17]5 Meetings and Discussions + + [18]5.1 Kernel Summit 2014 + + [19]5.2 Size/IOT summit at ELC Europe 2014 + +Recent work + + * Tom Zanussi and the Micro-yocto project (2014) + + Micro-Yocto is an effort in the Yocto Project to produce a + minimal kernel for very small embedded systems + + [20]microYocto and the Internet of Tiny (PDF) - Presentation + by Tom Zanussi at ELC 2014 + + See + [21]https://github.com/tzanussi/meta-galileo/raw/daisy/meta-ga + lileo/README for more information + * Vitaly Wool described running 2.6.33 on an ST microcontroler with + 2MB flash and 256K ram (2014) + + [22]Linux for Microcontrollers: Spreading the Disease (PDF) - + presented at ELC in April 2014 + +List of recently used techniques + +Vitaly Wool's project + + * kernel XIP + * dietnet + * ARM thumb mode + * application XIP on squashfs + +micro-yocto project + + * net-diet + * LTO + * SYSFS_SYSCALL + * USELIB + * BUG_ON + * X86_IOPORT + * CONFIG_PTRACE + * CONFIG_SIGNALS + * no sys_sendfile + + * network reductions: + + replace kernel stack with user-space stack (LWIP) + + TCP/UDP echo (requires app changes) + +instrumentation + + microYocto tracing hash triggers + +auto-reduce + + * LTO + * syscall filtering + * command line filtering + * global constraints + * kernel stack size + +Kernel string refactorization + + * refactor strings in the kernel so that they are more efficiently + used + * here is a [23]report on this work getting started + +Ideas for new reductions + + * trace-guided optimization + * cold code compression + + use U of Gent code to re-try cold code compression + +People or groups interested in size reductions + +individuals + + * Josh Triplett - e-mail:josh at joshtriplett dot org + + new linux tiny patches + * Tom Zanussi - e-mail: tom dot zanussi at linux dot intel dot com + + microYocto + * Andi Kleen - e-mail: ak at linux dot intel dot com + + netdiet patches + * Alan Cox - email: alan dot cox at linux dot intel dot com + * Shinsuke Kato - e-mail: kato dot shinsuke at jp dot panasonic dot + com + * Tim Bird - e-mail: tim dot bird at sonymobile dot com + + auto-reduce stuff + * Vitaly Wool - e-mail: vitaly dot wool at softprise dot net + + extreme microcontroller Linux (<256K RAM) + * Phil Blundell - e-mail: + + meta-micro (OE-based small distro - last work in 2012) + +companies + + * [24]Emcraft Systems sells a variety of microcontroller-based boards + and products + +Meetings and Discussions + +Kernel Summit 2014 + + Josh Triplett has proposed a session discussing size issues at the 2014 + Kernel Summit. His draft list of proposed topics was the following: + Topics: + * An overview of why the kernel's size still matters today ("but + don't we all have tons of memory and storage?") + * Tiny in RAM versus tiny on storage. + * How much the kernel has grown over time. + * How size regressions happen and how to avoid them + * Size measurement, bloat-o-meter, allnoconfig, and other tools + * Compression and the decompression stub + * Kconfig, and avoiding excessive configurability in the pursuit of + tiny + * Optimizing a kernel for its exact target userspace. + * Examples of shrinking the kernel + * Discussion on proposed ways to make the kernel tiny, how much they + might save, how much work they'd require, and how to implement them + with minimal impact to the un-shrunken common case. + + (see + [25]http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May + /000001.html for the discussion thread) + +Size/IOT summit at ELC Europe 2014 + + We are considering holding a Size/IOT meeting at ELC Europe. Details + will be placed here should this meeting end up being organized. + Retrieved from + "[26]https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&oldi + d=415441" + [27]Category: + * [28]System Size + +Navigation menu + +Personal tools + + * [29]Log in + * [30]Request account + +Namespaces + + * [31]Page + * [32]Discussion + + [ ] + +Variants + +Views + + * [33]Read + * [34]View source + * [35]View history + + [ ] + +More + +Search + + ____________________ Search Go + +Navigation + + * [36]Main Page + * [37]Community portal + * [38]Current events + * [39]Recent changes + * [40]Help + * [41]Volunteering + +Where else to find us + + * [42]Mastodon + * [43]Discord + * [44]Twitter (@elinux) + * [45]#elinux on Libera.Chat + * [46]Facebook (@elinux.org) + * [47]Mailing Lists + * [48]Matrix + +Tools + + * [49]What links here + * [50]Related changes + * [51]Special pages + * [52]Printable version + * [53]Permanent link + * [54]Page information + + * This page was last edited on 26 July 2016, at 08:54. + * Content is available under [55]a Creative Commons + Attribution-ShareAlike 3.0 Unported License unless otherwise noted. + + * [56]Privacy policy + * [57]About eLinux.org + * [58]Disclaimers + + * [59]a Creative Commons Attribution-ShareAlike 3.0 Unported License + * [60]Powered by MediaWiki + +References + + Visible links: + 1. https://elinux.org/opensearch_desc.php + 2. https://elinux.org/index.php?title=Special:RecentChanges&feed=atom + 3. https://elinux.org/Kernel_Size_Reduction_Work#mw-head + 4. https://elinux.org/Kernel_Size_Reduction_Work#p-search + 5. https://elinux.org/Linux_Tiny + 6. https://elinux.org/Kernel_Size_Reduction_Work#Recent_work + 7. https://elinux.org/Kernel_Size_Reduction_Work#List_of_recently_used_techniques + 8. https://elinux.org/Kernel_Size_Reduction_Work#Vitaly_Wool.27s_project + 9. https://elinux.org/Kernel_Size_Reduction_Work#micro-yocto_project + 10. https://elinux.org/Kernel_Size_Reduction_Work#instrumentation + 11. https://elinux.org/Kernel_Size_Reduction_Work#auto-reduce + 12. https://elinux.org/Kernel_Size_Reduction_Work#Kernel_string_refactorization + 13. https://elinux.org/Kernel_Size_Reduction_Work#Ideas_for_new_reductions + 14. https://elinux.org/Kernel_Size_Reduction_Work#People_or_groups_interested_in_size_reductions + 15. https://elinux.org/Kernel_Size_Reduction_Work#individuals + 16. https://elinux.org/Kernel_Size_Reduction_Work#companies + 17. https://elinux.org/Kernel_Size_Reduction_Work#Meetings_and_Discussions + 18. https://elinux.org/Kernel_Size_Reduction_Work#Kernel_Summit_2014 + 19. https://elinux.org/Kernel_Size_Reduction_Work#Size.2FIOT_summit_at_ELC_Europe_2014 + 20. https://elinux.org/images/5/54/Tom.zanussi-elc2014.pdf + 21. https://github.com/tzanussi/meta-galileo/raw/daisy/meta-galileo/README + 22. https://elinux.org/images/c/ca/Spreading.pdf + 23. https://elinux.org/Refactor_kernel_strings_-_Results + 24. http://www.emcraft.com/ + 25. http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000001.html + 26. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&oldid=415441 + 27. https://elinux.org/Special:Categories + 28. https://elinux.org/Category:System_Size + 29. https://elinux.org/index.php?title=Special:UserLogin&returnto=Kernel+Size+Reduction+Work + 30. https://elinux.org/Special:RequestAccount + 31. https://elinux.org/Kernel_Size_Reduction_Work + 32. https://elinux.org/index.php?title=Talk:Kernel_Size_Reduction_Work&action=edit&redlink=1 + 33. https://elinux.org/Kernel_Size_Reduction_Work + 34. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&action=edit + 35. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&action=history + 36. https://elinux.org/Main_Page + 37. https://elinux.org/eLinux.org:Community_portal + 38. https://elinux.org/eLinux.org:Current_events + 39. https://elinux.org/Special:RecentChanges + 40. https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents + 41. https://elinux.org/Sitesupport-url + 42. https://fosstodon.org/@elinux + 43. https://discord.com/channels/910986089798447144/910986089798447147 + 44. https://twitter.com/elinux + 45. irc:///#elinux@irc.libera.chat + 46. https://www.facebook.com/elinuxorg-750739005020534/ + 47. http://www.elinux.org/ELinuxWiki:Mailing_List + 48. https://matrix.to/#/#elinux:matrix.org + 49. https://elinux.org/Special:WhatLinksHere/Kernel_Size_Reduction_Work + 50. https://elinux.org/Special:RecentChangesLinked/Kernel_Size_Reduction_Work + 51. https://elinux.org/Special:SpecialPages + 52. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&printable=yes + 53. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&oldid=415441 + 54. https://elinux.org/index.php?title=Kernel_Size_Reduction_Work&action=info + 55. https://creativecommons.org/licenses/by-sa/3.0/ + 56. https://elinux.org/eLinux.org:Privacy_policy + 57. https://elinux.org/eLinux.org:About + 58. https://elinux.org/eLinux.org:General_disclaimer + 59. https://creativecommons.org/licenses/by-sa/3.0/ + 60. https://www.mediawiki.org/ + + Hidden links: + 62. https://elinux.org/Main_Page diff --git a/docs/forum.tinycorelinux.net_index.php_topic_16299.0.txt b/docs/forum.tinycorelinux.net_index.php_topic_16299.0.txt new file mode 100644 index 0000000..4043d51 --- /dev/null +++ b/docs/forum.tinycorelinux.net_index.php_topic_16299.0.txt @@ -0,0 +1,535 @@ + #[1]help [2]search [3]contents [4]Tiny Core Linux - RSS [5]prev [6]next + [7]index + + [8]Welcome Welcome | [9]FAQ FAQ | [10]Downloads Downloads | [11]Wiki + Wiki + +[12]Tiny Core Linux + + * Tiny Core Linux Forum + Welcome, Guest. Please [13]login or [14]register. + Did you miss your [15]activation email? + __________ __________ [Forever] Login + Login with username, password and session length + ____________________ Search + +News: + + [16]Language translations now possible! + * [17]Home + * [18]Help + * [19]Login + * [20]Register + + * [21]Tiny Core Linux » + * [22]General TC » + * [23]General TC Talk » + * [24]Announcing tinyx - our X server fork + + [25]« previous [26]next » + * [27]Print + + Pages: [1] [28]2 [29]3 [30]4 [31]Go Down + +Author Topic: Announcing tinyx - our X server fork (Read 27724 times) + +Offline [32]curaga + + * Administrator + * Hero Member + * * * * * * + * + * Posts: 10922 + * + +[33]Announcing tinyx - our X server fork + + « on: November 30, 2013, 06:13:57 AM » + Our current Xvesa and Xfbdev hail from the XFree86 4.8.0 era. Not easy + to build with a current environment, and so hard to fix bugs in. They + are also somewhat bigger than necessary. + So, as one of the last few users of Xvesa, we're announcing a fork of + xorg-server-1.2.0. It's been updated to build in a current environment, + had everything unnecessary stripped, and some custom tweaks for + user-friendliness and faster startup. + Compared to the existing ~700kb 32-bit binaries, these are ~500kb when + built with -Os, while at the same time supporting much more + functionality (15 extensions vs 8, DPMS among the most important). + Clone with "git clone [34]http://git.tinycorelinux.net/tinyx" to try it + out. Packages may be updated into the next (or next+1) release. + Or grab a release tarball from + [35]http://www.tinycorelinux.net/~curaga/tinyx-1.0rc1.tar.bz2 for an + easier build. + Test packages available at [36]http://tinycorelinux.net/~curaga/ + « Last Edit: December 13, 2013, 06:35:43 AM by curaga » + Logged + The only barriers that can stop you are the ones you create yourself. + __________________________________________________________________ + +Offline [37]gerald_clark + + * TinyCore Moderator + * Hero Member + * * * * * * + * + * Posts: 4254 + * + +[38]Re: Announcing tinyx - our X server fork + + « Reply #1 on: November 30, 2013, 08:40:50 AM » + How about some instructions. + I loaded compiletc, autoconf, perl5, automake, libtool, and gettext. + I still can't get it to compile under Core 5. + Logged + __________________________________________________________________ + +Offline [39]curaga + + * Administrator + * Hero Member + * * * * * * + * + * Posts: 10922 + * + +[40]Re: Announcing tinyx - our X server fork + + « Reply #2 on: November 30, 2013, 10:10:01 AM » + Sure, I think you're missing the X headers - Xorg-7.7-dev should do. + libtool-dev is also needed to generate the configure script. + The autofoo are only needed for git builds, for (future) release + tarballs only compiletc + Xorg-7.7-dev are enough. + edit: Added libXfont-dev as Xorg-dev's dep. + « Last Edit: November 30, 2013, 10:11:41 AM by curaga » + Logged + The only barriers that can stop you are the ones you create yourself. + __________________________________________________________________ + +Offline [41]Zendrael + + * Sr. Member + * * * * * + * + * Posts: 360 + * + + [42]Zendrael's home of projects + +[43]Re: Announcing tinyx - our X server fork + + « Reply #3 on: December 01, 2013, 01:33:48 PM » + Very nice! + Will get some tcz on the repo soon? There are already some "benchmarks" + against the Xvesa? The tinyX will suport more resolutions? Support for + Xcompmanger? + Thanks! + Logged + __________________________________________________________________ + +Offline [44]tinypoodle + + * Hero Member + * * * * * * + * + * Posts: 3857 + * + +[45]Re: Announcing tinyx - our X server fork + + « Reply #4 on: December 01, 2013, 10:23:26 PM » + Interesting news :) + Logged + "Software gets slower faster than hardware gets faster." Niklaus Wirth + - A Plea for Lean Software (1995) + __________________________________________________________________ + +Offline [46]curaga + + * Administrator + * Hero Member + * * * * * * + * + * Posts: 10922 + * + +[47]Re: Announcing tinyx - our X server fork + + « Reply #5 on: December 02, 2013, 07:09:47 AM » + TCZ packages will get there in a week or two. + Quote + + There are already some "benchmarks" against the Xvesa? The tinyX + will suport more resolutions? Support for Xcompmanger? + + - benchmarks: the main goal for fbdev and vesa is to be small. They + have no render acceleration, for that, use Xorg. + - more resolutions: this is not possible, as fbdev uses the existing + resolution, and vesa gets the resolutions from your BIOS. + - Xcompmgr: no, composite support is not included. Please use Xorg for + this. + As mentioned in the README, a possible future "Xmodesetting" would be + able to use any resolution, as long as an open KMS kernel driver + existed in graphics-KERNEL.tcz. However, you can already get the best + resolution by loading graphics- and Xfbdev, so the new server is not a + high priority. + Logged + The only barriers that can stop you are the ones you create yourself. + __________________________________________________________________ + +Offline [48]Misalf + + * Hero Member + * * * * * * + * + * Posts: 1702 + * + +[49]Re: Announcing tinyx - our X server fork + + « Reply #6 on: December 02, 2013, 12:17:55 PM » + With current Xvesa, I can't move windows via mouse (in fluxbox) while + numlock is activated. Could this possibly be fixed with this version? + -- + I tryed compiling both, git and tarball. Both fail to launch for me. + I did load the mentioned extensions for compiling. + Compiler flags as mentioned in wiki. + For the git version, I did first ran autogen.sh . + Code: [50][Select] + $ ./configure --prefix=/usr/local + ... + $ make + ... + $ make DESTDIR=/tmp/tinyx install-stripCompiling finishes without + errors. + I did also try make install with sudo but I guess that doesn't make + a difference when 'installing' to /tmp ? + Then I have repacked the current Xvesa.tcz with /usr/local/bin/Xvesa + replaced with that newly created one. + I tryed chown root:staff (like default Xvesa), root:root and + tc:staff on Xvesa before packing. Always same result: + $ startx gives error: "failed in waitforX" + $ Xvesa gives error: "Server must be suid root" + Logged + Download a copy and keep it handy: [51]Core book ;) + __________________________________________________________________ + +Offline [52]tinypoodle + + * Hero Member + * * * * * * + * + * Posts: 3857 + * + +[53]Re: Announcing tinyx - our X server fork + + « Reply #7 on: December 02, 2013, 07:23:29 PM » + What happens when you try to run it as root? + Logged + "Software gets slower faster than hardware gets faster." Niklaus Wirth + - A Plea for Lean Software (1995) + __________________________________________________________________ + +Offline [54]Misalf + + * Hero Member + * * * * * * + * + * Posts: 1702 + * + +[55]Re: Announcing tinyx - our X server fork + + « Reply #8 on: December 02, 2013, 10:39:23 PM » + Then it complains about bad resolution and being unable to find fonts - + "fixed" in particular. + Same if I add -screen 1280x1024 + I will test on a clean install later. + Logged + Download a copy and keep it handy: [56]Core book ;) + __________________________________________________________________ + +Offline [57]coreplayer2 + + * Hero Member + * * * * * * + * Posts: 3020 + * + +[58]Re: Announcing tinyx - our X server fork + + « Reply #9 on: December 03, 2013, 12:09:12 AM » + [59]Quote from: Misalf on December 02, 2013, 12:17:55 PM + + With current Xvesa, I can't move windows via mouse (in fluxbox) + while numlock is activated. Could this possibly be fixed with this + version? + + I can't remember off-hand how to resolve this issue but is not related + to Xvesa iirc, strangely i've experienced this before once.. though + haven't had the issue for a while, then today while trying to duplicate + the NumLK/typing/move windows issue with the hope of finding the + resolution, I've gone and activated the feature accidentally. So now + I have the issue where you can either type or you can move windows, but + not both. and i can't remember how I arrived here. Though I believe + this is fluxbox related + Nice work on the Xvesa/Xfbdev, after compiling I noticed that Xfbdev + is half the size of the version it replaces :thumbup: + going to take them both for a spin here if I can regain control of my + keyboard :p + « Last Edit: December 03, 2013, 12:16:13 AM by coreplayer2 » + Logged + __________________________________________________________________ + +Offline [60]tinypoodle + + * Hero Member + * * * * * * + * + * Posts: 3857 + * + +[61]Re: Announcing tinyx - our X server fork + + « Reply #10 on: December 03, 2013, 12:23:11 AM » + [62]Quote from: Misalf on December 02, 2013, 10:39:23 PM + + Then it complains about bad resolution and being unable to find + fonts - "fixed" in particular. + Same if I add -screen 1280x1024 + I will test on a clean install later. + + Try this: + Code: [63][Select] + sudo chmod u+rwxs,a+rx /path/to/Xvesa + Logged + "Software gets slower faster than hardware gets faster." Niklaus Wirth + - A Plea for Lean Software (1995) + __________________________________________________________________ + +Offline [64]curaga + + * Administrator + * Hero Member + * * * * * * + * + * Posts: 10922 + * + +[65]Re: Announcing tinyx - our X server fork + + « Reply #11 on: December 03, 2013, 06:44:11 AM » + Sorry about that, my fault in not posting better instructions. + The existing Xvesa had --prefix=/usr, and was later moved to + /usr/local. Per this, the bitmap fonts are in /usr. So the recommended + configure is: + ./configure --with-fontdir=/usr/lib/X11/fonts + This installs to /usr/local but also finds the existing fonts. + Logged + The only barriers that can stop you are the ones you create yourself. + __________________________________________________________________ + +Offline [66]Misalf + + * Hero Member + * * * * * * + * + * Posts: 1702 + * + +[67]Re: Announcing tinyx - our X server fork + + « Reply #12 on: December 03, 2013, 08:13:51 AM » + My first days with tinycore + fluxbox + Xvesa, I thought it would be + unstable until I discovered that I just have to re-deactivate the + numlock in order to move windows. I have qwertzy layout thus I use the + numpad a lot for inserting the '/' character (instead of SHIFT+7). + Under Xorg it works. + -- + Thanks curaga, I'll try that. + Logged + Download a copy and keep it handy: [68]Core book ;) + __________________________________________________________________ + +Offline [69]coreplayer2 + + * Hero Member + * * * * * * + * Posts: 3020 + * + +[70]Re: Announcing tinyx - our X server fork + + « Reply #13 on: December 03, 2013, 09:35:10 AM » + Quote + + ./configure --with-fontdir=/usr/lib/X11/fonts + + Thanks, Ok will also try this (since I appear to have the same issue + with the fonts) + @Misalf I couldn't find which key combo I pressed to change the + NumLK/windows position state from having control to not having any + control, so I rebooted restoring the Fluxbox default configuration and + the numlk window feature is acting normally again in Xvesa. good luck + Logged + __________________________________________________________________ + +Offline [71]Misalf + + * Hero Member + * * * * * * + * + * Posts: 1702 + * + +[72]Re: Announcing tinyx - our X server fork + + « Reply #14 on: December 03, 2013, 10:19:48 AM » + Code: [73][Select] + sudo chmod u+rwxs,a+rx /path/to/XvesaDid not help. + -- + Code: [74][Select] + ./configure --with-fontdir=/usr/lib/X11/fontsNow I'm able to lauch + sudo Xvesa (allone) but startx still doesn't work. + So I edited ~/.xsession to start Xvesa with sudo and this now + results in a seemingly workin X desktop. + Is it OK or even required for Xvesa to be ran as root? + However, after exiting X and running startx again, fluxbox fails to + launch (my conky lives, though). + /tmp/wm_errors + Code: [75][Select] + Error: Couldn't connect to XServer:0.0(Numlock/window-move bug still + there with this Xvesa; but can't test with default fluxbox configs) + running startx for a 3rd time, I also have a wbar. + -- + [Don't worry guys, i did not backup so I can go back any time][/code] + Logged + Download a copy and keep it handy: [76]Core book ;) + __________________________________________________________________ + + * [77]Print + + Pages: [1] [78]2 [79]3 [80]4 [81]Go Up + [82]« previous [83]next » + * [84]Tiny Core Linux » + * [85]General TC » + * [86]General TC Talk » + * [87]Announcing tinyx - our X server fork + + + * [88]SMF 2.0.19 | [89]SMF © 2021, [90]Simple Machines + * [91]XHTML + * [92]RSS + * [93]WAP2 + +References + + Visible links: + 1. http://forum.tinycorelinux.net/index.php?action=help + 2. http://forum.tinycorelinux.net/index.php?action=search + 3. http://forum.tinycorelinux.net/index.php + 4. http://forum.tinycorelinux.net/index.php?type=rss;action=.xml + 5. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,prev.html + 6. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,next.html + 7. http://forum.tinycorelinux.net/index.php/board,28.0.html + 8. http://tinycorelinux.net/ + 9. http://tinycorelinux.net/faq.html + 10. http://tinycorelinux.net/downloads.html + 11. https://wiki.tinycorelinux.net/ + 12. http://forum.tinycorelinux.net/index.php + 13. http://forum.tinycorelinux.net/index.php?action=login + 14. http://forum.tinycorelinux.net/index.php?action=register + 15. http://forum.tinycorelinux.net/index.php?action=activate + 16. http://forum.tinycorelinux.net/index.php/topic,7169.html + 17. http://forum.tinycorelinux.net/index.php + 18. http://forum.tinycorelinux.net/index.php?action=help + 19. http://forum.tinycorelinux.net/index.php?action=login + 20. http://forum.tinycorelinux.net/index.php?action=register + 21. http://forum.tinycorelinux.net/index.php + 22. http://forum.tinycorelinux.net/index.php#c9 + 23. http://forum.tinycorelinux.net/index.php/board,28.0.html + 24. http://forum.tinycorelinux.net/index.php/topic,16299.0.html + 25. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,prev.html#new + 26. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,next.html#new + 27. http://forum.tinycorelinux.net/index.php?action=printpage;topic=16299.0 + 28. http://forum.tinycorelinux.net/index.php/topic,16299.15.html + 29. http://forum.tinycorelinux.net/index.php/topic,16299.30.html + 30. http://forum.tinycorelinux.net/index.php/topic,16299.45.html + 31. http://forum.tinycorelinux.net/index.php?topic=16299.0#lastPost + 32. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 33. http://forum.tinycorelinux.net/index.php/topic,16299.msg96699.html#msg96699 + 34. http://git.tinycorelinux.net/tinyx + 35. http://www.tinycorelinux.net/~curaga/tinyx-1.0rc1.tar.bz2 + 36. http://tinycorelinux.net/~curaga/ + 37. http://forum.tinycorelinux.net/index.php?action=profile;u=531 + 38. http://forum.tinycorelinux.net/index.php/topic,16299.msg96700.html#msg96700 + 39. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 40. http://forum.tinycorelinux.net/index.php/topic,16299.msg96701.html#msg96701 + 41. http://forum.tinycorelinux.net/index.php?action=profile;u=1688 + 42. http://www.zendrael.com/ + 43. http://forum.tinycorelinux.net/index.php/topic,16299.msg96746.html#msg96746 + 44. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 45. http://forum.tinycorelinux.net/index.php/topic,16299.msg96758.html#msg96758 + 46. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 47. http://forum.tinycorelinux.net/index.php/topic,16299.msg96770.html#msg96770 + 48. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 49. http://forum.tinycorelinux.net/index.php/topic,16299.msg96780.html#msg96780 + 50. javascript:void(0); + 51. http://tinycorelinux.net/book.html + 52. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 53. http://forum.tinycorelinux.net/index.php/topic,16299.msg96787.html#msg96787 + 54. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 55. http://forum.tinycorelinux.net/index.php/topic,16299.msg96791.html#msg96791 + 56. http://tinycorelinux.net/book.html + 57. http://forum.tinycorelinux.net/index.php?action=profile;u=3262 + 58. http://forum.tinycorelinux.net/index.php/topic,16299.msg96794.html#msg96794 + 59. http://forum.tinycorelinux.net/index.php/topic,16299.msg96780.html#msg96780 + 60. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 61. http://forum.tinycorelinux.net/index.php/topic,16299.msg96795.html#msg96795 + 62. http://forum.tinycorelinux.net/index.php/topic,16299.msg96791.html#msg96791 + 63. javascript:void(0); + 64. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 65. http://forum.tinycorelinux.net/index.php/topic,16299.msg96810.html#msg96810 + 66. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 67. http://forum.tinycorelinux.net/index.php/topic,16299.msg96813.html#msg96813 + 68. http://tinycorelinux.net/book.html + 69. http://forum.tinycorelinux.net/index.php?action=profile;u=3262 + 70. http://forum.tinycorelinux.net/index.php/topic,16299.msg96818.html#msg96818 + 71. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 72. http://forum.tinycorelinux.net/index.php/topic,16299.msg96819.html#msg96819 + 73. javascript:void(0); + 74. javascript:void(0); + 75. javascript:void(0); + 76. http://tinycorelinux.net/book.html + 77. http://forum.tinycorelinux.net/index.php?action=printpage;topic=16299.0 + 78. http://forum.tinycorelinux.net/index.php/topic,16299.15.html + 79. http://forum.tinycorelinux.net/index.php/topic,16299.30.html + 80. http://forum.tinycorelinux.net/index.php/topic,16299.45.html + 81. http://forum.tinycorelinux.net/index.php?topic=16299.0#top + 82. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,prev.html#new + 83. http://forum.tinycorelinux.net/index.php/topic,16299.0/prev_next,next.html#new + 84. http://forum.tinycorelinux.net/index.php + 85. http://forum.tinycorelinux.net/index.php#c9 + 86. http://forum.tinycorelinux.net/index.php/board,28.0.html + 87. http://forum.tinycorelinux.net/index.php/topic,16299.0.html + 88. http://forum.tinycorelinux.net/index.php?action=credits + 89. https://www.simplemachines.org/about/smf/license.php + 90. https://www.simplemachines.org/ + 91. http://validator.w3.org/check?uri=referer + 92. http://forum.tinycorelinux.net/index.php?action=.xml;type=rss + 93. http://forum.tinycorelinux.net/index.php?wap2 + + Hidden links: + 95. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 96. http://forum.tinycorelinux.net/index.php?action=profile;u=531 + 97. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 98. http://forum.tinycorelinux.net/index.php?action=profile;u=1688 + 99. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 100. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 101. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 102. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 103. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 104. http://forum.tinycorelinux.net/index.php?action=profile;u=1608 + 105. http://forum.tinycorelinux.net/index.php?action=profile;u=5 + 106. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 + 107. http://forum.tinycorelinux.net/index.php?action=profile;u=13949 diff --git a/docs/harmful.cat-v.org_cat-v.txt b/docs/harmful.cat-v.org_cat-v.txt new file mode 100644 index 0000000..841183a --- /dev/null +++ b/docs/harmful.cat-v.org_cat-v.txt @@ -0,0 +1,97 @@ + [1]quotes | [2]docs | [3]repo | [4]golang | [5]sam | [6]man | [7]acme | + [8]Glenda | [9]9times | [10]harmful | [11]9P | [12]cat-v.org + + Related sites: | [13]site updates | [14]site map | + + [15]cat -v harmful stuff + + * [16]> Blog/ + * [17]» cat v/ + * [18]> economics/ + * [19]> films/ + * [20]> journalism/ + * [21]> people/ + * [22]> science/ + * [23]> security theater/ + * [24]> society/ + * [25]> software/ + * [26]> standards/ + * [27]> words/ + + UNIX Style, or cat -v Considered Harmful + + At the USENIX Summer Conference of 1983 [28]Rob Pike made a + presentation titled `[29]UNIX Style, or cat -v Considered Harmful' and + together with [30]Brian Kernighan wrote the paper `Program Design in + the UNIX Environment' ([31]pdf version, [32]ps version), published as + an article in [33]AT&T Bell Laboratories Technical Journal, October + 1984, Vol. 63 No. 8 Part 2. + + This was a prelude for their famous book [34]The Unix Programming + Environment (Prentice-Hall Software Series) that today is considered + the bible of Unix. + + Unfortunately their advice has been completely ignored, and today Unix + has become overcome by exactly the kind of mistakes they warned + against. +Bell Laboratories + +Murray Hill, NJ (dec!ucb)wav!research!rob + +It seems that UNIX has become the victim of cancerous growth at the hands of +organizations such as UCB. 4.2BSD is an order of magnitude larger than Version +5, but, Pike claims, not ten times better. + +The talk reviews reasons for UNIX's popularity and shows, using UCB cat as a +primary example, how UNIX has grown fat. cat isn't for printing files with line +numbers, it isn't for compressing multiple blank lines, it's not for looking at +non-printing ASCII characters, it's for concatenating files. + +We are reminded that ls isn't the place for code to break a single column into +multiple ones, and that mailnews shouldn't have its own more processing or joke +encryption code. + +Rob carried the standard well for the "spirit of UNIX," and you can look +forward to a deeper look at the philosophy of UNIX in his forthcoming book. + + [35]Powered by werc + + ____________________ Search + +References + + 1. http://quotes.cat-v.org/ + 2. http://doc.cat-v.org/ + 3. http://repo.cat-v.org/ + 4. http://go-lang.cat-v.org/ + 5. http://sam.cat-v.org/ + 6. http://man.cat-v.org/ + 7. http://acme.cat-v.org/ + 8. http://glenda.cat-v.org/ + 9. http://ninetimes.cat-v.org/ + 10. http://harmful.cat-v.org/ + 11. http://9p.cat-v.org/ + 12. http://cat-v.org/ + 13. http://cat-v.org/update_log + 14. http://harmful.cat-v.org/sitemap + 15. http://harmful.cat-v.org/ + 16. http://harmful.cat-v.org/Blog/ + 17. http://harmful.cat-v.org/cat-v/ + 18. http://harmful.cat-v.org/economics/ + 19. http://harmful.cat-v.org/films/ + 20. http://harmful.cat-v.org/journalism/ + 21. http://harmful.cat-v.org/people/ + 22. http://harmful.cat-v.org/science/ + 23. http://harmful.cat-v.org/security-theater/ + 24. http://harmful.cat-v.org/society/ + 25. http://harmful.cat-v.org/software/ + 26. http://harmful.cat-v.org/standards/ + 27. http://harmful.cat-v.org/words/ + 28. http://genius.cat-v.org/rob-pike/ + 29. http://doc.cat-v.org/unix/ + 30. http://genius.cat-v.org/brian-kernighan/ + 31. http://harmful.cat-v.org/cat-v/unix_prog_design.pdf + 32. http://harmful.cat-v.org/cat-v/unix_prog_design.ps + 33. http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=at%26t%20bell%20laboratories%20technical%20journal + 34. http://www.amazon.com/gp/product/013937681X?ie=UTF8&tag=catv-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=013937681X + 35. http://werc.cat-v.org/ diff --git a/docs/ja.nsommer.dk_articles_linux-and-tiny-c-compiler-in-the-browser-part-one.txt b/docs/ja.nsommer.dk_articles_linux-and-tiny-c-compiler-in-the-browser-part-one.txt new file mode 100644 index 0000000..d7eb9e7 --- /dev/null +++ b/docs/ja.nsommer.dk_articles_linux-and-tiny-c-compiler-in-the-browser-part-one.txt @@ -0,0 +1,777 @@ + [1]< Table of contents + + Linux and Tiny C Compiler in the browser, part one + + 2022-05-22 + +Introduction + + Current C compilers running in the browser are experimental, though + [2]Clang In Browser is pretty impressive. Instead of porting a compiler + to WASM, I'm going to take a different approach and use my favourite + method for a lot of things: virtual machines. It's slower, especially + since I'm using a JavaScript cpu emulator, but decent performance is + possible with a fast compiler like Tiny C Compiler and a custom Linux. + Demo + + Try cat /opt/test.c and tcc -run /opt/test.c + +Motivation + + I could sit for hours back in the days and tweak the Linux kernel on my + Pentium-something, in an attempt to make the system boot faster. Most + of the time I just broke things and had to recompile Gentoo. But + there's rarely a need today to compile Linux; if you need something + barebone, you probably use Docker with Alpine Linux. Compiling Linux is + still useful in the embedded space, and with a c compiler in the mix + you get to learn the basics of how programs work. + + In the mean time, unikernels such as MirageOS and Unikraft have + surfaced as a supplement or even alternative to Docker. One of the ways + they differ is that your code is compiled into an operating system + instead of running on top of Linux. Imagine you could compile Linux + into your code, having dead code elimination on every feature you don't + use! The sales pitch is this: reduced attack surface, fast boot times + and better performance. Building a custom Linux then becomes even more + exciting because unikernels borrow many concepts from Linux, eg. + Unikraft is configured in the same tui as the Linux kernel (and + Buildroot), make and gcc are used to a great extent, and you can choose + between multiple libc implementations, but what exactly is that? + + So... + +What to expect + + This tutorial teaches you how to compile a small Linux image for + running in the browser via v86; a 32-bit x86 cpu emulator in + javascript. You get insights into cross compilation with a modern + implementation of the c standard library, and c internals when we add a + fast compiler to the image. Remote debugging via gdb is described in + the end using gdbserver, virtual serial ports and qemu. + +Prerequisites + + Linux that is not wsl, at least an hour to spare for compilation and + the following packages needed by Buildroot: + + sudo apt install make gcc g++ libncurses-dev libssl-dev_____ + + I've built this on Ubuntu 20.04 and 22.04 using bash, but most modern + distro's should be fine. + + Before you start, create a directory for the project, perhaps + ~/my-v86-linux, then cd into that and run all commands from there. All + commands will assume you are in that directory. Name it whatever you + like, and it doesn't have to be in ~/. + +The v86 CPU emulator + + v86 runs in the browser and emulates an x86-compatible cpu and hardware + where machine code is translated to WebAssembly modules at runtime. The + list of emulated hardware is impressive: + * x86 instruction set similar to Pentium III + * Keyboard and mouse support + * VGA card + * IDE disk controller + * Network card + * virtio filesystem + * Sound card + + View the full list of emulated hardware in [3]v86's readme. + + You're not limited to Linux on this emulator. It runs Windows (1.01, + 3.1, 95, 98, 2000), ReactOS, FreeBSD, OpenBSD and various hobby + operating systems. + + v86 is a hobby project written by an anonymous developer under the + pseudonym "copy". Previous work according to [4]copy's webpage includes + an impossible game, Game of Life and a brainfuck interpreter written in + javascript. + +Buildroot + + Buildroot is a tool to generate embedded Linux systems through cross + compilation. It's a huge work effort of cross compilation scripts and + configuration files put together in a nice terminal ui, and you can + tweak just about anything. It also acts as customizable toolchain, that + provides us with all the necessary tools to cross compile applications + that doesn't come in Buildroot packages. Read more on + [5]https://buildroot.org. + + Let's get started. + + cd into your project directory, then download and extract Buildroot: + + Hint: Tab through commands and copy instead of using your mouse. + + mkdir buildroot_____________________________________________ + wget https://github.com/buildroot/buildroot/archive/refs/tag + --output-document - \__________________________________ + | tar -xz --strip-components 1 --directory buildroot________ + + Instead of building Linux from the default Buildroot configuration, we + use a template that sets the right cpu and architecture among other + things: + + wget https://github.com/humphd/browser-vm/archive/refs/tags/ + --output-document - \__________________________________ + | tar -xz --strip-components 1 browser-vm-1.0.2/buildroot-v8 + + Remove commands that compress licenses. We'll get to that later. + + echo "" > buildroot-v86/board/v86/post-image.sh_____________ + + Tell Buildroot to create a new .config file with preloaded settings + from the template + + make --directory buildroot BR2_EXTERNAL=../buildroot-v86 v86 + + You're almost ready to build the initial image. Execute: + + make --directory buildroot menuconfig_______________________ + + Go to Toolchain -> C library and pick musl, exit and save. Then build + everything + + make --directory buildroot__________________________________ + + This is going to take a while, but the good thing is that caching is + enabled, so next time will be substantially faster. + + About musl... It's an implementation of the c standard library, like + uclibc and glibc. Your distro is probably using glibc, the GNU C + Library, which is big in size and not well suited for embedded Linux + where size matters. uclibc is better suited here, and so is musl which + seems to be the clear winner in [6]this (biased) comparison. I prefer + musl's MIT license over (L)GPL, which makes it interesting for + proprietary applications running in unikernels. It's developed and + maintained by Rich Felker, with a long list of contributors, and the + source code is said to be a reference code to look into for systems + programming in [7]this podcast (at 01:01:17). + +Preparing the website + + While waiting for Buildroot to compile, let's create the website that + will host the emulator and run Buildroot Linux: + + mkdir web___________________________________________________ + wget https://github.com/copy/v86/releases/download/latest/li + --directory-prefix web__________________________________ + wget https://github.com/copy/v86/releases/download/latest/v8 + --directory-prefix web__________________________________ + wget https://github.com/copy/v86/releases/download/latest/v8 + --directory-prefix web__________________________________ + wget https://github.com/copy/v86/archive/refs/tags/latest.ta + --output-document - \__________________________________ + | tar -xz --strip-components 2 --directory web \___________ + v86-latest/bios/seabios.bin \__________________________ + v86-latest/bios/vgabios.bin_____________________________ + ____________________________________________________________ + cat >web/index.html <<EOF___________________________________ + ____________________________________________________________ + <meta charset="utf8">_______________________________________ + <title>Emulator</title>_____________________________________ + <body bgcolor="#101010">____________________________________ + ____________________________________________________________ + <div id="screen_container">_________________________________ + <div style="white-space: pre; font: 14px monospace; line + <canvas hidden></canvas>________________________________ + </div>______________________________________________________ + ____________________________________________________________ + <script src="/libv86.js"></script>__________________________ + <script>____________________________________________________ + var emulator = new V86Starter({_____________________________ + wasm_path : "/v86.wasm",_________________________ + memory_size : 64 * 1024 * 1024, // 64 MB memory ou + vga_memory_size : 2 * 1024 * 1024,_____________________ + screen_container : screen_container,____________________ + bios : {url: "/seabios.bin"},_______________ + vga_bios : {url: "/vgabios.bin"},_______________ + cdrom : {url: "/linux.iso"},_________________ + filesystem : {},__________________________________ + autostart : true_________________________________ + })__________________________________________________________ + </script>___________________________________________________ + EOF_________________________________________________________ + + When Buildroot is done compiling, run + + cp buildroot/output/images/rootfs.iso9660 web/linux.iso_____ + + Then open a new terminal and start a simple webserver pointing to the + web directory, eg. + + python3 -m http.server 8000 --directory web_________________ + + and open [8]http://localhost:8000 to see v86 in action. Log in as root, + no password needed. + +Customize your image + + Buildroot is all about customization. Try the following commands: + + make --directory buildroot menuconfig_______________________ + + make --directory buildroot busybox-menuconfig_______________ + + make --directory buildroot linux-menuconfig_________________ + + There's a lot to explore. + + menuconfig + + menuconfig is where you configure Buildroot with things such as Linux + kernel version, what bootloader to use (grub2, syslinux etc.), the libc + library you want to use like when you chose musl and which architecture + to compile for. There are multiple packages to choose from, ranging + from small libraries and utilities to X11 and Qt. + + busybox-menuconfig + + Busybox combines hundreds of Linux utilities into one binary and is + also highly configurable with busybox-menuconfig. It provides you with + ls, grep, diff and many other utilities you're used to on Linux, and + I'd encourage you to remove all the tools you don't use to create a + smaller image. Ideally Busybox would come with the bare minimum instead + of having to manually remove unnecessary things. This is where + unikernels shine, because they take the opposite approach, where you + start with almost nothing and add what you need. + + linux-menuconfig + + linux-menuconfig is where you configure the Linux kernel. There's a + million things to configure, and you can easily break something unless + you know what you're doing. In one of the following tutorials for this + series, I'll show you how to tweak the kernel by trial and error, since + that's how I do it: Remove one feature, test the system, rinse and + repeat. + + Resist the temptation to make changes for now. + + rootfs_overlay + + Located in buildroot-v86/board/v86/rootfs_overlay, this is where you + place files that you want to add to the image. Our template includes + two files: etc/fstab and etc/inittab. + + Disable kernel messages after login + + Some things are not critical for booting the system, but is run as part + of the boot process anyway. They can be slow to start and clutter the + terminal after login, potentially adding log messages in the middle of + writing a command. To disable kernel messages after login, create the + following file + + mkdir buildroot-v86/board/v86/rootfs_overlay/etc/profile.d__ + echo "echo 0 >/proc/sys/kernel/printk" \___________________ + >buildroot-v86/board/v86/rootfs_overlay/etc/profile.d/no + + All .sh files in etc/profile.d are run on login. + + Auto login + + etc/inittab prepares the file system and mounts etc/fstab, runs init + scripts and "spawn" applications after boot. One of the commands for + spawning ends with the comment "# GENERIC_SERIAL" and that line needs + to be changed to not prompt for login and just start /bin/sh. + + (F=buildroot-v86/board/v86/rootfs_overlay/etc/inittab && cp + && sed --in-place "28d" $F \______________________________ + && sed --in-place "s/.*# GENERIC_SERIAL/console::respawn:-\ + && diff /tmp/oldf $F)______________________________________ + + Notice that the command starts with console::respawn. Respawn means + that if sh crashes, Busybox will keep restarting it until it succeeds. + + getty is replaced here because it's the application that prompts for + login. It also prevents us from sending messages between tty's, which + only makes sense in a multi user system: If user A is logged into tty1 + and user B is in tty2, then A shouldn't be able to bother B with `echo + "Hi B!" >/dev/tty2`. Instead we spawn -/bin/sh, where the hyphen + instructs Busybox to treat the shell as a login shell. Without it, + /etc/profile and scripts in /etc/profile.d are ignored. + + To add the new files to your image, you simply compile again + + make --directory buildroot__________________________________ + cp buildroot/output/images/rootfs.iso9660 web/linux.iso_____ + +Add Tiny C Compiler + + Tiny C Compiler, or tcc, is: + * ANSI C compliant, with most [9]C99 extensions. + * Small, roughly ~300 KB. + * Fast according to [10]the homepage, specifically 9 times faster + than gcc. + + I've used tcc to compile win32 applications with opengl and gdi+, and a + pdf library that we'll use later to benchmark performance. There are + limitations to what can be compiled, I haven't managed to compile + libpng for instance, but you can use gcc to provide a shared library + that tcc can link with. + + The compiler is written by Fabrice Bellard, author of qemu, ffmpeg, + quickjs, jslinux and the list goes on. You've likely used his software + in one way or another. I will use the last version he released before + abondoning tcc, but it's alive and well in [11]this fork. + + To get tcc working we have to compile it twice: The first time is to + compile libtcc1.a. The way this happens according to the Makefile is + that gcc is used to compile tcc, and then tcc builds and outputs + libtcc1.a. If we start by compiling with musl, it's not going to run on + the host, and thus libtcc1.a cannot be built. So first step is to + configure the build with --enable-cross, which builds a cross compiler + that compiles the right libtcc1.a. After that, we can compile for a + single architecture and libc: x86 musl. + + mkdir tcc___________________________________________________ + wget http://download.savannah.gnu.org/releases/tinycc/tcc-0. + --output-document - \__________________________________ + | tar -xj --strip-components 1 --directory tcc \___________ + --exclude tests --exclude examples______________________ + ____________________________________________________________ + mkdir libtcc________________________________________________ + cp --recursive tcc/* libtcc_________________________________ + + Configure tcc cross compilers for current cpu architecture to get + i386-version of libtcc1.a + + (cd libtcc && ./configure --prefix=./output --enable-cross)_ + + Malloc hooks have been removed in glibc 2.34 and Ubuntu 22.04 ships + with glibc 2.35. The next two commands are unnecessary on Ubuntu 20.04, + but harmless. + + (F=libtcc/lib/bcheck.c && cp $F /tmp/oldf \________________ + && sed --in-place "s/#define CONFIG_TCC_MALLOC_HOOKS//" $F + && sed --in-place "s/#define HAVE_MEMALIGN//" $F \________ + && diff /tmp/oldf $F)______________________________________ + + Then build libtcc on the host and copy to the file system overlay. + + make --directory libtcc_____________________________________ + make --directory libtcc install_____________________________ + mkdir -p buildroot-v86/board/v86/rootfs_overlay/lib/tcc_____ + cp libtcc/output/lib/tcc/i386-libtcc1.a \__________________ + buildroot-v86/board/v86/rootfs_overlay/lib/tcc/libtcc1.a + + Next step is to configure and build the compiler for x86 musl. + + (cd tcc && ./configure \___________________________________ + --cpu=x86 \____________________________________________ + --config-musl \________________________________________ + --cross-prefix=${PWD}/../buildroot/output/host/bin/i686- + --elfinterp=/lib/ld-musl-i386.so.1 \___________________ + --crtprefix=/lib \_____________________________________ + --libdir=/lib \________________________________________ + --tccdir=/lib/tcc \____________________________________ + --bindir=/bin \________________________________________ + --includedir=/include \________________________________ + --sysincludepaths=/lib/tcc/include:/include \__________ + --sharedir=-unused \___________________________________ + `# We need debug symbols for later, but uncomment this i + `# The difference is ~70% file size reduction.` \______ + `# --strip-binaries`)___________________________________ + make --directory tcc \_____________________________________ + --assume-old libtcc1.a \_______________________________ + --assume-old tcc-doc.html \____________________________ + --assume-old tcc-doc.info_______________________________ + DESTDIR=$PWD/tcc/output make --directory tcc install________ + cp --recursive tcc/output/* buildroot-v86/board/v86/rootfs_o + + --assume-old makes make skip libtcc1.a. Also skip steps that require + makeinfo since documentation will end up in the directory + "output-unused" as specified a bit hacky with --sharedir=-unused. + DESTDIR is set when installing because configuring with + --prefix=./output compiles tcc with search paths beginning with that + prefix. + + --elfinterp points to the dynamic linker in the image, responsible for + locating shared libraries needed by an application, prepare it to run + and then execute it. Because we use musl, this file is called + ld-musl-i386.so.1, but on your glibc-based distro it's (likely) + ld-linux-x86-64.so.2. Without it, the system won't know how to start + applications and you'll get `/bin/sh: {your command}: not found` + + For tcc to create executables, it needs startup routines that are + linked into the executable. Those files start with crt, short for c + runtime, and we have configured tcc to search for them in /lib. Since + tcc supports running c without creating an executable via `tcc -run + file.c`, you only need these files if you want to build executables + (and if you plan on continuing this tutorial). Here's a quick summary + of crt files from [12]https://dev.gentoo.org/~vapier/crt.txt: + + crt1.o + Contains the _start symbol which sets up the env with + argc/argv/libc _init/libc _fini before jumping to the libc main. + + crti.o + Defines the function prolog; _init in the .init section and + _fini in the .fini section. + + crtn.o + Defines the function epilog. + + + cp buildroot/output/host/i686-buildroot-linux-musl/sysroot/l + buildroot-v86/board/v86/rootfs_overlay/lib______________ + + That is what's needed for running tcc in v86, but it doesn't do much + without musl's standard c headers. We pick only the bare minimum, + because all headers are ~5 mb uncompressed. + + printf "buildroot/output/host/i686-buildroot-linux-musl/sysr + bits alloca.h assert.h complex.h ctype.h errno.h fenv.h + inttypes.h iso646.h limits.h locale.h math.h memory.h ma + signal.h stdalign.h stdarg.h stdbool.h stddef.h stdint.h + stdnoreturn.h string.h strings.h tgmath.h threads.h time + wchar.h wctype.h \_____________________________________ + | xargs -0 cp --recursive --target buildroot-v86/board/v86/r + + Hello world + + With tcc compiled and installed into our image, it's time to prepare + some code to test if the compiler works. + + mkdir buildroot-v86/board/v86/rootfs_overlay/opt____________ + cat >buildroot-v86/board/v86/rootfs_overlay/opt/test.c <<EOF + #include <stdio.h>__________________________________________ + #include <string.h>_________________________________________ + ____________________________________________________________ + int main(int argc, char **argv)_____________________________ + {___________________________________________________________ + char *name = "stranger";________________________________ + if (argc > 1 && strlen(argv[1]) > 0)____________________ + name = argv[1];_____________________________________ + printf("Hello, %s\n", name);____________________________ + return 0;_______________________________________________ + }___________________________________________________________ + EOF_________________________________________________________ + + Rebuild image with the new files: + + make --directory buildroot__________________________________ + cp buildroot/output/images/rootfs.iso9660 web/linux.iso_____ + + If you've closed your server, open a new terminal and run + + python3 -m http.server 8000 --directory web_________________ + + Go to [13]http://localhost:8000 and try this in the emulator: + + # Compile and run without producing a binary________________ + tcc -run /opt/test.c________________________________________ + ____________________________________________________________ + # Create binary_____________________________________________ + tcc /opt/test.c -o hello____________________________________ + ./hello world_______________________________________________ + +Benchmarking + + Time for a quick benchmark to see what performance we can expect. We'll + use the excellent pdf writer library, libharu. + + mkdir libharu_______________________________________________ + wget https://github.com/libharu/libharu/archive/refs/tags/RE + --output-document - \__________________________________ + | tar -xz --strip-components 1 --wildcards --directory libha + "libharu-RELEASE_2_3_0/include/*.h" \________________ + "libharu-RELEASE_2_3_0/src/*.c" \____________________ + libharu-RELEASE_2_3_0/src/t4.h \_____________________ + libharu-RELEASE_2_3_0/demo/line_demo.c________________ + ____________________________________________________________ + cat >libharu/include/hpdf_config.h <<EOF____________________ + #define LIBHPDF_HAVE_NOPNGLIB_______________________________ + #define HPDF_NOPNGLIB_______________________________________ + #define LIBHPDF_HAVE_NOZLIB_________________________________ + EOF_________________________________________________________ + + Doing `sudo apt install sloccount` and then `sloccount libharu` tells + us that the library consists of 128394 physical source lines of code. + That's because of surprisingly big files with arrays containing + encoding data, but let's see how long it'll take to compile that by + creating a quick and dirty benchmark that works for both gcc and tcc. + + cat >libharu/benchmark <<EOF________________________________ + LIBHARUDIR=\$(dirname \$(readlink -f "\$0"))________________ + CC=\$1______________________________________________________ + [[ \$CC = gcc ]] && LIBMATH=-lm_____________________________ + time \$CC -I\$LIBHARUDIR/include "\$LIBHARUDIR/src/*.c" \\_ + \$LIBHARUDIR/demo/line_demo.c \$LIBMATH -o /dev/null____ + EOF_________________________________________________________ + chmod +x libharu/benchmark__________________________________ + ____________________________________________________________ + # Build a shared library for another benchmark______________ + buildroot/output/host/bin/i686-buildroot-linux-musl-gcc -sha + -Ilibharu/include libharu/src/*.c -lm \________________ + -o buildroot-v86/board/v86/rootfs_overlay/lib/libharu.so + ____________________________________________________________ + # Make it easy to run a benchmark where tcc links with libha + # compiling from scratch.___________________________________ + cat >libharu/benchmark-link <<EOF___________________________ + time tcc -Ilibharu/include -lharu libharu/demo/line_demo.c - + EOF_________________________________________________________ + chmod +x libharu/benchmark-link_____________________________ + ____________________________________________________________ + cp --recursive libharu buildroot-v86/board/v86/rootfs_overla + ____________________________________________________________ + make --directory buildroot__________________________________ + cp buildroot/output/images/rootfs.iso9660 web/linux.iso_____ + + Run the benchmarks + + Run this locally + + libharu/benchmark gcc_______________________________________ + + Run this in the emulator + + libharu/benchmark tcc # Patience required__________________ + + libharu/benchmark-link______________________________________ + + As the benchmark unsurprisingly shows us, linking to a precompiled + shared library is faster than compiling from scratch. On my machine, + benchmark-link is 60 ms in v86. Not bad! Take a look at + libharu/demo/line_demo.c, it's not the tinyest c file out there. + + I didn't show you how to compile a shared library with tcc on purpose + (only how to link with one). There's a bug somewhere, and we'll + investigate that in the next section. + +Debugging + + If you've followed the steps so far, you can open your emulator and + execute + + tcc -shared -fPIC -Ilibharu/include libharu/src/*.c_________ + + This command tells tcc to compile a shared library instead of an + executable and will take approximately 30 seconds, then it'll exit with + a segmentation fault. + + I won't tell you how to fix this problem, because I have no need to + compile shared libraries with tcc on a custom x86 system, nor do I have + the intellect to fix the bug. But I didn't know (the latter) at the + time, so I wanted to figure out what was wrong, which required... + + Remote debugging + + The gnu debugger, gdb, supports remote debugging via gdbserver, which + is a small application you run on the target and connect to from gdb. + Running gdbserver inside v86, inside a browser, and connecting to that + from gdb would be cool, but since gdb doesn't work in v86 (you'll find + out why later), gdbserver is not going to either. So to debug + something, we need to reproduce the bug in qemu, and use socat to + create a virtual serial port for gdb/gdbserver communication. And to + compile gdb we need musl-cross-make via git. + + sudo apt install qemu-system-i386 socat git_________________ + + With qemu installed, it's easy to boot your image + + qemu-system-i386 -serial stdio -cdrom web/linux.iso -cpu Wes + + And you even get a nice serial console for copy pasting! That was the + good news, now for the bad... + + Buildroot, gdb and musl doesn't go well together and results in + configure errors if you select the gdb package. So we have to compile + gdb on our own, using a different toolchain. This could have been + avoided with uclibc instead of musl, but in the name of MIT licenses, + here we are. Hopefully you won't mind another huge compilation step. + + The following will clone musl-cross-make, configure and compile it. + + git clone https://github.com/richfelker/musl-cross-make.git_ + ____________________________________________________________ + cat >musl-cross-make/config.mak <<EOF_______________________ + TARGET=i686-linux-musl______________________________________ + MUSL_VER=git-v1.2.2_________________________________________ + GCC_VER=10.3.0______________________________________________ + # Not needed libs___________________________________________ + COMMON_CONFIG += --disable-nls______________________________ + EOF_________________________________________________________ + ____________________________________________________________ + make --directory musl-cross-make -j$(nproc)_________________ + make --directory musl-cross-make install____________________ + + Now is the time to grab a coffee. + + Welcome back, we're now ready to build gdb/gdbserver with the toolchain + installed into musl-cross-make/output/bin. Compiling gdb 10.2 is ideal + here because it doesn't require gmp (GNU Multiple Precision Arithmetic + Library), which later versions does. + + mkdir gdb___________________________________________________ + wget https://ftp.gnu.org/gnu/gdb/gdb-10.2.tar.gz --output-do + | tar -xz --strip-components 1 --directory gdb______________ + (cd gdb && \_______________________________________________ + PATH=$PATH:$PWD/../musl-cross-make/output/bin \__________ + ./configure \_____________________________________________ + --prefix=$PWD/output \________________________________ + --host=i686-linux-musl \______________________________ + --disable-nls \_______________________________________ + --with-curses)_________________________________________ + PATH=$PATH:$PWD/musl-cross-make/output/bin make --directory + PATH=$PATH:$PWD/musl-cross-make/output/bin make --directory + + The new toolchain in `musl-cross-make/output/bin` follows a naming + convention for cross compilers, so every program starts with + i686-linux-musl as specified in musl-cross-make/config.mak by TARGET. + gdb follows the same convention, and by specifying i686-linux-musl in + `--host` and adding the toolchain to PATH, gdb is able to locate the + right tools without having to install them on your system. We also + --disable-nls (localization) and compile --with-curses instead of a + default ancient alternative that we'd have to compile separately. + + Clean gdbserver by strip'ing it of debug symbols and non-essential + data, and copy to the target. This reduces gdbserver file size from 8 + mb to 500 kb. For gdbserver to run, the c++ standard library is + required as well. + + musl-cross-make/output/bin/i686-linux-musl-strip gdb/output/ + cp gdb/output/bin/gdbserver buildroot-v86/board/v86/rootfs_o + musl-cross-make/output/bin/i686-linux-musl-strip \_________ + musl-cross-make/output/i686-linux-musl/lib/libstdc++.so. + cp musl-cross-make/output/i686-linux-musl/lib/libstdc++.so.6 + buildroot-v86/board/v86/rootfs_overlay/lib______________ + + These files are ~2500 kb in total, so you want to remove them again + after debugging. + + gdb must then be compiled for the host with i686 target support, which + is easy in Buildroot: + + make --directory buildroot menuconfig_______________________ + + then select Toolchain -> Build cross gdb for the host and compile + + make --directory buildroot__________________________________ + cp buildroot/output/images/rootfs.iso9660 web/linux.iso_____ + + Qemu and virtual serial ports + + While compiling, we create a pseudo terminal (pty) acting as a virtual + serial port. Since socat uses random id's for the terminals like + /dev/pty/2 and /dev/pty/18, we tell socat to create symbolic links for + the random id's with id's we know in advance. + + Open a new terminal and run the following: + + socat pty,rawer,link=/tmp/vserial-host pty,rawer,link=/tmp/v + + When compilation is done, start qemu in a new terminal and connect with + the virtual serial port on the host + + qemu-system-i386 -serial stdio -cdrom web/linux.iso -cpu Wes + -chardev serial,id=gdbserial,path=/tmp/vserial-host \__ + -device isa-serial,chardev=gdbserial____________________ + + if you write `dmesg | grep tty` in the serial console you'll see two + connected ports: ttyS0 which is connected to your terminal via `-serial + stdio` and ttyS1 is connected to the virtual socat serial port. + + Start gdbserver in your qemu serial console for tcc debugging + + gdbserver /dev/ttyS1 tcc -shared -fPIC -Ilibharu/include lib + + then start gdb on the host, pointing to the cross compiled version of + tcc + + buildroot/output/host/bin/i686-buildroot-linux-musl-gdb \__ + -ix buildroot/output/staging/usr/share/buildroot/gdbinit + tcc/output/bin/tcc______________________________________ + + -ix means: Before the "inferior", which is gdb's name for a process + (simply put), execute the file buildroot/.../gdbinit. `gdbinit` is + provided by Buildroot and contains the following: +add-auto-load-safe-path {...}/buildroot/output/host/i686-buildroot-linux-musl/sy +sroot +set sysroot {...}/buildroot/output/host/i686-buildroot-linux-musl/sysroot + + which specify the directory that contains copies of libraries on the + target, in corresponding subdirectories. + + Let's connect to qemu and run tcc: + + (gdb) + target remote /tmp/vserial-target___________________________ + (gdb) + continue____________________________________________________ + + You'll get a few warnings that I believe is due to shared libraries + being stripped of debugging symbols by Buildroot. Then the following + error appears: +0x004f9c1f in fill_local_got_entries (s1=0xb7e99020) at tccelf.c:1362 +1362 for_each_elem(s1->got->reloc, 0, rel, ElfW_Rel) { + + Looking into tcc's source, we see that this code is only run when + compiling shared libraries. Perhaps recompiling for uclibc makes a + difference, or upgrading to the tcc fork (which requires additional + work in regards to compilation). Let me know if you fix the error and + I'll add it to the tutorial. + + We could have added gdb to rootfs_overlay and run that in qemu instead, + but then we lose code snippets of the error due to missing source + files. Feel free to use gdb on the target if you're okay with just line + numbers. + + Debugging in v86 + + I've not been able to get gdb working in v86. Everything segfaults + whenever I attempt to debug. Changing toolchain to uclibc will make + Buildroot compile gdb, but it doesn't fix the issue, and downgrading + gdb from 11.2 to 10.2 or 8 makes no difference. gdb works when running + in qemu, so it must have something to do with v86. It would have been + great to have gdb tell what crashed at runtime, but a c compiler will + have to do for now. + +Licenses + + To get all licenses from Buildroot, you write + + make --directory buildroot legal-info_______________________ + + They're then found in buildroot/output/legal-info. Getting a complete + list of licenses for everything used here is left as an exercise for + the reader. + +What's next + + In the next tutorial(s) I'll show you how to: + * Interact with v86 from JavaScript via serial and 9P. + * Create a simple interface for dmesg diffing to better optimize the + image. + * Compile and run c applications in the browser with a small ui. + * Build a streaming parser for Linux kernel calls to create a basic + but highly stylable console with unicode support; to display stdout + (printf/puts/putchar/...) and ask for input on stdin + (scanf/gets/getchar/...). + + If you got this far, perhaps you want to subscribe to new tutorials? + Then [14]subscribetoj@nsommer.dk and I'll add you to the list. The mail + can be empty, but if not I promise I'll read it. You can always + [15]unsubscribetoj@nsommer.dk. + + Tipping: I'm writing tutorials for as long as there's money in the + bank. Help me write more by tipping via bank transfer (IBAN) to DK81 + 2000 6277 7121 54. Any amount is highly appreciated! + +References + + 1. https://ja.nsommer.dk/ + 2. https://tbfleming.github.io/cib + 3. https://github.com/copy/v86/blob/master/Readme.md#readme + 4. https://copy.sh/ + 5. https://buildroot.org/ + 6. http://www.etalabs.net/compare_libcs.html + 7. https://www.se-radio.net/2020/06/episode-414-jens-gustedt-on-modern-c + 8. http://localhost:8000/ + 9. https://bellard.org/tcc/tcc-doc.html#ISOC99-extensions + 10. https://bellard.org/tcc/ + 11. https://repo.or.cz/tinycc.git + 12. https://dev.gentoo.org/~vapier/crt.txt + 13. http://localhost:8000/ + 14. mailto:subscribetoj@nsommer.dk + 15. mailto:unsubscribetoj@nsommer.dk diff --git a/docs/landley.net_aboriginal_history.txt b/docs/landley.net_aboriginal_history.txt new file mode 100644 index 0000000..f2e37e2 --- /dev/null +++ b/docs/landley.net_aboriginal_history.txt @@ -0,0 +1,1229 @@ +Aboriginal Linux + + * New to the project? Read [1]About Aboriginal Linux. + * Current release: (version 1.4.4, November 11, 2015): [2]build + scripts, [3]prebuilt binaries. + * Development version: [4]git repository, [5]rss commit feed, + [6]snapshot tarball, [7]mailing list. + + News + * [8]News + + Documentation + * [9]About + * [10]README + * [11]Build Stages + * [12]Prebuilt Binaries + * [13]Screenshots + * [14]FAQ + * Presentation ([15]html [16]PDF [17]text) + + Download + * [18]Source Tarballs + * Prebuilt Binaries [19]Current [20]Older + + Development + * [21]Mailing List + * [22]Maintainer's Blog + * [23]Git Repository + * [24]Snapshot Tarball + * [25]Commits RSS + * [26]Releases RSS + * IRC #toybox on freenode.net + + Control Images + * [27]Build Control Images + +Where did "Aboriginal Linux" come from? Our story so far... + + My name is Rob Landley, and I've been working on Aboriginal Linux on + and off since the late 90's. It's what got me into BusyBox and uClibc, + embedded development, compiler internals, and so on. Now it's where I + put together everything else I'm doing (like toybox, tinycc, and the + relocatable gcc wrapper) to see what actually works and give it a good + stress-test. "Eating your own dogfood", and all that. + + The following may not be interesting to anybody but me. (It's as much + autobiography as technical history of the project. A big blog entry, + really.) But just for the record: + +Prehistory + + Back in the late 90's, before linksys routers came out, I installed + several masquerading gateways by putting Red Hat on old leftover 386 + machines. This involved removing as many packages as possible from the + base install, both to get the size down (to fit it on old hard drives) + and to reduce the security exposure of all the daemons Red Hat ran by + default (including a print server and an NFS server exposed to the + world, for no readily apparent reason). + + Back around Red Hat 6, the smallest base install was still hundreds of + megabytes, and needed dozens of packages removed to get a reasonably + stripped down system. (You couldn't choose _not_ to install things like + ghostscript, or printer support, only remove them after the fact.) + Package dependencies often forced me to delete stuff by hand: some + packages' uninstall scripts outright failed, others had circular + dependencies in long chains through dozens of packages, and there was + no distinction between "this package provides optional functionality" + and "it won't run without this", a dependency was a dependency as far + as RPM was concerned. + + Stripping down Linux installs was a time-consuming process that still + left behind mountains of junk doing who knows what, which I didn't + understand well enough to safely remove. + + Stripping down a full distribution seemed like the long way around to + get a minimal system. What I wanted was to build _up_ from an empty + hard drive, adding only what I needed. I knew how to build packages + from source to add them to a working system, but not how to _get_ a + working system in the first place. When I went to the the third Atlanta + Linux Showcase (in 1999), I pestered everyone I met to tell me how to + build a complete Linux system from source code. Lots of people thought + it was a great idea, but nobody could point me to the appropriate + HOWTO. A few months later, one of the people I'd asked emailed me about + the launch of the Linux From Scratch project, and from that I finally + learned what I needed to know. + + The LFS book linked to the [28]Linux Bootdisk HOWTO, and for a while I + got no further than that immensely educational resource. It explained + exactly what you needed to copy from an existing root filesystem in + order to run an arbitrary app from a bootable floppy. It explained the + directory layout, which configuration files were actually necessary and + what they did, the early boot process, and introduced me to the ldd + command with which I could track down the shared libraries a given + executable needed. + + Around this time I also encountered [29]tomsrtbt, which used the old + "format a 1.44 megabyte floppy to to 1.7 megabytes" trick to fit an + enormous amount of Linux system onto a single bootable floppy disk. + (This was also my introduction to the BusyBox project, and later to the + programming language LUA.) + + The above approach of cherry-picking your own boot environment using + prebuilt binaries didn't scale very well, and didn't let me mix and + match components (such as substituting busybox for Red Hat's command + line utilities), so when Linux From Scratch's 3.0 release came out I + cleared a month to sit down and properly work through it, understanding + what each step was doing. I turned their instructions into a bash + script as part of the learning process, because I kept screwing up + steps and having to start over, only to typo an earlier step as I + repeated it by hand and have to start over _again_. I joined the + Automated Linux From Scratch mailing list in hopes I could find (or + help create) an official script to use, but they were all talk and no + code. (Everybody had their own automation script, but the project + wanted to create something big like Gentoo and seemed to think that + publishing a simple script implementing the existing Linux From Scratch + instructions was beneath them. So everybody had their own script, none + of which were "official".) + + My own script quickly evolved to remove packages like gettext and + tcl/expect, things the masquerading servers I'd been assembling didn't + actually need. I poked at adding X11 (something I'd installed myself by + hand back under OS/2) and pondered running the system on my laptop + someday, but the hundreds of packages I'd need to build and the + constant maintenance of keeping it up to date kept that idea way down + on my to-do list. + +Version 0: The WebOffice version ("Yellowbox") + + Towards the end of 2000 I met the founders of a local start-up through + the Austin Linux Users Group (two Taiwanese guys named Lan and Lon), + and at the end of the year joined their start-up company "WebOffice" as + employee #4. The two founders were ex-AMD hardware guys who didn't + really program, who had already hired a recently retired professional + tennis player to do marketing for them. They had a prototype firewall + product they'd demonstrated to get venture capital funding: a small + yellow box running stock Red Hat 7. (When they first demonstrated it to + me, I diagnosed and removed the "code red" virus from it.) + + The money wasn't great, but the project was interesting, challenging, + and full of learning opportunities. Full-time Linux positions were + still somewhat rare back then, and to make up for the low salary (and + the fact they weren't offering stock options; yes I asked, they were + saving it for themselves and the VCs), I was promised that I could GPL + most of the code I was working on as soon as it shipped. Back in 2000, + that sounded like a pretty good deal. + + For a the first few months I was their only programmer, doing + everything from architecture to implementation (OS, applications, web + interface, the works). I became lead developer and architect when they + got a second round of VC funding they hired more developers. + + Alas, mostly bad ones. The founders didn't know enough about + programming to choose wisely, and I wasn't consulted on most hiring + decisions because I wasn't "management". Only one actual IDIOT in the + bunch, thank goodness, but they made me share an office with him. He + was another Taiwanese guy (this one named "Luan") who the founders felt + sorry for because his previous dot-com had gone under and he'd be + deported if he didn't stay employed to maintain his H1B visa. (Yes, + they admitted this to me when I complained about him.) Unfortunately, + not only did he not know anything of use to the company, but he never + showed any ability to learn, and after the third time "show me how to + do this" turned into him handing in my example code verbatim as his + work, our working relationship deteriorated somewhat. He literally + could not work out how to write a "hello world" program by himself, and + when I spent an hour explaining things to him rather than writing + example code he could turn in he got frustrated and accused me of being + obstructionist because I wouldn't do his job for him. (Of course he had + an MCSE.) + + And thus began my habit of taking my laptop to places other than my + office, so I could get work done without interruption... + + There are reasons this company didn't survive to the present day. + +Yellowbox technobabble. + + WebOffice's proposed product was an early multi-function embedded Linux + device. It was a masquerading fireball which provided dhcp and DNS for + its private subnet. It also provided a VPN bridging multiple such + subnets (possibly from behind other existing firewalls, by bouncing + connections off a public "star server"; an idea the founders of + WebOffice tried to patent over my objections). It also provided network + attached storage (samba) with a web-based user account management GUI. + It also provided scheduled actions, such as automated backup. It also + acted as a video server. And it did a dozen other things I don't even + remember. (Their marketing material called the project the "iLand + gateway 2000". I had no say in this.) + + I called it "yellowbox" (because it was), and described it as a "swiss + army server". The hardware was a standard PC motherboard and an 8 port + ethernet switch in a small custom-designed bright yellow metal case + with pretty decals on it. Inside was a 266mhz celeron, 128 megs of ram, + a 2 gig hard drive, two network cards, and the aforementioned 8 port + 100baseT ethernet switch removed from its case and screwed into a metal + frame. The back of the box exposed a lot of ethernet ports (one + "uplink" port and 8 switch ports, although only 7 of the switch's ports + worked because the eighth was soldered to the second internal ethernet + card; they labeled it "service" or some such because if the hole in the + back of the case didn't let them expose it to the outside world it + wouldn't fit right). The only other port was a place to plug in the + power cable. The front had many blinky lights (one of which was a blue + LED, which they were very proud of and considered a big selling point). + + Most importantly, the motherboard's video/keyboard/mouse ports weren't + exposed to the outside world: it was supposed to run as a headless box + administered through the network via a web server with clever CGI. We + could plug a keyboard and monitor into it during development, but only + by taking the case off. Out in the field, it had to "just work", and + would be a useless brick if it didn't boot all the way into the OS and + run our applications. + + This was my first exposure to embedded development. The hardware was + standard PC/x86, it wasn't too badly underpowered for what it did (at + least by the standards of the day), and it used wall current instead of + battery power... But it was a headless self-administering box meant to + function as an appliance to end users, which was new to me. It was also + a challenge to strip down the whole OS into a small enough package that + they could download entire new OS images using the internet speeds of + 2001, and then update the new OS image without losing data or turning + it into a brick. + + WebOffice's original prototype device ran a stock Red Hat 7 install + (the one that had the Code Red virus when they first demoed it to me + after a LUG meeting). The whole OS image took up almost a gigabyte, and + that's before they'd implemented any applications or web UI. I rebased + the system on Linux From Scratch, using my LFS 3.0 script to build the + base OS and creating a new script to build the additional packages + (apache, postscript, ssh, and so on) the project used. I got the OS + down under 100 megs (but not by much, it still used glibc and gnu + coreutils and so on). I then spent the next year and a half learning + how to properly strip down and secure an embedded system. I brushed + against both busybox and uClibc during this period, but couldn't get + either one to work in our project at the time. We needed more + functionality than either provided back then. + + I implemented all the web CGI stuff in Python; a part-time web designer + would come in once a week to mock up pages using Dreamweaver, and I'd + take the result and make my Python code spit heavily cleaned up + versions, plus actual content and minus most of the and similar + lunacy. Getting the stylesheets to work was interesting. (Working + around the way Internet Explorer treated the end-form tag as a break + tag and inserted extra vertical whitespace that didn't show up in + Netscape or Konqueror was also fun, although it _didn't_ do this if + your start form tag and end form tags were at different table levels. + Yes, to make it display right I had to make tags cross, so IE didn't + think it understood the data and thus get confused and do the wrong + thing. I'm not proud of this, but it was IE.) + + I learned how to configure and administer (and automate the + administration of) apache, samba, postfix, ssh, bind, dhcpd... I + created [30]a scalable vpn (which freeswan _wasn't_, nor was the + out-of-tree patch of the day remotely reliable) by combining iptables + port forwarding with ssh and a wrapper daemon. (Again the founders + tried to patent this; I objected strenuously that it was A) obvious, B) + they'd said I could GPL it when it shipped. This went on for a while). + + I also made an automated production process for WebOffice: my scripts + built a CD-rom image which, when booted (with the case off there was a + spare IDE port you could hook a cd-rom drive to), would partition and + format /dev/hda and install the final OS image on it, eject the CD, + play "charge" through the PC speaker, and power down the machine. (If + something went wrong, it played "taps" instead.) Yes, these CDs were + dangerous things to leave lying around, and I made sure to label 'em as + such. + + WebOffice wanted to be able to remotely upgrade the firmware, which + meant sending a new OS image as a single file. The install had to be + fairly atomic, if something went wrong during the upgrade (including a + power failure, including the user switching it off because it was + taking too long) the thing could easily become a brick. Obviously a + traditional "extract tarball into partition" approach was unacceptable, + even before "fsck" issues came up. (The only journaling filesystem in + the stock kernel at the time was reiserfs, and that was way too fiddly + and overcomplicated for me to trust my data to it. I moved the data + partition to ext3 when that got merged, but wanted to make the base OS + partition read-only for security reasons.) + + I wound up creating a gpg-signed tarball with several files, one of + which was the new kernel to boot, one of which was the initrd + (remember: this was back before initramfs), and one of which was a + filesystem image to read-only loopback mount as the new root + filesystem. (For security reasons I wanted root mounted read only, + which also suggested a compressed filesystem to save space. Squashfs + didn't exist yet and the ext2 compression patches had already + bit-rotted, so I used zisofs.) The tarball also contained a file with a + version string, and a file with an sha1sum of the concatenation of the + other four files. + + Extracting a firmware tarball wrote these files into a new subdirectory + (The tar invocation extracted those specific names, so an attacker + couldn't write to arbitrary locations in the filesystem with a + carefully crafted tarball; yes I was paranoid while learning about + security), and made use of the "lilo -R" option to switch to the new + firmware. That sets the LILO command line for the next boot only, so we + left the default pointing to the old firmware but told LILO that on the + next boot it should use the new firmware. If the new firmware came up + and its self-diagnostic checked out, it would change the LILO default. + If it didn't work, power cycle the box and the old firmware would come + up. (This greatly reduced the chances of turning the headless box into + a brick, and you couldn't do that with grub.) + + At a technical level, there was a chicken and egg problem here: the + root filesystem was a loopback mount, but the file to loopback mount + has to live somewhere. So the system needed a writeable partition for + logging and such anyway, so I made /dev/hda1 be ext3 and mounted it on + /var, and put the firmware in that. So during the boot process the + initrd needed to mount /dev/hda1 onto a /temp directory, loopback mount + the /temp/image file onto a /sub directory, and before doing the + pivot_root into /sub it needed to move the /temp mount into /sub/var. + This turned out to be nontrivial. + + Back under the 2.2 kernel you couldn't mount a partition in two places + at once, so mounting the same /dev/hda1 on both /tmp and /sub/var + wasn't an option. I had to use early (and buggy) 2.4 kernels to have + any chance to make this work (and also to make the VPN work, which + required the undocumented SO_ORIGINAL_DST getsockopt() existing in 2.4 + but not 2.2). + + The early 2.4 kernels sucked mightily. The memory management problems + that resulted in the rik->andrea switch in 2.4.10 hit the yellowbox + project kind of hard. I once drove the 2.4.7 kernel into a swap + thrashing state, went to lunch (instead of rebooting, just to see if it + would recover), and it was still swap thrashing and mostly paralyzed + when I came back over an hour later. The disk cache (especially the + dentry cache) could get unbalanced until it grew to evict all the + anonymous pages and froze the system hard. (A big rsync would do that + fairly reliably. Trying to avoid this I studied the md4 algorithm and + the rsync description file and spent a week writing most of my own + rsync implementation in python, but A) it maxed out at about + 300k/second on the processor we were using, B) it also caused the hang + because it was really a kernel issue and not an application issue.) It + was frustrating, but we persevered. + + Mounting a partition twice and leaking one of the mount points (the old + /temp was inaccessible after the pivot_root) was kind of unclean + anyway, the clean thing for the boot to do was actually move the /tmp + mount to /sub/var after mounting /sub but before the pivot_root into + /sub. But when I asked on linux-kernel how to do that, I was told that + "mount --move" didn't exist yet. A couple releases later Al Viro added + it, and I was one of the first happy users. + + I also wanted to put the kernel, initrd, and loopback mountable root + filesystem image together into a single file, so we didn't have to + extract a tarball during a firmware upgrade but could actually _boot_ + into the actual file we'd downloaded, after verifying its signature. + (This avoided the problem of successfully downloading the tarball but + not having enough space left to extract it. Since zisofs, zImage, and + initrd were already gzipped, compressing the firmware image for + transport wasn't a priority. Keep in mind: headless box, + self-administering. Even little things like this could turn into a big + problem in the field if you didn't handle them.) + + You could already use "losetup -o" to loopback mount a file at an + offset, and I made a "length" patch to LILO that let its config file + tell it to boot only the _start_ of the kernel file you fed it. But + dealing with the initrd in between was a pain, which is why I + eventually became an early avid follower of initramfs, and wound up + writing documentation for it when I couldn't find any and had to answer + so many questions myself. + +The end at WebOffice + + The original promise that I could GPL the code I was working on + (everything except the python CGI) once it shipped never came true. + Partly the founders were ambivalent about this whole "open source" + thing, wanting every competitive advantage they could get. (They kept + trying to patent obvious things I did. Their patent lawyer was a really + cool dude when he flew in from California.) + + Another contributing factor was that the founders were from Taiwan and + had no idea how to address the US market. Their marketer employee #3 + hadn't stayed very long (not much endorsement value for a tennis player + trying to sell servers), and they themselves only ever tried to sell + the device overseas (which made demonstrating the thing somewhat + difficult, and this also meant they were shipping a VPN with + cryptographic checks on firmware upgrades to places like Turkey, back + in the days of cryptographic export regulations). + + But the biggest problem was unending feature creep: every time the + founders saw or heard of a product that did something, we had to do + that too. I had a shippable product ready a few months after I started, + but they wouldn't ship it. I designed the firmware upgrade mechanism so + we could ship what we had and add more later, but they felt that doing + so would take focus away from developing more features. (For about a + while there they were trying to turn it into a video server. I made a + python CGI script for apache to cache large files, by downloading them + from an upstream server and sending them out as they came in as if it + had been a local file all along, while simultaneously writing them to + the hard drive for other users. Of course, they tried to patent this + too...) + + The tendency towards feature creep left them vulnerable to their + venture capitalist changing their business model. Another of the VC's + start-ups was paying lots of money to license the RealVideo streaming + server, so the VC convinced WebOffice to waste six months trying to + reverse engineer it. (After all, our idea of offering mp4 files though + Samba or Apache made us a video server, right? This was just another + kind of video server...) I wasn't interested in this direction and left + Austin for a while to spend time with my mother (who was suffering from + cancer and New Jersey) while they got this out of their system. They + hired over a half-dozen programmers to replace me during this period, + but progress on the yellow box ground to a halt anyway (and even went + backwards a bit with numerous regressions) until I came back. The + quality of the new hires varied ("erratic", "mediocre", and "suck" were + all represented). + + WebOffice ballooned to a dozen employees (over half of whom reported to + me when I came back, although I still had little say in hire/fire + decisions). The company bought itself back from the first VC by + mortgaging itself to a second VC, and refocused on the original + do-everything "swiss army server" idea. But they still wouldn't just + ship what they had as long as there were more features we could add, + and ultimately they burned through their venture capital without ever + sending more than a few prototypes to actual customers. + + WebOffice ran out of money in 2002, and instituted a round of layoffs. + I continued on half-time (at half-pay) for several more months, hoping + that necessity would make them focus on shipping units and bringing in + revenue, but it didn't happen. I left in November and spent the last + couple months of that year in Florida watching my mother die of cancer, + then driving around the country distributing her possessions to various + relatives, and finally crashing on Eric Raymond's couch for a few + months doing an "editing pass" on The Art of Unix Programming that + expanded the book from 9 chapters to 20. + +Version 1: Relaunch based on BusyBox and uClibc ("Firmware Linux") + + The code discussed here is [31]still online (if abandoned since 2005). + + When I returned to Austin in August 2003, I bought a condo near the + University of Texas (and near Metro, my favorite 24 hour coffee shop + with wireless internet access), enrolled in grad school, and [32]got + back into poking at Linux From Scratch. + + Linux From Scratch had reorganized itself. My old weboffice scripts had + been based on LFS 3, which involved building enough of a system to + chroot into and complete the build under that. The potential downside + was that bits of the host system could leak into the final target + system, such as copied headers or tools build by the host's compiler. + + In 2002 LFS 4 introduced an intermediate set of statically linked tools + in a "static" directory, which were deleted after the intermediate + system was built. In November 2003 LFS 5 renamed this temporary + directory to "tools". This new approach added the temporary directory + to the end of the $PATH during the chroot, rebuilt itself using the + temporary system, and then discarded the entire directory to eliminate + leaks of host files. This was a big enough change that it was less work + to start over from scratch than try to adapt my existing scripts. + + Starting over also seemed like a good idea because I was unsure of the + IP status of my old scripts. Although I'd been promised repeatedly I + could GPL everything but the python CGI when the yellowbox shipped, + actual shipping had never quite happened, and I didn't have that + promise in writing. (I don't remember if I lost it or if I'd been + without a contract all along. You could make an argument I owned all + the code I'd done outright in the second case, certainly that's what + the copyright notices on the individual files said, and I'd been + working on early versions of those scripts before I brought them to + weboffice in the first place and had never signed over those + preexisting copyrights. But I just didn't want to go there.) + +New Goals + + I also wanted to take the project in new directions, further into the + embedded space. WebOffice had focused on adding more and more features + to a bigger and bigger image, while I personally had focused on + trimming it down and streamlining it (for example replacing the + Postgresql database with a few flat text files to store configuration + and user information, thus replacing 200 megabytes of disk usage with + about 90k and speeding up the relevant code considerably). + + For the new project I had two main goals: make the bootable single file + idea work, and make the result much smaller and simpler. (I also wanted + to clean up the build so it didn't require root access, package and + document it all so anyone could use it, other similar tidying steps.) + + The firmware tarball I'd implemented for WebOffice had always been a + stopgap, something they could ship with quickly while I got a better + solution ready. What I really wanted was a single bootable file + containing kernel, initial ram disk, and root filesystem all in one. + (Putting an entire large root filesystem into a ramdisk consumed too + much memory, the root filesystem needed a backing store it could page + files in from.) + + The name Firmware Linux came from the goal of packaging an entire OS + image in a single bootable file, which could run directly and be used + to atomically upgrade embedded systems. + + My other goal for Firmware Linux started with the desire to replace as + much of the gnu tools as possible with something smaller and simpler. + The old yellowbox images from WebOffice had weighed in at almost 100 + megabytes, most of which was glibc, coreutils, diffutils, and so on. + This was clearly crazy, my first hard drive back in 1990 was only 120 + megabytes, and back under DOS that was enormous (and a huge step up + from my friend Chip's system with a 32 megabyte hard drive, which I + learned to program C on). When I looked at the gnu implementation of + the "cat" command and found out its source file was 833 lines of C code + (just to implement _cat_), I decided the FSF sucked at this whole + "software" thing. (Ok, I discovered that reading the gcc source at + Rutgers back in 1993, but at the time I thought only GCC was a horrible + bloated mass of conflicting #ifdefs, not everything the FSF had ever + touched. Back then I didn't know that the "Cathedral" in the original + Cathedral and the Bazaar paper was specifically referring to the GNU + project.) + + Searching for alternatives, I went back to take a closer look at + busybox and uClibc. I was familiar with both from Tom's Root Boot + (tomsrtbt), a popular single floppy Linux system that packed an amazing + amount of functionality into a single specially formatted (1.7 + megabyte) 3.5" floppy disk. I'd been using tomsrtbt for years, I just + hadn't tried to build anything like it myself. Compared to the tens of + megabytes of gnu bloat the LFS project produced, busybox and uClibc + seemed worth a look. + + [33]This old message was my first attempt at sniffing around at uClibc. + I didn't get time to seriously play with it (or BusyBox) until much + later. + + It also occurred to me that if the newly introduced /tools directory + was enough to build the final system, then all I needed for the system + to be self-hosting was enough extra packages to rebuild /tools. If the + prehistory stage had been about starting from a full distro and cutting + it down, and the WebOffice version had been about starting from ground + zero and piling up lots of functionality into a 100 megabyte tarball, + this new stage was about starting from an empty directory and adding as + little as possible to do what I wanted while staying small and simple. + + So the real questions were: + * How small could I get /tools and still build the rest of LFS under + it? + * What was the minimum functionality /tools needed in order to + rebuild itself from source _without_ first building a larger + system? + +Implementation + + I started by writing new scripts based on Linux From Scratch 4 (quickly + switching to LFS 5) to build a stock LFS system. I wrote a script to + build /tools, and another script run under a chroot to build a final + LFS system within tools. The second script acted as a test that the + /tools created by the first script was good enough. And once I had a + known working system, I started doing a number of different things to + it. + +Stripping down LFS 5.0 + + The full list of Linux From Scratch 5.0 packages were: autoconf, + automake, bash, binutils, bison, bzip2, coreutils, dejagnu, diffutils, + e2fsprogs, ed, expect, file, findutils, flex, gawk, several fragments + of gcc, gettext, glibc, grep, groff, grub, gzip, inetutils, kbd, less, + libtool, the linux kernel, m4, make, MAKEDEV, man, man-pages, modutils, + ncurses, net-tools, patch, perl, procinfo, procps, psmisc, sed, shadow, + sysklogd, sysvinit, tar, tcl, texinfo, util-linux, vim, and zlib. There + were also two LFS-specific packages, providing boot scripts, config + files, and miscellaneous utilities. + + I started by removing packages I didn't actually need. Tcl, expect, and + dejagnu hadn't been in LFS 4, so obviously it was possible to do + without them. (I was already starting to view newer versions of Linux + From Scratch as "bloated" compared to old versions. I could always + build and run test suites later, and rebuilding the system under itself + to produce a working result was already a fairly extensive test.) + + I could also eliminate ed (which patch can use for obsolete patch + formats, but who cares?), gettext (only needed for + internationalization, which is best done at the X11 level and not at + the command line), libtool (which is a NOP on ELF Linux systems and + always has been, blame the FSF for trying to get us to use it at all), + and man (and man-pages, groff, and texinfo, which are used to + build/display documentation). + + A bunch of development tools (autoconf, automake, binutils, bison, + flex, gcc, make, and m4) wouldn't be needed on a stripped down system + (such as a router) that never needed to compile anything. (Perl might + be in this group as well, since it was only included because glibc + needed it to build. The linux kernel and glibc both supplied files used + by the compiler, such as the headers in /usr/include, so this group + depended on them even if they had other more direct uses.) Similarly, + the e2fsprogs package was used to create a filesystem, but mkisofs and + such could substitute for it. + + The kernel and grub were basic infrastructure, not really part of the + root filesystem and easy to build separately. (I was still using my + modified LILO anyway.) The C library (glibc) was the next layer past + that, every userspace program had to link against it either statically + or dynamically. The boot scripts, MAKEDEV, sysvinit, and modutils were + all similarly low-level infrastructure pieces to boot the system or + talk to hardware. The shadow package provided login and /etc/passwd + support. The ncurses and zlib packages were shared libraries I + understood, but were both largely optional (and gzip/zlib seemed + somehow redundant). Bash was a command shell, bzip2 and gzip were + compression programs, tar an archiver, vim a text editor, and sysklogd + a logging daemon that wrote stuff to /var/messages. + + That left coreutils, diffutils, file, findutils, gawk, grep, inetutils, + kbd, less, net-tools, patch, procinfo, procps, psmisc, sed, and + util-linux as "other stuff in the $PATH" which were only really needed + if some application (such as a package build) used them. After enough + study, I felt comfortable I understood what they all did. + + That's what chapter 6, which built the final Linux From Scratch system, + contained. Chapter 5 had a much shorter list: binutils, gcc, linux + (used just for headers), glibc, tcl, expect, dejagnu, gawk, coreutils, + bzip2, gzip, diffutils, findutils, make, grep, sed, gettext, ncurses, + patch, tar, texinfo, bash, util-linux, and perl. And chapter 5 _had_ to + contain enough to build chapter 6, and thus rebuild the entire system + from source. + + Again, tcl, expect, dejagnu, gettext, and texinfo could be discarded. + (Most of those weren't even present in the earlier versions of Linux + From Scratch I'd used, they had to be optional.) That left just 19 + packages. The compiler toolchain was just binutils, gcc, make, glibc, + and the Linux headers (all that autoconf, automake, lex, and bison + stuff was obviously optional and could be added later from within a + working system). Perl was only used to build glibc, if that was + replaced or fixed then the need for perl (at least at this stage) could + go away. Busybox claimed to provide replacements for gawk, coreutils, + bzip2, gzip, findutils, grep, sed, tar, bash, and util-linux. Since + busybox didn't use ncurses, it should be possible to build that at the + start of chapter 6. And what was diffutils doing here at all? It turns + out that the perl configure stage uses "cmp" (which it provides), so if + you didn't need perl you didn't need this. + + Since Linux From Scratch's "chapter 6" started by rebuilding binutils + and gcc (which were the big, complicated, tough packages), those + obviously didn't need any more than was in chapter 5 to rebuild + themselves. + + All this analysis reduced Linux From Scratch's chapter 5 to four + functional groups: + * Compiler - binutils, gcc, make, and the linux headers copied into + /usr/include/linux. + * C library - glibc or similar + * Lots of posix command line utilities - everything else + * Bootloader and kernel - Linux, Lilo, etc (not necessarily part of + the root filesystem at all). + +Replacing packages with BusyBox and uClibc + + Once I ran out of obvious packages to remove, I experimented with + package substitutions, swapping out the stock Linux From Scratch + packages for other (smaller) implementations of the same functionality. + The two obvious goals (again, pursued in parallel) were to swap glibc + for uClibc, and to use busybox in place of as many other commands it + could replace. + + In theory, a self-hosting LFS chapter 5 root filesystem that could + rebuild itself directly from source could be reduced to binutils, gcc, + make, uClibc, linux-headers, and an _extensively_ upgraded busybox. (Of + course such a modified chapter 5 should still be able to build the + unmodified chapter 6. If it couldn't, there was something wrong with + it, so that was a good test.) + + Both BusyBox and uClibc were maintained by a guy named Erik Andersen, + who had started them while working for a company called Lineo and + continued them after he left (a little like the way I was continuing + Firmware Linux). In both cases he'd found a long-stalled existing + project to salvage and relaunch instead of starting from scratch, but + in reality he'd taken dead projects, replaced all their existing code, + and built a community around them. + +BusyBox + + Busybox was nice because I could introduce it piecemeal. I could + replace commands one at a time, swap an existing /tools/bin binary with + its busybox equivalent and run the build to see if it worked. If it + didn't, I could compare the two versions of the build against each + other to see what had changed, or try to replace a different (simpler) + command. + + The Linux From Scratch installation instructions also listed the files + installed by each package, so I could look through the lists ( [34]sed + had just one, [35]gzip installed a little over a dozen, + http://archive.linuxfromscratch.org/lfs-museum/5.0/LFS-BOOK-5.0-HTML/ch + apter06/util-linux.html>util-linux + installed over 60) to see what was actually needed ("sed" yes, "cal" + not so much) and what busybox did and didn't provide already and what + would need to be added or upgraded. + + I focused on eliminating packages, which meant I started by tackling + fairly complicated commands like "bunzip" and "sed", because getting + those to work would let me drop an entire package. I quickly sent in so + many bugfixes to sed I wound up maintaining the applet, and got + distracted rewriting bunzip entirely (but my new implementation + compiled to only 7k). + + Eventually, I wound up getting busybox to replace bzip2, coreutils, + e2fsprogs, file, findutils, gawk, grep, inetutils, less, modutils, + net-tools, patch, procps, sed, shadow, sysklogd, sysvinit, tar, + util-linux, and vim. + + To do that, I wound up extensively upgrading (or rewriting from + scratch) dozens of different busybox commands and adding several new + ones from scratch. + + One new command was switch_root, for initramfs support. I wrote an + initramfs file for the kernel's Documentation directory because I + investigated it for Firmware Linux. (And later gave my first OLS + presentation on the topic, and write an article series about it when I + worked at TimeSys.) + + Another new command was mdev, which was a rewrite of [36]a shell script + I used to populate /dev, which Frank Sorenson [37]ported to C and I + extended (adding a config file based on irc conversations with Gentoo's + Solar). + +uClibc + + Replacing glibc with uClibc took some doing, but at the time the uClibc + project was quite heavily developed and rapidly improving (coming out + with 8 releases in 2002 and 8 more in 2003) so there was always + something new to try. If something didn't work, they were happy to fix + it. + + uClibc version 0.9.26 (January 2004) was the breakthrough version that + went from "here are the packages known to work, anything else probably + won't" to "any package you try to build against this will most likely + work, please let us know about anything that doesn't". When uClibc did + finally work, it allowed me to remove perl from /tools (which was only + need to build glibc, but not required by anything else in LFS). + + I also experimented with dynamically linking /tools, as another way to + get the size down. Linux From Scratch statically linked chapter 5 for + simplicity sake, I tried to get the existing compiler to link against + the C library I just built. This was quite a learning experience. + Everything from changing the library loader path to making sure gcc + could find crt0.o at a nonstandard location was all new, and fiddly, + and cryptic, and didn't work. And thus began the long war between me + and gcc's path logic. (Since I had static linking to fall back on, I + could poke at this in parallel with my other work on the project, and + didn't get it to actually _work_ for quite some time.) + + At the time, programs were normally built against uClibc by using a + wrapper around gcc that rewrote its command line arguments to link + against a different C library. Of course I [38]took the wrapper apart + to [39]see how it worked and [40]how to make gcc link against uClibc + without it. What I wanted was a compiler that naturally linked against + uClibc, not an existing glibc compiler repurposed to do so. + + Based on what the wrapper was doing and a lot of tweaking and questions + on the mailing list (which Erik graciously answered), [41]I got it + working around the middle of 2003. + +User Mode Linux + + The Linux From Scratch build assumed you had root access, in order to + mknod devices, chroot into the temporary system (chapter 5) directory + to build the final system (the chapter 6 packages), and to loopback + mount files to create system images. + + Asking people to download random code and run it as root seemed kind of + impolite at best, and actively dangerous at worst. (When buildroot + first came out I ran "make uninstall" in it. The resulting host/target + confusion it suffered deleted things like gzip off my host. Back then I + was still using a Red Hat system which meant "pam", and when the + security theatre modules suffered an auto-immune response to my + attempts to patch the system back together with busybox, I had to + reinstall the OS in order to be able to launch X11 again.) + + Since the end result of my system builds was just a file (a tarball or + a filesystem image), there was no real excuse for requiring root + access. The packages built as a normal user already, in theory that was + the hard part. + + My solution was User Mode Linux. (Of course I wrote a quick [42]User + Mode Linux HOWTO containing everything I needed to know to do what I + was doing with it.) + + User Mode Linux was an early virtual machine, which could give me + simulated root access (enough for my needs), but without extensive + setup thanks to the "hostfs" (a bit like qemu's virtfs), and without + requiring a new source package (I already had the Linux kernel sources, + this was just another way of building them). + + I [43]first got UML working in a patched 2.6.9 kernel, and later + integrated it into the build when I got [44]unpatched 2.6.11 to build a + usable User Mode Linux image (although I had to [45]patch it a bit + myself later). I could then use that to chroot (via UML's "hostfs") and + loopback mount as a normal user, and then mknod within that loopback + mount, and run the chapter 5 environment within UML to build chapter 6. + Of course I wrote a quick [46]User Mode Linux HOWTO. + + Using UML was optional, and the scripts autodetected if you were + running as root and would chroot directly instead of firing up what + amounted to an emulator, but running as root was not recommended. + +Why 2006 was a lost year + +The rise of buildroot + + Shortly after I figured out how the uClibc wrapper (and gcc in general) + worked under the covers, the uClibc developers abandoned the wrapper in + favor of a new project called "buildroot". + + The buildroot project was the response to fresh gcc bloat: around gcc + 3.0 a new shared library called libgcc_s.so showed up, more or less a + dynamic version of the old libgcc.a. It contained various gcc internal + functions (such as 64 bit division on 32 bit platforms), which most + nontrivial programs wound up linking against. Unfortunately, shared + libraries can link against other shared libraries, and libgcc_s.so + linked against libc.so.6. So any program that linked against this + library snuck in a reference to glibc and wouldn't load without it, + even if it was otherwise linked against uClibc. + + This meant the gcc wrapper was no longer sufficient, but since + libgcc_s.so was part of gcc, the only way to get a new version of + libgcc_s.so that linked against uClibc (instead of glibc) was to + download the gcc source code and build gcc itself against uClibc. + + And that's exactly what buildroot did: built uClibc and a new compiler + out of the four source packages uClibc, binutils, gcc, and the linux + kernel for the kernel headers, hooking the whole mess together with + several ./configure options and source patches. Then it used the new + uClibc compiler to build Erik's other project, BusyBox, as a test case + that it was all working correctly. + + In order to test both static and dynamic linking, buildroot created a + new uClibc root filesystem directory containing the uClibc shared + libraries, and a second instance of busybox dynamically linked against + those, which you could chroot and test out the uClibc version of + busybox. Since he already had the kernel source lying around, Eric even + taught it to build a User Mode Linux binary that could do the chroot + for you. + +Problems with buildroot + + Of course I took buildroot apart to see how it worked, [47]wrote the + first buildroot HOWTO (because I tend to document everything I didn't + initially understand), made a number of [48]design suggestions, and + even [49]offered patches. + + But I didn't really like the design of buildroot (nested makefiles + aren't the most straightforward approach to anything, its need to run + as root meant that early versions [50]ate my laptop ([51]twice, + contributing strongly to my conviction that builds should never run as + root), and it [52]couldn't rebuild itself under itself, and in general + was a [53]constantly broken moving target with no stable releases. + + So I continued to work on my existing build project instead (which was + several years old by that point). Buildroot was an instructive + counterexample on many fronts: my project should not require root + access to build, shell scripts were more readable than nested + makefiles, releases were important, and it's vital to have boundaries + so you can clearly state what your project DOESN'T do. + + I also checked in with buildroot from time to time to see what it was + doing (several patches to make various packages work with uClibc were + only ever documented by being checked into the buildroot repository, + and then the uClibc developers acted shocked I hadn't heard of them). + + The biggest problem with buildroot was the impact it had on BusyBox and + uClibc development. Although buildroot started out as just a test + harness for uClibc and busybox, it quickly grew out of hand. Since the + easy way to regression test that a package worked against uClibc was to + add it to the test suite and build it as part of the test root + filesystem, lots of packages got added fairly quickly. People packaged + up and shipped the root filesystem created by buildroot when they + wanted a simple uClibc+busybox root filesystem, and then complained + when it didn't build some package they needed. + + Within a few months, buildroot had exploded from a simple test harness + into a half-assed Linux distribution. Erik [54]tried to avoid this + (he'd previously built a [55]uClibc-native version of Debian Woody and + knew perfectly well what a real distro looked like), but buildroot + turned into a distro anyway because the project had no clear boundaries + that allowed him to say "no, this new feature is not within the + project's scope". He never drew a line in the sand that allowed him to + say "no", and thus over time steady feature creep buried him. + + As a distro, buildroot was a deeply flawed. It had no package + management tools (such as rpm or deb or portage), nor did it have the + tens of thousands of packages build descriptions in the large and + carefully maintained repository of Red Hat, Ubuntu, Gentoo, or even + Slackware. For the project's first five years, buildroot never even had + a release, instead insisting users grab a random source control + snapshot du jour and hope for the best. Despite this, buildroot was the + focus of the development efforts of the BusyBox and uClibc communities, + and became their standard repository of knowledge about how to build + packages for all sorts of embedded environments. + +Buildroot derails uClibc and BusyBox development + + With no clear dividing line between "how to build" and "what to build", + buildroot's scope and complexity exploded, and despite its limitations + as a distro what buildroot could do was suck away an endless amount of + development time from the BusyBox and uClibc developers. By 2005, both + uClibc and BusyBox development were clearly suffering. + + Erik started by abandoning busybox after the 1.0 release, both because + 1.0 seemed like a good stopping point (since it was "done" now), and + because he just didn't have time for it anymore. Other developers + (including myself) still did new development, found bugs and fixed + them, but there was no prospect of a new release. + + Over on the uClibc side of things, Erik held on longer but the release + frequency slowed, from seven releases in 2003 (0.9.17 through 0.9.24) + to two in 2004, one in 2005, and none at all in the whole year 2006. + + The uClibc 0.9.26 release (in January 2004) was the point at which Erik + stopped maintaining a supported application list, because most things + just worked now. That was the point at which uClibc became generally + useful, and could have been the basis for a 1.0 release similar to + BusyBox's. But due to buildroot diverting the development community, a + uClibc 1.0 release became a more and more distant possibility as + development lost focus: by the end of the decade, uClibc still had no + clear plan to produce a 1.0 release. + +BusyBox takes over my life + + By 2005, Firmware Linux built a system that could rebuild itself, but + it still used a lot of gnu packages. I continued to replace more of + these executables with busybox, making BusyBox supply more of my + development environment and submitting numerous patches, everything + from minor bugfixes and complete ground-up applet rewrites. I also + pestered other people (such as the awk maintainer) into repeatedly + fixing their parts of the code when some package build failed and I + narrowed it down to a reproducible test case.At this point, Firmware + Linux wasn't held back by my build infrastructure (which was just a + pile of shell scripts anyway), but by deficiencies in BusyBox. I became + one of the most active BusyBox developers, using Firmware Linux as a + test environment for my busybox changes, and gradually began spending + more time working on BusyBox than the rest of Firmware Linux combined. + + After the BusyBox 1.0 release gave Erik an excuse to step back, I + continued to work intensely on the project, and the bugfixes I needed + (and that other developers supplied) kept accumulating. I eventually + collected enough together to make a bugfix-only release, which became + the official 1.01 when Erik approved it. And it turns out "he who cuts + releases is the maintainer". Erik officially handed over maintainership + a few months later, when I cut my first new development release + (busybox 1.1.0). + +Tinycc, QEMU, and TimeSys. + + I was introduced to Fabrice Bellard's "tinycc" by the October 27, 2004 + slashdot story about [56]tccboot, an ISO image that booted Linux + _from_source_code_, booting into a compiler that compiled the linux + kernel and a simple userspace in a matter of seconds, and then ran the + resulting kernel. + + Afterwards I kept track of tinycc with an eye towards replacing gcc and + binutils, thus producing a gnu-free development environment. (And then + I'd ask Richard Stallman if a system without a line of gnu code + anywhere in it was still Gnu/Linux/Dammit and mock him when he said + yes.) + + Tinycc was a small and simple C compiler, fitting a complete combined + compiler and linker into a single 100k executable. It compiled code so + quickly that its most common use was turning C into a scripting + language: by starting C source files with "#!/usr/bin/tinycc -run" and + setting the executable bit on the source file, tcc could compile and + launch it in a small fraction of a second. + + When I encountered it, tinycc couldn't build an unmodified Linux kernel + (the tccboot kernel was a hacked up subset of Linux 2.4), but was only + the third compiler ever (after gcc and Intel's x86-only closed source + icc) that had ever built a working Linux kernel, and the tinycc + developers were working towards full C99 compliance and the ability to + build Linux 2.6. + + Alas Tinycc got derailed the same way uClibc did: it spawned a side + project that sucked its developers away. In this case, the side project + was the emulator QEMU. Inspired by the speed of tinycc, Fabrice came up + with another compiler that took pages of foriegn binary code as its + input, [57]translating them on the fly a page at a time into equivalent + binary code the current machine could run. As he explained in the + [58]QEMU 0.1 announcement, the purpose was to allow Wine to run on + non-x86 machines, but QEMU quickly turned into a very fast general + purpose emulator. + + Towards the end of 2005 I [59]started playing with QEMU, as a potential + replacement for User Mode Linux. When I [60]got it to work I decided + that Firmware Linux should support every target QEMU did, meaning I had + to learn cross compiling. + + When I mentioned this on the #uClibc channel on Freenode, one of the + regulars asked if I wanted to come work at his company, TimeSys. + +My time at TimeSys + + TimeSys did embedded development, via extensive cross compiling. They + had a couple dozen extremely talented engineers and masses of + accumulated expertise. It was such an interesting job and a great group + of guys I was willing to move to Pittsburgh (with my fiancee). I + started there January 15, 2006. + + At TimeSys I worked on BusyBox (having become the project's official + maintainer with the 1.1.0 release). I also poked at uClibc a bit and + [61]encouraged its [62]development however [63]I could. (There was + another cake for the next release, that one made and delivered by + Howard Tayler of Schlock Mercenary. I asked him on the theory that if + he's truly mercenary, and lives in the same town as Erik, I just have + to pay him enough. I note his price has probably gone up since then.) + + But the reason I took the job was to learn stuff I didn't already know. + There were a bunch of guys doing cross compiling, and I learned + everything I could from them. What were the various hardware targets, + and what was each good for? How do you make a cross compiler, and how + do you use it? I spent the whole of 2006 learning stuff from a bunch of + great guys. (I've never worked with a better team of engineers than + TimeSys had in mid-2006.) + + Unfortunately, it couldn't last. Shortly before I arrived at TimeSys + they completed a cross compiling build system (based on "TSRPM", a + giant Rube Goldberg set of Perl wrappers and LD_PRELOAD library + intercepts that cross compiled RPM source packages), and used it to + cross compile the whole of Fedora Core 2 to several different hardware + platforms. This was a popular product that sold well, and the CEO of + the company decided that engineering had completed its task and the + company's emphasis would now shift to marketing. This decision + destroyed the engineering department. + + Engineering's task was NOT done. New Fedora releases came out every 6 + months, and Red Hat only supported 3 releases back (18 months). The + TSRPM build system was extremely brittle and only ran on a specific set + of carefully crafted servers in our build room: machines running 32-bit + Red Hat 9 (already obsolete even then). Timesys was selling other + companies access to these machines ("TimeSys LinuxLink"), so their + engineers could log into them through the network and run their builds + on them. This didn't scale. + + Nevertheless, the CEO froze the engineering budget transferred the + resources to sales and marketing. Laurie, the head of marketing, took + this as her cue to try to take over the company, diverting engineers to + report to her (starting with the webmaster, who quit, and then the + system administrator, who quit...) + + We discovered an interesting Corrolary to Brooks' Law (adding more + manpower to a late project makes it later, because your existing + productive people get distracted training the new ones). The corollary + is that shrinking teams get paralyzed by knowledge transfers: everybody + spends all their time trying to learn what the departing engineers + know, as you try to preserve a minimal level of necessary expertise + within the team. + + Through heroic effort the understaffed engineers managed to rebase + LinuxLink to Fedora Core 5 just as Fedora Core 2 was end-of-lifed by + Red Hat (since everything was cross compiled, this was an enormous + undertaking requiring almost as much work as porting Fedora Core 2 had + in the first place). And this burned them all out. A few people had + quit during this: the ones transferred to report to Marketing, and a + few instances of natural attrition as their friends launched start-ups + they wanted in on. But those people weren't replaced. The engineers + realized that senior management did not value them, and that they'd + never get the resources to turn their prototype build farm into a real + sustainable production system, not when those dollars could go to + cold-call salesman selling shares in the prototype. + + Timesys had been expanding engineering when I came onboard, but a few + months later it had a reorg where the boss who'd hired me (Manas + Saksena) was "promoted into a closet" with nobody reporting to him + anymore. He quit and went to work at Red Hat, where he launched the + Fedora for Arm project (thus eliminating a significant part of TimeSys' + customer base for their ported Fedora versions). His successor (and the + last new hire before the freeze, when Manas was attempting to expand + engineering to keep up with the success of the LinuxLink subscriptions) + was David Mandala. David struggled mightily to keep the department + together and shield us from the insanity of the CEO and marketing head, + but he eventually confronted the CEO with a "do this or the company is + doomed" presentation that the CEO didn't even listen to the first page + of. David resigned and went to work for Ubuntu, where he became the + head of Ubuntu Mobile and Embedded (and later Ubuntu for Arm). + + David's resignation was like a bomb going off in engineering, and + everybody started sending out their resumes. Perhaps a fifth of + engineering had already left (and not been replaced), but now the + floodgates opened and the team of two dozen engineers I'd been hired + into, with a sattelite office in california and telecommuters in New + England and Germany, rapidly collapsed down to a dozen, then a + half-dozen engineers. + + We stopped doing knowledge transfers, and began speculating about a + replacement build system given the now absolute necessity of throwing + the old one out, since we could no longer reproduce it, let alone + maintain it. + +The design of Aboriginal LInux + + I returned to my Firmware Linux + +UNFINISHED AFTER THIS POINT. +-------- + +Buildroot traffic +[64]slowly +[65]strangled uClibc development discussion on the uClibc list until I gave up +and [66]created +a new list and politely kicked the buildroot traffic over there. + + + + +Cake + +Me suggesting new buildroot list: + http://lists.uclibc.org/pipermail/uclibc/2003-November/028342.html + + Instead buildroot set off to reinvent the +wheel, maintaining their repository in + + Debian's repository contained over 45,000 +packages + +BusyBox + + +Mention of FWL relaunch in 2004 + http://landley.livejournal.com/766.html + +---------------------------- + +- tcc spawns qemu +- Busybox maintainership, timesys, relaunch to current version. + + +Busybox maintainership + + When the Firmware Linux project started, busybox applets like sed + and sort weren't powerful enough to handle the "./configure; make; + make install" of packages like binutils or gcc. Busybox was usable + in an embedded router or rescue floppy, but trying to get real work + done with it revealed numerous bugs and limitations. (It hung, it + segfaulted, produced the wrong output, refused to run due to + unrecognized command line options... You name it.) + + So I spent about 3 years improving Busybox (and pestering other + people into improving their bits), and along the way accidentally + become the BusyBox maintainer (at least until the project's + crazy-uncle founder showed up and [67]drove me away again). The + result is that in Firmware Linux, Busybox now functions as an + effective replacement for bzip2, coreutils, diffutils, e2fsprogs, + file, findutils, gawk, grep, inetutils, less, modutils, net-tools, + patch, procps, sed, shadow, sysklogd, sysvinit, tar, util-linux, and + vim. I was in the process of writing a new shell to replace bash + with when I left. + + Firmware Linux stalled while I was BusyBox maintainer (2005-2006) + due to lack of time, and since that ended most of my spare + programming time has gone into launching toybox. But one of the main + goals of toybox is to replace BusyBox in Firmware Linux, so as + toybox matures it'll naturally lead to more of my time spent working + on FWL. + + The server behind this website does not currently run on Firmware + Linux. Making it do so is a TODO item. After that, I'd like to get + it to the point where I can use it on my laptop. :) + + A snapshot of the old website is [68]available here. + + I [69]started playing around with QEMU in november 2005, about the + same time I started keeping a more detailed [70]technical blog on my + own website, and shortly before I [71]went to work for TimeSys. + __________________________________________________________________ + + Copyright 2002, 2011 Rob Landley <rob@landley.net> + +References + + 1. http://landley.net/aboriginal/about.html + 2. http://landley.net/aboriginal/downloads/aboriginal-1.4.4.tar.gz + 3. http://landley.net/aboriginal/bin + 4. https://github.com/landley/aboriginal + 5. https://github.com/landley/aboriginal/commits/master.atom + 6. https://github.com/landley/aboriginal/archive/master.tar.gz + 7. http://lists.landley.net/listinfo.cgi/aboriginal-landley.net + 8. http://landley.net/aboriginal/news.html + 9. http://landley.net/aboriginal/about.html + 10. http://landley.net/aboriginal/README + 11. http://landley.net/aboriginal/build-stages.html + 12. http://landley.net/aboriginal/downloads/binaries + 13. http://landley.net/aboriginal/screenshots + 14. http://landley.net/aboriginal/FAQ.html + 15. https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu + 16. http://landley.net/aboriginal/downloads/presentation.pdf + 17. http://landley.net/aboriginal/presentation.html + 18. http://landley.net/aboriginal/downloads + 19. http://landley.net/aboriginal/downloads/binaries + 20. http://landley.net/aboriginal/downloads/old/binaries + 21. http://lists.landley.net/listinfo.cgi/aboriginal-landley.net + 22. http://landley.net/notes.html + 23. https://github.com/landley/aboriginal + 24. https://github.com/landley/aboriginal/archive/master.tar.gz + 25. https://github.com/landley/aboriginal/commits/master.atom + 26. https://github.com/landley/aboriginal/tags.atom + 27. http://landley.net/aboriginal/control-images + 28. http://tldp.org/HOWTO/Bootdisk-HOWTO/index.html + 29. http://www.toms.net/rb/ + 30. http://dvpn.sf.net/ + 31. http://landley.net/aboriginal/old + 32. http://landley.livejournal.com/766.html + 33. http://uclibc.org/lists/uclibc/2002-September/004380.html + 34. http://archive.linuxfromscratch.org/lfs-museum/5.0/LFS-BOOK-5.0-HTML/chapter06/sed.html + 35. http://archive.linuxfromscratch.org/lfs-museum/5.0/LFS-BOOK-5.0-HTML/chapter06/gzip.html + 36. http://lkml.indiana.edu/hypermail/linux/kernel/0510.3/1732.html + 37. http://lists.busybox.net/pipermail/busybox/2005-December/051458.html + 38. http://www.uclibc.org/lists/uclibc/2003-August/006795.html + 39. http://lists.uclibc.org/pipermail/uclibc/2003-September/027714.html + 40. http://www.uclibc.org/lists/uclibc/2003-September/006875.html + 41. http://lists.uclibc.org/pipermail/uclibc/2003-August/027643.html + 42. http://landley.net/writing/docs/UML.html + 43. http://landley.livejournal.com/10201.html + 44. http://landley.livejournal.com/2005/01/21/ + 45. http://landley.livejournal.com/12578.html + 46. http://landley.net/writing/docs/UML.html + 47. http://www.uclibc.org/lists/uclibc/2003-August/006674.html + 48. http://lists.uclibc.org/pipermail/uclibc/2003-August/027542.html + 49. http://lists.uclibc.org/pipermail/uclibc/2003-August/027559.html + 50. http://lists.uclibc.org/pipermail/uclibc/2003-August/027558.html + 51. http://lists.uclibc.org/pipermail/uclibc/2003-November/028413.html + 52. http://lists.uclibc.org/pipermail/uclibc/2003-November/028389.html + 53. http://lists.uclibc.org/pipermail/uclibc/2003-December/028610.html + 54. http://lists.uclibc.org/pipermail/uclibc/2003-August/027567.html + 55. http://lists.uclibc.org/pipermail/uclibc/2003-November/028364.html + 56. http://bellard.org/tcc/tccboot.html + 57. http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html + 58. http://www.winehq.org/pipermail/wine-devel/2003-March/015577.html + 59. http://landley.net/notes-2005.html#27-10-2005 + 60. http://landley.livejournal.com/22566.html + 61. http://landley.net/pictures/uclibc-cake-2005-1.jpg + 62. http://landley.net/pictures/uclibc-cake-2005-2.jpg + 63. http://lists.busybox.net/pipermail/uclibc/2006-July/016032.html + 64. http://lists.uclibc.org/pipermail/uclibc/2003-November/028342.html + 65. http://lists.uclibc.org/pipermail/uclibc/2005-October/033720.html + 66. http://lists.uclibc.org/pipermail/uclibc/2006-July/036836.html + 67. http://lwn.net/Articles/202106/ + 68. http://landley.net/aboriginal/old + 69. http://landley.livejournal.com/22566.html + 70. http://landley.net/notes-2005.html + 71. http://landley.livejournal.com/24021.html diff --git a/docs/patraulea.com_nbd-http.txt b/docs/patraulea.com_nbd-http.txt new file mode 100644 index 0000000..c930c36 --- /dev/null +++ b/docs/patraulea.com_nbd-http.txt @@ -0,0 +1,22 @@ + If you have NBD support enabled in your kernel, you can use this + to read a file over HTTP as a block device. The most obvious use + for me was (is) to mount ISO images without having to download + them entirely. If your linux distribution installer allows early + console access, you should be able to even install the OS from + a CD ISO over HTTP. + Sources are available [1]here. + To use it, compile (you need kernel headers and pthreads + installed), load the kernel module and run nbd-http: + make + modprobe nbd + ./nbd-http /dev/nbd0 http://mirror.org/file.iso + (and in another console:) + mount /dev/nbd0 /mnt/cdrom + Due to the nbd driver using the userland process to make block + requests, there is apparently no other way to stop the nbd + userland helper other than ``killlal -9 nbd-http''. + Feedback is welcome at reverse(moc.liamg@cojrah) - Harjoc Bogdan. + +References + + 1. https://patraulea.com/nbd-http/src/ diff --git a/docs/ptspts.blogspot.com_2009_11_tiny-self-contained-c-compiler-using.txt b/docs/ptspts.blogspot.com_2009_11_tiny-self-contained-c-compiler-using.txt new file mode 100644 index 0000000..5105d16 --- /dev/null +++ b/docs/ptspts.blogspot.com_2009_11_tiny-self-contained-c-compiler-using.txt @@ -0,0 +1,567 @@ + #[1]pts.blog - Atom [2]pts.blog - RSS [3]pts.blog - Atom + +[4]pts.blog + +Flattr this blog + +Blog Archive + + * [5]|> [6]2021 (1) + + [7]|> [8]October (1) + + * [9]|> [10]2020 (3) + + [11]|> [12]December (1) + + [13]|> [14]April (2) + + * [15]|> [16]2019 (2) + + [17]|> [18]February (2) + + * [19]|> [20]2018 (5) + + [21]|> [22]June (1) + + [23]|> [24]April (4) + + * [25]|> [26]2017 (6) + + [27]|> [28]December (1) + + [29]|> [30]October (1) + + [31]|> [32]September (1) + + [33]|> [34]February (3) + + * [35]|> [36]2016 (8) + + [37]|> [38]November (1) + + [39]|> [40]July (1) + + [41]|> [42]June (1) + + [43]|> [44]May (1) + + [45]|> [46]April (1) + + [47]|> [48]March (1) + + [49]|> [50]February (1) + + [51]|> [52]January (1) + + * [53]|> [54]2015 (5) + + [55]|> [56]December (1) + + [57]|> [58]November (1) + + [59]|> [60]March (2) + + [61]|> [62]February (1) + + * [63]|> [64]2014 (22) + + [65]|> [66]October (2) + + [67]|> [68]September (3) + + [69]|> [70]August (2) + + [71]|> [72]July (3) + + [73]|> [74]June (2) + + [75]|> [76]April (3) + + [77]|> [78]January (7) + + * [79]|> [80]2013 (24) + + [81]|> [82]December (9) + + [83]|> [84]November (2) + + [85]|> [86]October (3) + + [87]|> [88]August (5) + + [89]|> [90]May (1) + + [91]|> [92]April (2) + + [93]|> [94]March (1) + + [95]|> [96]February (1) + + * [97]|> [98]2012 (21) + + [99]|> [100]December (2) + + [101]|> [102]November (5) + + [103]|> [104]September (2) + + [105]|> [106]August (2) + + [107]|> [108]June (2) + + [109]|> [110]April (2) + + [111]|> [112]March (2) + + [113]|> [114]February (1) + + [115]|> [116]January (3) + + * [117]|> [118]2011 (30) + + [119]|> [120]December (2) + + [121]|> [122]November (3) + + [123]|> [124]October (5) + + [125]|> [126]September (1) + + [127]|> [128]August (6) + + [129]|> [130]June (3) + + [131]|> [132]May (1) + + [133]|> [134]April (3) + + [135]|> [136]March (1) + + [137]|> [138]February (2) + + [139]|> [140]January (3) + + * [141]|> [142]2010 (49) + + [143]|> [144]December (6) + + [145]|> [146]November (6) + + [147]|> [148]October (3) + + [149]|> [150]September (1) + + [151]|> [152]August (4) + + [153]|> [154]July (3) + + [155]|> [156]June (10) + + [157]|> [158]May (2) + + [159]|> [160]April (2) + + [161]|> [162]March (3) + + [163]|> [164]February (4) + + [165]|> [166]January (5) + + * [167]v [168]2009 (53) + + [169]|> [170]December (5) + + [171]v [172]November (9) + o [173]How fast does 8g in Google Go compile? + o [174]How to write a program with multiple packages in + G... + o [175]FUSE protocol tutorial for Linux 2.6 + o [176]Buffered IO speed test of Google Go + o [177]How to read a whole file to String in Java + o [178]How to convert a Unix timestamp to a civil date + o [179]AES encpytion in Python using C extensions + o [180]How to use \showhyphens with beamer + o [181]Tiny, self-contained C compiler using TCC + uClibc + + [182]|> [183]October (7) + + [184]|> [185]September (4) + + [186]|> [187]August (4) + + [188]|> [189]July (3) + + [190]|> [191]June (6) + + [192]|> [193]May (6) + + [194]|> [195]April (5) + + [196]|> [197]March (4) + + * [198]|> [199]2008 (1) + + [200]|> [201]September (1) + +Recommended + + * [javascript] + [202]IO Digital Sec + 1 year ago + +2009-11-01 + +Tiny, self-contained C compiler using TCC + uClibc + + This post presents how I played with a small C compiler and a small + libc on Linux. I've combined TCC (the [203]Tiny C Compiler) 0.9.25 and + [204]uClibc 0.9.26, compressed with [205]UPX 3.03 to a tiny, + self-contained C compiler for Linux i386. You don't need any external + files (apart from the compiler executable) to compile (or interpret) C + code, and the compiled executable will be self-contained as well. + + Here is how to download and use it for compilation on a Linux x86 or + x86_64 system: +$ uname +Linux +$ wget -O pts-tcc https://raw.githubusercontent.com/pts/pts-tcc/master/pts-tcc-0 +.9.26-uclibc-0.9.30.1 +$ chmod +x pts-tcc +$ ls -l pts-tcc +-rwxrwxr-- 1 pts pts 349640 Nov 1 13:07 pts-tcc +$ wget -O example1.c https://raw.githubusercontent.com/pts/pts-tcc/master/pts-tc +c/example1.c +$ cat example1.c +#! ./pts-tcc -run +int printf(char const*fmt, ...); +double sqrt(double x); +int main() { + printf("Hello, World!\n"); + return sqrt(36) * 7; +} +$ ./pts-tcc example1.c +$ file a.out +a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically link +ed, not stripped +$ ls -l a.out +-rwxrwxr-x 1 pts pts 17124 Nov 1 13:17 a.out +$ ./a.out; echo "$?" +Hello, World! +42 +$ strace -e open ./pts-tcc example1.c +open("/proc/self/mem", O_RDONLY) = 3 +open("/proc/self/mem", O_RDONLY) = 3 +open("example1.c", O_RDONLY) = 3 +open("/proc/self/mem", O_RDONLY) = 3 +open("/proc/self/mem", O_RDONLY) = 3 +open("a.out", O_WRONLY|O_CREAT|O_TRUNC, 0777) = 3 +$ strace ./a.out +execve("./a.out", ["./a.out"], [/* 47 vars */]) = 0 +ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 +ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 +write(1, "Hello, World!\n", 14Hello, World! +) = 14 +_exit(42) = ? + + As you can see above, my version the compiler is less than 250k in + size, and it doesn't need any library files (such as libc.so) for + compilation (as indicated by the strace output above), and the compiled + binary doesn't need library files either. + + TCC can run the C program without creating any binaries: +$ rm -f a.out +$ ./pts-tcc -run example1.c; echo "$?" +Hello, World! +42 +$ head -1 example1.c +#! ./pts-tcc -run +$ chmod +x example1.c +$ ./example1.c; echo "$?" +Hello, World! + + TCC is a very fast compiler (see the speed comparisons on it web site), + it is versatile (it can compile the Linux kernel), but it doesn't + optimize much: the code it produces is usually larger and slower than + the output of a traditional, optimizing C compiler such as gcc -O2. + + The shell script [206]pts-tcc-0.9.26-compile.sh builds TCC from source, + adding uClibc, and compressing with UPX. + +Update: TCC 0.9.25 and uClibc 0.9.29 (or older) + + Please note that TCC 0.9.25 is buggy, don't use it! +$ wget -O pts-tcc https://raw.githubusercontent.com/pts/pts-tcc/master/pts-tcc/p +ts-tcc-0.9.25 +$ chmod +x pts-tcc +$ ls -l pts-tcc +-rwxr-xr-x 1 pts eng 241728 Apr 8 16:53 pts-tcc + +Update: TCC 0.9.25 and uClibc 0.9.30.1 + + Please note that TCC 0.9.25 is buggy, don't use it! +$ wget -O pts-tcc https://raw.githubusercontent.com/pts/pts-tcc/master/pts-tcc-0 +.9.25-uclibc-0.9.30.1 +$ chmod +x pts-tcc +$ ls -l pts-tcc +-rwxr-xr-x 1 pts eng 336756 Apr 8 16:53 pts-tcc + +Update: TCC 0.9.26 and uClibc 0.9.30.1 + +$ wget -O pts-tcc https://raw.githubusercontent.com/pts/pts-tcc/master/pts-tcc-0 +.9.26-uclibc-0.9.30.1 +$ chmod +x pts-tcc +$ ls -l pts-tcc +-rwxr-xr-x 1 pts eng 349640 Apr 8 16:53 pts-tcc + + Posted by pts at [207]13:06 + +6 comments: + + [208]Porcupine Saul said... + This looks like a cool tool, man. Thanks for sticking it out + there. + + [209]April 2, 2010 at 4:03:00PM GMT+2 [210][icon_delete13.gif] + + [211]Biff said... + I tried unsuccessfully to get this working on a build of + OpenWrt. Not sure what I've done wrong. It would be nice to + understand what configuration I need to do to transfer the + resultant tcc exe to an embedded system and make it work. + See here for the error. + https://forum.openwrt.org/viewtopic.php?id=26000 + + [212]August 6, 2010 at 12:29:00PM GMT+2 [213][icon_delete13.gif] + + [214]Unknown said... + I really really want to get this working, and I have tried many + different things, however I cannot seem to replicate the setup + you have. + When I use your wrapper, I get the following: + + echo 'int printf(char*fmt,...);main(){return + 1>printf("he110\n");}' + + ./i386-uclibc-gcc -static -o test test.c + + ./test + + grep -l he110 test.out + test.out + + ./i386-uclibc-gcc -o test test.c + /usr/bin/ld: cannot find /lib//libc.so.0 + /usr/bin/ld: cannot find /usr/lib//uclibc_nonshared.a + /usr/bin/ld: cannot find /lib//ld-uClibc.so.0 + collect2: ld returned 1 exit status + It seems to work statically, however I have something wrong with + ld, (the double slashes) and I cannot seem to find where in the + script or wrapper (or the proper environment variable) that can + fix this. I should note that I have also build the uclibc + toolchain using buildroot, and have it stored in + /usr/local/uclibc, but I cannot seem to get the uclibc ld to run + instead of the (/usr/bin/ld) one. + Furthermore, by using my compiler instead of the wrapper, I am + able to compile pts-tcc and it displays its help output, however + when trying to use it to compile I get: + user@ubuntu:~/Downloads/Tcc$ ./pts-tcc test.c + tcc: undefined symbol '__uClibc_main' + tcc: undefined symbol 'printf' + So if you could please give a little more details as to how to + set up your environment, and where things need to be located, I + would appreciate it. + Also, if you could tell me what is going on with this perl line: + for F in tcclibc.a "$UCLIBC_USR"/lib/{crt1.o,crti.o,crtn.o}; do + G="${F##*/}" + export NAME="data_${G%.*}" + perl -e '$_=join("",); my$L=length; + s@([^-+/\w])@sprintf"\\%03o",ord$1@ge; print".globl + $ENV{NAME}\n.section .data\n.align 4\n.size + $ENV{NAME},$L\n$ENV{NAME}:\n.string \"$_\\001\"\n"' <"$F" + done >tcc-0.9.25/libcdata.s + Thank you so much, I would really like to get this working. + (On a side note, would there be an binary copy already lying + around, for the i386 architecture?) + + [215]October 29, 2010 at 5:33:00AM GMT+2 + [216][icon_delete13.gif] + + [217]Unknown said... + Oops, found the binary, and it works great. I just cannot figure + out how you did it. + + [218]October 29, 2010 at 5:42:00AM GMT+2 + [219][icon_delete13.gif] + + [220]Darren said... + I -_love_ this - it's solved a big problem for me - trouble is I + just found a bug in tcc*.25, that's fixed in '26. I went to try + to modify your build script, but I don't have all the right + versions of things... any chance of an update? + (thx) + Darren + + [221]April 7, 2013 at 1:00:00PM GMT+2 [222][icon_delete13.gif] + + [223]pts said... + @Darren: I've updated pts-tcc so a version using TCC 0.9.26 is + available. Please see it in the updated blog post. + + [224]April 8, 2013 at 5:04:00PM GMT+2 [225][icon_delete13.gif] + + [226]Post a Comment + [227]Newer Post [228]Older Post [229]Home + Subscribe to: [230]Post Comments (Atom) + +References + + Visible links: + 1. https://ptspts.blogspot.com/feeds/posts/default + 2. https://ptspts.blogspot.com/feeds/posts/default?alt=rss + 3. https://ptspts.blogspot.com/feeds/6808943651025396418/comments/default + 4. https://ptspts.blogspot.com/ + 5. javascript:void(0) + 6. https://ptspts.blogspot.com/2021/ + 7. javascript:void(0) + 8. https://ptspts.blogspot.com/2021/10/ + 9. javascript:void(0) + 10. https://ptspts.blogspot.com/2020/ + 11. javascript:void(0) + 12. https://ptspts.blogspot.com/2020/12/ + 13. javascript:void(0) + 14. https://ptspts.blogspot.com/2020/04/ + 15. javascript:void(0) + 16. https://ptspts.blogspot.com/2019/ + 17. javascript:void(0) + 18. https://ptspts.blogspot.com/2019/02/ + 19. javascript:void(0) + 20. https://ptspts.blogspot.com/2018/ + 21. javascript:void(0) + 22. https://ptspts.blogspot.com/2018/06/ + 23. javascript:void(0) + 24. https://ptspts.blogspot.com/2018/04/ + 25. javascript:void(0) + 26. https://ptspts.blogspot.com/2017/ + 27. javascript:void(0) + 28. https://ptspts.blogspot.com/2017/12/ + 29. javascript:void(0) + 30. https://ptspts.blogspot.com/2017/10/ + 31. javascript:void(0) + 32. https://ptspts.blogspot.com/2017/09/ + 33. javascript:void(0) + 34. https://ptspts.blogspot.com/2017/02/ + 35. javascript:void(0) + 36. https://ptspts.blogspot.com/2016/ + 37. javascript:void(0) + 38. https://ptspts.blogspot.com/2016/11/ + 39. javascript:void(0) + 40. https://ptspts.blogspot.com/2016/07/ + 41. javascript:void(0) + 42. https://ptspts.blogspot.com/2016/06/ + 43. javascript:void(0) + 44. https://ptspts.blogspot.com/2016/05/ + 45. javascript:void(0) + 46. https://ptspts.blogspot.com/2016/04/ + 47. javascript:void(0) + 48. https://ptspts.blogspot.com/2016/03/ + 49. javascript:void(0) + 50. https://ptspts.blogspot.com/2016/02/ + 51. javascript:void(0) + 52. https://ptspts.blogspot.com/2016/01/ + 53. javascript:void(0) + 54. https://ptspts.blogspot.com/2015/ + 55. javascript:void(0) + 56. https://ptspts.blogspot.com/2015/12/ + 57. javascript:void(0) + 58. https://ptspts.blogspot.com/2015/11/ + 59. javascript:void(0) + 60. https://ptspts.blogspot.com/2015/03/ + 61. javascript:void(0) + 62. https://ptspts.blogspot.com/2015/02/ + 63. javascript:void(0) + 64. https://ptspts.blogspot.com/2014/ + 65. javascript:void(0) + 66. https://ptspts.blogspot.com/2014/10/ + 67. javascript:void(0) + 68. https://ptspts.blogspot.com/2014/09/ + 69. javascript:void(0) + 70. https://ptspts.blogspot.com/2014/08/ + 71. javascript:void(0) + 72. https://ptspts.blogspot.com/2014/07/ + 73. javascript:void(0) + 74. https://ptspts.blogspot.com/2014/06/ + 75. javascript:void(0) + 76. https://ptspts.blogspot.com/2014/04/ + 77. javascript:void(0) + 78. https://ptspts.blogspot.com/2014/01/ + 79. javascript:void(0) + 80. https://ptspts.blogspot.com/2013/ + 81. javascript:void(0) + 82. https://ptspts.blogspot.com/2013/12/ + 83. javascript:void(0) + 84. https://ptspts.blogspot.com/2013/11/ + 85. javascript:void(0) + 86. https://ptspts.blogspot.com/2013/10/ + 87. javascript:void(0) + 88. https://ptspts.blogspot.com/2013/08/ + 89. javascript:void(0) + 90. https://ptspts.blogspot.com/2013/05/ + 91. javascript:void(0) + 92. https://ptspts.blogspot.com/2013/04/ + 93. javascript:void(0) + 94. https://ptspts.blogspot.com/2013/03/ + 95. javascript:void(0) + 96. https://ptspts.blogspot.com/2013/02/ + 97. javascript:void(0) + 98. https://ptspts.blogspot.com/2012/ + 99. javascript:void(0) + 100. https://ptspts.blogspot.com/2012/12/ + 101. javascript:void(0) + 102. https://ptspts.blogspot.com/2012/11/ + 103. javascript:void(0) + 104. https://ptspts.blogspot.com/2012/09/ + 105. javascript:void(0) + 106. https://ptspts.blogspot.com/2012/08/ + 107. javascript:void(0) + 108. https://ptspts.blogspot.com/2012/06/ + 109. javascript:void(0) + 110. https://ptspts.blogspot.com/2012/04/ + 111. javascript:void(0) + 112. https://ptspts.blogspot.com/2012/03/ + 113. javascript:void(0) + 114. https://ptspts.blogspot.com/2012/02/ + 115. javascript:void(0) + 116. https://ptspts.blogspot.com/2012/01/ + 117. javascript:void(0) + 118. https://ptspts.blogspot.com/2011/ + 119. javascript:void(0) + 120. https://ptspts.blogspot.com/2011/12/ + 121. javascript:void(0) + 122. https://ptspts.blogspot.com/2011/11/ + 123. javascript:void(0) + 124. https://ptspts.blogspot.com/2011/10/ + 125. javascript:void(0) + 126. https://ptspts.blogspot.com/2011/09/ + 127. javascript:void(0) + 128. https://ptspts.blogspot.com/2011/08/ + 129. javascript:void(0) + 130. https://ptspts.blogspot.com/2011/06/ + 131. javascript:void(0) + 132. https://ptspts.blogspot.com/2011/05/ + 133. javascript:void(0) + 134. https://ptspts.blogspot.com/2011/04/ + 135. javascript:void(0) + 136. https://ptspts.blogspot.com/2011/03/ + 137. javascript:void(0) + 138. https://ptspts.blogspot.com/2011/02/ + 139. javascript:void(0) + 140. https://ptspts.blogspot.com/2011/01/ + 141. javascript:void(0) + 142. https://ptspts.blogspot.com/2010/ + 143. javascript:void(0) + 144. https://ptspts.blogspot.com/2010/12/ + 145. javascript:void(0) + 146. https://ptspts.blogspot.com/2010/11/ + 147. javascript:void(0) + 148. https://ptspts.blogspot.com/2010/10/ + 149. javascript:void(0) + 150. https://ptspts.blogspot.com/2010/09/ + 151. javascript:void(0) + 152. https://ptspts.blogspot.com/2010/08/ + 153. javascript:void(0) + 154. https://ptspts.blogspot.com/2010/07/ + 155. javascript:void(0) + 156. https://ptspts.blogspot.com/2010/06/ + 157. javascript:void(0) + 158. https://ptspts.blogspot.com/2010/05/ + 159. javascript:void(0) + 160. https://ptspts.blogspot.com/2010/04/ + 161. javascript:void(0) + 162. https://ptspts.blogspot.com/2010/03/ + 163. javascript:void(0) + 164. https://ptspts.blogspot.com/2010/02/ + 165. javascript:void(0) + 166. https://ptspts.blogspot.com/2010/01/ + 167. javascript:void(0) + 168. https://ptspts.blogspot.com/2009/ + 169. javascript:void(0) + 170. https://ptspts.blogspot.com/2009/12/ + 171. javascript:void(0) + 172. https://ptspts.blogspot.com/2009/11/ + 173. https://ptspts.blogspot.com/2009/11/how-fast-does-8g-in-google-go-compile.html + 174. https://ptspts.blogspot.com/2009/11/how-to-write-program-with-multiple.html + 175. https://ptspts.blogspot.com/2009/11/fuse-protocol-tutorial-for-linux-26.html + 176. https://ptspts.blogspot.com/2009/11/buffered-io-speed-test-of-google-go.html + 177. https://ptspts.blogspot.com/2009/11/how-to-read-whole-file-to-string-in.html + 178. https://ptspts.blogspot.com/2009/11/how-to-convert-unix-timestamp-to-civil.html + 179. https://ptspts.blogspot.com/2009/11/aes-encpytion-in-python-using-c.html + 180. https://ptspts.blogspot.com/2009/11/how-to-use-showhyphens-with-beamer.html + 181. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html + 182. javascript:void(0) + 183. https://ptspts.blogspot.com/2009/10/ + 184. javascript:void(0) + 185. https://ptspts.blogspot.com/2009/09/ + 186. javascript:void(0) + 187. https://ptspts.blogspot.com/2009/08/ + 188. javascript:void(0) + 189. https://ptspts.blogspot.com/2009/07/ + 190. javascript:void(0) + 191. https://ptspts.blogspot.com/2009/06/ + 192. javascript:void(0) + 193. https://ptspts.blogspot.com/2009/05/ + 194. javascript:void(0) + 195. https://ptspts.blogspot.com/2009/04/ + 196. javascript:void(0) + 197. https://ptspts.blogspot.com/2009/03/ + 198. javascript:void(0) + 199. https://ptspts.blogspot.com/2008/ + 200. javascript:void(0) + 201. https://ptspts.blogspot.com/2008/09/ + 202. https://iodigitalsec.com/ + 203. http://bellard.org/tcc/ + 204. http://www.uclibc.org/ + 205. http://upx.sourceforge.net/ + 206. https://github.com/pts/pts-tcc/blob/master/pts-tcc-0.9.26-compile.sh + 207. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html + 208. https://www.blogger.com/profile/13523835355464525279 + 209. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1270216996272#c1780721860826453864 + 210. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=1780721860826453864 + 211. https://www.blogger.com/profile/14344647540020869827 + 212. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1281090567095#c6665460077644589152 + 213. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=6665460077644589152 + 214. https://www.blogger.com/profile/16368219482343702957 + 215. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1288323202749#c5065061273223465540 + 216. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=5065061273223465540 + 217. https://www.blogger.com/profile/16368219482343702957 + 218. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1288323742923#c8312086593726964224 + 219. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=8312086593726964224 + 220. https://www.blogger.com/profile/15410121341266501317 + 221. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1365332400683#c2984614004162073806 + 222. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=2984614004162073806 + 223. https://www.blogger.com/profile/00909092426117039110 + 224. https://ptspts.blogspot.com/2009/11/tiny-self-contained-c-compiler-using.html?showComment=1365433441521#c8060845628300786053 + 225. https://www.blogger.com/delete-comment.g?blogID=8821846818714029393&postID=8060845628300786053 + 226. https://www.blogger.com/comment.g?blogID=8821846818714029393&postID=6808943651025396418 + 227. https://ptspts.blogspot.com/2009/11/how-to-use-showhyphens-with-beamer.html + 228. https://ptspts.blogspot.com/2009/10/how-to-enable-autologin-in-ubuntu.html + 229. https://ptspts.blogspot.com/ + 230. https://ptspts.blogspot.com/feeds/6808943651025396418/comments/default + + Hidden links: + 232. https://www.blogger.com/post-edit.g?blogID=8821846818714029393&postID=6808943651025396418&from=pencil diff --git a/docs/raw.githubusercontent.com_Angstrom-distribution_meta-linaro_master_recipes-core_auto-serial-console_auto-serial-console_auto-getty.txt b/docs/raw.githubusercontent.com_Angstrom-distribution_meta-linaro_master_recipes-core_auto-serial-console_auto-serial-console_auto-getty.txt new file mode 100644 index 0000000..f376619 --- /dev/null +++ b/docs/raw.githubusercontent.com_Angstrom-distribution_meta-linaro_master_recipes-core_auto-serial-console_auto-serial-console_auto-getty.txt @@ -0,0 +1,37 @@ +#!/bin/sh -e + +[ -f /etc/default/autogetty ] && . /etc/default/autogetty + +[ 1 -gt $ENABLED ] && exit + +while true; do + for arg in $(cat /proc/cmdline); do + case $arg in + console=*) + tty=${arg#console=} + tty=${tty#/dev/} + + case $tty in + tty[a-zA-Z]* ) + PORT=${tty%%,*} + + tmp=${tty##$PORT,} + SPEED=${tmp%%n*} + + # if console=/dev/tty* without speed is given + [ $SPEED = $PORT ] && SPEED=115200 + BITS=${tmp##${SPEED}n} + + # 8bit serial is default + [ -z $BITS ] && BITS=8 + # [ 8 -eq $BITS ] && GETTY_ARGS="$GETTY_ARGS -8 " + + [ -z $SPEED ] && SPEED='115200,57600,38400,19200,9600' + + GETTY_ARGS="$AUTOGETTY_ARGS $GETTY_ARGS $SPEED $PORT" + /sbin/getty $GETTY_ARGS + esac + esac + done +done + diff --git a/docs/stackoverflow.com_questions_27941775_what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de.txt b/docs/stackoverflow.com_questions_27941775_what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de.txt new file mode 100644 index 0000000..4f4dd31 --- /dev/null +++ b/docs/stackoverflow.com_questions_27941775_what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de.txt @@ -0,0 +1,668 @@ + #[1]Stack Overflow [2]Feed for question 'What is the minimum amount of + RAM required to run Linux kernel on an Embedded device?' + + [3]Stack Overflow + 1. [4]About + 2. [5]Products + 3. [6]For Teams + + 1. [7]Stack Overflow Public questions & answers + 2. [8]Stack Overflow for Teams Where developers & technologists share + private knowledge with coworkers + 3. [9]Talent Build your employer brand + 4. [10]Advertising Reach developers & technologists worldwide + 5. [11]Labs The future of collective knowledge sharing + 6. [12]About the company + + ____________________ + Loading... + + 1. + +[13]current community + (BUTTON) + + Stack Overflow + [14]help [15]chat + + Meta Stack Overflow + +your communities + [16]Sign up or [17]log in to customize your list. + +[18]more stack exchange communities + [19]company blog + 2. (BUTTON) + 3. [20]Log in + 4. [21]Sign up + + 1. + 1. [22]Home + 2. [23]Questions + 3. [24]Tags + 4. + 5. [25]Users + 6. [26]Companies + 7. Collectives + 8. [27]Explore Collectives + 9. Labs + 10. [28]Discussions + 2. Teams + Stack Overflow for Teams - Start collaborating and sharing + organizational knowledge. [29]Create a free Team [30]Why Teams? + 3. Teams + 4. Create free Team + +Collectives(TM) on Stack Overflow + + Find centralized, trusted content and collaborate around the + technologies you use most. + [31]Learn more about Collectives + + Teams + + Q&A for work + + Connect and share knowledge within a single location that is structured + and easy to search. + [32]Learn more about Teams + + Get early access and see previews of new features. + [33]Learn more about Labs + +[34]What is the minimum amount of RAM required to run Linux kernel on an +Embedded device? + + [35]Ask Question + Asked 9 years ago + Modified [36]12 months ago + Viewed 23k times + (BUTTON) + 14 + (BUTTON) (BUTTON) + + What is the minimum amount of RAM required to run Linux kernel on an + Embedded device? In Linux-0.11 for 80x86, the minimum RAM required was + 2MB to load the kernel data structures and interrupt vectors. + + How much is the minimum needed RAM for present Linux-3.18 kernel? Does + different architectures like x86 and ARM have different requirements + for minimum RAM required for booting? How does one calculates the same? + * [37]linux-kernel + * [38]embedded + * [39]kernel + * [40]linux-device-driver + * [41]embedded-linux + + [42]Share + [43]Improve this question + (BUTTON) Follow + asked Jan 14, 2015 at 11:24 + manav m-n's user avatar + [44]manav m-nmanav m-n + 11.2k2323 gold badges7575 silver badges9898 bronze badges + 5 + * What are you trying to achieve? Depending on the device you're + trying to squeeze Linux onto I'd imagine you might be able to shunt + most of it off into (FLASH) ROM. + - [45]doynax + Jan 14, 2015 at 11:37 + * @doynax: i am trying to port linux on an embedded device with + limited RAM. The flash is read-only. + - [46]manav m-n + Jan 14, 2015 at 12:00 + * 1 + Your question is too vague. Many Linux kernel features can be + omitted if not needed, and consequently reduce the memory + footprint. The types of daemons required and the applications will + also dictate memory requirements. The processor architecture and + instruction set impact memory requirements (e.g. for ARM the kernel + can be compiled in Thumb mode, 16-bit, instructions to reduce + kernel size). + - [47]sawdust + Jan 14, 2015 at 18:51 + * Not only is it rather subjective; it is also temporal. The values + will change over time; no one will care about 3.18 eventually. + Also, a minimal configuration may not do what you want. <1MB is + definitely possible with some Linux versions and configurations. + For instance, you can remove procfs and/or sysfs, but most Linux + user space programs may not work. Minimal might be no network, no + sound, no mm, only initramfs and a console driver (maybe). + - [48]artless noise + Jan 15, 2015 at 20:13 + * QEMU + buildroot 2017.02 x86_64 goes down to about 32MiB. Likely + anything smaller will require patches / be insane. + - [49]Ciro Santilli OurBigBook.com + Jun 11, 2017 at 14:42 + + [50]Add a comment | + +3 Answers 3 + + Sorted by: [51]Reset to default + [Highest score (default)___________] + (BUTTON) + 13 + (BUTTON) (BUTTON) + + It's possible to shrink it down to ~600 KiB. Check the work done by Tom + Zanussi from Intel. [52]Presentation from Tom and [53]Wiki page about + the topic. + + UPDATE. Tom published interesting [54]statistics about memory use by + different subsystems in the kernel. He did research during that time + when he was working on the project. + + Yet another interesting project is [55]Gray486linux. + [56]Share + [57]Improve this answer + (BUTTON) Follow + [58]edited Jan 16, 2023 at 13:31 + answered Jan 14, 2015 at 18:58 + 0andriy's user avatar + [59]0andriy0andriy + 4,31622 gold badges2424 silver badges3838 bronze badges + 4 + * 1 + I cannot see in either of those links anything to suggest 600KiB. + Can you be more specific? Is that kernel image size of run-time RAM + footprint? [60]This presentation shows stages to decreasing a + distribution each increasingly smaller down to 1.6Mb, but at which + point it is probably so crippled that it hardly becomes worth it - + so it boots then what can you do with it!? + - [61]Clifford + Jan 14, 2015 at 21:36 + * 1.6M is a RAM size of the system, besides kernel you have to have + RAM for other stuff, like init and / or shell. So, 600KiB is a RAM + footprint of the kernel. But be aware that some stuff you have to + compile in into user space programs like TCP/IP, IIRC. + - [62]0andriy + Jan 15, 2015 at 17:32 + * [63]Linux on 8-bit uC + - [64]manav m-n + Jan 19, 2015 at 7:40 + * 1 + @Manav, yes, I know that one, but it doesn't sound like a + production-ready solution :-) + - [65]0andriy + Jan 19, 2015 at 8:34 + + [66]Add a comment | + (BUTTON) + 4 + (BUTTON) (BUTTON) + + [67]This site suggests: + + A minimal uClinux configuration could be run from 4MB RAM, although + the recommendation we are giving to our customers is that they + should design in at least 16 MB's worth of RAM. + + If you are using SDRAM, the problem would be getting a part any smaller + than 16Mb at reasonable volume cost and availability, so maybe it is a + non-problem? For SRAM however, that is a large and relatively expensive + part. + + eLinux.org has a [68]lot of information on embedded kernel size, how to + determine it, and how to minimise it. + [69]Share + [70]Improve this answer + (BUTTON) Follow + answered Jan 14, 2015 at 21:21 + Clifford's user avatar + [71]CliffordClifford + 90.1k1313 gold badges8888 silver badges165165 bronze badges + 1 + * From the above provided link: The size of a bootable uClinux image, + with integrated initramfs, worthy of the functionality capable of + running from 16 MB of RAM would be in the 2-3 MB ballpark. What is + the size of the uClinux kernel when it is uncompressed? + - [72]manav m-n + Jan 15, 2015 at 6:46 + + [73]Add a comment | + (BUTTON) + 2 + (BUTTON) (BUTTON) + + It depends how you define Linux. If you ask for current operating + systems then we are talking about way above 100MByte, better 1000MByte + of memory. + + If we are talking about "Linux from Scratch" then we are also talking + about how much pain you are willing to suffer. In the mid-1990 I build + a Linux system by compiling every binary myself and made it run on a + 386sx16, 1,5MByte of memory. While it had a 40MByte harddrive it was + mostly empty. I compiled my own Kernel 1.0.9, my own libc5, my own base + tools, SVGAlib. That system was somewhat useable for using textmode and + SVGAlib applications. Increasing the memory to 2MByte did help a lot. + And believe me, the system was extremely bare. Today all components + need at least twice the memory but then there is also ulibc instead of + libc and busybox. + + At 8MByte of memory I can create a very basic system today from + scratch. At 512MByte of memory you might have a somewhat modern looking + but slow desktop system. + [74]Share + [75]Improve this answer + (BUTTON) Follow + answered Jun 26, 2021 at 19:57 + Crass Spektakel's user avatar + [76]Crass SpektakelCrass Spektakel + 3111 bronze badge + + [77]Add a comment | + +Your Answer + + Reminder: Answers generated by artificial intelligence tools are not + allowed on Stack Overflow. [78]Learn more + (BUTTON) + + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + + Thanks for contributing an answer to Stack Overflow! + * Please be sure to answer the question. Provide details and share + your research! + + But avoid ... + * Asking for help, clarification, or responding to other answers. + * Making statements based on opinion; back them up with references or + personal experience. + + To learn more, see our [79]tips on writing great answers. + (BUTTON) + Draft saved + Draft discarded + ____________________ + +Sign up or [80]log in + + Sign up using Google + Sign up using Facebook + Sign up using Email and Password + (BUTTON) Submit + +Post as a guest + + Name + ____________________ + Email + + Required, but never shown + ________________________________________ + +Post as a guest + + Name + ____________________ + Email + + Required, but never shown + ________________________________________ + (BUTTON) Post Your Answer (BUTTON) Discard + + By clicking "Post Your Answer", you agree to our [81]terms of service + and acknowledge you have read our [82]privacy policy. + + Not the answer you're looking for? Browse other questions tagged + * [83]linux-kernel + * [84]embedded + * [85]kernel + * [86]linux-device-driver + * [87]embedded-linux + + or [88]ask your own question. + * The Overflow Blog + * [89]Maximum Glitch: How to break Tetris + * [90]How to build a role-playing video game in 24 hours + * Featured on Meta + * [91]Sites can now request to enable a banner to warn about their + policy on... + * [92]Temporary policy: Generative AI (e.g., ChatGPT) is banned + +Linked + + 2 + [93]Is it a good embedded programming practice to disable an interrupt + in an interrupt? + +Related + + 11 + [94]Minimum configuration to run embedded Linux on an ARM processor? + 1 + [95]Are there any memory restrictions on Linux Kernel Modules? + 52 + [96]How does the linux kernel manage less than 1GB physical memory? + 1 + [97]android 2.2 minimum hardware requirement + 80 + [98]How much memory could vm use + 5 + [99]Linux driver for embedded Linux + 0 + [100]What are the minimum system requirements of Windows Embedded OSs? + 4 + [101]Theoretical embedded linux requirements + 0 + [102]RAM access on linux + 1 + [103]On 32-bit ARM Linux, how 2 GB RAM is addressed + +[104]Hot Network Questions + + * [105]Including an old publication in a CV for a PhD + * [106]Drawing radius for minimal_circle and diagonal for + oriented_bbox in QGIS + * [107]Forgotten Book Title - space sci-fi within solar system + * [108]What was the standard time in the Principality of Lippe? + * [109]Scoot airlines in European Union-Schengen + * [110]Planet orbiting a star orbiting a black hole - can there be + life? + * [111]Cybernetic AIs get hacked, while sentient AGIs are immune? + * [112]Is it insider trading if I bought Boeing puts while I am + inside the wrecked airplane? + * [113]How to justify a racist empire's use of other sentient species + as shock troops? + * [114]I overstayed in Ukraine during Covid. What does this stamp + mean and will it affect getting a Schengen visa? + * [115]Why is it possible to keep an object, say a book, horizontal + while holding its corner? + * [116]How to draw a polygon + * [117]Definition of 'uncle-in-law' + * [118]The 50 moves game + * [119]Is it bad practice to have a "most_recent" boolean column in + addition to a "create_at" timestamp column to track the latest + version of a record? + * [120]Why did my coworker see a "painting-ified" version of my + background image on a Zoom call? + * [121]Why is E(th / (1 - th)) different than E(th) / (1 - E(th))? + * [122]Do Western governments or organizations control the media and + newspapers to censor some news? + * [123]Algorithm needed to find optimum area of 2-dimensional data + set + * [124]I realized I made a huge mistake grading a student's thesis. + Panicking and unsure what to do + * [125]LaTeX tables lines are not connected + * [126]What is exactly the issue with Russia using North Korean + missiles? + * [127]Does this kind of simile have a more precise/specific name? + * [128]How to report the interaction effect in the paper? + + [129]more hot questions + [130]Question feed + +Subscribe to RSS + + Question feed + + To subscribe to this RSS feed, copy and paste this URL into your RSS + reader. + https://stackoverflo + +[131]Stack Overflow + + * [132]Questions + * [133]Help + +[134]Products + + * [135]Teams + * [136]Advertising + * [137]Collectives + * [138]Talent + +[139]Company + + * [140]About + * [141]Press + * [142]Work Here + * [143]Legal + * [144]Privacy Policy + * [145]Terms of Service + * [146]Contact Us + * [147]Cookie Settings + * [148]Cookie Policy + +[149]Stack Exchange Network + + * [150]Technology + * [151]Culture & recreation + * [152]Life & arts + * [153]Science + * [154]Professional + * [155]Business + * [156]API + * [157]Data + + * [158]Blog + * [159]Facebook + * [160]Twitter + * [161]LinkedIn + * [162]Instagram + + Site design / logo © 2024 Stack Exchange Inc; user contributions + licensed under [163]CC BY-SA. rev 2024.1.10.3270 + + Your privacy + + By clicking "Accept all cookies", you agree Stack Exchange can store + cookies on your device and disclose information in accordance with our + [164]Cookie Policy. + (BUTTON) Accept all cookies (BUTTON) Necessary cookies only + (BUTTON) Customize settings + +References + + Visible links: + 1. https://stackoverflow.com/opensearch.xml + 2. https://stackoverflow.com/feeds/question/27941775 + 3. https://stackoverflow.com/ + 4. https://stackoverflow.co/ + 5. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 6. https://stackoverflow.co/teams/ + 7. https://stackoverflow.com/questions + 8. https://stackoverflow.co/teams/ + 9. https://stackoverflow.co/talent/ + 10. https://stackoverflow.co/advertising/ + 11. https://stackoverflow.co/labs/ + 12. https://stackoverflow.co/ + 13. https://stackoverflow.com/ + 14. https://stackoverflow.com/help + 15. https://chat.stackoverflow.com/?tab=site&host=stackoverflow.com + 16. https://stackoverflow.com/users/signup?ssrc=site_switcher&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f27941775%2fwhat-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 17. https://stackoverflow.com/users/login?ssrc=site_switcher&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f27941775%2fwhat-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 18. https://stackexchange.com/sites + 19. https://stackoverflow.blog/ + 20. https://stackoverflow.com/users/login?ssrc=head&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f27941775%2fwhat-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 21. https://stackoverflow.com/users/signup?ssrc=head&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f27941775%2fwhat-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 22. https://stackoverflow.com/ + 23. https://stackoverflow.com/questions + 24. https://stackoverflow.com/tags + 25. https://stackoverflow.com/users + 26. https://stackoverflow.com/jobs/companies?so_medium=stackoverflow&so_source=SiteNav + 27. https://stackoverflow.com/collectives + 28. https://stackoverflow.com/collectives/beta/discussions + 29. https://try.stackoverflow.co/why-teams/?utm_source=so-owned&utm_medium=side-bar&utm_campaign=campaign-38&utm_content=cta + 30. https://stackoverflow.co/teams/ + 31. https://stackoverflow.com/collectives + 32. https://stackoverflow.co/teams/ + 33. https://stackoverflow.co/labs/ + 34. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 35. https://stackoverflow.com/questions/ask + 36. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de?lastactivity + 37. https://stackoverflow.com/questions/tagged/linux-kernel + 38. https://stackoverflow.com/questions/tagged/embedded + 39. https://stackoverflow.com/questions/tagged/kernel + 40. https://stackoverflow.com/questions/tagged/linux-device-driver + 41. https://stackoverflow.com/questions/tagged/embedded-linux + 42. https://stackoverflow.com/q/27941775 + 43. https://stackoverflow.com/posts/27941775/edit + 44. https://stackoverflow.com/users/220386/manav-m-n + 45. https://stackoverflow.com/users/247643/doynax + 46. https://stackoverflow.com/users/220386/manav-m-n + 47. https://stackoverflow.com/users/1599004/sawdust + 48. https://stackoverflow.com/users/1880339/artless-noise + 49. https://stackoverflow.com/users/895245/ciro-santilli-ourbigbook-com + 50. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 51. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de?answertab=scoredesc#tab-top + 52. http://events.linuxfoundation.org/sites/events/files/slides/tom.zanussi-elc2014.pdf + 53. http://elinux.org/Kernel_Size_Reduction_Work + 54. https://lore.kernel.org/linux-serial/1491325150.7125.62.camel@tzanussi-mobl.amr.corp.intel.com/ + 55. https://github.com/marmolak/gray486linux + 56. https://stackoverflow.com/a/27950451 + 57. https://stackoverflow.com/posts/27950451/edit + 58. https://stackoverflow.com/posts/27950451/revisions + 59. https://stackoverflow.com/users/2511795/0andriy + 60. http://elinux.org/images/2/2b/Elce11_hart.pdf + 61. https://stackoverflow.com/users/168986/clifford + 62. https://stackoverflow.com/users/2511795/0andriy + 63. http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit + 64. https://stackoverflow.com/users/220386/manav-m-n + 65. https://stackoverflow.com/users/2511795/0andriy + 66. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 67. http://electronicdesign.com/embedded/practical-advice-running-uclinux-cortex-m3m4 + 68. http://elinux.org/System_Size#Runtime_size_of_kernel + 69. https://stackoverflow.com/a/27952688 + 70. https://stackoverflow.com/posts/27952688/edit + 71. https://stackoverflow.com/users/168986/clifford + 72. https://stackoverflow.com/users/220386/manav-m-n + 73. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 74. https://stackoverflow.com/a/68145842 + 75. https://stackoverflow.com/posts/68145842/edit + 76. https://stackoverflow.com/users/14661062/crass-spektakel + 77. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 78. https://stackoverflow.com/help/ai-policy + 79. https://stackoverflow.com/help/how-to-answer + 80. https://stackoverflow.com/users/login?ssrc=question_page&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f27941775%2fwhat-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de%23new-answer + 81. https://stackoverflow.com/legal/terms-of-service/public + 82. https://stackoverflow.com/legal/privacy-policy + 83. https://stackoverflow.com/questions/tagged/linux-kernel + 84. https://stackoverflow.com/questions/tagged/embedded + 85. https://stackoverflow.com/questions/tagged/kernel + 86. https://stackoverflow.com/questions/tagged/linux-device-driver + 87. https://stackoverflow.com/questions/tagged/embedded-linux + 88. https://stackoverflow.com/questions/ask + 89. https://stackoverflow.blog/2024/01/09/maximum-glitch-how-to-break-tetris/ + 90. https://stackoverflow.blog/2024/01/11/how-to-build-a-role-playing-video-game-in-24-hours/ + 91. https://meta.stackexchange.com/questions/395881/sites-can-now-request-to-enable-a-banner-to-warn-about-their-policy-on-ai-genera + 92. https://meta.stackoverflow.com/questions/421831/temporary-policy-generative-ai-e-g-chatgpt-is-banned + 93. https://stackoverflow.com/questions/34992058/is-it-a-good-embedded-programming-practice-to-disable-an-interrupt-in-an-interru?noredirect=1 + 94. https://stackoverflow.com/questions/1522146/minimum-configuration-to-run-embedded-linux-on-an-arm-processor + 95. https://stackoverflow.com/questions/3394386/are-there-any-memory-restrictions-on-linux-kernel-modules + 96. https://stackoverflow.com/questions/4528568/how-does-the-linux-kernel-manage-less-than-1gb-physical-memory + 97. https://stackoverflow.com/questions/4622052/android-2-2-minimum-hardware-requirement + 98. https://stackoverflow.com/questions/11683850/how-much-memory-could-vm-use + 99. https://stackoverflow.com/questions/15911807/linux-driver-for-embedded-linux + 100. https://stackoverflow.com/questions/31805670/what-are-the-minimum-system-requirements-of-windows-embedded-oss + 101. https://stackoverflow.com/questions/33236375/theoretical-embedded-linux-requirements + 102. https://stackoverflow.com/questions/35307264/ram-access-on-linux + 103. https://stackoverflow.com/questions/71075394/on-32-bit-arm-linux-how-2-gb-ram-is-addressed + 104. https://stackexchange.com/questions?tab=hot + 105. https://academia.stackexchange.com/questions/205791/including-an-old-publication-in-a-cv-for-a-phd + 106. https://gis.stackexchange.com/questions/474151/drawing-radius-for-minimal-circle-and-diagonal-for-oriented-bbox-in-qgis + 107. https://scifi.stackexchange.com/questions/283497/forgotten-book-title-space-sci-fi-within-solar-system + 108. https://history.stackexchange.com/questions/74165/what-was-the-standard-time-in-the-principality-of-lippe + 109. https://travel.stackexchange.com/questions/185631/scoot-airlines-in-european-union-schengen + 110. https://worldbuilding.stackexchange.com/questions/253544/planet-orbiting-a-star-orbiting-a-black-hole-can-there-be-life + 111. https://worldbuilding.stackexchange.com/questions/253485/cybernetic-ais-get-hacked-while-sentient-agis-are-immune + 112. https://law.stackexchange.com/questions/98706/is-it-insider-trading-if-i-bought-boeing-puts-while-i-am-inside-the-wrecked-airp + 113. https://worldbuilding.stackexchange.com/questions/253451/how-to-justify-a-racist-empires-use-of-other-sentient-species-as-shock-troops + 114. https://travel.stackexchange.com/questions/185636/i-overstayed-in-ukraine-during-covid-what-does-this-stamp-mean-and-will-it-affe + 115. https://physics.stackexchange.com/questions/796748/why-is-it-possible-to-keep-an-object-say-a-book-horizontal-while-holding-its-c + 116. https://blender.stackexchange.com/questions/309698/how-to-draw-a-polygon + 117. https://english.stackexchange.com/questions/617717/definition-of-uncle-in-law + 118. https://chess.stackexchange.com/questions/43529/the-50-moves-game + 119. https://dba.stackexchange.com/questions/334770/is-it-bad-practice-to-have-a-most-recent-boolean-column-in-addition-to-a-crea + 120. https://superuser.com/questions/1825387/why-did-my-coworker-see-a-painting-ified-version-of-my-background-image-on-a-z + 121. https://stats.stackexchange.com/questions/636701/why-is-e%ce%b8-1-%ce%b8-different-than-e%ce%b8-1-e%ce%b8 + 122. https://politics.stackexchange.com/questions/83937/do-western-governments-or-organizations-control-the-media-and-newspapers-to-cens + 123. https://or.stackexchange.com/questions/11506/algorithm-needed-to-find-optimum-area-of-2-dimensional-data-set + 124. https://academia.stackexchange.com/questions/205787/i-realized-i-made-a-huge-mistake-grading-a-students-thesis-panicking-and-unsur + 125. https://tex.stackexchange.com/questions/706908/latex-tables-lines-are-not-connected + 126. https://politics.stackexchange.com/questions/83893/what-is-exactly-the-issue-with-russia-using-north-korean-missiles + 127. https://linguistics.stackexchange.com/questions/48163/does-this-kind-of-simile-have-a-more-precise-specific-name + 128. https://stats.stackexchange.com/questions/636712/how-to-report-the-interaction-effect-in-the-paper + 129. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 130. https://stackoverflow.com/feeds/question/27941775 + 131. https://stackoverflow.com/ + 132. https://stackoverflow.com/questions + 133. https://stackoverflow.com/help + 134. https://stackoverflow.co/ + 135. https://stackoverflow.co/teams/ + 136. https://stackoverflow.co/advertising/ + 137. https://stackoverflow.co/collectives/ + 138. https://stackoverflow.co/talent/ + 139. https://stackoverflow.co/ + 140. https://stackoverflow.co/ + 141. https://stackoverflow.co/company/press/ + 142. https://stackoverflow.co/company/work-here/ + 143. https://stackoverflow.com/legal + 144. https://stackoverflow.com/legal/privacy-policy + 145. https://stackoverflow.com/legal/terms-of-service/public + 146. https://stackoverflow.co/company/contact/ + 147. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 148. https://stackoverflow.com/legal/cookie-policy + 149. https://stackexchange.com/ + 150. https://stackexchange.com/sites#technology + 151. https://stackexchange.com/sites#culturerecreation + 152. https://stackexchange.com/sites#lifearts + 153. https://stackexchange.com/sites#science + 154. https://stackexchange.com/sites#professional + 155. https://stackexchange.com/sites#business + 156. https://api.stackexchange.com/ + 157. https://data.stackexchange.com/ + 158. https://stackoverflow.blog/?blb=1 + 159. https://www.facebook.com/officialstackoverflow/ + 160. https://twitter.com/stackoverflow + 161. https://linkedin.com/company/stack-overflow + 162. https://www.instagram.com/thestackoverflow + 163. https://stackoverflow.com/help/licensing + 164. https://stackoverflow.com/legal/cookie-policy + + Hidden links: + 166. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 167. https://stackoverflow.com/ + 168. https://meta.stackoverflow.com/ + 169. javascript:void(0) + 170. javascript:void(0) + 171. javascript:void(0) + 172. https://stackoverflowteams.com/teams/create/free/?utm_source=so-owned&utm_medium=side-bar&utm_campaign=campaign-38&utm_content=cta + 173. https://stackoverflow.com/posts/27941775/timeline + 174. https://stackoverflow.com/users/220386/manav-m-n + 175. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 176. https://stackoverflow.com/posts/27950451/timeline + 177. https://stackoverflow.com/users/2511795/0andriy + 178. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 179. https://stackoverflow.com/posts/27952688/timeline + 180. https://stackoverflow.com/users/168986/clifford + 181. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 182. https://stackoverflow.com/posts/68145842/timeline + 183. https://stackoverflow.com/users/14661062/crass-spektakel + 184. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 185. https://stackoverflow.com/q/34992058 + 186. https://stackoverflow.com/q/1522146 + 187. https://stackoverflow.com/q/3394386 + 188. https://stackoverflow.com/q/4528568 + 189. https://stackoverflow.com/q/4622052 + 190. https://stackoverflow.com/q/11683850 + 191. https://stackoverflow.com/q/15911807 + 192. https://stackoverflow.com/q/31805670 + 193. https://stackoverflow.com/q/33236375 + 194. https://stackoverflow.com/q/35307264 + 195. https://stackoverflow.com/q/71075394 + 196. https://stackoverflow.com/questions/27941775/what-is-the-minimum-amount-of-ram-required-to-run-linux-kernel-on-an-embedded-de + 197. https://stackoverflow.com/ diff --git a/docs/stackoverflow.com_questions_4327942_non-buffering-stdin-reading.txt b/docs/stackoverflow.com_questions_4327942_non-buffering-stdin-reading.txt new file mode 100644 index 0000000..2a6bb30 --- /dev/null +++ b/docs/stackoverflow.com_questions_4327942_non-buffering-stdin-reading.txt @@ -0,0 +1,725 @@ + #[1]Stack Overflow [2]Feed for question 'non-buffering stdin reading' + + [3]Stack Overflow + 1. [4]About + 2. [5]Products + 3. [6]For Teams + + 1. [7]Stack Overflow Public questions & answers + 2. [8]Stack Overflow for Teams Where developers & technologists share + private knowledge with coworkers + 3. [9]Talent Build your employer brand + 4. [10]Advertising Reach developers & technologists worldwide + 5. [11]Labs The future of collective knowledge sharing + 6. [12]About the company + + ____________________ + Loading... + + 1. + +[13]current community + (BUTTON) + + Stack Overflow + [14]help [15]chat + + Meta Stack Overflow + +your communities + [16]Sign up or [17]log in to customize your list. + +[18]more stack exchange communities + [19]company blog + 2. (BUTTON) + 3. [20]Log in + 4. [21]Sign up + + 1. + 1. [22]Home + 2. [23]Questions + 3. [24]Tags + 4. + 5. [25]Users + 6. [26]Companies + 7. Collectives + 8. [27]Explore Collectives + 9. Labs + 10. [28]Discussions + 2. Teams + Stack Overflow for Teams - Start collaborating and sharing + organizational knowledge. [29]Create a free Team [30]Why Teams? + 3. Teams + 4. Create free Team + +Collectives(TM) on Stack Overflow + + Find centralized, trusted content and collaborate around the + technologies you use most. + [31]Learn more about Collectives + + Teams + + Q&A for work + + Connect and share knowledge within a single location that is structured + and easy to search. + [32]Learn more about Teams + + Get early access and see previews of new features. + [33]Learn more about Labs + +[34]non-buffering stdin reading + + [35]Ask Question + Asked 13 years, 1 month ago + Modified [36]9 years ago + Viewed 6k times + (BUTTON) + 9 + (BUTTON) (BUTTON) + + My test application is +#include <sys/types.h> +#include <sys/wait.h> +#include <signal.h> +#include <unistd.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <fcntl.h> + +int main(int argc, char *argv[], char *envp[]) { + int fd[2]; + + if(pipe(fd) < 0) { + printf("Can\'t create pipe\n"); + exit(-1); + } + + pid_t fpid = fork(); + if (fpid == 0) { + close(0); + close(fd[1]); + char *s = (char *) malloc(sizeof(char)); + while(1) if (read(fd[0], s, 1)) printf("%i\n", *s); + } + close(fd[0]); + char *c = (char *) malloc(sizeof(char)); + while (1) { + if (read(0, c, 1) > 0) write(fd[1], c, 1); + } + return 0; +} + + I want to see char-code after each entered char. But in fact *s is + printed only after '\n' in the console. So seems like stdin (file with + desc 0) is buffered. But the read function is buffer-less, isn't it? + Where am I wrong. + + UPD: I use linux. + + So the solution is +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <termios.h> + +int main(int argc, char *argv[], char *envp[]) { + int fd[2]; + + if(pipe(fd) < 0) { + printf("Can\'t create pipe\n"); + exit(-1); + } + + struct termios term, term_orig; + + if(tcgetattr(0, &term_orig)) { + printf("tcgetattr failed\n"); + exit(-1); + } + + term = term_orig; + + term.c_lflag &= ~ICANON; + term.c_lflag |= ECHO; + term.c_cc[VMIN] = 0; + term.c_cc[VTIME] = 0; + + if (tcsetattr(0, TCSANOW, &term)) { + printf("tcsetattr failed\n"); + exit(-1); + } + + pid_t fpid = fork(); + if (fpid == 0) { + close(0); + close(fd[1]); + char *s = (char *) malloc(sizeof(char)); + while(1) if (read(fd[0], s, 1)) printf("%i\n", *s); + } + close(fd[0]); + char *c = (char *) malloc(sizeof(char)); + while (1) { + if (read(0, c, 1) > 0) write(fd[1], c, 1); + } + return 0; +} + + * [37]c + * [38]linux + * [39]unix + * [40]posix + + [41]Share + (BUTTON) Follow + [42]edited Dec 1, 2010 at 19:10 + Ximik + asked Dec 1, 2010 at 18:54 + Ximik's user avatar + [43]XimikXimik + 2,45533 gold badges2727 silver badges5353 bronze badges + 2 + * 1 + Note that this has nothing to do with buffering. + - [44]Simon Tóth + Dec 1, 2010 at 19:05 + * Shouldn't the code reset the terminal attributes in the parent to + term_orig before exiting? You should probably also have the child + exit at some point -- it will continually get 0 from read() after + the parent shuts up shop. However, the parent is also in an + infinite loop; the processes only end when signalled. You really + need a signal handler that calls tcsetattr() with the original + terminal values for the main signals you're likely to get (that can + be handled): HUP, INT, QUIT perhaps, PIPE and TERM is a good set. + You can't do anything about KILL or STOP, of course. + - [45]Jonathan Leffler + Jan 19, 2021 at 3:27 + + [46]Add a comment | + +3 Answers 3 + + Sorted by: [47]Reset to default + [Highest score (default)___________] + (BUTTON) + 15 + (BUTTON) (BUTTON) + + Unfortunately, the behavior you're looking for is not possible with + standard ANSI C, and the default mode for UNIX terminal I/O is + line-oriented, which means you will always need an inputted \n + character to retrieve the input. You'll need to use terminal I/O + facilities that let you program in [48]non-canonical mode, so that each + key-press triggers an event. On Linux/UNIX, you can look into the + <termios.h> header, or the [49]ncurses library. + [50]Share + (BUTTON) Follow + [51]edited May 23, 2017 at 10:29 + Community's user avatar + [52]CommunityBot + 111 silver badge + answered Dec 1, 2010 at 18:56 + Charles Salvia's user avatar + [53]Charles SalviaCharles Salvia + 52.6k1414 gold badges130130 silver badges142142 bronze badges + 1 + * 4 + @Ximik, yes and they are not using standard ANSI C. Most use + external libraries such as ncurses or termcap. + - [54]Charles Salvia + Dec 1, 2010 at 18:59 + + [55]Add a comment | + (BUTTON) + 5 + (BUTTON) (BUTTON) + + It seems to me that your solution is a little bit complicated. Still + don't understand why do you need pipe and 2 process. +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <termios.h> + +int main(int argc, char *argv[], char *envp[]) { + struct termios term, term_orig; + + if(tcgetattr(0, &term_orig)) { + printf("tcgetattr failed\n"); + exit(-1); + } + + term = term_orig; + + term.c_lflag &= ~ICANON; + term.c_lflag |= ECHO; + term.c_cc[VMIN] = 0; + term.c_cc[VTIME] = 0; + + if (tcsetattr(0, TCSANOW, &term)) { + printf("tcsetattr failed\n"); + exit(-1); + } + + char ch; + while (1) { + if (read(0, &ch, 1) > 0) + printf(" %d\n", ch); + } + return 0; +} + + [56]Share + (BUTTON) Follow + [57]edited Dec 30, 2014 at 12:56 + answered Dec 30, 2014 at 12:14 + Sam Toliman's user avatar + [58]Sam TolimanSam Toliman + 12311 silver badge55 bronze badges + + [59]Add a comment | + (BUTTON) + 3 + (BUTTON) (BUTTON) + + Unix buffers your tty characters inside the kernel in part so that + programs don't have to individually handle line editing unless they + want to. + + You can instruct the tty driver to give you the bytes immediately. + There are various libraries that make this a bit easier than using the + raw ioctl. You might start with termios(3). + [60]Share + (BUTTON) Follow + answered Dec 1, 2010 at 18:59 + DigitalRoss's user avatar + [61]DigitalRossDigitalRoss + 144k2525 gold badges250250 silver badges330330 bronze badges + 1 + * 3 + And sadly nobody got around to improving this kernel-level line + editing to make it actually usable... In principle it could be + nearly as nice as readline. + - [62]R.. GitHub STOP HELPING ICE + Dec 1, 2010 at 20:46 + + [63]Add a comment | + +Your Answer + + Reminder: Answers generated by artificial intelligence tools are not + allowed on Stack Overflow. [64]Learn more + (BUTTON) + + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + _______________________________________________________________________ + + Thanks for contributing an answer to Stack Overflow! + * Please be sure to answer the question. Provide details and share + your research! + + But avoid ... + * Asking for help, clarification, or responding to other answers. + * Making statements based on opinion; back them up with references or + personal experience. + + To learn more, see our [65]tips on writing great answers. + (BUTTON) + Draft saved + Draft discarded + ____________________ + +Sign up or [66]log in + + Sign up using Google + Sign up using Facebook + Sign up using Email and Password + (BUTTON) Submit + +Post as a guest + + Name + ____________________ + Email + + Required, but never shown + ________________________________________ + +Post as a guest + + Name + ____________________ + Email + + Required, but never shown + ________________________________________ + (BUTTON) Post Your Answer (BUTTON) Discard + + By clicking "Post Your Answer", you agree to our [67]terms of service + and acknowledge you have read our [68]privacy policy. + + Not the answer you're looking for? Browse other questions tagged + * [69]c + * [70]linux + * [71]unix + * [72]posix + + or [73]ask your own question. + * The Overflow Blog + * [74]Maximum Glitch: How to break Tetris + * [75]How to build a role-playing video game in 24 hours + * Featured on Meta + * [76]Sites can now request to enable a banner to warn about their + policy on... + * [77]Temporary policy: Generative AI (e.g., ChatGPT) is banned + +Linked + + 55 + [78]Canonical vs. non-canonical terminal input + 0 + [79]Why does this C code have unexpected behavior + 2 + [80]End while loop when 'Enter' + 2 + [81]How does copying input to output program work? + 0 + [82]Output behaviour of scanf and printf in C (Eclipse Console) + 0 + [83]How would I go about, using the scanner class, taking in one + character and then continuing to display the next random character for + the user to enter? + +Related + + 2 + [84]Reading stdin in C + 6 + [85]Making stdin non-blocking + 18 + [86]read() from stdin + 51 + [87]Reading from stdin + 0 + [88]Linux unbuffered reads from STDIO + 2 + [89]Buffering stdin & stdout + 1 + [90]read() for reading stream from stdin + 1 + [91]Read from stdin and fill buffer until EOF + 1 + [92]Linux stdin buffering + 1 + [93]Pipes in C, buffer for reading stdin + +[94]Hot Network Questions + + * [95]Why was this move a miss? + * [96]Using an op-amp to produce a low-current voltage rail + * [97]The sum of the squares of the diagonals in a polygon + * [98]Do courts declare acts of the legislature unconstitutional? + * [99]Is George a dishwasher? + * [100]Cybernetic AIs get hacked, while sentient AGIs are immune? + * [101]What happened to Jazz in 1980? + * [102]I have an absolute certainty that cannot be refuted + * [103]Seeking an English Equivalent for the Concept of "Evil Eye" + * [104]What commercial airplane broke the sound barrier in 1979? + * [105]Validate a CPF number + * [106]is there a program that automatically convert old printings + into TeX files? + * [107]Including an old publication in a CV for a PhD + * [108]Why did my coworker see a "painting-ified" version of my + background image on a Zoom call? + * [109]Group generated by two irrational plane rotations + * [110]Planet orbiting a star orbiting a black hole - can there be + life? + * [111]Why is it possible to keep an object, say a book, horizontal + while holding its corner? + * [112]Significant Mann Whitney, and significant t-test, but in the + other direction + * [113]What is the lowest tech level that could sustain life on Mars + or the Moon? + * [114]Does wire gauge matter for speaker cable for a home stereo + system? + * [115]Algorithm needed to find optimum area of 2-dimensional data + set + * [116]First fundamental theorem of Calculus continuity not + necessary? + * [117]Find a fraction with the smallest denominator + * [118]Is This a Fake Bank? + + [119]more hot questions + [120]Question feed + +Subscribe to RSS + + Question feed + + To subscribe to this RSS feed, copy and paste this URL into your RSS + reader. + https://stackoverflo + lang-c + +[121]Stack Overflow + + * [122]Questions + * [123]Help + +[124]Products + + * [125]Teams + * [126]Advertising + * [127]Collectives + * [128]Talent + +[129]Company + + * [130]About + * [131]Press + * [132]Work Here + * [133]Legal + * [134]Privacy Policy + * [135]Terms of Service + * [136]Contact Us + * [137]Cookie Settings + * [138]Cookie Policy + +[139]Stack Exchange Network + + * [140]Technology + * [141]Culture & recreation + * [142]Life & arts + * [143]Science + * [144]Professional + * [145]Business + * [146]API + * [147]Data + + * [148]Blog + * [149]Facebook + * [150]Twitter + * [151]LinkedIn + * [152]Instagram + + Site design / logo © 2024 Stack Exchange Inc; user contributions + licensed under [153]CC BY-SA. rev 2024.1.10.3270 + + Your privacy + + By clicking "Accept all cookies", you agree Stack Exchange can store + cookies on your device and disclose information in accordance with our + [154]Cookie Policy. + (BUTTON) Accept all cookies (BUTTON) Necessary cookies only + (BUTTON) Customize settings + +References + + Visible links: + 1. https://stackoverflow.com/opensearch.xml + 2. https://stackoverflow.com/feeds/question/4327942 + 3. https://stackoverflow.com/ + 4. https://stackoverflow.co/ + 5. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 6. https://stackoverflow.co/teams/ + 7. https://stackoverflow.com/questions + 8. https://stackoverflow.co/teams/ + 9. https://stackoverflow.co/talent/ + 10. https://stackoverflow.co/advertising/ + 11. https://stackoverflow.co/labs/ + 12. https://stackoverflow.co/ + 13. https://stackoverflow.com/ + 14. https://stackoverflow.com/help + 15. https://chat.stackoverflow.com/?tab=site&host=stackoverflow.com + 16. https://stackoverflow.com/users/signup?ssrc=site_switcher&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f4327942%2fnon-buffering-stdin-reading + 17. https://stackoverflow.com/users/login?ssrc=site_switcher&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f4327942%2fnon-buffering-stdin-reading + 18. https://stackexchange.com/sites + 19. https://stackoverflow.blog/ + 20. https://stackoverflow.com/users/login?ssrc=head&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f4327942%2fnon-buffering-stdin-reading + 21. https://stackoverflow.com/users/signup?ssrc=head&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f4327942%2fnon-buffering-stdin-reading + 22. https://stackoverflow.com/ + 23. https://stackoverflow.com/questions + 24. https://stackoverflow.com/tags + 25. https://stackoverflow.com/users + 26. https://stackoverflow.com/jobs/companies?so_medium=stackoverflow&so_source=SiteNav + 27. https://stackoverflow.com/collectives + 28. https://stackoverflow.com/collectives/beta/discussions + 29. https://try.stackoverflow.co/why-teams/?utm_source=so-owned&utm_medium=side-bar&utm_campaign=campaign-38&utm_content=cta + 30. https://stackoverflow.co/teams/ + 31. https://stackoverflow.com/collectives + 32. https://stackoverflow.co/teams/ + 33. https://stackoverflow.co/labs/ + 34. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 35. https://stackoverflow.com/questions/ask + 36. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading?lastactivity + 37. https://stackoverflow.com/questions/tagged/c + 38. https://stackoverflow.com/questions/tagged/linux + 39. https://stackoverflow.com/questions/tagged/unix + 40. https://stackoverflow.com/questions/tagged/posix + 41. https://stackoverflow.com/q/4327942 + 42. https://stackoverflow.com/posts/4327942/revisions + 43. https://stackoverflow.com/users/414016/ximik + 44. https://stackoverflow.com/users/211659/%c5%a0imon-t%c3%b3th + 45. https://stackoverflow.com/users/15168/jonathan-leffler + 46. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 47. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading?answertab=scoredesc#tab-top + 48. https://stackoverflow.com/questions/358342/canonical-vs-non-canonical-terminal-input + 49. http://www.gnu.org/software/ncurses/ + 50. https://stackoverflow.com/a/4327964 + 51. https://stackoverflow.com/posts/4327964/revisions + 52. https://stackoverflow.com/users/-1/community + 53. https://stackoverflow.com/users/168288/charles-salvia + 54. https://stackoverflow.com/users/168288/charles-salvia + 55. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 56. https://stackoverflow.com/a/27705297 + 57. https://stackoverflow.com/posts/27705297/revisions + 58. https://stackoverflow.com/users/4177256/sam-toliman + 59. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 60. https://stackoverflow.com/a/4328000 + 61. https://stackoverflow.com/users/140740/digitalross + 62. https://stackoverflow.com/users/379897/r-github-stop-helping-ice + 63. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 64. https://stackoverflow.com/help/ai-policy + 65. https://stackoverflow.com/help/how-to-answer + 66. https://stackoverflow.com/users/login?ssrc=question_page&returnurl=https%3a%2f%2fstackoverflow.com%2fquestions%2f4327942%2fnon-buffering-stdin-reading%23new-answer + 67. https://stackoverflow.com/legal/terms-of-service/public + 68. https://stackoverflow.com/legal/privacy-policy + 69. https://stackoverflow.com/questions/tagged/c + 70. https://stackoverflow.com/questions/tagged/linux + 71. https://stackoverflow.com/questions/tagged/unix + 72. https://stackoverflow.com/questions/tagged/posix + 73. https://stackoverflow.com/questions/ask + 74. https://stackoverflow.blog/2024/01/09/maximum-glitch-how-to-break-tetris/ + 75. https://stackoverflow.blog/2024/01/11/how-to-build-a-role-playing-video-game-in-24-hours/ + 76. https://meta.stackexchange.com/questions/395881/sites-can-now-request-to-enable-a-banner-to-warn-about-their-policy-on-ai-genera + 77. https://meta.stackoverflow.com/questions/421831/temporary-policy-generative-ai-e-g-chatgpt-is-banned + 78. https://stackoverflow.com/questions/358342/canonical-vs-non-canonical-terminal-input?noredirect=1 + 79. https://stackoverflow.com/questions/9635877/why-does-this-c-code-have-unexpected-behavior?noredirect=1 + 80. https://stackoverflow.com/questions/22420665/end-while-loop-when-enter?noredirect=1 + 81. https://stackoverflow.com/questions/19358874/how-does-copying-input-to-output-program-work?noredirect=1 + 82. https://stackoverflow.com/questions/62695441/output-behaviour-of-scanf-and-printf-in-c-eclipse-console?noredirect=1 + 83. https://stackoverflow.com/questions/18948393/how-would-i-go-about-using-the-scanner-class-taking-in-one-character-and-then?noredirect=1 + 84. https://stackoverflow.com/questions/5976520/reading-stdin-in-c + 85. https://stackoverflow.com/questions/8101079/making-stdin-non-blocking + 86. https://stackoverflow.com/questions/8975521/read-from-stdin + 87. https://stackoverflow.com/questions/15883568/reading-from-stdin + 88. https://stackoverflow.com/questions/17848561/linux-unbuffered-reads-from-stdio + 89. https://stackoverflow.com/questions/35358924/buffering-stdin-stdout + 90. https://stackoverflow.com/questions/46391925/read-for-reading-stream-from-stdin + 91. https://stackoverflow.com/questions/49826427/read-from-stdin-and-fill-buffer-until-eof + 92. https://stackoverflow.com/questions/57916475/linux-stdin-buffering + 93. https://stackoverflow.com/questions/70254889/pipes-in-c-buffer-for-reading-stdin + 94. https://stackexchange.com/questions?tab=hot + 95. https://chess.stackexchange.com/questions/43542/why-was-this-move-a-miss + 96. https://electronics.stackexchange.com/questions/697252/using-an-op-amp-to-produce-a-low-current-voltage-rail + 97. https://math.stackexchange.com/questions/4843747/the-sum-of-the-squares-of-the-diagonals-in-a-polygon + 98. https://law.stackexchange.com/questions/98786/do-courts-declare-acts-of-the-legislature-unconstitutional + 99. https://literature.stackexchange.com/questions/26019/is-george-a-dishwasher + 100. https://worldbuilding.stackexchange.com/questions/253485/cybernetic-ais-get-hacked-while-sentient-agis-are-immune + 101. https://music.stackexchange.com/questions/133400/what-happened-to-jazz-in-1980 + 102. https://philosophy.stackexchange.com/questions/107345/i-have-an-absolute-certainty-that-cannot-be-refuted + 103. https://ell.stackexchange.com/questions/346463/seeking-an-english-equivalent-for-the-concept-of-evil-eye + 104. https://aviation.stackexchange.com/questions/102460/what-commercial-airplane-broke-the-sound-barrier-in-1979 + 105. https://codegolf.stackexchange.com/questions/269151/validate-a-cpf-number + 106. https://tex.stackexchange.com/questions/706975/is-there-a-program-that-automatically-convert-old-printings-into-tex-files + 107. https://academia.stackexchange.com/questions/205791/including-an-old-publication-in-a-cv-for-a-phd + 108. https://superuser.com/questions/1825387/why-did-my-coworker-see-a-painting-ified-version-of-my-background-image-on-a-z + 109. https://mathoverflow.net/questions/462012/group-generated-by-two-irrational-plane-rotations + 110. https://worldbuilding.stackexchange.com/questions/253544/planet-orbiting-a-star-orbiting-a-black-hole-can-there-be-life + 111. https://physics.stackexchange.com/questions/796748/why-is-it-possible-to-keep-an-object-say-a-book-horizontal-while-holding-its-c + 112. https://stats.stackexchange.com/questions/636755/significant-mann-whitney-and-significant-t-test-but-in-the-other-direction + 113. https://worldbuilding.stackexchange.com/questions/253452/what-is-the-lowest-tech-level-that-could-sustain-life-on-mars-or-the-moon + 114. https://diy.stackexchange.com/questions/290981/does-wire-gauge-matter-for-speaker-cable-for-a-home-stereo-system + 115. https://or.stackexchange.com/questions/11506/algorithm-needed-to-find-optimum-area-of-2-dimensional-data-set + 116. https://math.stackexchange.com/questions/4843647/first-fundamental-theorem-of-calculus-continuity-not-necessary + 117. https://codegolf.stackexchange.com/questions/269180/find-a-fraction-with-the-smallest-denominator + 118. https://money.stackexchange.com/questions/160911/is-this-a-fake-bank + 119. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 120. https://stackoverflow.com/feeds/question/4327942 + 121. https://stackoverflow.com/ + 122. https://stackoverflow.com/questions + 123. https://stackoverflow.com/help + 124. https://stackoverflow.co/ + 125. https://stackoverflow.co/teams/ + 126. https://stackoverflow.co/advertising/ + 127. https://stackoverflow.co/collectives/ + 128. https://stackoverflow.co/talent/ + 129. https://stackoverflow.co/ + 130. https://stackoverflow.co/ + 131. https://stackoverflow.co/company/press/ + 132. https://stackoverflow.co/company/work-here/ + 133. https://stackoverflow.com/legal + 134. https://stackoverflow.com/legal/privacy-policy + 135. https://stackoverflow.com/legal/terms-of-service/public + 136. https://stackoverflow.co/company/contact/ + 137. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 138. https://stackoverflow.com/legal/cookie-policy + 139. https://stackexchange.com/ + 140. https://stackexchange.com/sites#technology + 141. https://stackexchange.com/sites#culturerecreation + 142. https://stackexchange.com/sites#lifearts + 143. https://stackexchange.com/sites#science + 144. https://stackexchange.com/sites#professional + 145. https://stackexchange.com/sites#business + 146. https://api.stackexchange.com/ + 147. https://data.stackexchange.com/ + 148. https://stackoverflow.blog/?blb=1 + 149. https://www.facebook.com/officialstackoverflow/ + 150. https://twitter.com/stackoverflow + 151. https://linkedin.com/company/stack-overflow + 152. https://www.instagram.com/thestackoverflow + 153. https://stackoverflow.com/help/licensing + 154. https://stackoverflow.com/legal/cookie-policy + + Hidden links: + 156. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 157. https://stackoverflow.com/ + 158. https://meta.stackoverflow.com/ + 159. javascript:void(0) + 160. javascript:void(0) + 161. javascript:void(0) + 162. https://stackoverflowteams.com/teams/create/free/?utm_source=so-owned&utm_medium=side-bar&utm_campaign=campaign-38&utm_content=cta + 163. https://stackoverflow.com/posts/4327942/timeline + 164. https://stackoverflow.com/users/414016/ximik + 165. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 166. https://stackoverflow.com/posts/4327964/timeline + 167. https://stackoverflow.com/users/-1/community + 168. https://stackoverflow.com/users/168288/charles-salvia + 169. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 170. https://stackoverflow.com/posts/27705297/timeline + 171. https://stackoverflow.com/users/4177256/sam-toliman + 172. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 173. https://stackoverflow.com/posts/4328000/timeline + 174. https://stackoverflow.com/users/140740/digitalross + 175. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 176. https://stackoverflow.com/q/358342 + 177. https://stackoverflow.com/q/9635877 + 178. https://stackoverflow.com/q/22420665 + 179. https://stackoverflow.com/q/19358874 + 180. https://stackoverflow.com/q/62695441 + 181. https://stackoverflow.com/q/18948393 + 182. https://stackoverflow.com/q/5976520 + 183. https://stackoverflow.com/q/8101079 + 184. https://stackoverflow.com/q/8975521 + 185. https://stackoverflow.com/q/15883568 + 186. https://stackoverflow.com/q/17848561 + 187. https://stackoverflow.com/q/35358924 + 188. https://stackoverflow.com/q/46391925 + 189. https://stackoverflow.com/q/49826427 + 190. https://stackoverflow.com/q/57916475 + 191. https://stackoverflow.com/q/70254889 + 192. https://stackoverflow.com/questions/4327942/non-buffering-stdin-reading + 193. https://stackoverflow.com/ diff --git a/docs/suckless.org_philosophy.txt b/docs/suckless.org_philosophy.txt new file mode 100644 index 0000000..58f1ed7 --- /dev/null +++ b/docs/suckless.org_philosophy.txt @@ -0,0 +1,136 @@ + [1]suckless.org - software that sucks less + __________________________________________________________________ + + [2]home [3]dwm [4]st [5]core [6]surf [7]tools [8]libs [9]e.V. + [10]download [11]source + __________________________________________________________________ + + * [12]about + * [13]coding style/ + * [14]community/ + * [15]conferences/ + * [16]donations/ + * [17]faq/ + * [18]hacking/ + * [19]other projects/ + * [20]people/ + * [21]philosophy/ + * [22]project ideas/ + * [23]rocks/ + * [24]sucks/ + * [25]wiki/ + __________________________________________________________________ + +Philosophy + + We are the home of quality software such as [26]dwm, [27]dmenu, [28]st + and plenty of other [29]tools, with a focus on simplicity, clarity and + frugality. Our philosophy is about keeping things simple, minimal and + usable. We believe this should become the mainstream philosophy in the + IT sector. Unfortunately, the tendency for complex, error-prone and + slow software seems to be prevalent in the present-day software + industry. We intend to prove the opposite with our software projects. + + Our project focuses on advanced and experienced computer users. In + contrast with the usual proprietary software world or many mainstream + open source projects that focus more on average and non-technical end + users, we think that experienced users are mostly ignored. This is + particularly true for user interfaces, such as graphical environments + on desktop computers, on mobile devices, and in so-called Web + applications. We believe that the market of experienced users is + growing continuously, with each user looking for more appropriate + solutions for his/her work style. + + Designing simple and elegant software is far more difficult than + letting ad-hoc or over-ambitious features obscure the code over time. + However one has to pay this price to achieve reliability and + maintainability. Furthermore, minimalism results in reasonable and + attainable goals. We strive to maintain minimalism and clarity to drive + development to completion. + +Manifest + + Many (open source) hackers are proud if they achieve large amounts of + code, because they believe the more lines of code they've written, the + more progress they have made. The more progress they have made, the + more skilled they are. This is simply a delusion. + + Most hackers actually don't care much about code quality. Thus, if they + get something working which seems to solve a problem, they stick with + it. If this kind of software development is applied to the same source + code throughout its entire life-cycle, we're left with large amounts of + code, a totally screwed code structure, and a flawed system design. + This is because of a lack of conceptual clarity and integrity in the + development process. + + Code complexity is the mother of bloated, hard to use, and totally + inconsistent software. With complex code, problems are solved in + suboptimal ways, valuable resources are endlessly tied up, performance + slows to a halt, and vulnerabilities become a commonplace. The only + solution is to scrap the entire project and rewrite it from scratch. + + The bad news: quality rewrites rarely happen, because hackers are proud + of large amounts of code. They think they understand the complexity in + the code, thus there's no need to rewrite it. They think of themselves + as masterminds, understanding what others can never hope to grasp. To + these types, complex software is the ideal. + + Ingenious ideas are simple. Ingenious software is simple. Simplicity is + the heart of the Unix philosophy. The more code lines you have removed, + the more progress you have made. As the number of lines of code in your + software shrinks, the more skilled you have become and the less your + software sucks. + +Related links + + * [30]The Duct Tape Programmer + * [31]Why should I have written ZeroMQ in C, not C++ + * [32]Best practices in application architecture: Use layers to + decouple + * [33]Facebook's code quality problem + * [34]Minimal Viable Programs + * [35]Why I Write Games in C + * [36]Use of command-line tools for effective data processing + +References + + Visible links: + 1. https://suckless.org/ + 2. https://suckless.org/ + 3. https://dwm.suckless.org/ + 4. https://st.suckless.org/ + 5. https://core.suckless.org/ + 6. https://surf.suckless.org/ + 7. https://tools.suckless.org/ + 8. https://libs.suckless.org/ + 9. https://ev.suckless.org/ + 10. https://dl.suckless.org/ + 11. https://git.suckless.org/ + 12. https://suckless.org/ + 13. https://suckless.org/coding_style/ + 14. https://suckless.org/community/ + 15. https://suckless.org/conferences/ + 16. https://suckless.org/donations/ + 17. https://suckless.org/faq/ + 18. https://suckless.org/hacking/ + 19. https://suckless.org/other_projects/ + 20. https://suckless.org/people/ + 21. https://suckless.org/philosophy/ + 22. https://suckless.org/project_ideas/ + 23. https://suckless.org/rocks/ + 24. https://suckless.org/sucks/ + 25. https://suckless.org/wiki/ + 26. https://dwm.suckless.org/ + 27. https://tools.suckless.org/dmenu + 28. https://st.suckless.org/ + 29. https://tools.suckless.org/ + 30. http://www.joelonsoftware.com/items/2009/09/23.html + 31. http://www.250bpm.com/blog:4 + 32. http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef014e5f920093970c-pi + 33. http://www.darkcoding.net/software/facebooks-code-quality-problem/ + 34. http://joearms.github.io/published/2014-06-25-minimal-viable-program.html + 35. http://jonathanwhiting.com/writing/blog/games_in_c/ + 36. https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html + + Hidden links: + 38. https://suckless.org/ diff --git a/docs/www.kernel.org_doc_html_v4.15_dev-tools_kgdb.txt b/docs/www.kernel.org_doc_html_v4.15_dev-tools_kgdb.txt new file mode 100644 index 0000000..c1cb07a --- /dev/null +++ b/docs/www.kernel.org_doc_html_v4.15_dev-tools_kgdb.txt @@ -0,0 +1,1242 @@ + #[1]Index [2]Search [3]The Linux Kernel documentation [4]Development + tools for the kernel [5]Linux Kernel Selftests [6]Debugging kernel and + modules via gdb + + [7]The Linux Kernel + 4.15.0 + ____________________ + * [8]The Linux kernel user's and administrator's guide + + * [9]The Linux kernel user-space API guide + + * [10]Working with the kernel development community + * [11]Development tools for the kernel + + [12]Coccinelle + + [13]Sparse + + [14]kcov: code coverage for fuzzing + + [15]Using gcov with the Linux kernel + + [16]The Kernel Address Sanitizer (KASAN) + + [17]The Undefined Behavior Sanitizer - UBSAN + + [18]Kernel Memory Leak Detector + + [19]Debugging kernel and modules via gdb + + [20]Using kgdb, kdb and the kernel debugger internals + o [21]Introduction + o [22]Compiling a kernel + # [23]Kernel config options for kgdb + # [24]Kernel config options for kdb + o [25]Kernel Debugger Boot Arguments + # [26]Kernel parameter: kgdboc + # [27]Kernel parameter: kgdbwait + # [28]Kernel parameter: kgdbcon + # [29]Run time parameter: kgdbreboot + # [30]Kernel parameter: nokaslr + o [31]Using kdb + # [32]Quick start for kdb on a serial port + # [33]Quick start for kdb using a keyboard connected + console + o [34]Using kgdb / gdb + # [35]Connecting with gdb to a serial port + o [36]kgdb and kdb interoperability + # [37]Switching between kdb and kgdb + # [38]Running kdb commands from gdb + o [39]kgdb Test Suite + o [40]Kernel Debugger Internals + # [41]Architecture Specifics + # [42]kgdboc internals + o [43]Credits + + [44]Linux Kernel Selftests + * [45]How to write kernel documentation + * [46]Kernel Hacking Guides + + * [47]The Linux driver implementer's API guide + * [48]Core API Documentation + * [49]Linux Media Subsystem Documentation + * [50]Linux Networking Documentation + * [51]The Linux Input Documentation + * [52]Linux GPU Driver Developer's Guide + * [53]Security Documentation + * [54]Linux Sound Subsystem Documentation + * [55]Linux Kernel Crypto API + * [56]Linux Filesystems API + + * [57]SuperH Interfaces Guide + + * [58]Korean translations + + * [59]Chinese translations + + * [60]Japanese translations + + [61]The Linux Kernel + * [62]Docs » + * [63]Development tools for the kernel » + * Using kgdb, kdb and the kernel debugger internals + * [64]View page source + __________________________________________________________________ + +Using kgdb, kdb and the kernel debugger internals[65]¶ + + Author: Jason Wessel + +Introduction[66]¶ + + The kernel has two different debugger front ends (kdb and kgdb) which + interface to the debug core. It is possible to use either of the + debugger front ends and dynamically transition between them if you + configure the kernel properly at compile and runtime. + + Kdb is simplistic shell-style interface which you can use on a system + console with a keyboard or serial console. You can use it to inspect + memory, registers, process lists, dmesg, and even set breakpoints to + stop in a certain location. Kdb is not a source level debugger, + although you can set breakpoints and execute some basic kernel run + control. Kdb is mainly aimed at doing some analysis to aid in + development or diagnosing kernel problems. You can access some symbols + by name in kernel built-ins or in kernel modules if the code was built + with CONFIG_KALLSYMS. + + Kgdb is intended to be used as a source level debugger for the Linux + kernel. It is used along with gdb to debug a Linux kernel. The + expectation is that gdb can be used to "break in" to the kernel to + inspect memory, variables and look through call stack information + similar to the way an application developer would use gdb to debug an + application. It is possible to place breakpoints in kernel code and + perform some limited execution stepping. + + Two machines are required for using kgdb. One of these machines is a + development machine and the other is the target machine. The kernel to + be debugged runs on the target machine. The development machine runs an + instance of gdb against the vmlinux file which contains the symbols + (not a boot image such as bzImage, zImage, uImage...). In gdb the + developer specifies the connection parameters and connects to kgdb. The + type of connection a developer makes with gdb depends on the + availability of kgdb I/O modules compiled as built-ins or loadable + kernel modules in the test machine's kernel. + +Compiling a kernel[67]¶ + + * In order to enable compilation of kdb, you must first enable kgdb. + * The kgdb test compile options are described in the kgdb test suite + chapter. + +Kernel config options for kgdb[68]¶ + + To enable CONFIG_KGDB you should look under Kernel hacking > Kernel + debugging and select KGDB: kernel debugger. + + While it is not a hard requirement that you have symbols in your + vmlinux file, gdb tends not to be very useful without the symbolic + data, so you will want to turn on CONFIG_DEBUG_INFO which is called + Compile the kernel with debug info in the config menu. + + It is advised, but not required, that you turn on the + CONFIG_FRAME_POINTER kernel option which is called Compile the kernel + with frame pointers in the config menu. This option inserts code to + into the compiled executable which saves the frame information in + registers or on the stack at different points which allows a debugger + such as gdb to more accurately construct stack back traces while + debugging the kernel. + + If the architecture that you are using supports the kernel option + CONFIG_STRICT_KERNEL_RWX, you should consider turning it off. This + option will prevent the use of software breakpoints because it marks + certain regions of the kernel's memory space as read-only. If kgdb + supports it for the architecture you are using, you can use hardware + breakpoints if you desire to run with the CONFIG_STRICT_KERNEL_RWX + option turned on, else you need to turn off this option. + + Next you should choose one of more I/O drivers to interconnect + debugging host and debugged target. Early boot debugging requires a + KGDB I/O driver that supports early debugging and the driver must be + built into the kernel directly. Kgdb I/O driver configuration takes + place via kernel or module parameters which you can learn more about in + the in the section that describes the parameter kgdboc. + + Here is an example set of .config symbols to enable or disable for + kgdb: +# CONFIG_STRICT_KERNEL_RWX is not set +CONFIG_FRAME_POINTER=y +CONFIG_KGDB=y +CONFIG_KGDB_SERIAL_CONSOLE=y + +Kernel config options for kdb[69]¶ + + Kdb is quite a bit more complex than the simple gdbstub sitting on top + of the kernel's debug core. Kdb must implement a shell, and also adds + some helper functions in other parts of the kernel, responsible for + printing out interesting data such as what you would see if you ran + lsmod, or ps. In order to build kdb into the kernel you follow the same + steps as you would for kgdb. + + The main config option for kdb is CONFIG_KGDB_KDB which is called + KGDB_KDB: include kdb frontend for kgdb in the config menu. In theory + you would have already also selected an I/O driver such as the + CONFIG_KGDB_SERIAL_CONSOLE interface if you plan on using kdb on a + serial port, when you were configuring kgdb. + + If you want to use a PS/2-style keyboard with kdb, you would select + CONFIG_KDB_KEYBOARD which is called KGDB_KDB: keyboard as input device + in the config menu. The CONFIG_KDB_KEYBOARD option is not used for + anything in the gdb interface to kgdb. The CONFIG_KDB_KEYBOARD option + only works with kdb. + + Here is an example set of .config symbols to enable/disable kdb: +# CONFIG_STRICT_KERNEL_RWX is not set +CONFIG_FRAME_POINTER=y +CONFIG_KGDB=y +CONFIG_KGDB_SERIAL_CONSOLE=y +CONFIG_KGDB_KDB=y +CONFIG_KDB_KEYBOARD=y + +Kernel Debugger Boot Arguments[70]¶ + + This section describes the various runtime kernel parameters that + affect the configuration of the kernel debugger. The following chapter + covers using kdb and kgdb as well as providing some examples of the + configuration parameters. + +Kernel parameter: kgdboc[71]¶ + + The kgdboc driver was originally an abbreviation meant to stand for + "kgdb over console". Today it is the primary mechanism to configure how + to communicate from gdb to kgdb as well as the devices you want to use + to interact with the kdb shell. + + For kgdb/gdb, kgdboc is designed to work with a single serial port. It + is intended to cover the circumstance where you want to use a serial + console as your primary console as well as using it to perform kernel + debugging. It is also possible to use kgdb on a serial port which is + not designated as a system console. Kgdboc may be configured as a + kernel built-in or a kernel loadable module. You can only make use of + kgdbwait and early debugging if you build kgdboc into the kernel as a + built-in. + + Optionally you can elect to activate kms (Kernel Mode Setting) + integration. When you use kms with kgdboc and you have a video driver + that has atomic mode setting hooks, it is possible to enter the + debugger on the graphics console. When the kernel execution is resumed, + the previous graphics mode will be restored. This integration can serve + as a useful tool to aid in diagnosing crashes or doing analysis of + memory with kdb while allowing the full graphics console applications + to run. + +kgdboc arguments[72]¶ + + Usage: +kgdboc=[kms][[,]kbd][[,]serial_device][,baud] + + The order listed above must be observed if you use any of the optional + configurations together. + + Abbreviations: + * kms = Kernel Mode Setting + * kbd = Keyboard + + You can configure kgdboc to use the keyboard, and/or a serial device + depending on if you are using kdb and/or kgdb, in one of the following + scenarios. The order listed above must be observed if you use any of + the optional configurations together. Using kms + only gdb is generally + not a useful combination. + +Using loadable module or built-in[73]¶ + + 1. As a kernel built-in: + Use the kernel boot argument: +kgdboc=<tty-device>,[baud] + + 2. As a kernel loadable module: + Use the command: +modprobe kgdboc kgdboc=<tty-device>,[baud] + + Here are two examples of how you might format the kgdboc string. + The first is for an x86 target using the first serial port. The + second example is for the ARM Versatile AB using the second serial + port. + 1. kgdboc=ttyS0,115200 + 2. kgdboc=ttyAMA1,115200 + +Configure kgdboc at runtime with sysfs[74]¶ + + At run time you can enable or disable kgdboc by echoing a parameters + into the sysfs. Here are two examples: + 1. Enable kgdboc on ttyS0: +echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc + + 2. Disable kgdboc: +echo "" > /sys/module/kgdboc/parameters/kgdboc + + Note + + You do not need to specify the baud if you are configuring the console + on tty which is already configured or open. + +More examples[75]¶ + + You can configure kgdboc to use the keyboard, and/or a serial device + depending on if you are using kdb and/or kgdb, in one of the following + scenarios. + 1. kdb and kgdb over only a serial port: +kgdboc=<serial_device>[,baud] + + Example: +kgdboc=ttyS0,115200 + + 2. kdb and kgdb with keyboard and a serial port: +kgdboc=kbd,<serial_device>[,baud] + + Example: +kgdboc=kbd,ttyS0,115200 + + 3. kdb with a keyboard: +kgdboc=kbd + + 4. kdb with kernel mode setting: +kgdboc=kms,kbd + + 5. kdb with kernel mode setting and kgdb over a serial port: +kgdboc=kms,kbd,ttyS0,115200 + + Note + + Kgdboc does not support interrupting the target via the gdb remote + protocol. You must manually send a SysRq-G unless you have a proxy that + splits console output to a terminal program. A console proxy has a + separate TCP port for the debugger and a separate TCP port for the + "human" console. The proxy can take care of sending the SysRq-G for + you. + + When using kgdboc with no debugger proxy, you can end up connecting the + debugger at one of two entry points. If an exception occurs after you + have loaded kgdboc, a message should print on the console stating it is + waiting for the debugger. In this case you disconnect your terminal + program and then connect the debugger in its place. If you want to + interrupt the target system and forcibly enter a debug session you have + to issue a Sysrq sequence and then type the letter g. Then you + disconnect the terminal session and connect gdb. Your options if you + don't like this are to hack gdb to send the SysRq-G for you as well as + on the initial connect, or to use a debugger proxy that allows an + unmodified gdb to do the debugging. + +Kernel parameter: kgdbwait[76]¶ + + The Kernel command line option kgdbwait makes kgdb wait for a debugger + connection during booting of a kernel. You can only use this option if + you compiled a kgdb I/O driver into the kernel and you specified the + I/O driver configuration as a kernel command line option. The kgdbwait + parameter should always follow the configuration parameter for the kgdb + I/O driver in the kernel command line else the I/O driver will not be + configured prior to asking the kernel to use it to wait. + + The kernel will stop and wait as early as the I/O driver and + architecture allows when you use this option. If you build the kgdb I/O + driver as a loadable kernel module kgdbwait will not do anything. + +Kernel parameter: kgdbcon[77]¶ + + The kgdbcon feature allows you to see [78]printk() messages inside gdb + while gdb is connected to the kernel. Kdb does not make use of the + kgdbcon feature. + + Kgdb supports using the gdb serial protocol to send console messages to + the debugger when the debugger is connected and running. There are two + ways to activate this feature. + 1. Activate with the kernel command line option: +kgdbcon + + 2. Use sysfs before configuring an I/O driver: +echo 1 > /sys/module/kgdb/parameters/kgdb_use_con + + Note + + If you do this after you configure the kgdb I/O driver, the setting + will not take effect until the next point the I/O is reconfigured. + + Important + + You cannot use kgdboc + kgdbcon on a tty that is an active system + console. An example of incorrect usage is: +console=ttyS0,115200 kgdboc=ttyS0 kgdbcon + + It is possible to use this option with kgdboc on a tty that is not a + system console. + +Run time parameter: kgdbreboot[79]¶ + + The kgdbreboot feature allows you to change how the debugger deals with + the reboot notification. You have 3 choices for the behavior. The + default behavior is always set to 0. + 1 echo -1 > /sys/module/debug_core/parameters/kgdbreboot Ignore the + reboot notification entirely. + 2 echo 0 > /sys/module/debug_core/parameters/kgdbreboot Send the detach + message to any attached debugger client. + 3 echo 1 > /sys/module/debug_core/parameters/kgdbreboot Enter the + debugger on reboot notify. + +Kernel parameter: nokaslr[80]¶ + + If the architecture that you are using enable KASLR by default, you + should consider turning it off. KASLR randomizes the virtual address + where the kernel image is mapped and confuse gdb which resolve kernel + symbol address from symbol table of vmlinux. + +Using kdb[81]¶ + +Quick start for kdb on a serial port[82]¶ + + This is a quick example of how to use kdb. + 1. Configure kgdboc at boot using kernel parameters: +console=ttyS0,115200 kgdboc=ttyS0,115200 nokaslr + + OR + Configure kgdboc after the kernel has booted; assuming you are + using a serial port console: +echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc + + 2. Enter the kernel debugger manually or by waiting for an oops or + fault. There are several ways you can enter the kernel debugger + manually; all involve using the SysRq-G, which means you must have + enabled CONFIG_MAGIC_SysRq=y in your kernel config. + + When logged in as root or with a super user session you can + run: +echo g > /proc/sysrq-trigger + + + Example using minicom 2.2 + Press: CTRL-A f g + + When you have telneted to a terminal server that supports + sending a remote break + Press: CTRL-] + Type in: send break + Press: Enter g + 3. From the kdb prompt you can run the help command to see a complete + list of the commands that are available. + Some useful commands in kdb include: + + lsmod Shows where kernel modules are loaded + ps Displays only the active processes + ps A Shows all the processes + summary Shows kernel version info and memory usage + bt Get a backtrace of the current process using dump_stack() + dmesg View the kernel syslog buffer + go Continue the system + 4. When you are done using kdb you need to consider rebooting the + system or using the go command to resuming normal kernel execution. + If you have paused the kernel for a lengthy period of time, + applications that rely on timely networking or anything to do with + real wall clock time could be adversely affected, so you should + take this into consideration when using the kernel debugger. + +Quick start for kdb using a keyboard connected console[83]¶ + + This is a quick example of how to use kdb with a keyboard. + 1. Configure kgdboc at boot using kernel parameters: +kgdboc=kbd + + OR + Configure kgdboc after the kernel has booted: +echo kbd > /sys/module/kgdboc/parameters/kgdboc + + 2. Enter the kernel debugger manually or by waiting for an oops or + fault. There are several ways you can enter the kernel debugger + manually; all involve using the SysRq-G, which means you must have + enabled CONFIG_MAGIC_SysRq=y in your kernel config. + + When logged in as root or with a super user session you can + run: +echo g > /proc/sysrq-trigger + + + Example using a laptop keyboard: + Press and hold down: Alt + Press and hold down: Fn + Press and release the key with the label: SysRq + Release: Fn + Press and release: g + Release: Alt + + Example using a PS/2 101-key keyboard + Press and hold down: Alt + Press and release the key with the label: SysRq + Press and release: g + Release: Alt + 3. Now type in a kdb command such as help, dmesg, bt or go to continue + kernel execution. + +Using kgdb / gdb[84]¶ + + In order to use kgdb you must activate it by passing configuration + information to one of the kgdb I/O drivers. If you do not pass any + configuration information kgdb will not do anything at all. Kgdb will + only actively hook up to the kernel trap hooks if a kgdb I/O driver is + loaded and configured. If you unconfigure a kgdb I/O driver, kgdb will + unregister all the kernel hook points. + + All kgdb I/O drivers can be reconfigured at run time, if CONFIG_SYSFS + and CONFIG_MODULES are enabled, by echo'ing a new config string to + /sys/module/<driver>/parameter/<option>. The driver can be unconfigured + by passing an empty string. You cannot change the configuration while + the debugger is attached. Make sure to detach the debugger with the + detach command prior to trying to unconfigure a kgdb I/O driver. + +Connecting with gdb to a serial port[85]¶ + + 1. Configure kgdboc + Configure kgdboc at boot using kernel parameters: +kgdboc=ttyS0,115200 + + OR + Configure kgdboc after the kernel has booted: +echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc + + 2. Stop kernel execution (break into the debugger) + In order to connect to gdb via kgdboc, the kernel must first be + stopped. There are several ways to stop the kernel which include + using kgdbwait as a boot argument, via a SysRq-G, or running the + kernel until it takes an exception where it waits for the debugger + to attach. + + When logged in as root or with a super user session you can + run: +echo g > /proc/sysrq-trigger + + + Example using minicom 2.2 + Press: CTRL-A f g + + When you have telneted to a terminal server that supports + sending a remote break + Press: CTRL-] + Type in: send break + Press: Enter g + 3. Connect from gdb + Example (using a directly connected port): +% gdb ./vmlinux +(gdb) set remotebaud 115200 +(gdb) target remote /dev/ttyS0 + + Example (kgdb to a terminal server on TCP port 2012): +% gdb ./vmlinux +(gdb) target remote 192.168.2.2:2012 + + Once connected, you can debug a kernel the way you would debug an + application program. + If you are having problems connecting or something is going + seriously wrong while debugging, it will most often be the case + that you want to enable gdb to be verbose about its target + communications. You do this prior to issuing the target remote + command by typing in: +set debug remote 1 + + Remember if you continue in gdb, and need to "break in" again, you need + to issue an other SysRq-G. It is easy to create a simple entry point by + putting a breakpoint at sys_sync and then you can run sync from a shell + or script to break into the debugger. + +kgdb and kdb interoperability[86]¶ + + It is possible to transition between kdb and kgdb dynamically. The + debug core will remember which you used the last time and automatically + start in the same mode. + +Switching between kdb and kgdb[87]¶ + +Switching from kgdb to kdb[88]¶ + + There are two ways to switch from kgdb to kdb: you can use gdb to issue + a maintenance packet, or you can blindly type the command $3#33. + Whenever the kernel debugger stops in kgdb mode it will print the + message KGDB or $3#33 for KDB. It is important to note that you have to + type the sequence correctly in one pass. You cannot type a backspace or + delete because kgdb will interpret that as part of the debug stream. + 1. Change from kgdb to kdb by blindly typing: +$3#33 + + 2. Change from kgdb to kdb with gdb: +maintenance packet 3 + + Note + Now you must kill gdb. Typically you press CTRL-Z and issue the + command: +kill -9 % + +Change from kdb to kgdb[89]¶ + + There are two ways you can change from kdb to kgdb. You can manually + enter kgdb mode by issuing the kgdb command from the kdb shell prompt, + or you can connect gdb while the kdb shell prompt is active. The kdb + shell looks for the typical first commands that gdb would issue with + the gdb remote protocol and if it sees one of those commands it + automatically changes into kgdb mode. + 1. From kdb issue the command: +kgdb + + Now disconnect your terminal program and connect gdb in its place + 2. At the kdb prompt, disconnect the terminal program and connect gdb + in its place. + +Running kdb commands from gdb[90]¶ + + It is possible to run a limited set of kdb commands from gdb, using the + gdb monitor command. You don't want to execute any of the run control + or breakpoint operations, because it can disrupt the state of the + kernel debugger. You should be using gdb for breakpoints and run + control operations if you have gdb connected. The more useful commands + to run are things like lsmod, dmesg, ps or possibly some of the memory + information commands. To see all the kdb commands you can run monitor + help. + + Example: +(gdb) monitor ps +1 idle process (state I) and +27 sleeping system daemon (state M) processes suppressed, +use 'ps A' to see all. +Task Addr Pid Parent [*] cpu State Thread Command + +0xc78291d0 1 0 0 0 S 0xc7829404 init +0xc7954150 942 1 0 0 S 0xc7954384 dropbear +0xc78789c0 944 1 0 0 S 0xc7878bf4 sh +(gdb) + +kgdb Test Suite[91]¶ + + When kgdb is enabled in the kernel config you can also elect to enable + the config parameter KGDB_TESTS. Turning this on will enable a special + kgdb I/O module which is designed to test the kgdb internal functions. + + The kgdb tests are mainly intended for developers to test the kgdb + internals as well as a tool for developing a new kgdb architecture + specific implementation. These tests are not really for end users of + the Linux kernel. The primary source of documentation would be to look + in the drivers/misc/kgdbts.c file. + + The kgdb test suite can also be configured at compile time to run the + core set of tests by setting the kernel config parameter + KGDB_TESTS_ON_BOOT. This particular option is aimed at automated + regression testing and does not require modifying the kernel boot + config arguments. If this is turned on, the kgdb test suite can be + disabled by specifying kgdbts= as a kernel boot argument. + +Kernel Debugger Internals[92]¶ + +Architecture Specifics[93]¶ + + The kernel debugger is organized into a number of components: + 1. The debug core + The debug core is found in kernel/debugger/debug_core.c. It + contains: + + A generic OS exception handler which includes sync'ing the + processors into a stopped state on an multi-CPU system. + + The API to talk to the kgdb I/O drivers + + The API to make calls to the arch-specific kgdb implementation + + The logic to perform safe memory reads and writes to memory + while using the debugger + + A full implementation for software breakpoints unless + overridden by the arch + + The API to invoke either the kdb or kgdb frontend to the debug + core. + + The structures and callback API for atomic kernel mode + setting. + Note + kgdboc is where the kms callbacks are invoked. + 2. kgdb arch-specific implementation + This implementation is generally found in arch/*/kernel/kgdb.c. As + an example, arch/x86/kernel/kgdb.c contains the specifics to + implement HW breakpoint as well as the initialization to + dynamically register and unregister for the trap handlers on this + architecture. The arch-specific portion implements: + + contains an arch-specific trap catcher which invokes + kgdb_handle_exception() to start kgdb about doing its work + + translation to and from gdb specific packet format to pt_regs + + Registration and unregistration of architecture specific trap + hooks + + Any special exception handling and cleanup + + NMI exception handling and cleanup + + (optional) HW breakpoints + 3. gdbstub frontend (aka kgdb) + The gdbstub is located in kernel/debug/gdbstub.c. It contains: + + All the logic to implement the gdb serial protocol + 4. kdb frontend + The kdb debugger shell is broken down into a number of components. + The kdb core is located in kernel/debug/kdb. There are a number of + helper functions in some of the other kernel components to make it + possible for kdb to examine and report information about the kernel + without taking locks that could cause a kernel deadlock. The kdb + core contains implements the following functionality. + + A simple shell + + The kdb core command set + + A registration API to register additional kdb shell commands. + o A good example of a self-contained kdb module is the + ftdump command for dumping the ftrace buffer. See: + kernel/trace/trace_kdb.c + o For an example of how to dynamically register a new kdb + command you can build the kdb_hello.ko kernel module from + samples/kdb/kdb_hello.c. To build this example you can + set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your + kernel config. Later run modprobe kdb_hello and the next + time you enter the kdb shell, you can run the hello + command. + + The implementation for kdb_printf() which emits messages + directly to I/O drivers, bypassing the kernel log. + + SW / HW breakpoint management for the kdb shell + 5. kgdb I/O driver + Each kgdb I/O driver has to provide an implementation for the + following: + + configuration via built-in or module + + dynamic configuration and kgdb hook registration calls + + read and write character interface + + A cleanup handler for unconfiguring from the kgdb core + + (optional) Early debug methodology + Any given kgdb I/O driver has to operate very closely with the + hardware and must do it in such a way that does not enable + interrupts or change other parts of the system context without + completely restoring them. The kgdb core will repeatedly "poll" a + kgdb I/O driver for characters when it needs input. The I/O driver + is expected to return immediately if there is no data available. + Doing so allows for the future possibility to touch watchdog + hardware in such a way as to have a target system not reset when + these are enabled. + + If you are intent on adding kgdb architecture specific support for a + new architecture, the architecture should define HAVE_ARCH_KGDB in the + architecture specific Kconfig file. This will enable kgdb for the + architecture, and at that point you must create an architecture + specific kgdb implementation. + + There are a few flags which must be set on every architecture in their + asm/kgdb.h file. These are: + * + + NUMREGBYTES: + The size in bytes of all of the registers, so that we can + ensure they will all fit into a packet. + + * + + BUFMAX: + The size in bytes of the buffer GDB will read into. This + must be larger than NUMREGBYTES. + + * + + CACHE_FLUSH_IS_SAFE: + Set to 1 if it is always safe to call flush_cache_range or + flush_icache_range. On some architectures, these functions + may not be safe to call on SMP since we keep other CPUs in + a holding pattern. + + There are also the following functions for the common backend, found in + kernel/kgdb.c, that must be supplied by the architecture-specific + backend unless marked as (optional), in which case a default function + maybe used if the architecture does not need to provide a specific + implementation. + + int kgdb_skipexception(int exception, struct pt_regs * regs)[94]¶ + (optional) exit kgdb_handle_exception early + + Parameters + + int exception + Exception vector number + + struct pt_regs * regs + Current struct pt_regs. + + Description + + On some architectures it is required to skip a breakpoint exception + when it occurs after a breakpoint has been removed. This can be + implemented in the architecture specific portion of kgdb. + + void kgdb_breakpoint(void)[95]¶ + compiled in breakpoint + + Parameters + + void + no arguments + + Description + + This will be implemented as a static inline per architecture. This + function is called by the kgdb core to execute an architecture specific + trap to cause kgdb to enter the exception processing. + + int kgdb_arch_init(void)[96]¶ + Perform any architecture specific initalization. + + Parameters + + void + no arguments + + Description + + This function will handle the initalization of any architecture + specific callbacks. + + void kgdb_arch_exit(void)[97]¶ + Perform any architecture specific uninitalization. + + Parameters + + void + no arguments + + Description + + This function will handle the uninitalization of any architecture + specific callbacks, for dynamic registration and unregistration. + + void pt_regs_to_gdb_regs(unsigned long * gdb_regs, struct pt_regs + * regs)[98]¶ + Convert ptrace regs to GDB regs + + Parameters + + unsigned long * gdb_regs + A pointer to hold the registers in the order GDB wants. + + struct pt_regs * regs + The struct pt_regs of the current process. + + Description + + Convert the pt_regs in regs into the format for registers that GDB + expects, stored in gdb_regs. + + void sleeping_thread_to_gdb_regs(unsigned long * gdb_regs, struct + task_struct * p)[99]¶ + Convert ptrace regs to GDB regs + + Parameters + + unsigned long * gdb_regs + A pointer to hold the registers in the order GDB wants. + + struct task_struct * p + The struct task_struct of the desired process. + + Description + + Convert the register values of the sleeping process in p to the format + that GDB expects. This function is called when kgdb does not have + access to the struct pt_regs and therefore it should fill the gdb + registers gdb_regs with what has been saved in struct thread_struct + thread field during switch_to. + + void gdb_regs_to_pt_regs(unsigned long * gdb_regs, struct pt_regs + * regs)[100]¶ + Convert GDB regs to ptrace regs. + + Parameters + + unsigned long * gdb_regs + A pointer to hold the registers we've received from GDB. + + struct pt_regs * regs + A pointer to a struct pt_regs to hold these values in. + + Description + + Convert the GDB regs in gdb_regs into the pt_regs, and store them in + regs. + + int kgdb_arch_handle_exception(int vector, int signo, int err_code, + char * remcom_in_buffer, char * remcom_out_buffer, struct + pt_regs * regs)[101]¶ + Handle architecture specific GDB packets. + + Parameters + + int vector + The error vector of the exception that happened. + + int signo + The signal number of the exception that happened. + + int err_code + The error code of the exception that happened. + + char * remcom_in_buffer + The buffer of the packet we have read. + + char * remcom_out_buffer + The buffer of BUFMAX bytes to write a packet into. + + struct pt_regs * regs + The struct pt_regs of the current process. + + Description + + This function MUST handle the `c' and `s' command packets, as well + packets to set / remove a hardware breakpoint, if used. If there are + additional packets which the hardware needs to handle, they are handled + here. The code should return -1 if it wants to process more packets, + and a 0 or 1 if it wants to exit from the kgdb callback. + + void kgdb_roundup_cpus(unsigned long flags)[102]¶ + Get other CPUs into a holding pattern + + Parameters + + unsigned long flags + Current IRQ state + + Description + + On SMP systems, we need to get the attention of the other CPUs and get + them into a known state. This should do what is needed to get the other + CPUs to call kgdb_wait(). Note that on some arches, the NMI approach is + not used for rounding up all the CPUs. For example, in case of MIPS, + smp_call_function() is used to roundup CPUs. In this case, we have to + make sure that interrupts are enabled before calling + smp_call_function(). The argument to this function is the flags that + will be used when restoring the interrupts. There is local_irq_save() + call before [103]kgdb_roundup_cpus(). + + On non-SMP systems, this is not called. + + void kgdb_arch_set_pc(struct pt_regs * regs, unsigned long pc)[104]¶ + Generic call back to the program counter + + Parameters + + struct pt_regs * regs + Current struct pt_regs. + + unsigned long pc + The new value for the program counter + + Description + + This function handles updating the program counter and requires an + architecture specific implementation. + + void kgdb_arch_late(void)[105]¶ + Perform any architecture specific initalization. + + Parameters + + void + no arguments + + Description + + This function will handle the late initalization of any architecture + specific callbacks. This is an optional function for handling things + like late initialization of hw breakpoints. The default implementation + does nothing. + + struct kgdb_arch[106]¶ + Describe architecture specific values. + + Definition +struct kgdb_arch { + unsigned char gdb_bpt_instr; + unsigned long flags; + int (* set_breakpoint) (unsigned long, char *); + int (* remove_breakpoint) (unsigned long, char *); + int (* set_hw_breakpoint) (unsigned long, int, enum kgdb_bptype); + int (* remove_hw_breakpoint) (unsigned long, int, enum kgdb_bptype); + void (* disable_hw_break) (struct pt_regs *regs); + void (* remove_all_hw_break) (void); + void (* correct_hw_break) (void); + void (* enable_nmi) (bool on); +}; + + Members + + gdb_bpt_instr + The instruction to trigger a breakpoint. + + flags + Flags for the breakpoint, currently just KGDB_HW_BREAKPOINT. + + set_breakpoint + Allow an architecture to specify how to set a software + breakpoint. + + remove_breakpoint + Allow an architecture to specify how to remove a software + breakpoint. + + set_hw_breakpoint + Allow an architecture to specify how to set a hardware + breakpoint. + + remove_hw_breakpoint + Allow an architecture to specify how to remove a hardware + breakpoint. + + disable_hw_break + Allow an architecture to specify how to disable hardware + breakpoints for a single cpu. + + remove_all_hw_break + Allow an architecture to specify how to remove all hardware + breakpoints. + + correct_hw_break + Allow an architecture to specify how to correct the hardware + debug registers. + + enable_nmi + Manage NMI-triggered entry to KGDB + + struct kgdb_io[107]¶ + Describe the interface for an I/O driver to talk with KGDB. + + Definition +struct kgdb_io { + const char * name; + int (* read_char) (void); + void (* write_char) (u8); + void (* flush) (void); + int (* init) (void); + void (* pre_exception) (void); + void (* post_exception) (void); + int is_console; +}; + + Members + + name + Name of the I/O driver. + + read_char + Pointer to a function that will return one char. + + write_char + Pointer to a function that will write one char. + + flush + Pointer to a function that will flush any pending writes. + + init + Pointer to a function that will initialize the device. + + pre_exception + Pointer to a function that will do any prep work for the I/O + driver. + + post_exception + Pointer to a function that will do any cleanup work for the I/O + driver. + + is_console + 1 if the end device is a console 0 if the I/O device is not a + console + +kgdboc internals[108]¶ + +kgdboc and uarts[109]¶ + + The kgdboc driver is actually a very thin driver that relies on the + underlying low level to the hardware driver having "polling hooks" to + which the tty driver is attached. In the initial implementation of + kgdboc the serial_core was changed to expose a low level UART hook for + doing polled mode reading and writing of a single character while in an + atomic context. When kgdb makes an I/O request to the debugger, kgdboc + invokes a callback in the serial core which in turn uses the callback + in the UART driver. + + When using kgdboc with a UART, the UART driver must implement two + callbacks in the struct uart_ops. Example from drivers/8250.c: +#ifdef CONFIG_CONSOLE_POLL + .poll_get_char = serial8250_get_poll_char, + .poll_put_char = serial8250_put_poll_char, +#endif + + Any implementation specifics around creating a polling driver use the + #ifdef CONFIG_CONSOLE_POLL, as shown above. Keep in mind that polling + hooks have to be implemented in such a way that they can be called from + an atomic context and have to restore the state of the UART chip on + return such that the system can return to normal when the debugger + detaches. You need to be very careful with any kind of lock you + consider, because failing here is most likely going to mean pressing + the reset button. + +kgdboc and keyboards[110]¶ + + The kgdboc driver contains logic to configure communications with an + attached keyboard. The keyboard infrastructure is only compiled into + the kernel when CONFIG_KDB_KEYBOARD=y is set in the kernel + configuration. + + The core polled keyboard driver driver for PS/2 type keyboards is in + drivers/char/kdb_keyboard.c. This driver is hooked into the debug core + when kgdboc populates the callback in the array called + kdb_poll_funcs[]. The kdb_get_kbd_char() is the top-level function + which polls hardware for single character input. + +kgdboc and kms[111]¶ + + The kgdboc driver contains logic to request the graphics display to + switch to a text context when you are using kgdboc=kms,kbd, provided + that you have a video driver which has a frame buffer console and + atomic kernel mode setting support. + + Every time the kernel debugger is entered it calls + kgdboc_pre_exp_handler() which in turn calls con_debug_enter() in the + virtual console layer. On resuming kernel execution, the kernel + debugger calls kgdboc_post_exp_handler() which in turn calls + con_debug_leave(). + + Any video driver that wants to be compatible with the kernel debugger + and the atomic kms callbacks must implement the mode_set_base_atomic, + fb_debug_enter and fb_debug_leave operations. For the fb_debug_enter + and fb_debug_leave the option exists to use the generic drm fb helper + functions or implement something custom for the hardware. The following + example shows the initialization of the .mode_set_base_atomic operation + in drivers/gpu/drm/i915/intel_display.c: +static const struct drm_crtc_helper_funcs intel_helper_funcs = { +[...] + .mode_set_base_atomic = intel_pipe_set_base_atomic, +[...] +}; + + Here is an example of how the i915 driver initializes the + fb_debug_enter and fb_debug_leave functions to use the generic drm + helpers in drivers/gpu/drm/i915/intel_fb.c: +static struct fb_ops intelfb_ops = { +[...] + .fb_debug_enter = drm_fb_helper_debug_enter, + .fb_debug_leave = drm_fb_helper_debug_leave, +[...] +}; + +Credits[112]¶ + + The following people have contributed to this document: + 1. Amit Kale <[113]amitkale@linsyssoft.com> + 2. Tom Rini <[114]trini@kernel.crashing.org> + + In March 2008 this document was completely rewritten by: + * Jason Wessel <[115]jason.wessel@windriver.com> + + In Jan 2010 this document was updated to include kdb. + * Jason Wessel <[116]jason.wessel@windriver.com> + + [117]Next [118]Previous + __________________________________________________________________ + + © Copyright The kernel development community. + Built with [119]Sphinx using a [120]theme provided by [121]Read the + Docs. + +References + + 1. https://www.kernel.org/doc/html/v4.15/genindex.html + 2. https://www.kernel.org/doc/html/v4.15/search.html + 3. https://www.kernel.org/doc/html/v4.15/index.html + 4. https://www.kernel.org/doc/html/v4.15/dev-tools/index.html + 5. https://www.kernel.org/doc/html/v4.15/dev-tools/kselftest.html + 6. https://www.kernel.org/doc/html/v4.15/dev-tools/gdb-kernel-debugging.html + 7. https://www.kernel.org/doc/html/v4.15/index.html + 8. https://www.kernel.org/doc/html/v4.15/admin-guide/index.html + 9. https://www.kernel.org/doc/html/v4.15/userspace-api/index.html + 10. https://www.kernel.org/doc/html/v4.15/process/index.html + 11. https://www.kernel.org/doc/html/v4.15/dev-tools/index.html + 12. https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.html + 13. https://www.kernel.org/doc/html/v4.15/dev-tools/sparse.html + 14. https://www.kernel.org/doc/html/v4.15/dev-tools/kcov.html + 15. https://www.kernel.org/doc/html/v4.15/dev-tools/gcov.html + 16. https://www.kernel.org/doc/html/v4.15/dev-tools/kasan.html + 17. https://www.kernel.org/doc/html/v4.15/dev-tools/ubsan.html + 18. https://www.kernel.org/doc/html/v4.15/dev-tools/kmemleak.html + 19. https://www.kernel.org/doc/html/v4.15/dev-tools/gdb-kernel-debugging.html + 20. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html + 21. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#introduction + 22. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#compiling-a-kernel + 23. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-config-options-for-kgdb + 24. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-config-options-for-kdb + 25. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-debugger-boot-arguments + 26. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdboc + 27. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdbwait + 28. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdbcon + 29. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#run-time-parameter-kgdbreboot + 30. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-nokaslr + 31. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-kdb + 32. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#quick-start-for-kdb-on-a-serial-port + 33. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#quick-start-for-kdb-using-a-keyboard-connected-console + 34. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-kgdb-gdb + 35. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#connecting-with-gdb-to-a-serial-port + 36. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdb-and-kdb-interoperability + 37. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#switching-between-kdb-and-kgdb + 38. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#running-kdb-commands-from-gdb + 39. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdb-test-suite + 40. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-debugger-internals + 41. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#architecture-specifics + 42. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-internals + 43. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#credits + 44. https://www.kernel.org/doc/html/v4.15/dev-tools/kselftest.html + 45. https://www.kernel.org/doc/html/v4.15/doc-guide/index.html + 46. https://www.kernel.org/doc/html/v4.15/kernel-hacking/index.html + 47. https://www.kernel.org/doc/html/v4.15/driver-api/index.html + 48. https://www.kernel.org/doc/html/v4.15/core-api/index.html + 49. https://www.kernel.org/doc/html/v4.15/media/index.html + 50. https://www.kernel.org/doc/html/v4.15/networking/index.html + 51. https://www.kernel.org/doc/html/v4.15/input/index.html + 52. https://www.kernel.org/doc/html/v4.15/gpu/index.html + 53. https://www.kernel.org/doc/html/v4.15/security/index.html + 54. https://www.kernel.org/doc/html/v4.15/sound/index.html + 55. https://www.kernel.org/doc/html/v4.15/crypto/index.html + 56. https://www.kernel.org/doc/html/v4.15/filesystems/index.html + 57. https://www.kernel.org/doc/html/v4.15/sh/index.html + 58. https://www.kernel.org/doc/html/v4.15/translations/ko_KR/index.html + 59. https://www.kernel.org/doc/html/v4.15/translations/zh_CN/index.html + 60. https://www.kernel.org/doc/html/v4.15/translations/ja_JP/index.html + 61. https://www.kernel.org/doc/html/v4.15/index.html + 62. https://www.kernel.org/doc/html/v4.15/index.html + 63. https://www.kernel.org/doc/html/v4.15/dev-tools/index.html + 64. https://www.kernel.org/doc/html/v4.15/_sources/dev-tools/kgdb.rst.txt + 65. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-kgdb-kdb-and-the-kernel-debugger-internals + 66. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#introduction + 67. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#compiling-a-kernel + 68. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-config-options-for-kgdb + 69. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-config-options-for-kdb + 70. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-debugger-boot-arguments + 71. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdboc + 72. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-arguments + 73. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-loadable-module-or-built-in + 74. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#configure-kgdboc-at-runtime-with-sysfs + 75. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#more-examples + 76. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdbwait + 77. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-kgdbcon + 78. https://www.kernel.org/doc/html/v4.15/driver-api/basics.html#c.printk + 79. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#run-time-parameter-kgdbreboot + 80. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-parameter-nokaslr + 81. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-kdb + 82. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#quick-start-for-kdb-on-a-serial-port + 83. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#quick-start-for-kdb-using-a-keyboard-connected-console + 84. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#using-kgdb-gdb + 85. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#connecting-with-gdb-to-a-serial-port + 86. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdb-and-kdb-interoperability + 87. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#switching-between-kdb-and-kgdb + 88. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#switching-from-kgdb-to-kdb + 89. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#change-from-kdb-to-kgdb + 90. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#running-kdb-commands-from-gdb + 91. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdb-test-suite + 92. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kernel-debugger-internals + 93. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#architecture-specifics + 94. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_skipexception + 95. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_breakpoint + 96. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch_init + 97. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch_exit + 98. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.pt_regs_to_gdb_regs + 99. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.sleeping_thread_to_gdb_regs + 100. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.gdb_regs_to_pt_regs + 101. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch_handle_exception + 102. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_roundup_cpus + 103. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_roundup_cpus + 104. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch_set_pc + 105. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch_late + 106. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_arch + 107. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#c.kgdb_io + 108. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-internals + 109. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-and-uarts + 110. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-and-keyboards + 111. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#kgdboc-and-kms + 112. https://www.kernel.org/doc/html/v4.15/dev-tools/kgdb.html#credits + 113. mailto:amitkale%40linsyssoft.com + 114. mailto:trini%40kernel.crashing.org + 115. mailto:jason.wessel%40windriver.com + 116. mailto:jason.wessel%40windriver.com + 117. https://www.kernel.org/doc/html/v4.15/dev-tools/kselftest.html + 118. https://www.kernel.org/doc/html/v4.15/dev-tools/gdb-kernel-debugging.html + 119. http://sphinx-doc.org/ + 120. https://github.com/snide/sphinx_rtd_theme + 121. https://readthedocs.org/ diff --git a/docs/www.pps.jussieu.fr_~jch_software_kdrive.txt b/docs/www.pps.jussieu.fr_~jch_software_kdrive.txt new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/docs/www.pps.jussieu.fr_~jch_software_kdrive.txt diff --git a/docs/www.reddit.com_r_suckless_comments_n14xnq_can_sbase_replace_busybox.txt b/docs/www.reddit.com_r_suckless_comments_n14xnq_can_sbase_replace_busybox.txt new file mode 100644 index 0000000..95c342b --- /dev/null +++ b/docs/www.reddit.com_r_suckless_comments_n14xnq_can_sbase_replace_busybox.txt @@ -0,0 +1,294 @@ + [1]Skip to main content + + Reddit and its partners use cookies and similar technologies to provide + you with a better experience. + + By accepting all cookies, you agree to our use of cookies to deliver + and maintain our services and site, improve the quality of Reddit, + personalize Reddit content and advertising, and measure the + effectiveness of advertising. + + By rejecting non-essential cookies, Reddit may still use certain + cookies to ensure the proper functionality of our platform. + + For more information, please see our [2]Cookie Notice and our + [3]Privacy Policy. + + (BUTTON) Open menu Open navigation Go to Reddit Home + + (BUTTON) r/suckless A chip (BUTTON) A close button + + (BUTTON) Get app Get the Reddit app [4]Log In Log in to Reddit + (BUTTON) Expand user menu Open settings menu + * [5]Log In / Sign Up + * [6]Advertise on Reddit + * [7]Shop Collectible Avatars + + Get the Reddit app + + (BUTTON) + + Scan this QR code to download the app now + + Or check it out in the app stores + + Go to suckless + [8]r/suckless + [9]r/suckless + + Welcome to /r/suckless, the unofficial subreddit of the suckless + community. In this subreddit you can find discussions surrounding + suckless software, adjacent projects, and community ideas. + __________________________________________________________________ + + Members Online + o + [10]diamant711 + +Can sbase replace busybox? + + Can I use sbase as a replacement for busybox without problems? + (BUTTON) Read more + Closed o total votes + Yes + No + Voting closed + Archived post. New comments cannot be posted and votes cannot be cast. + Locked post. New comments cannot be posted. + + + __________________________________________________________________ + + TOPICS + + Gaming + * [11]Valheim + * [12]Genshin Impact + * [13]Minecraft + * [14]Pokimane + * [15]Halo Infinite + * [16]Call of Duty: Warzone + * [17]Path of Exile + * [18]Hollow Knight: Silksong + * [19]Escape from Tarkov + * [20]Watch Dogs: Legion + + + + Sports + + * [21]NFL + * [22]NBA + * [23]Megan Anderson + * [24]Atlanta Hawks + * [25]Los Angeles Lakers + * [26]Boston Celtics + * [27]Arsenal F.C. + * [28]Philadelphia 76ers + * [29]Premier League + * [30]UFC + + + + Business + + * [31]GameStop + * [32]Moderna + * [33]Pfizer + * [34]Johnson & Johnson + * [35]AstraZeneca + * [36]Walgreens + * [37]Best Buy + * [38]Novavax + * [39]SpaceX + * [40]Tesla + + + + Crypto + + * [41]Cardano + * [42]Dogecoin + * [43]Algorand + * [44]Bitcoin + * [45]Litecoin + * [46]Basic Attention Token + * [47]Bitcoin Cash + + + + Television + + * [48]The Real Housewives of Atlanta + * [49]The Bachelor + * [50]Sister Wives + * [51]90 Day Fiance + * [52]Wife Swap + * [53]The Amazing Race Australia + * [54]Married at First Sight + * [55]The Real Housewives of Dallas + * [56]My 600-lb Life + * [57]Last Week Tonight with John Oliver + + + + Celebrity + + * [58]Kim Kardashian + * [59]Doja Cat + * [60]Iggy Azalea + * [61]Anya Taylor-Joy + * [62]Jamie Lee Curtis + * [63]Natalie Portman + * [64]Henry Cavill + * [65]Millie Bobby Brown + * [66]Tom Hiddleston + * [67]Keanu Reeves + __________________________________________________________________ + + + + RESOURCES + + [68]About Reddit + + [69]Advertise + + [70]Help + + [71]Blog + + [72]Careers + + [73]Press + + + + POPULAR POSTS + + [74]English / Global + + [75]Deutsch + + [76]Español + + [77]Français + + [78]Italiano + + [79]Português + + [80]Reddit, Inc. © 2024. All rights reserved. + + Top 5% [81]Rank by size + +Top Posts + __________________________________________________________________ + + * Reddit + reReddit: Top posts of April 29, 2021 + ______________________________________________________________ + + * Reddit + reReddit: Top posts of April 2021 + ______________________________________________________________ + + * Reddit + reReddit: Top posts of 2021 + ______________________________________________________________ + + ____________________ ____________________ + +References + + Visible links: + 1. https://www.reddit.com/r/suckless/comments/n14xnq/can_sbase_replace_busybox/?rdt=57519#main-content + 2. https://reddit.com/en-us/policies/cookies + 3. https://reddit.com/en-us/policies/privacy-policy + 4. https://www.reddit.com/login + 5. https://www.reddit.com/login + 6. https://ads.reddit.com/?utm_source=web3x_consumer&utm_name=user_menu_cta + 7. https://www.reddit.com/avatar/shop + 8. https://www.reddit.com/r/suckless/ + 9. https://www.reddit.com/r/suckless/ + 10. https://www.reddit.com/user/diamant711/ + 11. https://reddit.com/t/valheim/ + 12. https://reddit.com/t/genshin_impact/ + 13. https://reddit.com/t/minecraft/ + 14. https://reddit.com/t/pokimane/ + 15. https://reddit.com/t/halo_infinite/ + 16. https://reddit.com/t/call_of_duty_warzone/ + 17. https://reddit.com/t/path_of_exile/ + 18. https://reddit.com/t/hollow_knight_silksong/ + 19. https://reddit.com/t/escape_from_tarkov/ + 20. https://reddit.com/t/watch_dogs_legion/ + 21. https://reddit.com/t/nfl/ + 22. https://reddit.com/t/nba/ + 23. https://reddit.com/t/megan_anderson/ + 24. https://reddit.com/t/atlanta_hawks/ + 25. https://reddit.com/t/los_angeles_lakers/ + 26. https://reddit.com/t/boston_celtics/ + 27. https://reddit.com/t/arsenal_fc/ + 28. https://reddit.com/t/philadelphia_76ers/ + 29. https://reddit.com/t/premier_league/ + 30. https://reddit.com/t/ufc/ + 31. https://reddit.com/t/gamestop/ + 32. https://reddit.com/t/moderna/ + 33. https://reddit.com/t/pfizer/ + 34. https://reddit.com/t/johnson_johnson/ + 35. https://reddit.com/t/astrazeneca/ + 36. https://reddit.com/t/walgreens/ + 37. https://reddit.com/t/best_buy/ + 38. https://reddit.com/t/novavax/ + 39. https://reddit.com/t/spacex/ + 40. https://reddit.com/t/tesla/ + 41. https://reddit.com/t/cardano/ + 42. https://reddit.com/t/dogecoin/ + 43. https://reddit.com/t/algorand/ + 44. https://reddit.com/t/bitcoin/ + 45. https://reddit.com/t/litecoin/ + 46. https://reddit.com/t/basic_attention_token/ + 47. https://reddit.com/t/bitcoin_cash/ + 48. https://reddit.com/t/the_real_housewives_of_atlanta/ + 49. https://reddit.com/t/the_bachelor/ + 50. https://reddit.com/t/sister_wives/ + 51. https://reddit.com/t/90_day_fiance/ + 52. https://reddit.com/t/wife_swap/ + 53. https://reddit.com/t/the_amazing_race_australia/ + 54. https://reddit.com/t/married_at_first_sight/ + 55. https://reddit.com/t/the_real_housewives_of_dallas/ + 56. https://reddit.com/t/my_600lb_life/ + 57. https://reddit.com/t/last_week_tonight_with_john_oliver/ + 58. https://reddit.com/t/kim_kardashian/ + 59. https://reddit.com/t/doja_cat/ + 60. https://reddit.com/t/iggy_azalea/ + 61. https://reddit.com/t/anya_taylorjoy/ + 62. https://reddit.com/t/jamie_lee_curtis/ + 63. https://reddit.com/t/natalie_portman/ + 64. https://reddit.com/t/henry_cavill/ + 65. https://reddit.com/t/millie_bobby_brown/ + 66. https://reddit.com/t/tom_hiddleston/ + 67. https://reddit.com/t/keanu_reeves/ + 68. https://www.redditinc.com/ + 69. https://ads.reddit.com/?utm_source=web3x_consumer&utm_name=left_nav_cta + 70. https://www.reddithelp.com/ + 71. https://redditblog.com/ + 72. https://www.redditinc.com/careers + 73. https://www.redditinc.com/press + 74. https://www.reddit.com/ + 75. https://www.reddit.com/de/ + 76. https://www.reddit.com/es/ + 77. https://www.reddit.com/fr/ + 78. https://www.reddit.com/it/ + 79. https://www.reddit.com/pt/ + 80. https://redditinc.com/ + 81. https://www.reddit.com/best/communities/56/#t5_2sczw/ + + Hidden links: + 83. https://www.reddit.com/ + 84. https://play.google.com/store/apps/details?id=com.reddit.frontpage + 85. https://apps.apple.com/US/app/id1064216828 + 86. https://www.reddit.com/r/suckless/ + 87. https://www.reddit.com/posts/2021/april-29-1/ + 88. https://www.reddit.com/posts/2021/april/ + 89. https://www.reddit.com/posts/2021/ @@ -29,9 +29,9 @@ ifconfig -a # qemu #nbd-client -N ROOT 10.0.0.2 /dev/nbd0 # 86Box -nbd-client -N ROOT 10.0.2.2 /dev/nbd0 +#nbd-client -N ROOT 10.0.2.2 /dev/nbd0 # Unisys -#nbd-client -N ROOT 192.168.1.31 /dev/nbd0 +nbd-client -N ROOT 192.168.1.31 /dev/nbd0 mount -t ext4 /dev/nbd0 /mnt #echo "Loading additional modules.." |