Sponsored Content
Full Discussion: Building Light weight Distro
Top Forums Shell Programming and Scripting Building Light weight Distro Post 302813495 by Corona688 on Monday 27th of May 2013 11:54:42 AM
Old 05-27-2013
Quote:
Originally Posted by kg_gaurav
My question is how can we build such a light distribution when just kernel comes in 50+mb.
The kernel is not 50 megabytes, more like 5.

If the kernel is built with every possible device driver that's an awful lot of modules, but 50 megabytes still seems like an awful lot. Don't mistake the source code for the kernel itself -- you don't need the .c files to make the system boot. A light distro just gives you the binary part.
 

2 More Discussions You Might Find Interesting

1. Infrastructure Monitoring

Light-weight alternative to `df` (without SNMP)

Overview: I'm looking for a way to get usage data for all mount points (UFS,VxFS & NFS) on a Solaris system. I'm starting with `df` but would like to find something that might be more light-weight. Background: Using SNMP is not an option in this case, instead I need to use basic built-in... (2 Replies)
Discussion started by: seg
2 Replies

2. Solaris

How to simulate light weight process (LWP)?

Hello, We had a problem on a Solaris system (SunOS 5.10) that hit LWP limit and caused fork 11 error. Now we need to come up with a script to simulate and reproduce that scenario. What would be a simple and valid way to generate lots of Light Weight Processes? Thanks, Jay (1 Reply)
Discussion started by: seafan
1 Replies
INTRO(9)						   BSD Kernel Developer's Manual						  INTRO(9)

NAME
intro -- introduction to system kernel interfaces DESCRIPTION
This section contains information about the interfaces and subroutines in the kernel. PROTOTYPES ANSI-C AND ALL THAT Yes please. We would like all code to be fully prototyped. If your code compiles cleanly with cc -Wall we would feel happy about it. It is important to understand that this isn't a question of just shutting up cc, it is a question about avoiding the things it complains about. To put it bluntly, don't hide the problem by casting and other obfuscating practices, solve the problem. INDENTATION AND STYLE
Believe it or not, there actually exists a guide for indentation and style. It isn't generally applied though. We would appreciate if people would pay attention to it, and at least not violate it blatantly. We don't mind it too badly if you have your own style, but please make sure we can read it too. Please take time to read style(9) for more information. NAMING THINGS
Some general rules exist: 1. If a function is meant as a debugging aid in DDB, it should be enclosed in #ifdef DDB #endif /* DDB */ And the name of the procedure should start with the prefix DDB_ to clearly identify the procedure as a debugger routine. SCOPE OF SYMBOLS
It is important to carefully consider the scope of symbols in the kernel. The default is to make everything static, unless some reason requires the opposite. There are several reasons for this policy, the main one is that the kernel is one monolithic name-space, and pollution is not a good idea here either. For device drivers and other modules that don't add new internal interfaces to the kernel, the entire source should be in one file if possi- ble. That way all symbols can be made static. If for some reason a module is split over multiple source files, then try to split the module along some major fault-line and consider using the number of global symbols as your guide. The fewer the better. SEE ALSO
style(9) HISTORY
The intro section manual page appeared in FreeBSD 2.2. BSD
December 13, 1995 BSD
All times are GMT -4. The time now is 02:52 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy