On 2/28/2012 10:33 AM, Reuben Thomas wrote:
On 28 February 2012 16:41, BGB<cr88...@gmail.com>  wrote:
  - 1 order of magnitude is gained by removing feature creep.  I agree
   feature creep can be important.  But I also believe most feature
   belong to a long tail, where each is needed by a minority of users.
   It does matter, but if the rest of the system is small enough,
   adding the few features you need isn't so difficult any more.

this could help some, but isn't likely to result in an order of magnitude.
Example: in Linux 3.0.0, which has many drivers (and Linux is often
cited as being "mostly drivers"), actually counting the code reveals
about 55-60% in drivers (depending how you count). So that even with
only one hardware configuration, you'd save less than 50% of the code
size, i.e. a factor of 2 at very best.

yeah, kind of the issue here.

one can shave code, reduce redundancy, increase abstraction, ... but this will only buy so much.

then one can start dropping features, but how many can one drop and still have everything still work?...

one can be like, "well, maybe we will make something like MS-DOS, but in long-mode?" (IOW: single-big address space, with no user/kernel separation, or conventional processes, and all kernel functionality is essentially library functionality).

ok, how small can this be made?
maybe 50 kloc, assuming one is sparing with the drivers.

I once wrote an OS kernel (long-dead project, ended nearly a decade ago), going and running a line counter on the whole project, I get about 84 kloc. further investigation: 44 kloc of this was due to a copy of NASM sitting in the apps directory (I tried to port NASM to my OS at the time, but it didn't really work correctly, very possibly due to a quickly kludged-together C library...).

so, a 40 kloc OS kernel, itself at the time bordering on "barely worked".

what sorts of HW drivers did it have: ATA / IDE, console, floppy, VESA, serial mouse, RS232, RTL8139. how much code as drivers: 11 kloc.

how about VFS: 5 kloc, which include (FS drivers): "BSHFS" (IIRC, a TFTP-like shared filesystem), FAT (12/16/32), RAMFS.

another 5 kloc goes into the network code, which included TCP/IP, ARP, PPP, and an HTTP client+server.

boot loader was 288 lines (ASM), "setup" was 792 lines (ASM).

boot loader: copies boot files ("setup.bin" and "kernel.sys") into RAM (in the low 640K). seems hard-coded for FAT12.

"setup" was mostly responsible for setting up the kernel (copying it to the desired address) and entering protected mode (jumping into the kernel). this is commonly called a "second-stage" loader, partly because it does a lot of stuff which is too bulky to do in the boot loader (which is limited to 512 bytes, whereas "setup" can be up to 32kB).

"setup" magic: Enable A20, load GDT, enter big-real mode, check for "MZ" and "PE" markers (kernel was PE/COFF it seems), copies kernel image to VMA base, pushes kernel entry point to stack, remaps IRQs, executes 32-bit return (jumps into protected mode).

around 1/2 of the "setup" file is code for jumping between real and protected mode and for interfacing with VESA.

note: I was using PE/COFF for apps and libraries as well.
IIRC, I was using a naive process-based model at the time.

could a better HLL have made the kernel drastically smaller? I have my doubts...

add the need for maybe a compiler, ... and the line count is sure to get larger quickly.

based on my own code, one could probably get a basically functional C compiler in around 100 kloc, but maybe smaller could be possible (this would include the compiler+assembler+linker).

apps/... would be a bit harder.

in my case, the most direct path would be just dumping all of my existing libraries on top of my original OS project, and maybe dropping the 3D renderer (since it would be sort of useless without GPU support, OpenGL, ...). this would likely weigh in at around 750-800 kloc (but could likely be made into a self-hosting OS, since a C compiler would be included, and as well there is a C runtime floating around).

this is all still a bit over the stated limit.

maybe, one could try to get a functional GUI framework and some basic applications and similar in place (probably maybe 100-200 kloc more, at least).

probably, by this point, one is looking at something like a Windows 3.x style disk footprint (maybe using 10-15 MB of HDD space or so for all the binaries...).

granted, in my case, the vast majority of the code would be C, probably with a smaller portion of the OS and applications being written in BGBScript or similar...

fonc mailing list

Reply via email to