From owner-freebsd-hackers Sun Jul 14 10:51:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA15568 for hackers-outgoing; Sun, 14 Jul 1996 10:51:29 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA15477 for ; Sun, 14 Jul 1996 10:51:17 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA20531; Sun, 14 Jul 1996 19:50:40 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA25114; Sun, 14 Jul 1996 19:50:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id TAA11956; Sun, 14 Jul 1996 19:30:47 +0200 (MET DST) From: J Wunsch Message-Id: <199607141730.TAA11956@uriah.heep.sax.de> Subject: Re: Preach it (was Some recent changes to GENERIC) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 14 Jul 1996 19:30:46 +0200 (MET DST) Cc: pjchilds@imforei.apana.org.au, jonny@gaia.coppe.ufrj.br (Joao Carlos Mendes Luis) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607141548.MAA19290@mailhost.coppe.ufrj.br> from Joao Carlos Mendes Luis at "Jul 14, 96 12:48:16 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Joao Carlos Mendes Luis wrote: (Moved to -hackers again, this is becoming technical.) > I was thinking about a completely different opioin this week. What if the > config program could make the kernel something like a microkernel ? For > example, suppose I want to build an embedded BSD (in EPROM) just to make > some kind of industrial process control. I would not need lots of things. > For example: SWAP, FS support (MFS and/or NFS only !), networking, console, > and maybe even some system calls could disappear. > > I have a friend making some tests on this and he cannot make something less > than 300K for the kernel. It' still too much for such an application. Uaah! I've just tried to configurate a `minimal' kernel, with just the following devices: isa0, fdc0, fd0, wdc0, wd0, sc0, npx0, sio0, sio1, sio2, sio3, lpt0 Only FFS configured, and no other pseudo-devices. First bummer: the kernel doesn't link. _netisr_set is undefined. After fiddling around, the following patch fixes this: Index: sys/i386/i386/machdep.c =================================================================== RCS file: /usr/home/cvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.192 diff -u -u -r1.192 machdep.c --- machdep.c 1996/06/08 11:03:01 1.192 +++ machdep.c 1996/07/14 17:13:35 @@ -40,6 +40,7 @@ #include "npx.h" #include "isa.h" +#include "ether.h" #include "opt_sysvipc.h" #include "opt_ddb.h" #include "opt_bounce.h" @@ -208,12 +209,14 @@ int cpu_class = CPUCLASS_386; /* smallest common denominator */ static void dumpsys __P((void)); +#if NETHER > 0 static void setup_netisrs __P((struct linker_set *)); /* XXX declare elsewhere */ +extern struct linker_set netisr_set; +#endif static vm_offset_t buffer_sva, buffer_eva; vm_offset_t clean_sva, clean_eva; static vm_offset_t pager_sva, pager_eva; -extern struct linker_set netisr_set; #define offsetof(type, member) ((size_t)(&((type *)0)->member)) @@ -271,10 +274,12 @@ } } +#if NETHER > 0 /* * Quickly wire in netisrs. */ setup_netisrs(&netisr_set); +#endif /* #ifdef ISDN @@ -460,6 +465,7 @@ } } +#if NETHER > 0 int register_netisr(num, handler) int num; @@ -486,6 +492,7 @@ register_netisr(nit->nit_num, nit->nit_isr); } } +#endif static struct cpu_nameclass i386_cpus[] = { { "Intel 80286", CPUCLASS_286 }, /* CPU_286 */ The fix is arguably bogus, but i found _netisr_set defined (for some obfuscated reason i couldn't examine) in if_ether.o in another kernel. So i assume it depends on NETHER. If somebody knows it better (and understands all the magic behind these linker sets), he should feel free to correct the above patch, and commit a fix (or submit it for committing). Still, the resulting kernel is: j@uriah 195% size kernel text data bss dec hex 434176 40960 25828 500964 7a4e4 The prime single offending object files by size are syscons.o, pmap.o, and userconfig.o. Umm, the latter is not even an option right now -- we bloat all our kernels with it, regardless of whether it's needed or not. Next attempt, use MFS (but no FFS), and isa0, npx0, sio0, sio1, sio2, sio3, lpt0. text data bss dec hex 393216 32768 22776 448760 6d8f8 Still pompous. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)