Basically I want to strip the system down as much as possible,

practically nothing would be good.

My GNU/Linux appliances ran on a 4MB system image.
On Thu, Mar 27, 2008 at 4:16 PM, Stephano Zanzin

Please don't insult OpenBSD by comparing with linux. ;)
Have you ever seen the source code of OpenBSD kernel?
Have you considered how the kernel build system is organized?
Have you seen the linux kernel source?
What do you mean by "practically nothing would be good"?
And oh by the way OpenBSD is not a kernel, it is an operating system and

many people still dunno the difference between the two.
You have the choice of putting "practically nothing" by choosing only

those distributions you want in the install stage.
Another thing you could do is take a look at crunchgen(1).
# cd /usr/src/distrib/crunch
# make
# make install
man crunchgen
It is only because linux kernel is so "modular" (laugh) that people want to

build their own kernel. And to tell you honestly I still dunno how to

compile and install a linux kernel. And it varies between distros to

make things worse.
And it is easier to compile an OpenBSD kernel than to compile a linux

userland app.
Please don't retrofit OpenBSD to fit into the linux mould. It is

unfortunate that such garbage like linux is so popular.
I guess people do not read the kernel source. 
But the world always had more fools than smart people...
-Girish

I asked a perfectly valid question about whether or not that error I'm

getting is due to that function call being GNU only and therefor being

missing from the OpenBSD libc, now can someone answer that?
I do NOT want to to tarnish all OpenBSD users with this brush I used

below with my response to Girish, I've included it for interests sake

in case anyone wants to read it. I do NOT want to start a flame war I

just want a question answered and to be really honest I would still

like to use OpenBGP.
----=========  Pointless flame to an idiot, please ignore unless you

want a laugh  =========----
On Fri, Mar 28, 2008 at 12:20 AM, Girish Venkatachalam

It's a UNIX-like system is it not? Therefor comparisons are valid,

Yes, I have worked extensively with various BSD Net/2 derived kernels.

As I mentioned earlier the embedded UNIX industry has been my employer

Yes I have and I have a good reason for finding the system

Yes and I've had issues with it and spent a lot of time rewriting

memory management routines to better suit my uses.

I'm quite well aware of that,... however its mainly only the kernel

I'm interested in,... I'm quite willing to build and support my own

I have used crunchgen before with my tiny NetBSD systems.

However there is only so much that crunchgen can do if the source

Just blindly using the GENERIC kernel on you're OpenBSD install CD

(you did buy one right) is daft.

My home firewall has a very cut down kernel on it that only includes

what I want in it. Why bloat it with drivers/etc I don't need?

Yes my home firewall is an OpenBSD-current box,... I think thats going

    ./configure

    make

    make install

Mmmmmmmmm funny haven't seen any *BSD phones yet, or Oracle/Sybase IQ

for BSD yet.

It's popular because of two things,... people are willing to work

together (unlike the OpenBSD people it seems) and its malleable to an

Oh I do and its precisely because I liked it that I'm considering

Arrogance like this is PRECISELY why I'm going to go back to the

NetBSD/Linux ca...
[ message continues ]

On Fri, Mar 28, 2008 at 2:47 AM, Ross Cameron <ross.cameron@linuxpro.co.za>
Ummm, yes, we do trust the GENERIC kernel from the OpenBSD install CD.  It's

meant to be used, why wouldn't we use it?
I agree with some of your points but when you talk like this you sound like
Who freakin' cares?  You probably realize that popularity doesn't guarantee

quality.
Greg
--

Bicycle fun ride in the middle of nowhere:

http://lodesertprotosites.org/pokerrun/pokerrun.html

http://ticketmastersucks.org

Dethink to survive - Mclusky

> ... using the GENERIC kernel ...
I'll answer because I floated a poorly framed question like this one

earlier.  The second part of my answer is probably more useful.
1) A lot of thought and planning goes into the GENERIC kernel and the

final arrangement is a source of pride.  So if it's matter of trusting

the code then it is still possible, if you have the time, resources or

skill, to do your own code audit and still have a GENERIC kernel.
Staying with the GENERIC configuration allows your feedback regarding

kernel function to contribute to the activities and functions being

focused on in the project.  Deviating from the GENERIC configuration

means that the trouble of sorting out your problems from those of the

GENERIC configuration is too much trouble, and you are on your own.
However ...
2) One thing that may not be visible enough is that config(8) can be

used to modify kernel parameters without needing to recompile.  That

gives you a fair amount of customization without deviating from the

GENERIC configuration.
It is possible to make modifications to the currently running kernel as

well as to save these changes in the form of a new kernel binary so that

the changes stay even after system restarts.
See the section "kernel modification" in config(8) for more info:

	http://www.openbsd.org/cgi-bin/man.cgi?query=config
Regards,

-Lars

One thing I'm not clear on: if the only issue is kernel size based on

having an old box with low memory, where every MB counts, does

deactivating unnecessary drivers with config actually result in a

smaller kernel or just a kernel with deactivated drivers?  Shrinking the

kernel would be the only reason I would have of touching the kernel as

I'm not into trying out experimental features.  It would be too bad if

config doesn't do this.
Doug.

Douglas A. Tutty wrote:
config strictly deactivates the drivers, it doesn't reduce memory

consumption or disk footprint.
WELL...there MIGHT be a small savings in data structures not allocated

for drivers, but that would most likely only be the case if you had such

a device in the machine, but deactivated the driver. (i.e., em(4) (the

driver) might allocate a RAM buffer for each em(4) card in the machine,

but only for the cards in the machine...disable the driver, you don't

allocate the buffers, but you can't use the card).
Since OpenBSD uses a monolithic kernel, it is outside the ability of

config to physically remove the deactivated drivers.  That would be a

funky kind of relinking, or a bunch of loadable modules, ala Windows or

Linux, which is why Windows and Linux needs so much less RAM than

OpenBSD.  Oh..wait... ;)
Removing drivers for reduced memory is really a "for advanced users

only" task, and you VERY QUICKLY run into diminishing returns.  One

problem is you almost certainly need another computer -- if you have

16M RAM, you want to whittle down the kernel a lot...but $DEITY help

you if you need to build that new kernel on that machine, since just

sitting at the shell prompt will have you into swap.  HOWEVER, by

the time you get to 32M, I doubt you will appreciate the time and

effort required to build and reboot off a new kernel (even if compiled

on another machine).  You just won't be adding much functionality to

the machine -- there won't be something major you will suddenly be

able to do that you couldn't do before.
Nick.

Digressing slightly into config and what's in the FAQ regarding why or

why not to deviate from GENERIC...
Using config to modify the GENERIC kernel's settings can apparently

improve boot speed.  So maybe config should be mentioned in section 5.6

of the FAQ, "Why do I need a custom kernel?" to steer those wondering

about improving boot time away from trying unnecessarily to create a

custom kernel.
e.g. for B' 5.6, "Why do I need a custom kernel?"
	Removing device drivers may speed the boot process on

	your system, but can complicate recovery should you have

	a hardware problem, and is very often done wrong.  config

	can be used instead of re-compiling to modify kernel parameters

	and speed booting.  See the section of the config(8) man page
That could also be useful to have in the FAQ somewhere.  It's explicit

in the kernel's nature, but could be mentioned for those who miss the
That can be emphasized more heavily by moving forward one sentence in

section 5.6, and adding that in.
e.g. for the very start of B' 5.6:
	"Actually, you probably don't.  Only the most advanced and

	knowledgeable users with the most demanding applications

	need to worry about a customized kernel or system, and even

	then you very quickly run into diminishing returns."
Regards,

-Lars

no, for the same reason that people should not recompile a kernel.
you might end up disabling something you need.
Lars, the FAQ, this list, they are really for people who need help, not

for people to tweak their machines for silly reasons.
you say, "config makes me boot faster."  so then people go and config

their kernel, and then we get problem reports about broken kernels.
that's fine if you want to go break your machines.  don't try telling

others to do the same.
--

jakemsr@sdf.lonestar.org

SDF Public Access UNIX System - http://sdf.lonestar.org

I disagree,... this form of knowledge sharing amongst more advanced

users of any OS should be encouraged.

Perhaps there is merit in it in a wider context,... we wont know

unless such things are discussed and debated.

    Simply poh pohing it out of hand without wider discussion

throughout the user base is foolish at best.

Yes, and the knowledge among the more advanced users is "don't do it". So
Oh, really. And you think that we haven't discussed this for the past

10 years? all over the mailing lists. 
//art

On Mon, Mar 31, 2008 at 3:47 AM, Ross Cameron <ross.cameron@linuxpro.co.za>
Unfortunately, a lot of !advanced users will also experiment, and then come

back with "it's broken, fix it".   For advanced users who like to tinker,

OpenBSD's support model is /usr/src/.  Unfortunately, too many people who

think they can mangle config means that they are "advanced (l)users".
In my experience, it's simply a matter of experience and resources, and the

OpenBSD project as a whole is very unhappy with supporting users who insist

on playing with "ooo, shiny, I need another 1% of performance", or "I can

get my kernel down to 3,467,296 bytes with stupid kernel tricks!"
It all boils down to the old "doctor, doctor, it hurts when I do that"

joke.  OpenBSD is just being proactive in telling the users 'don't do that'.
On the other hand, people like you do have legitimate needs, and it's up to

the developers to see if they can support you.
--

http://www.glumbert.com/media/shift

http://www.youtube.com/watch?v=tGvHNNOLnCk

"This officer's men seem to follow him merely out of idle curiosity." --

Sandhurst officer cadet evaluation.

"Securing an environment of Windows platforms from abuse - external or

internal - is akin to trying to install sprinklers in a fireworks factory

where smoking on the job is permitted." -- Gene Spafford

learn french: http://www.youtube.com/watch?v=j1G-3laJJP0&feature=related

please learn to use the archives before saying whether or not something

has been/needs to be discussed.
--

jakemsr@sdf.lonestar.org

SDF Public Access UNIX System - http://sdf.lonestar.org

I know that on a regular i386 machine, its far easier to add a bit of

ram than to fitz with the kernel.  I had seen on this list a while ago

someone needing to fitz with the kernel for putting OBSD on some

imbedded device.  He (she?) wasn't building on the imbedded device, just

wanted to pare down memory usage as much as possible.
So perhaps to add to this entry for the FAQ, something that address this

desire to shrink the kernel to save memory:
	"... For standard i386 old computers with little ram,

	recompiling the kernel does not provide enough free memory to

	affect what you can then do with that old computer.  You are far

	better to just add a bit more ram."
I know that other distros have dropped actual 386 CPUs from their

supported list so that i386 actually needs minimum 486.  The reasoning

I've heard is that the amount of memory required is too much for any

remaining actual 386 boxes to actually have.
I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per

MB) and I think it could take a maximum 16 MB (but my memory from 1988

is very fuzzy).  Where there any 386 boxes that could take 32MB ram, and

do any still exist?
Doug.

Douglas A. Tutty wrote:
Same thing was done recently with OpenBSD, actually.  There are better

reasons, however... The big one was the 80386 was a "first generation"

32 bit processor for Intel, and there were a lot of ugly work-arounds

in the OpenBSD kernel for 80386 systems that didn't need to be there

for 80486 and later systems. Dropping support for the 80386 simplified

the kernel code, and as we know, that's a very good thing.
There were some practical reasons why you don't want to use OpenBSD on

an 80386 system:
1) OpenBSD /requires/ a hardware FPU.  The 80386 chip did not have it,

you needed to add-on an 80387 Math coprocessor, and a relatively small

number of 80386 machines had this.
2) There are things we "just do" today that were big deals back in the

80386 and before days, simple little things like compressing a file.

Simply loading an 80386 system with OpenBSD was an all-day affair, due

mostly to the time required to uncompress the *.tgz files!
3) IDE disks were not common on 80386 systems.  You don't want to try

to install OpenBSD on an MFM or ESDI drive.  Even what should have

been an easy retrofit was complicated by inflexible BIOSs.
4) 16M RAM was almost unheard of back then...and many of the 80386

systems of the day were using different RAM than more modern systems

do, so the likelihood that you had an OpenBSD-capable 80386 was

very low, and upgrading it to being OpenBSD-capable was cost-prohibitive.
When this was done, no one had been sending in 80386 dmesg's for a long

time.  Even before then...the 80386 code spent some time broken around

the 3.3 days..and only a couple people had even noticed (we didn't even

realize it wasn't broke machines until we realized that several people
oh, most certainly.

The VERY FIRST generation of non-IBM-brand 80386 (i.e., Zenith, Compaq,

AST, etc.) systems were basically 80286 systems with a faster processor

and almost everything else carried over from the 80286 siblings.

However, by the time the second generation...
[ message continues ]

I think it more likely that most people bought the 386SX because they

didn't have much money rather than they didn't need much speed.  That's

certainly the reason I and a couple of friends did.  There was also the

80386SL variation which used less power and was particularly good for

laptops.  As it happens I bought three 80387SL FP co-processors, for my

Toshiba T3300SL laptop, for my desktop and one as a Christmas gift.  It

made a huge difference in number-crunching times.  (The 80387SL seems to

have replaced the 387SX rather early.)  The laptop dual-booted DOS and

COHERENT, a commercial 16-bit UNIX-like operating system.  When there

were no readily-available 32-bit OSs, the 386SX/SL processors seemed to

make sense.  No good reason for them later...
Emilio

I believe it was mentioned aways back in the message stream, but perhaps

it's worth reconsidering at this juncture...
Keep the low emi/rfi 386 machine user-proximity but convert it to an X

server with the more capable X client (app server) machine farther away.
-----Original Message-----

From: Douglas A. Tutty <dtutty@porchlight.ca>

To: misc <misc@openbsd.org>

Subject: Re: configuring the GENERIC kernel (was Re: Issue compiling a

program on OpenBSD)

Date: Sun, 30 Mar 2008 13:12:57 -0400

Mailer: Mutt/1.5.13 (2006-08-11)

Delivered-To: 8f27e956@gmail.com
I know that other distros have dropped actual 386 CPUs from their

supported list so that i386 actually needs minimum 486.  The reasoning

I've heard is that the amount of memory required is too much for any

remaining actual 386 boxes to actually have.
I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per

MB) and I think it could take a maximum 16 MB (but my memory from 1988

is very fuzzy).  Where there any 386 boxes that could take 32MB ram, and

do any still exist?
Doug.

Sure that suggestion was made.  Currently, the X server is my Athlon64

and is 60 feet away from my wife and its still too close.  I have been

given a dual P-133 Tyan board which will become the

application/file/whatever server and we'll see how close to it my wife

can be once I get it set up in a good steel case (I'm looking at

addtronics steel cases since this board is Baby-AT).  I'll save the

Athlon box for things that only it can do conveniently (editing or

retouching picture, watching DVDs, graphical web-browsing).
Note that none of my old boxes are low enough in RAM to need a custom

kernel.  The Tyan board will take a max of 512 MB (8 x 64 MB EDO ECC

SIMMS) once I get them.  My IBM 486 takes 4 x 32 MB once I get them.

The biggest issue is boot drives: I may be using CF cards for boot and

then adding a scsi card to the Tyan and use SCSI drives for the data

archive.
Doug.

if your machine is low enough on ram that you would even consider

recompiling a kernel, just to save ram, it's time to retire

the machine.
--

jakemsr@sdf.lonestar.org

SDF Public Access UNIX System - http://sdf.lonestar.org

I'd disagree VERY strongly there,... there are LOTS of low spec (yet

industrial tolerance) hardware appliances out there (and I spend

almost my entire live working on this kind of hardware.

    The malleability and source availability of the free UNIX-like

systems is what allows one to use these platforms in the first place.

Imagine trying to get Microsoft or Sun to produce an OS for you that

runs on a 486dx100?

great.  you know what you're doing (presumably).  this discussion is

not about such hardware, nor about such situations.
the thing is, if you do such things, you _BETTER_ know what you're

doing, because you are "on your own".  do not expect help from

here.  and definitely _DO NOT_ try to hide that you have made such
there are "distros" based on OpenBSD specifically for such purposes.

discussions about tweaking your kernel for such situations are

probably much more acceptable there.
I think people don't comprehend how small the OpenBSD developer community

is compared to, oh, let's say linux.
--

jakemsr@sdf.lonestar.org

SDF Public Access UNIX System - http://sdf.lonestar.org

That's for him to decide, not you.  It's his machine, and it might be a

fairly good one at that, despite being small or old.  If you do not know

the answer to the question, it is acceptable to be quiet.
My machines have more than enough RAM, but what he brings up is an

interesting question: "does deactivating unnecessary drivers with config

actually result in a smaller kernel or just a kernel with deactivated

drivers?"
I'll have to schedule time to try two kernels, one with more

deactivated, and compare their resource usage.  The deactivation via

config(8) definitely speeds up the boot process significantly on the

slow units.
Regards,

-Lars

well no fucking shit, Lars.
it was a suggestion.
--

jakemsr@sdf.lonestar.org

SDF Public Access UNIX System - http://sdf.lonestar.org

Linux fanbois are annoying.  So are OpenBSD fanbois.
On Thu, Mar 27, 2008 at 6:20 PM, Girish Venkatachalam <
--

http://www.glumbert.com/media/shift

http://www.youtube.com/watch?v=tGvHNNOLnCk

"This officer's men seem to follow him merely out of idle curiosity." --

Sandhurst officer cadet evaluation.

"Securing an environment of Windows platforms from abuse - external or

internal - is akin to trying to install sprinklers in a fireworks factory

where smoking on the job is permitted." -- Gene Spafford

learn french: http://www.youtube.com/watch?v=j1G-3laJJP0&feature=related