[HN Gopher] Exploring the Internals of Linux v0.01
___________________________________________________________________
Exploring the Internals of Linux v0.01
Author : ingve
Score : 288 points
Date : 2023-08-12 16:06 UTC (6 hours ago)
(HTM) web link (seiya.me)
(TXT) w3m dump (seiya.me)
| urbandw311er wrote:
| I really enjoyed this, thanks for sharing.
|
| I'm pleased to see the frequency and depth of the comments in the
| code too, makes it all very accessible.
|
| Anyone managed to get it to compile?
| anthk wrote:
| On 8MB, it was the minimal usable in mid late 90's for minimal
| systems such as today's 1GB systems with some light X
| environment.
|
| There was even a Howto for 4MB laptops.
|
| If you wanted to run X confortabily, even with FVWM and RXVT, you
| needed 16MB.
| rwmj wrote:
| Well, 1993 or 94, I had Linux, X11, fvwm(2?) and emacs running
| in 5MB. To be fair it was not very fast, and one later and
| extremely expensive PS600 upgrade to 16MB made it perform much
| better.
| anthk wrote:
| If you had 5MB you would just spawn Emacs in a tty and use
| SVGALib stuff to display images.
|
| Today I do the same with Gemini/Gopher/light HTTP pages and
| nsxiv to display the pictures and mpv+yt-dlp to watch
| videos/music/podcasts.
|
| That on an Atom N270, which today is like having 4MB and a
| 386 back in the day in 1999.
| dansalvato wrote:
| Wow, an Atom N270? I'm envious, I've always wanted to find
| a fun way to make use of old hardware like that. I have a
| Google Cr-48 chromebook with a similar CPU and 2GB of RAM.
| I'd be interested in learning more about your setup to see
| if I could get something similar going.
| capr wrote:
| The strcpy implementation is probably similar, just moved to gcc.
| qwertox wrote:
| Regarding the following code,
|
| ``` printk("Kernel panic: %s\n\r",s); for(;;); ```,
|
| could the for-loop be damaging to the CPU by over-utilizing a
| small portion over and over again, in terms of it heating up a
| tiny space on it?
| userbinator wrote:
| All CPUs didn't consume much power back then even at full load
| (several watts[1]), and thus leaving the CPU in a busy loop was
| the norm.
|
| [1] http://www.cocoon-culture.com/lib/noise-report/external-
| docs...
| TillE wrote:
| It's not a risk or anything, but it does waste power compared
| to using the HLT instruction.
| innocenat wrote:
| I think you need CLI; HLT as HLT by itself still allow
| machine to be woke up from interrupt.
| bpye wrote:
| Even with interrupts enabled sticking a HLT in that loop
| would be better than not.
| irdc wrote:
| That's pretty much what DOS did as well.
| bediger4000 wrote:
| Maybe not the for-loop, but there has been research into
| damaging CPUs by repeated execution of some particular
| instructions:
|
| https://www.semanticscholar.org/paper/MAGIC%3A-Malicious-Agi...
| qingcharles wrote:
| No.
| chucklenorris wrote:
| I remember win95 didn't use hlt instruction in the idle thread,
| it just did the same as linux. Power management wasn't a thing
| back then. I think ACPI and hlt came with winnt only.
| anthk wrote:
| You could use Rain to cool down your CPU. That tool was
| useful under VM's and DOSBox too.
| gattilorenz wrote:
| On Pentium or higher. 486s and earlier didn't really have
| an HLT instruction, iirc
| justsomehnguy wrote:
| >> All x86 processors from the 8086 onward had the HLT
| instruction, but it was not used by MS-DOS prior to
| 6.0[2] and was not specifically designed to reduce power
| consumption until the release of the Intel DX4 processor
| in 1994. MS-DOS 6.0 provided a POWER.EXE that could be
| installed in CONFIG.SYS and in Microsoft's tests it saved
| 5%.[3]
| flatiron wrote:
| every x86 has had halt. win95 was just not using it even
| though you could write a 10 line program to get context
| switched in when idle that would halt it. it was one of
| my first programs as a child on a 486 66 dx2.
|
| i just had chat gpt generate said program and i think its
| very similar to what I wrote. I'm unsure if it ever did
| anything but i've always been interested in efficiency:
|
| #include <stdio.h>
|
| #include <windows.h>
|
| void main() { printf("Setting process
| priority to low...\n");
| SetPriorityClass(GetCurrentProcess(),
| IDLE_PRIORITY_CLASS); printf("Halting the
| processor when no other programs are running...\n");
| while (1) { __asm { hlt }
| } }
| loeg wrote:
| No. CPUs need to be designed to tolerate busy loops without
| damaging themselves (with appropriate cooling). CPUs of that
| era did not measure their own temperature, but they also
| weren't trying to squeeze as much juice through as the later
| Pentium 4s that ran very hot. Modern CPUs are self-regulating
| and try very hard to avoid damaging themselves even with
| inadequate cooling.
| Farmadupe wrote:
| Im assuming the "halt and catch fire" thing is only really
| possible on pre-microprocessor machines built of discrete
| components, where the individual parts are small enough to
| overheat by themselves if driven wrong.
|
| I'd guess the physical CPU package of an i386 would cope just
| fine with the few (hundreds?) of gates toggling in that small
| loop.
|
| I wonder if it might be possible to do on a modern FPGA, if you
| artifically create some unstable circuit and pack deliberately
| it in a corner of the die?
|
| There's probably some AVX512 concoction that would be the
| closest equivalent on a modern X64. There's probably an easy
| experiment -- if that concoction makes CPU freq drop and also
| makes whole-package thermals drop, it /could/ be due to
| localized die heating.
| [deleted]
| bragr wrote:
| No. Intel CPU's, even way before Linux, were microcoded, so
| you're still using the full instruction fetch, decode, and
| microcode system for every step in your infinite for loop. You
| aren't wearing out the CPU any more than running any other
| code.
| umanwizard wrote:
| None of the instructions likely to be emitted by that loop
| will be microcoded, and the instruction will always be
| fetched from L1 cache. That said, this won't be an issue
| simply because CPUs are designed and tested to be able to
| handle hot loops.
| sedatk wrote:
| My AMD 386DX/40 didn't even have a fan or a heatsink.
| colonwqbang wrote:
| The CPU would probably run cooler since it's not doing
| anything. Most of the circuit would be static, not flipping
| from 0->1 or 1->0 which is what tends to expend the most power.
| badrabbit wrote:
| I had an askhn about a "linux internals" book (lookup "windows
| internals"), I would be glad to contribute to crowdfunding such
| an effort, but not strictly for the kernel but every major
| userspace subsystem as well.
|
| https://news.ycombinator.com/item?id=33728590
| quietbritishjim wrote:
| > counter = (counter >> 1) + priority ... Note that counter >> 1
| is a faster way to divide by 2 ... This means that if a task is
| waiting for I/O for a long time, and its priority is higher than
| 2, counter value will monotonically increase when counter is
| updated.
|
| Actually the effect is that counter will exponentially decay up
| to 2 * priority (if the task is not runnable). You can sanity
| check this by looking at the limit: if counter is 2*priority then
| that expression will leave it at its current value.
| fasterik wrote:
| Just like you read the classics in literature, I think it would
| be interesting to read some of the classic codebases. They should
| fit the following criteria:
|
| - The project was highly successful or influential
|
| - Freely available source code
|
| - Ideally the bulk of the project was written by one person
|
| So far my list includes Linux, the John Carmack id releases
| (wolf3d, DOOM, Quake), SQLite, and vim. Any others I'm missing?
| ansbalin wrote:
| The Apollo guidance computer source code?
| https://github.com/virtualagc/virtualagc
| fasterik wrote:
| Very cool. Unfortunately it's probably not very relevant to
| current programming practice, but it definitely fits the bill
| for historical impact.
| nurettin wrote:
| https://github.com/virtualagc/virtualagc/blob/master/Solariu.
| ..
| philistine wrote:
| BBedit ?
| MikeTheGreat wrote:
| That's not open source, is it?
|
| I feel like we can be more (or less) flexible about the
| 'impact' and 'single author' criteria, but we _definitely_
| need to be able to see the source :)
| malkosta wrote:
| Redis...
| quickthrower2 wrote:
| Fairly old Glasgow Haskell Compiler:
| https://github.com/ghc/ghc/commit/e7d21ee4f8ac907665a7e170c7...
|
| Bitcoin?
|
| Redis?
|
| Coreutils?
| mananaysiempre wrote:
| Those aren't necessarily written as people would do it today,
| but Knuth's literate sources for TeX[1] and METAFONT[2] are
| explicitly meant for reading. The literate program family also
| includes LCC[3], but _A retargetable C compiler_ is a book that
| you'd need to buy; and PBRT[4], but _Physically based
| rendering_ is more exposition than program (even if the program
| is a perfectly good one). The source for Unix V6[5] with the
| accompanying commentary by Lions is probably as much of a
| classic as it's possible to get. And as an eccentric choice in
| a similar format, may I suggest cmForth[6], perhaps paired with
| _Footsteps in an empty valley_ [7]?
|
| Also, though this is not precisely what you're asking for, _The
| architecture of open-source applications_ and its sequels[8]
| have the original designers' reflections on some well-known
| codebases.
|
| [1] http://mirrors.ctan.org/info/knuth-pdf/tex/tex.pdf
|
| [2] http://mirrors.ctan.org/info/knuth-pdf/mf/mf.pdf
|
| [3] https://github.com/drh/lcc
|
| [4] https://pbr-book.org/
|
| [5] http://v6.cuzuco.com/
|
| [6]
| https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.ft...
|
| [7] http://forth.org/OffeteStore/4001-footstepsFinal.pdf
|
| [8] https://aosabook.org/
| yjftsjthsd-h wrote:
| Assorted members of the unix and BSD family probably would
| qualify - research unix (at least v6, but maybe others) and
| 4.4bsd-lite come to mind. Maybe minix.
| pbaam wrote:
| Lua's codebase is also great for getting started
| umanwizard wrote:
| The original releases of gcc and GNU emacs both fit all your
| criteria.
| pseudostem wrote:
| I am not a programmer (yet). I am an openBSD fanboy. I've read
| stories of people reading the code and raving about the
| quality. It does tick 2 of the checkboxes you mentioned (not
| just one person). Does this qualify?
| fasterik wrote:
| Yes, I think so. Being written by one person isn't a hard
| requirement, it's just that I feel like you get a better
| sense of programming style and someone's approach to problem
| solving when you read code that hasn't been touched by too
| many people.
|
| Projects with a maintainer who strictly enforces code style
| and quality would still fit the description. From what I've
| heard, OpenBSD falls under this category. I'll add it to my
| list.
| apples_oranges wrote:
| I studied assembly graphics programming on the Amiga 500 and
| had a good time
| lanstin wrote:
| When Redhat IPOed (or soon after? quarterly report? I can't
| remember) they sent out a poster with the 0.01 source code to
| their share holders. It fits and is fun to read from time to
| time.
| bergkvist wrote:
| I feel like looking at the first working versions of a big
| successful project is a great way to understand how it works.
|
| Usually it will only contain the most important core features
| without a lot of abstractions/generalizations. So it is actually
| manageable to read through all of the code in a couple of days.
| peter_d_sherman wrote:
| >"Linus didn't have a machine with 8MB RAM:
|
| '* For those with more memory than 8 Mb - tough luck. I've
| * not got it, why should you :-) The source is here. Change
| * it. (Seriously - it shouldn't be too difficult. ...'
|
| Today, machines with 8GB RAM are very common. Furthermore, 8GB is
| not enough at all for software engineers ;)"
|
| Bill Gates, 1981: "640K ought to be enough for anyone..."
|
| Linus Torvalds, 1991: "8MB ought to be enough for anyone..."
|
| Jen-Hsun Huang, 2023: " _144TB_ ought to be enough for anyone...
| "
|
| :-) <g> :-)
|
| (Disclaimer: The above quotes are written for comedy purposes
| only! The above individuals referenced probably didn't actually
| say those things! <g>)
| cobertos wrote:
| What is <g>? My first thought was
| https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g but
| that cant be right
| throwaway29303 wrote:
| It means to grin. Sometimes it shows up as *g* too.
| robin_reala wrote:
| Grin, if I remember rightly.
| stevefolta wrote:
| > I thought GCC (or C itself) has good backward compatibility,
| but it's not sufficient.
|
| Ha! It's been a long time since GCC was even able to compile
| older versions of _itself_.
| [deleted]
| SubjectToChange wrote:
| Par for the course honestly. Obviously major C compilers are
| only becoming more strict about acceptable code. For instance
| when -fno-common was made the default in GCC 10 it ended up
| breaking an rather incredible number of packages.
| yjftsjthsd-h wrote:
| Setting stricter defaults makes sense, but not being _able_
| to compile older code even with options to disable checks
| seems like a regression.
| kccqzy wrote:
| Years of language-lawyering really refined our own
| understanding of what is and isn't correct code. Any older
| code is just so full of UB that they can barely be said to
| be valid code.
|
| It's just a product of the times.
| yjftsjthsd-h wrote:
| That's besides the point. The latest release of, let's
| say Linux, has bugs in it (statistically, unless it's the
| first perfect bug-free release ever). Would it be
| reasonable for a compiler to refuse to compile it? The
| compiler's job isn't to refuse to compile bad code if it
| _could_ compile it, only to warn the user and try to help
| fix it if possible.
| tinus_hn wrote:
| For code that has undefined behavior, the compiler may
| refuse to compile it or compile it into literally
| anything.
|
| A common mistake is expecting code that has undefined
| behavior to be compiled into something that makes logical
| sense.
|
| You may disagree with it but that's how compilers work
| and how the standard describes they should work.
| dwattttt wrote:
| The problem isn't that the compiler chooses not to
| compile something if it deems it broken. The problem is
| that the broken code's behaviour is coupled to the
| compiler of the time.
|
| The behaviour you want isn't "compile this version of
| Linux even though it has a bug", it's "compile this
| version of Linux as if you were a compiler at the time
| which accepted this broken code in this way", which is a
| very tall order, along the lines of bug-for-bug
| compatibility while also fixing the bug.
| penguin_booze wrote:
| I don't know if what's shown is the actual source code, but I
| notice spaces were used instead of tabs. Maybe Torvalds became a
| tab advocate only further down the line.
| sedatk wrote:
| They were trying to save storage space and build times as the
| source grew in size.
| parasti wrote:
| Any truth to this? Somebody must have ran a benchmark at
| least?
| water-your-self wrote:
| A parse of the topic on the style guide doesnt suggest
| anything of the sort
|
| https://www.kernel.org/doc/html/v4.10/process/coding-
| style.h...
| benj111 wrote:
| I hope the parent was being humourous.
|
| 1 tab is 1 byte, 4 spaces is 4 bytes, so it doesn't
| actually work anyway.
|
| And you can't rely on it being multiples of 4 anyway, so
| you'd have to iterate and check the bytes to check they are
| actually spaces.
|
| So no, it's be slower, but not enough to matter.
|
| Edit: or is the parent proposing the opposite? I sti hope
| they're being humourous as it still doesn't really matter
| sedatk wrote:
| No, that was my actual theory for what happened, but
| apparently not true at all:
| https://news.ycombinator.com/item?id=37104012
| sedatk wrote:
| I actually went ahead and asked Linus Torvalds himself. He
| said he'd never use spaces, and always used tabs from the
| get go. So, my theory fails :)
|
| > What? No.
|
| > It always used tabs.
|
| > And by "always used tabs" I mean "mistakes probably
| happened, and there may be spaces in some places", but
| afaik I've always used hard-tabs as the normal indentation.
|
| > If you see something else, you probably have some archive
| that has been reformatted.
___________________________________________________________________
(page generated 2023-08-12 23:00 UTC)