Kernel options

[MrMoo]

Is there a rational over the current kernel options?  It seems some are a bit dubious, especially on the embedded platform.  The caveat emptor is whether it actually makes a remote iota of a difference in image size or memory usage.

For example:

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

Creates a bigger kernel we could do without on a small device.

options 	PREEMPTION		# Enable kernel thread preemption

On Linux maximum performance is lower with kernel pre-emption enabled, the same on BSD?

options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options 	NFSCLIENT		# Network Filesystem Client
options 	NFSSERVER		# Network Filesystem Server
options 	NFS_ROOT		# NFS usable as /, requires NFSCLIENT
options 	MSDOSFS			# MSDOS Filesystem
options 	GEOM_GPT		# GUID Partition Tables.
options 	SCSI_DELAY=5000		# Delay (in ms) before probing SCSI

# Bus support.  Do not remove isa, even if you have no isa slots
device		eisa

# ATA and ATAPI devices
...

# SCSI Controllers
...

# SCSI peripherals
...

# RAID controllers interfaced to the SCSI subsystem
...

# RAID controllers
...

# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support
device		cbb		# cardbus (yenta) bridge
device		pccard		# PC Card (16-bit) bus
device		cardbus		# CardBus (32-bit) bus

# Parallel port
device		ppc
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer
device		plip		# TCP/IP over parallel
device		ppi		# Parallel port interface device
#device		vpo		# Requires scbus and da

# FireWire support
device		firewire	# FireWire bus code
device		sbp		# SCSI over FireWire (Requires scbus and da)
device		fwe		# Ethernet over FireWire (non-standard!)

Are any of these actually used?  I can see NFSCLIENT / NFSROOT being handy for a PXE developer build, and the ATA for VMware and maybe with a Soekris and a USB HDD?

[sullrich]

You are looking at the wrong kernel?  I don't see any debugging info in pfSense_wrap.6

[MrMoo]

Aya, too many kernel configs in CVS, I was looking here:

http://cvstrac.pfsense.com/fileview?f=freesbie/files/pfSense_wrap.6&v=1.11

Instead of here:

http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense_wrap.6?rev=1.29

:D

[MrMoo]

Kernel packages:  I'm wondering through my directory server and covering all the options available, updating some details here, hopefully all on my own website when its working.  I think i'm repeating Manuel Kasper and working on a m0n0bsd core and building the application on top of that.  Currently after playing way too long on the kernel build options I am thinking from a user point of view these are nice packages:

embedded
generic
enterprise

embedded developer
generic developer
enterprise developer

Where generic = embedded + VGA + IDE + CD-ROM + keyboard + USB + Firewire, enterprise = generic + scsi + raid, and developer += nfs + debug + ktrace.

I'm working on the general developer options are 1)  chroot,  2)  vmware,  3)  pxe boot + nfs root,  and 4)  installed.

I would imagine a lot of debate of options has preceeded similarly for any normal O/S distribution and that scsi/raid can easily be merged with the generic set.  For FreeBSD I could see this as more advantageous if the SCSI settle time wasn't mandatory even if you have no SCSI cards installed?

[sullrich]

@MrMoo:

Kernel packages:  I'm wondering through my directory server and covering all the options available, updating some details here, hopefully all on my own website when its working.  I think i'm repeating Manuel Kasper and working on a m0n0bsd core and building the application on top of that.  Currently after playing way too long on the kernel build options I am thinking from a user point of view these are nice packages:

You may want to take a look at FreeSBIE 2 a little closer before making your decision.

[MrMoo]

I'm working on FreeSBIE now, it appears you are not using ccache to help buildworld, do you have a really fast build machine?  I'm very tempted to setup distcc to help out too.

[sullrich]

Make sure its FreeSBIE 2.  It's much better.

My machine is modest, P4 3.2 with 3ware raid 10 (4 drives).

[billm]

@MrMoo:

I'm working on FreeSBIE now, it appears you are not using ccache to help buildworld, do you have a really fast build machine?  I'm very tempted to setup distcc to help out too.

We tried out distcc across a three machine dual proc 3ghz xeon farm…it cut down the build from 50 minutes on the current hardware to around 20...wasn't worth the speed improvement (considering it added 20 minutes xfer time b4 it could be tested).

--Bill

[MrMoo]

There appear to be no CFLAGS in the pfSense make.conf.embedded, would it be more adviseable to use the following:

CPUTYPE?=i486
CFLAGS= -Os -pipe

That's optimising for smallest size and 486 architecture to help out the WRAP/Soekris boxes.  Its a bit tedious to prove one way or another I guess though  :(

[sullrich]

Yes, I don't want my nexcom units that run embedded to be optimized in that fashion.  It's a hard balancing act unfortunately.

[MrMoo]

And so the choices are either 1) default to pentium optimisations like a lot of commercial software, 2) default to a high cpu (pentium4) to tweak extra performance, 3) offer a lot more packages.

I think it all comes down to real world tests, I know from a highspeed messaging company they only recently moved from 486 to pentium optimisations, so that apart from the Gentoo fan set its not overly beneficial.  If the performance tweaks are needed to run your machines you are badly specifying your hardware.  The conclusion from that would be to run with the lowest common denominator for the supported hardware set which instead would be:

CPUTYPE?=i486
CFLAGS= -O -pipe

One possble alternative is to merge alternative kernels into pfSenses package system, i.e. download an optimised kernel for your configuration option.

[sullrich]

@MrMoo:

One possble alternative is to merge alternative kernels into pfSenses package system, i.e. download an optimised kernel for your configuration option.

We too can be ricers.  Not sure that I like this.