Archive for October 27th, 2006

Posted on Oct 27th, 2006

Ever since my college days, I always loved to have my own compiled kernel. It gave me that special feeling of "my machine is better than yours". I am sure each time my new kernel boots up the feeling I have is is the same as what Super Man has when he bashs up the bad people.

A custom kernel boots up the system faster, it takes up lesser memory space and one can install drivers for hardware not supported by a default kernel. Besides these benefits, a custom kernel serves as an interesting conversation topic with geeks. Just ask them "What is your kernel size ?". This would keep the Geek busy for sometime where he would explain all the great things he did to the kernel options to optimize his box.
If you happen to be a geek yourself, this is a great question to put forward to those lowly Nubies. They’ll never trouble you with stories of their nephew or kid sister after this :-D

Before we get down to compiling our own kernel, it is a wonderful idea to backup the present kernel.
# cd /boot
# cp -pvr kernel kernel.orig

The original generic kernel is now stored as kernel.orig. In case the kernel does not boot (which has happened with me many times) boot up with the generic kernel and try again. Booting any other kernel is simple. At the boot time goto to the boot prompt and simple say "boot kernel.orig" and the default kernel would boot up.

The kernel sources are located in the /usr/src/sys directory. If not installed, the kernel sources can be installed with the following commands. First insert the FreeBSD install CD in your CD drive.

# mount /cdrom# mkdir -p /usr/src/sys# ln -s /usr/src/sys /sys# cat /cdrom/src/ssys.[a-d]* | tar -xzvf - 

Then go to the director where the configuration files are located.

#cd /sys/i386/conf

In this directory the GENERIC kernel configuration file is located. Copy this file and it as your custom name.

#cp -pvr GENERIC BABYBSD
# vi BABYBSD

First change the ident value from GENERIC to BABYBSD (or whatever name you prefer). I have given my sample configuration file at the end of this article. The options are quite easy to understand and a good starting point would be the FreeBSD Handbook which has documented most of the kernel options.
You can also go to a shell and run the command #make LINT in this directory which would create a file called LINT which has all the options supported by the kernel listed.

After this stage just run the following commands

#/usr/sbin/config BABYBSD
#cd ../compile/BABYBSD
#make depend
#make
#make install

Please note that you must be root to run the make install. Reboot and the kernel should boot with your shining new kernel. :-)



# My Sample Kernel Configuration File for FreeBSD/i386

machine i386
cpu

I586_CPU
cpu

I686_CPU
ident

BABYBSD

options SCHED_4BSD

# 4BSD scheduler
options INET

# InterNETworking
options INET6

# IPv6 communications protocols
options FFS

# Berkeley Fast Filesystem
options SOFTUPDATES

# Enable FFS soft updates support
options UFS_ACL

# Support for access control lists
options UFS_DIRHASH

# Improve performance on big directories
options MD_ROOT

# MD is a potential root device
options NFSCLIENT

# Network Filesystem Client
options NFSSERVER

# Network Filesystem Server
options NFS_ROOT

# NFS usable as /, requires NFSCLIENT
options MSDOSFS

# MSDOS Filesystem
options NTFS
options CD9660

# ISO 9660 Filesystem
options PROCFS

# Process filesystem (requires PSEUDOFS)
options PSEUDOFS

# Pseudo-filesystem framework
options GEOM_GPT

# GUID Partition Tables.
options COMPAT_43

# Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4

# Compatible with FreeBSD4
options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI
options KTRACE

# ktrace(1) support
options SYSVSHM

# SYSV-style shared memory
options SYSVMSG

# SYSV-style message queues
options SYSVSEM

# SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT # Print register bitfields in debug

# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT # Print register bitfields in debug

# output. Adds ~215k to driver.
options ADAPTIVE_GIANT

# Giant mutex is adaptive.

device apic

# I/O APIC

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

# Floppy drives
device fdc

# ATA and ATAPI devices
device ata
device atadisk

# ATA disk drives
device atapicd

# ATAPI CDROM drives
options ATA_STATIC_ID # Static device numbering

# SCSI peripherals
device scbus

# SCSI bus (required for SCSI)
device ch

# SCSI media changers
device da

# Direct Access (disks)
device cd

# CD
device pass

# Passthrough device (direct SCSI access)
device ses

# SCSI Environmental Services (and SAF-TE)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc

# AT keyboard controller
device atkbd

# AT keyboard
device psm

# PS/2 mouse

device vga

# VGA video card driver

device splash

# Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device sc

# Enable this for the pcvt (VT220 compatible) console driver
#device vt
#options XSERVER

# support for X server on a vt console
#options FAT_CURSOR # start with block cursor

device agp

# support several AGP chipsets

# Floating point support - do not disable.
device npx

# Power management support (see NOTES for more options)
#device apm
# Add suspend/resume support for the i8254.
device pmtimer

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the ‘device miibus’ line in order to use these NICs!
device miibus

# MII bus support
device rl

# RealTek 8129/8139

# Wireless NIC cards
device wlan

# 802.11 support

# Pseudo devices.
device loop

# Network loopback
device mem

# Memory and kernel memory devices
device io

# I/O device
device random

# Entropy device
device ether

# Ethernet support
device sl

# Kernel SLIP
device ppp

# Kernel PPP
device tun

# Packet tunnel.
device pty

# Pseudo-ttys (telnet etc)
device md

# Memory "disks"
device gif

# IPv6 and IPv4 tunneling
device faith

# IPv6-to-IPv4 relaying (translation)

# The `bpf’ device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that ‘bpf’ is required for DHCP.
device bpf

# Berkeley packet filter

# USB support
device uhci

# UHCI PCI->USB interface
device ohci

# OHCI PCI->USB interface
device ehci

# EHCI PCI->USB interface (USB 2.0)
device usb

# USB Bus (required)
#device udbp

# USB Double Bulk Pipe devices
device ugen

# Generic
device uhid

# "Human Interface Devices"
device ukbd

# Keyboard
device umass

# Disks/Mass storage - Requires scbus and da
device ums

# Mouse

# Specific to my Machine
device atapicam # for CD Writer to be detected by K3B and other CD writing software
device sound

# To Enable Sound
device "snd_ad1816"
device "snd_als4000"
device snd_cmi
device "snd_cs4281"
device snd_csa
device "snd_ds1"
device "snd_emu10k1"
device "snd_es137x"
device snd_ess
device "snd_fm801"
device snd_gusc
device snd_ich
device snd_maestro
device "snd_maestro3"
device snd_mss
device snd_neomagic
device "snd_sb16"
device snd_sbc
device snd_solo
device "snd_t4dwave"
device "snd_via8233"
device "snd_via82c686"
device snd_vibes
device snd_uaudio
device pcii
device acpi
device acpi_asus
device acpi_video

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

options DEVICE_POLLING
options HZ=1000
options PERFMON
device apm_saver # Requires APM

options AUTO_EOI_1
options AUTO_EOI_2

options VESA


Posted on Oct 27th, 2006

So, why should you use any O/R mapping tool? I am not talking about a specific tool but rather all O/R mapping tools in general. There are a number of reasons for using an O/R mapping tool but before I dive into that, let me give you a brief overview of what an O/R mapping tool really is.

An O/R mapping tool generates persistence objects for your .NET application. It is a modeling and code generation tool that connects to your database and reads its schema, then lets you map objects to database tables and views, specify single-row insert, update, load, and delete operations, queries and stored procedure calls, as methods to these objects. And, it also lets you define one-to-one, one-to-many, many-to-one, and many-to-many relationships between objects based on relationships between tables in the database. It then generates fully working persistence objects code for you.

There are many other features that a good O/R mapping tool provides but I’m keeping my description brief so I can talk more about the benefits.

Reason 1: Cuts down your development time

First benefit of an O/R mapping tool is that it saves you a ton of development time (20% to 50% time depending on your situation). Now, O/R mapping tool is not generating any “rocket science” code for you and you could definitely do it manually if you wanted. But, this is a lot of tedious work and you would definitely be happier if you didn’t have to do it yourself. Let’s do some simple math.

A typical application with 15-20 database tables has 30-50 objects (including domain and factory objects) and this is roughly 5000 to 10,000 lines of code. It is likely to take you a few weeks to a couple of months to develop and test this code. And, if your application has more tables than this (which many do), then just multiple the above numbers by that much.

On the other hand, an O/R Mapping tool would generate this code for you in a day or two. Even here, you need these 1-2 days primarily to determine your object mappings to the database. The actual code generation is instantaneous. So, your time saving is tremendous.

Reason 2: Produces better designed code

Second benefit of an O/R mapping tool is that it lets you produce better designed code than doing it yourself by-hand. I know what you’re thinking. You think you can do a better job than an O/R mapping tool because you write every aspect of your code. Some of you definitely can but not everyone. Consider this. An average development team has different levels of expertise and experience and not everybody is a good designer. As a result, they may not follow design patterns in their code and end up with a lesser quality code. And, if multiple developers are writing code, their code is very likely going to be inconsistent with each other. And, inconsistency itself is a big source of poor quality in an application’s code.

On the other hand, a good O/R mapping tool uses code templates that have excellent design because they are very likely designed and created by very senior (architect level) engineers. And, these code templates almost always follow known design patterns. So, the code that you’ll generate from an O/R mapping tool is very likely going to be better designed than code designed by your own development team.

Reason 3: You don’t have to be a .NET expert

Third benefit of using an O/R mapping tool is that you don’t have to be a .NET expert to develop your persistence code. As you know, data access code is critical for the overall performance of your application. If this code is designed and developed poorly, it can severely affect your application. So, if you developed this code by hand, you need to be an export of .NET, COM+, stateless components, and MTS.

However, if you use an O/R mapping tool, you can focus primarily on the “logical design” of your persistence objects including object mapping and the different types of interactions with the database including insert, update, load, delete, queries, stored procedure calls, relationships, and more. And, the O/R mapping tool would do the rest for it. It would ensure that the generated code follows all the best practices of writing stateless .NET components to run in COM+ and MTS.

Reason 4: Saves you testing time

Fourth benefit of an O/R mapping tool is that it reduces your testing effort dramatically. If you developed all the persistence code by hand, you would also be responsible for testing it yourself. And, as you know, testing is as much effort as development in any project.

On the other hand, if you generated code from an O/R mapping tool, it is coming from code templates that are very likely thoroughly tested by the software vendor itself (more so than you because it is their primary focus). And, on top of it, most likely hundreds or perhaps thousands of other customers are using this tool and have tested the code generated from this O/R mapping tool. As a result, many of the bugs that you might not find in your own testing have already been found and fixed in the generated code of an O/R mapping tool.

Reason 5: Simplifies your .NET development

If you have to write all the persistence code yourself, you’re bogged down into the details of ADO.NET, COM+, MTS, stateless .NET components, and more. And, you end up spending a lot of time in details that you really don’t need to. On the other hand, if you generate code from an O/R mapping tool, you get well design objects and you only need to deal with their public interface.

Below is an example of code you’ll write if you used an O/R mapping tool.

try {

Employees objInfo = new Employees();

EmployeesFactory objFactory = new EmployeesFactory();

objInfo.EmployeeID = EmployeeID;

objFactory.Load(objInfo);

// code here to use the “objInfo” object } catch(Exception ex) {

// code here to handle the exception

return; }

As you can see, the generated code is very simple to use than actually writing the .NET components yourself.

Many people have never heard of O/R mapping tools and many more have heard of them but are afraid to use them. I hope I have made a strong enough case here for you to give a serious consideration to O/R mapping for your project.

Iqbal Khan is the Director of Sales & Marketing at AlachiSoft (http://www.alachisoft.com/), a leading provider of O/R Mapping tool called TierDeveloper. You can reach him at iqbal@alachisoft.com.