From owner-freebsd-current@FreeBSD.ORG Thu Jun 24 01:36:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4A3106566B for ; Thu, 24 Jun 2010 01:36:22 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 399E28FC14 for ; Thu, 24 Jun 2010 01:36:21 +0000 (UTC) Received: by wwb24 with SMTP id 24so1258304wwb.13 for ; Wed, 23 Jun 2010 18:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=X5SpNat18Q1kKLu4bLwAyh6YP9gvizkSmJOj96JmJXs=; b=cbG4cxNMDNif5456VUkQ7KrAaQaKbvSuWSu/8eodMoz1+yXRtp42qSCq+TIuE2oouQ ZVTnVHHinqSS54ZoC18AqDOf0PvK+cvTNAaL3rYZRXqUWbLW3wv7qUVOaX1uWFwVgo5z IOF8KWqGTOikaRxJKj8cTY04gtbckZ3Oi3hm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SVn8ZJKdby2PqPKxJpdt8efGsRzanZj5310sNv8SaI9w2YiwyTZ83OGlNK0CHrENM5 0zZ2rByC72PHqIs1I3QLMiaD5Q4kM13f67QkP3k+im+spTOU0eq5di7hUBkqpXoNRDlC Zwj4mYg5o1YoCJKP3fYzXdH531nG6u21u2Cuo= MIME-Version: 1.0 Received: by 10.216.160.70 with SMTP id t48mr3208318wek.82.1277343381040; Wed, 23 Jun 2010 18:36:21 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.216.52.145 with HTTP; Wed, 23 Jun 2010 18:36:20 -0700 (PDT) In-Reply-To: <20100612100006.000073fa@unknown> References: <20100612100006.000073fa@unknown> Date: Thu, 24 Jun 2010 04:36:20 +0300 X-Google-Sender-Auth: 47B02MGKjlsAQDkr6y-bWgzuzVg Message-ID: From: Mohammed Farrag To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Chargen , freebsd-hackers@freebsd.org, Matt Thyer , freebsd-current@freebsd.org, Mohammed@freebsd.org Subject: Re: I need reply in Embedded FreeBSD Kernel Theme X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 01:36:22 -0000 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 :) @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 @ 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 @ 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. @ bruce Thanx for ur reply.