Dr A Sahu Dept of Comp Sc & Engg. IIT Guwahati. File System, Block Devices Block Device Registration Initialization of Sbull Block Device Operation Request.

Slides:



Advertisements
Similar presentations
Principles of I/O Hardware I/O Devices Block devices, Character devices, Others Speed Device Controllers Separation of electronic from mechanical components.
Advertisements

Device Drivers. Linux Device Drivers Linux supports three types of hardware device: character, block and network –character devices: R/W without buffering.
RT_FIFO, Device driver.
Lecture for Lab 3, Exp1 of EE505 (Developing Device Driver) T.A. Chulmin Kim CoreLab. Mar, 11, 2011 [XenSchedulerPaper_Hotcloud-commits] r21 - /
Computer System Laboratory
Computer System Overview
SCSI Mid-layer Eric Youngdale 2nd Annual Linux Storage Management Workshop October 2000.
Operating Systems Input/Output Devices (Ch , 12.7; , 13.7)
63 UQC152H3 Advanced OS Writing a Device Driver. 64 The SCULL Device Driver Simple Character Utility for Loading Localities 6 devices types –Scull-03.
Home: Phones OFF Please Unix Kernel Parminder Singh Kang Home:
Block devices and Linux Linux has a generic block device layer with which all filesystems will interact. SCSI is no different in this regard – it registers.
CS 342 – Operating Systems Spring 2003 © Ibrahim Korpeoglu Bilkent University1 Input/Output – 3 I/O Software CS 342 – Operating Systems Ibrahim Korpeoglu.
1 Input/Output Chapter 3 TOPICS Principles of I/O hardware Principles of I/O software I/O software layers Disks Clocks Reference: Operating Systems Design.
1 I/O Management in Representative Operating Systems.
Chapter 3 Buffer Cache TOPICS UNIX system Architecture Buffer Cache
Device Drivers In Linux © Gregory Kesden Fall 2000.
I/O Tanenbaum, ch. 5 p. 329 – 427 Silberschatz, ch. 13 p
M. Muztaba Fuad Advanced Operating System Project Device Drivers.
File System. NET+OS 6 File System Architecture Design Goals File System Layer Design Storage Services Layer Design RAM Services Layer Design Flash Services.
I/O Systems ◦ Operating Systems ◦ CS550. Note:  Based on Operating Systems Concepts by Silberschatz, Galvin, and Gagne  Strongly recommended to read.
Operating System Program 5 I/O System DMA Device Driver.
Bolin Hsu CS6900 Independent study Bolin Hsu
CS 6560 Operating System Design Lecture 13 Finish File Systems Block I/O Layer.
CSCC69: Operating Systems Assignment 3 Review. Assignment Review Implement the file-related system calls – open, close, dup2 – read, write, lseek – chdir,
Disk Access. DISK STRUCTURE Sector: Smallest unit of data transfer from/to disk; 512B 2/4/8 adjacent sectors transferred together: Blocks Read/write heads.
Operating Systems (CS 340 D) Dr. Abeer Mahmoud Princess Nora University Faculty of Computer & Information Systems Computer science Department.
1 Computer System Overview Chapter 1. 2 n An Operating System makes the computing power available to users by controlling the hardware n Let us review.
CSC 322 Operating Systems Concepts Lecture - 25: by Ahmed Mumtaz Mustehsan Special Thanks To: Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall,
COMP 3438 – Part I - Lecture 4 Introduction to Device Drivers Dr. Zili Shao Department of Computing The Hong Kong Polytechnic Univ.
The Story of Device Drivers Ankush Garg, Dheeraj Mehra, Rohan Paul,Vaibhav Anand Silodia, Rohit Prakash.
Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze Unit OS6: Device Management 6.1. Principles of I/O.
File System Implementation Chapter 12. File system Organization Application programs Application programs Logical file system Logical file system manages.
Chapter 4. INTERNAL REPRESENTATION OF FILES
Chapter 5 File Management File System Implementation.
Device Drivers CPU I/O Interface Device Driver DEVICECONTROL OPERATIONSDATA TRANSFER OPERATIONS Disk Seek to Sector, Track, Cyl. Seek Home Position.
Multiprogramming. Readings r Silberschatz, Galvin, Gagne, “Operating System Concepts”, 8 th edition: Chapter 3.1, 3.2.
UNIX Files File organization and a few primitives.
Chapter 4. INTERNAL REPRESENTATION OF FILES
Sogang University Advanced Operating Systems (Enhanced Device Driver Operations) Advanced Operating Systems (Enhanced Device Driver Operations) Sang Gue.
Digital UNIX Internals II4 - 1Buffer Caches Chapter Four.
Files & File system. A Possible File System Layout Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved
1 Chapter 4. INTERNAL REPRESENTATION OF FILES THE DESIGN OF THE UNIX OPERATING SYSTEM Maurice J. bach Prentice Hall.
Chapter 13 – I/O Systems (Pgs ). Devices  Two conflicting properties A. Growing uniformity in interfaces (both h/w and s/w): e.g., USB, TWAIN.
Interfacing Device Drivers with the Kernel
B LOCK L AYER S UBSYSTEM Linux Kernel Programming CIS 4930/COP 5641.
Linux File system Implementations
CSNB334 Advanced Operating Systems 6. Device Management Lecturer: Asma Shakil.
4P13 Week 12 Talking Points Device Drivers 1.Auto-configuration and initialization routines 2.Routines for servicing I/O requests (the top half)
Lab 12 Department of Computer Science and Information Engineering National Taiwan University Lab12 – Driver 2014/12/16 1 /21.
CSCC69: Operating Systems Tutorial 10. Hints on testing Assignment 3 How to test tlb replacement algorithms? – Write a program that creates an array larger.
COMP 3438 – Part I - Lecture 5 Character Device Drivers
4P13 Week 9 Talking Points
ICOM Noack Linux I/O structure Device special files Device switch tables and fops How the kernel finds a device Parts of a device driver or module.
1 The File System. 2 Linux File System Linux supports 15 file systems –ext, ext2, xia, minix, umsdos, msdos, vfat, proc, smb, ncp, iso9660, sysv, hpfs,
MINIX Presented by: Clinton Morse, Joseph Paetz, Theresa Sullivan, and Angela Volk.
1 Reminders Project 3 due tomorrow in lecture turnin + report Today’s office hours in 006 changed to 5:30-6:30 Project 4 out soon, due last day of classes.
File System Design David E. Culler CS162 – Operating Systems and Systems Programming Lecture 23 October 22, 2014 Reading: A&D a HW 4 out Proj 2 out.
1 Chapter 11 I/O Management and Disk Scheduling Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and.
Chapter 3 Buffer Cache TOPICS UNIX system Architecture Buffer Cache
Protection of System Resources
Buffer Cache.
Linux Kernel Driver.
Semester Review Chris Gill CSE 422S - Operating Systems Organization
Introduction to Linux Device Drivers
CPSC 457 Operating Systems
Overview Continuation from Monday (File system implementation)
CSE 451 Fall 2003 Section 11/20/2003.
Week 9 March 4, 2004 Adrienne Noble.
Internal Representation of Files
Mr. M. D. Jamadar Assistant Professor
Presentation transcript:

Dr A Sahu Dept of Comp Sc & Engg. IIT Guwahati

File System, Block Devices Block Device Registration Initialization of Sbull Block Device Operation Request processing

Block Devices (Disk) – Sector, inode File systems (Operations) – Read/write, open,close, lseek, type

Block Devices (Disk) – Sector, inode File systems (Operations) – Read/write, open,close, lseek, type

Block Devices (Disk) – Sector, inode File systems (Operations) – Read/write, open,close, lseek, type

Component in the kernel that handles file- systems, directory and file access. Abstracts common tasks of many file-systems. Presents the user with a unified interface, via the file-related system calls (open, stat, chmod etc.). Filesystem-specific operations:- vector them to the filesystem in charge of the file.

$ mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom Steps involved: – Find the file system.(file_systems list) – Find the VFS inode of the directory that is to be the new file system's mount point. – Allocate a VFS superblock and call the file system specific read_super function.

– The details of how a block device works ll_rw_block() : trigger I/O transfer __make_request (): make request -> request queue task queue : plug/unplug use the mechanism request service routine : – How to write a block device driver writing a module – Init / exit implement the necessary operations – block_device_operations – request_fn_proc

In fs/block_dev.c struct file_operations def_blk_fops = { open: blkdev_open, release: blkdev_close, llseek: block_llseek, read: generic_file_read, write: generic_file_write, mmap: generic_file_mmap, fsync: block_fsync, ioctl: blkdev_ioctl, };

Additional operations for block device only In include/linux/fs.h : struct block_device_operations { int (*open) (struct inode *, struct file *); int (*release) (struct inode *, struct file *); int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long); int (*check_media_change) (kdev_t); int (*revalidate) (kdev_t); }; In include/linux/blkdev.h : typedef void (request_fn_proc) (request_queue_t *q);

Bh= block header

Provides common functionality for all block devices in Linux – Uniform interface (to file system) e.g. bread( ) block_prepare_write( ) block_read_full_page( ) ll_rw_block( ) – buffer management and disk caching – Block I/O requests scheduling Generates and queues actual I/O requests in a request queue (per device) – Individual device driver services this queue (likely interrupt driven)

Data structure: in include/linux/blkdev.h Queue header: type request_queue_t typedef structure request_queue request_queue_t – queue_head: double linked list of pending requests – request_fn: pointer to request service routine Queue element: struct request – cmd: read or write – Number of request sectors, segments – bh, bhtail: a list of buffer header – Memory area (for I/O transfer)

Generic block device layer – Generates and queues I/O request – If the request queue is initially empty, schedule a plug_tq tasklet into tq_disk task queue Asynchronous run of task queue tq_disk – Run in a few places (e.g., in kswapd) – Take a request from the queue and call the request_fn function: q->request_fn(q);

To service all I/O requests in the queue Typical interrupt-driven procedure – Service the first request in the queue – Set up hardware so it raises interrupt when it is done – Return Interrupt handler tasklet – Remove the just-finished request from the queue – Re-enter the request service routine (to service the next)

ll_rw_block() submit_bh() generic_make_request() __make_request() – generic_plug_device() – elevator algorithm – __get_request_wait()

void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]) – rw: read/write – nr: number of buffer_head structures in the array – bhs: array of buffer_head structures Top-level function to submit the I/O request Checks whether the requested operation is permitted by the device – Performing a write operation on a read-only device Checks the buffer size is a multiple of the sector size of the device Locks the buffer and verifies whether the operation is required – If the dirty bit is not set on the buffer, write operation is not necessary – Read operation on a buffer with uptodate buffer is redundant

void submit_bh(int rw, struct buffer_head *bh) submit a buffer_head to the block device later for I/O Sets the BH_Req and the BH_Launder flags on the buffer Sets the real device and sector values – count = bh->b_size >> 9; – bh->b_rdev = bh->b_dev; – bh->b_rsector = bh->b_blocknr * count;

void generic_make_request(int rw, struct buffer_head *bh) Hand a buffer head to it ’ s device driver for I/O Checks the requested sector is within the range (blk_size[major][minor] Get the request queue of the device, calls make_request_fn to put the buffer in the request queue (in most case,this handler is __make_request)

static int __make_request(request_queue_t * q, int rw, struct buffer_head * bh) Inserts the buffer in the request queue Plug device by calling plug_device_fn handler of the request queue – In most case, this is generic_plug_device() – Submits the plug_tq to the disk task queue tq_disk Enlarger an existing request – elevator algorithm

__get_request_wait() – If a new request has to be created and there are no free request objects, it waits on the request queue till it gets a free request object – static struct request *__get_request_wait(request_queue_t *q, int rw) { register struct request *rq; DECLARE_WAITQUEUE(wait, current); generic_unplug_device(q); add_wait_queue(&q->wait_for_request, &wait); do { set_current_state(TASK_UNINTERRUPTIBLE); if (q->rq[rw].count < batch_requests) schedule(); spin_lock_irq(&io_request_lock); rq = get_request(q,rw); spin_unlock_irq(&io_request_lock); } while (rq == NULL); remove_wait_queue(&q->wait_for_request, &wait); current->state = TASK_RUNNING; return rq; }

__generic_unplug_device() – Called by __get_request_wait() or generic_unplug_device() – Marks the queue as unplugged – Calls the request_fn handler of the request queue

Not completely rid of major/minor number yet – Still keep queues and device driver related parameters in arrays indexed by major numbers In include/linux/blkdev.h – struct blk_dev_struct { request_queue_t request_q; queue_proc *queue; void *data; } struct blk_dev_struct blk_dev[MAX_BLKDEV]; #define BLK_DEFAULT_QUEUE(_MAJOR) &blk_dev[_MAJOR].request_q

Matrices for device paramaters – Type: int * xxx[MAX_BLKDEV]; – Indexed by major then minor number – blk_size, blksize_size, hardsec_size, max_readahead, max_sectors, max_segments Read ahead parameters – int read_ahead[] (include/linux/fs.h) – Indexed by major number You will need to set these parameters for any device in your init and open functions

Assign major number for each device driver Define macros for each device (by major number) – MAJOR_NR: major number – DEVICE_NAME: name of your device – DEVICE_INTR: device interrupt handler – DEVICE_REQUEST: request service routine – DEVICE_NR(): how to calculate the minor number You may have to add a set for each new device driver (major number) you introduce

Device operation structure: – static struct block_device_operations xxx_fops = { open: xxx_open, release: xxx_release, ioctl: xxx_ioctl, check_media_change, xxx_check_change, revalidate, xxx_revalidate, owner: THIS_MODULE, };

Xxx_open() – MOD_INC_USE_COUNT; Xxx_release() – MOD_DEC_USE_COUNT; Xxx_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg) – switch(cmd) BLKGETSIZE HDIO_GETGEO … – default: return blk_ioctl(inode->i_rdev, cmd, arg);

#define MAJOR_NR XXX_MAJOR static int __init xxx_init(void){ /* probe the hardware, request irq, … */ devfs_dir = devfs_mk_dir(NULL, “ xxx_dir ”, NULL); /* old way: register_blkdev(MAJOR_NR, “ xxx ”, &xxx_bdops); */ devfs_handle = devfs_register_blk(devfs_dir, “ xxx",......); blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), xxx_request); read_ahead[MAJOR_NR] = 8; /* 8 sector (4K) read ahead */ /* you may also setup those: blk_size[MAJOR_NR] blksize_size[MAJOR_NR] hardsect_size[MAJOR_NR] */ /* rest of the initial setup */ printk( … ); return 0; }

static void __exit xxx_exit (void) { /* clean up */ blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR)); /* old way: unregister_blkdev(MAJOR_NR, “ xxx ” ); */ devfs_unregister(devfs_handle); devfs_unregister(devfs_dir); /* clean up */ } module_init(xxx_init); module_exit(xxx_exit);

static void xxx_request(request_queue_t *q) { while (1) { INIT_REQUEST;//a macro,quit while loop when request queue is empty switch (CURRENT->cmd) { case READ: /* do read request, i.e: memcpy(q->buffer, mem_block, size); */ case WRITE: /* do write request, i.e: memcpy(mem_block, q->buffer, size); */ default:/* impossible */ return 0; } end_request(status);//when finishing a request, remove it }

Write all the device operation functions – xxx_open(), xxx_release(), xxx_ioctl()... Write a request service routine – xxx_request() Write interrupt handler and related tasklets Write module “ init ” and “ exit ” functions to – Register and unregister the device driver – Set up and clear up the request queue and parameters – Set up and clear up the interrupt line and handler