SOLARIS BASICS-P3

SOLARIS BASICS-P3

DEVICE NAMING CONVENTION

According to Solaris devices has 3 names.

But Why…?

Isn’t it good to call the devices by their actual names…?

Why 3-3 names…?

What I understand is Perspective. Same thing has different names at different places.

Let’s see the names in Solaris perspective.

We are going to encounter with “DRIVERS”… what are they…?

To access a device system first searches its driver. Hence the device driver acts as interpreter between system and that device. Without device driver no communication is possible.

Device names are,

1.  PHYSICAL

2.  INSTANCE

3.  LOGICAL

Let’s start intersection…JJ

Oohhh… wait…wait… before starting isn’t it good to understand that from where these names are coming…?

At the time of booting, kernel searches for all attached devices in system and create a “DEVICE TREE”. This tree is referred further for all naming’s.

PHYSICAL DEVICE NAME:

·         These are devices directly attached to system.

·         Managed by “devfs” file system.

·         Resides under “/devices” directory.

·         This is actual device tree build by kernel, so here the direct entries of physical devices are created.

·         Full device path names.

Physical device tree listing is based upon the device tree build by kernel while booting.

Stage 1.

While booting all devices are powered on and accessed by POST. Then the accessed devices are considered in Device tree.

Stage 2.

Now POST has ran, devices passed the POST and considered by Kernel. Now the thing to notice is “ DEVICE FILE”. If some HW present at boot time but no device file associated with it, then kernel will ignore that device.

Device files are drivers for that device.

INSTANCE NAME:

·         Abbreviated name assigned by kernel.

·         All instance names are shortened names for Physical devices.

·         Once the Instance name has been assigned to device, it remains mapped with device. To keep the instance name consistent across reboots, the system records them in a file called “PATH_TO_INST”. This file is read only at startup and updated by “devfsadm” daemon.

·         /etc/path_to_inst

sd# => where sd (scsi disk) is the disk name and # is the no, like sd0 for first scsi disk.

dad# => where dad (direct access device) is disk name and # is no, like dad0 for first IDE disk.

ata# => where ata (adv technology attachment) also known ass IDE (integrated device electronics) is the disk name and # is no, like ata0 for first IDE disk.

LOGICAL DEVICE NAME:

·         When a device is added first time, a logical device name is created with physical device name.

·         Logical device names are used for config purpose.

·         “/dev” directory contains logical device name

·         “/dev” has a sym link to “/devices”

Again logical devices are of 2 types,

BLOCK & RAW

/dev/dsk/c1t0d0s0 => Block Device

/dev/rdsk/c1t0d0s0 => Raw Device

Both are referring to same slice i.e. Slice 0

	RAW	BLOCK
1	Deals in sectors (512 bytes), if data smaller than 512 bytes then the sector wasted. Data will be written to next sector.	Deals in block size (8kb) further devided in to 1KB fragment, no wastage of space.
2	Does not entertain FS/OS, they bypass the FS buffer and use DMA to/from program/application buffer.	It contains the FS and respects the FS/OS, by allowing buffer.
3	it doess not contain FS and don't cache, so it can be faster for certain applications.	same as above
4	we cannot mount raw devices	It can be mounted
5	Management issue, cant accessed by OS tools	supports management

Raw devices are faster for those applications that provide and manage their own buffer, the application must provide certain tools for management purpose.

We cannot manage a raw device using OS tools.