[Prev][Next][Index][Thread]

Re: more newbie questions...


> Hi...sorry for bothering you...but I have several more questions:

I have some answers to a few of them.

> 2) When any initilization is called there is whole bunch of stuff
> displayed on stdout, about probing etc. is there a way to buffer that in
> a pointer, but not display it, cause I am really unable to read what had
> scrolled upwards.

The easiest way is to write a simple buffer library implementing the
ttystream interface and initialise the base_console to use it instead
of the VGA.  Look at oskit/kern/x86/pc/*_console.c.  The simplest
way to do this is probably to override the code in base_console_init.c.

An alternative to using just a memory buffer might be to implement
"more" as a COM component.  That is, you buffer stdin in memory and
use some keyboard strokes (page up/down? cursor keys? whatever you
want) to control what's coming out of stdout.  

> 3) Why OSkit's kernels are so huge? the linux fs read sample kernel is
> like almost a meg in size, even after stripping it. If I want to be able
> to make full featured bootable floppies for my system. it's just if I
> add
> scheduling, shell, network drivers, and file system it would take 3
> floppies, that is really not good for me. A ny suggestions?

The size of the kernels disturbs me too.  Some reasons for this include:

1) It's relatively hard to replace one "component" with another - which means
   that we lean towards having a single general purpose component rather than 
   having a number of specialised components.  For example, the standard
   console code includes support for serial lines and VGAs and gdb but
   you're probably only using one of the three in any particular build.

   [That said, it's easier to replace components in the oskit than in
   the kernels we took the bits from.]

2) COM has a huge overhead in code size:
   1) all that wrapper code to implement each method
   2) no dead code elimination

   [But, again, COM brings some advantages too]

3) Those encapsulated components we took out of Linux/*BSD/etc can be 
   pretty big.  Worse yet, they have a lot of dependencies so using
   an encapsulated component can suck in a lot of support code.

   [And, again, the gain is that we have a lot more device drivers,
   etc than we'd have if we tried to write our own drivers with,
   you'd hope (but may not achieve) less dependencies.]
   
I'm working on this problem - with a reasonable amount of success.  My
favourite example is reducing the hello kernel from about 40k down to
2k by cutting out a lot of irrelevant stuff (irqs, serial lines, etc).
Mind you, the hello kernel is a particularily simple case -don't
expect such big gains in a more complex kernel- and, IMO, 2k is still
ridiculously large for such a simple program.

> 4) Where can I find information on how exec loader libary loads the
> executables,  with what stack? where does it grow?
> etc.

Section 25 (at least, in the copy of the docs I'm looking at.)  The
idea is that you provide the functions used to allocate the memory and
you're told what each block of memory will be used for.  So, if you
want a growable stack, your allocator should do some appropriate magic
when asked to allocate the stack.  

(I vaguely remember seeing some growable stack code in
oskit/unsupported/redzone.c but I know nothing about it and, as the
name suggests, it's unsupported.  It doesn't look as though it is
integrated with the exec loader.)

> 5) not a question but a suggestion, I think OS-Kit documentation should
> have more numbers, less theory...

What kind of numbers?  Also, it seems to me that half your questions
were about "theory" so I'd say it needs more "theory" (and, who knows,
perhaps more "numbers" too?)

Perhaps I need a more concrete example of what you'd cut out and what
you'd add.

--
Alastair Reid        reid@cs.utah.edu        http://www2.cs.utah.edu/~reid/
References: