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
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
