[openbeos] Re: binary middle ground

> Well, everyone in my current house, all former ex-Be engineers,
> know how big the BeOS source code is (5 million lines of code,
> give or take 1 million).

hmmm... I'll need to make some room on my HDD :)))


> Do I have to say more?
I won't ask you any password. But I wouldn't mind if...  :-D

Btw, let's put some serious stuff in that mail.
Some thoughts about the bfs kernel integration:

It's true that the kernel needs enough knowledge of the layout to load the bfs 
driver. Btw we don't have many choices here. Either we use static drivers, then 
we don't have problems, but we have to rebuild the kernel, either we use 
dynamicaly loaded drivers (which is more in use these days, just look at 
Linux), but we need a minimal static bfs driver anyway. Linux's approach is a 
bit different, since it uses modules (= dynamicaly loaded drivers), but also
static drivers, for ones that are needed at boot-time (like ext2fs). This is 
done like that in Linux because of the history: since everyone has the source,
everyone can recompile it. But since the BeOS kernel historically is closed.
Since we want to make it open-source, nothing prevent us now from using the 
Linux model, though it maybe not the most apropriate.

One other possibility Linux has is the initial ramdisk (initrd), which in fact 
is a primary root filesystem (boot, since Linux doesn't use a pseudo-fs for /),
that is used to load drivers that are needed at boot-time but are available as 
modules, and also most of the time to setup the ISA PnP (maybe not with the 
last kernels). Anyway the initrd still has to be found somewhere on the disk, 
so we still need a minimal fs.

Yeah, it's the chicken-and-egg problem :)
just like the key to open the door is behind the door :-(

François.

Other related posts: