Re: I need reply in Embedded FreeBSD Kernel Theme

hi sorry for being late in reply but I had some problems in the last week. I
hope u still remeber what I was talking about :)
_at_chargen
Thanx for ur reply.
Embedded computer systems permeate all aspects of our daily lives.
Alarm clocks, coffee makers, digital watches, cell phones, and automobiles
are just a few of the devices that make use of embedded systems. The
design and development of such systems is unique, because the design
constraints are different for each system.
I supposed a new design for reducing the size of the kernel to be able to
work in such an environment which has some constraints make it does not have
the ability to get large memory, large storage devices or others.
/////////////////////////////

as far as your document goes:
"We will unload all the drivers that indicated with zeros in the module
metadata file. That would make the OS to be a few of Megabytes."

unload? what is the logic here?

I'm sorry but what is the real gain here,
//////////////////////
The configuration file is dependent on the kernel (which is included as a
compiled kernel). If I unload these unneeded drivers, I decrease the size of
the compiled kernel So it will have the ability to work in more constrained
environment and that is suitable to work for Operating Systems for small
chips for embedded systems.

As the Internet grew, the requirements of embedded systems also began to
grow in complexity. In addition to solving classic embedded systems
problems, system designers were required to add connectivity for sending and
receiving data or providing an automated method for software upgrades.
Rather than increase the development effort, system designers have moved
toward using third-party hardware and evaluating open source software.
Thanx Chargen
_at_ andrew
Thanx for your reply. I appreciate your effort to download the document.
Regarding the uploading of the document to that site, I am sorry for that
but I tried to attach it with the email but it was refused because its size
was too large. I did not send it in the text part because the text format
and tables will be lost.
I am sorry for that.

//////////////////////////////
///////////////////////////

After a couple of quick readings, I'm not sure I correctly understand what
you plan to achieve. It sounds like you are trying to achive something like
hardware specific dynamic module loading (like in Solaris, for example), but
then it also sounds like you are trying to build a kernel based on a
generated config which somehow involves building a tiny binary hardware
profile built from POST data.

Are you compiling a kernel at some point rather than just generating a
loader.conf for modules in order to minimise the running size?
////////////////////////////////////////////////////////
This approach will combine the two both. It will build a kernel based on a
generated config which somehow involves building a tiny binary hardware
profile built from POST data.  It also will use hardware specific dynamic
module loading because I don't have to load all the drivers for devices
connected to the machine. I will use this dynamic module loading at the
start-up only not at the run time because some considerations of the
embedded systems for chips not being to load modules and change how to work
at run time. that would make power problems.
////////////////////////////////////////////////////////

I was most confused by


 We will unload all the drivers that indicated with zeros in the
> module metadata file. That would make the OS to be a
> few of Megabytes.
>

Whether you are compiling a kernel for the (chosen) hardware based on a
generated kernel or loader config, I don't see a sensible case in which you
would ever need to "unload" any driver.
///////////////////////////////////////////////////////////////
yeah I know it is not sensible but I wrote it as a result of what I supposed
before so it has no meaning. just a result to clarify what I reduced here.

Thanx for ur sympathy and I will be glad to send you my next file to get ur
comments about.

////////////////////////////////////////////////////////////////



As much fun as it is spending hours manually tweaking and testing a kernel
config for each system and deciding what modules to use, I like the idea of
a one time guided process based on accurately identified hardware to build
an optimal kernel, so I hope that's what you're proposing.
//////////////////////////////////////////////////////////////////
Actually, I am deciding many time guided process based on accurately
identified hardware to build an optimal kernel because I think this is more
dynamic for considerations of changing the purpose of the embedded system. I
mean sometimes u may need to perform deterministic operation in this boot so
u do not have to load all drivers which there will be a lot of unneeded
drivers of them at this boot process. I will determine the dependencies to
provide optimal kernel.
Thanx Andrew

_at_ Matt
Thanx for ur reply Matt.
/////////////////////////////////////////////////////

FreeBSD is already a very modular system and the traditional way (a
traditional way) to build for embedded systems is to follow the
NanoBSD build method (tools included in the source tree) with a
stripped down kernel in which you only load the modules your hardware
requires using the FreeBSD loader (or after the initial boot).
////////////////////////////////////////////////////
yeah I read about that. My mentor suggested that before and my idea is very
close to NanoBSD but I don't know if the freebsd loader will load the moduls
based on the hardware requirements or user requirements. I will be glad to
reply me.
////////////////////////////////////////////////

However my Soekris net4801 board still takes about 2.5 minutes to boot
and I think time could be saved by parallel probing of hardware where
possible.
////////////////////////////////////////////////////
I think parallel probing is not providing in many boards. It's supported for
the new borders only (correct me if I am wrong). I have to develop something
which can be used in most of embedded systems.
///////////////////////////////////////////////////

I'd vote for more work on FreeBSD's existing boot method rather than
an entirely new implementation.

What problem are you trying to solve Mohammed ?
//////////////////////////////
I am not going to change in the main boot process. I am only changing the
how of including the kernel in the configuration file. that is it and
everything will be done as it is in the current freebsd. no more. That would
save space and that is what I need to reduce the size of kernel in memory.

_at_ bruce
Thanx for ur reply.