Kernel-Land vs. Userland

In Linux, a bright line exists between the kernel’s execution context and that of the programs being run. The kernel’s context is called kernel-land or kernel space and encompasses all the device interaction, threads, interrupt handlers, data structures, and memory. When a program is executed, the kernel creates a virtual memory address, configures resource descriptors (like those for files, timers, and semaphores), loads the program into memory, and configures the processor’s registers to start execution. All of this activity occurs in userland. These two execution contexts can communicate under controlled circumstances but are otherwise separate and distinct. Although the kernel and userland are separate and distinct, they’re very much related. When the kernel boots, it initializes (and registers) devices that can be used later in the startup process or when the system is up and running. For example, when a board boots that has a USB host controller, the driver for that device initializes in the kernel; in userland, programs can run that interrogate the devices attached to the USB bus and load corresponding drivers.
Understanding the hand-off from the kernel to the first userland process helps when you’re debugging startup problems and trying to reduce startup time. From a diagnostic perspective, knowing that the kernel started successfully means booting problems have been automatically narrowed to something in the root file system or initial RAM disk. From a performance perspective, knowing that a configuration step can be done in the kernel or userland (such as assigning an IP address to a network adapter) means certain activities can be deferred until later and scheduled such that system appears to boot faster, or when you can more readily control the configuration process.

Source of Information : Pro Linux Embedded Systems