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

Re: SEUL: Auto-compilation/Is it possible ?



   Delivered-To: jfm@sidney.remcomp.fr
   X-Authentication-Warning: mail.txcc.net: majordomo set sender to owner-seul-project using -f
   X-Mailer: exmh version 2.0gamma 1/27/96
   Cc: "Aldo-Pier Solari" <solaris@fobos.ulpgc.es>
   Date: Sat, 09 Aug 1997 00:10:16 -0700
   From: Erik Walthinsen <omega@aracnet.com>
   Sender: owner-seul-project@mail.txcc.net
   Precedence: bulk
   Reply-To: seul-project@seul.org
   X-UIDL: 2d72ccd717206f71c2e0a197cd23ca5a


   > Is is possible to have a kind of 'point'n'click' function to get the 
   > SEUL/Linux kernel 'auto-compiled' for the particular 
   > machine/processor/RAM/etc. a particular user may have ?

   It would almost be trivial, once the appropriate data is gathered for the 
   system.  The system would run a completely modular kernel on install, then 
   once it has figured things out it could schedule a true background kernel 
   build.

   First, the build:  A good way to do this would be to have a standard config 
   that is completely modular, then apply diffs for the hardware in question.  
   In other words, the standard config has, say, the 3c905 driver built as a 
   module.  If the user has a 3c905, the build would have that built into the 
   kernel.

   In reality, only a few drivers would need to be built into the kernel, mostly 
   ether and scsi drivers.  Everything else would stay modular, as modular 
   kernels are generally considered '*the* way to go'.  The main reason to build 
   a 'custom' kernel is to eliminate things that the user doesn't need, such as 
   multiport cards, and change certain things, like the chip that's being built 
   for (Pentium vs. 386 does improve performance some...).

Another soltion is to provide one "universal" kernel for the install
(and as a backup), and some optimized kernels the user (or a program
reading /proc) would choose for normal use.  With modules you don't
need much more than about half a dozen kernels to cover all the needs.

   Now to the scheduling for background build part:  As part of the admin 
   backend, the system will be doing a lot of automatic things.  Some of these 
   will be quite lengthy, which the user doesn't want to sit through.  Examples 
   of these in the Doze* environment include booting, disk defrag, etc.  As we 
   happen to have a *real* OS, we can do these in the background.

   What could be done is to schedule a process (make zImage) with a really low 
   priority (nice 20, or even better).  Some time after the admin backend starts 
   learning usage patterns (yes, a little AI will do us a lot of good), it can 
   start a kernel build.  Due to the nature of make, this can be stopped at any 
   point and restarted later, assuming the clock retains it's setting.

   Now the AI part...  Not really AI, more of a high-level record of who does 
   what, when, etc.  Record when each user logs in and out, what kind of apps 
   they use, etc.  This data will not be sent to a central repository, like an 
   un-named Redmond-based company is rumored to have coded into their "OS".  
   Rather, it will be used to allow the computer to function somewhat more 
   usefully.  The current example is the building of a kernel.

   Say our user has a certain schedule.  He gets up in the morning, resumes
   (APM) his system and has it configured (via more pseudo-AI stuff) to connect
   and retrieve mail at that time.  He goes and makes coffee, comes back and 
   reads his mail.  He then logs out, suspends the box, and goes to work.

   In this example, the admin backend would have gathered enough data (assuming 
   a pattern develops) to know to *not* kick off the kernel build, or anything 
   else that's scheduled for background, during this time.  The time it uses to 
   start the build would be after dinner, around 7:00pm, when the user in 
   question checks his mail, reads through usenet, and surfs a little.  Nice low 
   utilization (except for Navigator) time that can be used without impacting 
   the user.

   OK, I may be crazy (in fact, I know I am), and this may be a stupid idea.  In 
   that case, please break the news to me kindly.  If it's a good idea, be loud
   and verbose in your praise...  8-)

   (Muhahahahah! Hey, why the straightjacket? He.!.mmmfff! Mmmmfffmmff! ????)

Yes.  You are crazy.  You need an electroshock.  Shutdown your
computer (to avoid data corruption).  Plug it out.  Then insert your
fingers in the plug.  Wait a couple of minutes.  Remove your fingers
from the plug.  It works better with the 220V we have in Europe.  :-)

People using their computers at home do not let their computers
powered during the night.   They pay the bills.

Building a kernel takes 12 minutes on a P75.  So put an OPTIMIZE
KERNEL entry in the root menus and if clicked present the user with a
simplified version of xconfig: CPU can be autodetected (well Intel
CPUs) and we will be using modules, so the only choices the user will
have to do would be about non-modular, non-autodetectable things.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================

----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------