The ‘ioctl’ driver-function includes struct file_operations, Driver services, The ‘file’ paradigm, An imperfect paradigm, The serial UART, Recall role of a device-driver, UART’s baudrate-control. | The ‘ioctl’ driver-function On implementing a way to query and modify our UART’s baudrate via the ‘device-file’ abstraction ‘struct file_operations’ • For a Linux device-driver’s ‘module_init()’ function, there are two main actions: – Initializing the driver’s global data-structures (this includes verifying the device’s presence) – Registering the driver’s service-functions with the kernel (., the ‘file_operations’ structure) • The driver’s ‘module_exit()’ function then has the duty to ‘unregister’ those services Driver services • For character-mode device-drivers (like ‘’, ‘’ and ‘’), we have implemented some (or all) of the following service-functions (., driver ‘methods’): – – – – read() llseek() write() mmap() The ‘file’ paradigm • The UNIX approach to device-control is to create objects that represent i/o-devices, but which behave like ‘files’ do, insofar as the application programmer is concerned • So ‘read()’, ‘lseek()’, ‘write()’ and ‘mmap() use the same function-call syntax – and in most respects the same semantics – for both ordinary ‘files’ and ‘device-files’ An imperfect paradigm • But often there are a few ways in which the file-object paradigm doesn’t quite fit with important features of an i/o device • In these cases, device-drivers can provide a ‘workaround’ that allows applications to perform device-actions that deviate from customary ‘read/write/seek’ file-like actions • This ‘workaround’ mechanism is .
