Smartphone Operating System (779883), страница 42
Текст из файла (страница 42)
Symbian OS has made several design choices that differentiateit from general-purpose desktop systems and other smartphone platforms.Consider the environment for smartphones. They are single-userdevices and require no user identification. A phone user can executeapplications, dial the phone and access networks all without identification.
In this environment, using permissions-based security is challenging,because the lack of identification means only one set of permissions ispossible – the same set for everyone.2Instead of user permissions, security often takes advantage of othertypes of information. In Symbian OS v9 and later, applications aregiven a set of capabilities when they are installed. (The process thatgrants capabilities to an application is covered in Chapter 14.) Thecapability set for an application is matched against the access that theapplication requests. If the access is in the capability set, then accessis granted; otherwise, it is refused.
Capability matching requires someoverhead – matching occurs at every system call that involves access toa resource – but the overhead of matching file ownership with a file’sowner is gone. The tradeoff works well for Symbian OS.There are some other forms of file security on Symbian OS. There areareas of the Symbian OS storage medium that applications cannot accesswithout special capability. This special capability is only provided to theapplication that installs software onto the system.
The effect of this is thatinstalled applications are protected from non-system access (meaning that2This does not mean that applications are barred from requesting user identification.This discussion only addresses system identification.194FILE SYSTEMS AND STORAGEnon-system malicious programs, such as viruses, cannot infect installedapplications).For Symbian OS, the use of capabilities has worked as well as fileownership for protecting access to files.8.5 SummaryThis chapter has examined how operating systems implement file systemsand files to store data. We began by examining the basic concepts of files,directories and partitioning. We looked at attributes of files, the name andstructure of files and directories, and the operations that can be performedon them. We then looked at how file systems are implemented and gaveseveral examples – from FAT file systems used in Microsoft Windows tothe file system used in Unix.
We gave an overview of some issues withusing file systems on mobile phones and finished the chapter by lookingat file-system security.Exercises1.Explain the difference between a text file and a binary file on aSymbian OS device.2.Consider a file that is 2000 bytes long stored on a medium with512-byte blocks. Assuming that the FCB is in memory, how manystorage I/O operations are required to read the entire file in each ofthe following systems?a. a contiguous storage schemeb.
a linked storage schemec. a FAT implementation schemed. a UFS implementation scheme.3.Consider a UFS design where there are 12 direct pointers, anindirect pointer, a double-indirect point and a triple-indirect pointeras described in Section 8.2. What is the largest possible file that canbe supported with this design?4.Why is it better to store items from the boot sector – root directoryFCB, operating system boot code, etc – on a storage medium ratherthan in the boot sector?EXERCISES1955.Consider a file system that uses linked allocation for file blocks.What benefits are gained by making these blocks adjacent whenthe allocation scheme remains as linked allocation?6.Is it beneficial to locate free space blocks next to each other?7.When defragmentation is attempted on a storage medium, thereare often areas of the medium that cannot be moved.
Characterizethese areas and describe why they cannot be moved.8.Consider the situation when a smartphone shares RAM betweenoperating system memory and a file system.a. What file-system implementation is likely to be used? Explain.b.
How can a file system adapt to dynamically changing storagesizes (as operating system needs change, the file space growsand shrinks)?9.Why could Microsoft Windows 98, which used a FAT16 file system,only support partitions with a maximum size of 2 GB?10.If VFS and UFS were to be implemented for Symbian OS, woulda flash memory card that uses this combination have more or lessspace than a card formatted with a FAT16 file system?11.If a new file system were to be invented for the next version ofSymbian OS, what improvements could be made over the FAT16file system?12.Is fragmentation a problem on the storage medium used by SymbianOS? Why or why not?9Input and OutputA computer can do all the computing in the world, but it would be auseless device without input and output. I think there are many peoplelike this.
Sometimes people are thinkers; others like to talk (output) alot without listening (input); still others hear you (input) but do nottalk (output) to you. The most pleasant people to be with are typicallythose who listen, consider what you are saying and reply. Thus it iswith computers. While there are few computers that take input whileproducing absolutely no output and there are no computers that produceonly output (even computer-driven clocks need to be set with input),the most useful computers are those with general input and outputcapabilities.Operating systems must balance the needs for general computing withthe needs to process input and generate output.
It is very easy to get thesetasks out of balance; proper techniques are required to do all of them atthe same time. Management and control of input and output can be adifficult thing.This chapter discusses what is required to bring a balance to input andoutput. We have discussed related topics in other chapters, but here webring the pieces together.
We first give an overview of I/O components.We then review I/O hardware and give examples of the concepts neededto manage I/O. Then we look at software issues connected to I/O.We discuss I/O in Symbian OS and conclude with some Symbian OSexamples.198INPUT AND OUTPUT9.1 I/O ComponentsAn operating system must manage input and output just like it managesthe other resources in a computer system.
Input and output are harderresources to manage, however, because of their variety in function andspeed. While the CPU of a computer remains the same, any number ofI/O devices can be connected and disconnected. Consider a mouse, aCD-ROM drive and a printer. These devices are all different in speedand in the way they are used, yet they must all be managed by the sameoperating system.We typically manage complexity by using abstraction.
Throughout thisbook, we have emphasized how operating systems try to deal with therelevant details of something through a standard interface, while ignoringmuch of the complexity that is not relevant to management. That is themethod used here: standard interfaces handled in a standard mannerallow I/O technology to expand and differentiate without forcing theoperating system to change at the same rapid pace.
However, innovationaround I/O advances rapidly and standard interfaces are often outpacedby the needs of new devices – thus resulting in new ‘standard’ interfaces.This, too, must be managed and allowed to happen in a controlled setting.There are three components that are important to an operating system’smanagement of I/O. Device controllers on the hardware side are linkedto device drivers on the software side by buses (see Figure 9.1).Hardware Interface: Device ControllersA device controller is a hardware component that represents the hardwareinterface to the operating system. A controller has the ability to operatethe device to which it is attached.
A controller provides an interfacethat translates between the complex working of an I/O device and theoperating system.A controller is really a device in its own right. It is typically made up ofa processor, some memory and some microcode that enables it to processinteractions with an operating system. It is programmed to interact withthe operating system using standard interfaces and to translate the abstractinteraction it receives through its interfaces into specific operations thataccomplish on a device what the operating system is asking.
A controllercan operate a simple device, such as a serial device, or it can be in chargeof a complex system, such as storage media. The controller is responsibleI/O COMPONENTS199Operating systemDevice driverBusDevice controllerI/O deviceFigure 9.1Relationship between device drivers and device controllersfor performing tasks that the operating system requires, such as reading,writing, formatting or mapping bad sectors.Sometimes a controller is not directly connected to its device usingan I/O bus system such as USB or Firewire.
A controller must sometimescommunicate with many devices at once across an I/O bus connection. In all cases, a controller represents the hardware side of the I/Oabstraction.Software Interface: Device DriversThe software side of the I/O abstraction is a collection of device drivers. Adevice driver is a piece of software that interacts with the operating systemusing a standard interface and then interacts with device controllers,providing the software side of the translation between the operatingsystem and the device.Since devices are invented and evolve rapidly, supplying device driversthat work in each operating system is typically the responsibility of a200INPUT AND OUTPUThardware manufacturer.1 When a user attaches a device, that deviceusually comes with a driver that can be (or sometimes has already been)installed and can handle the new addition.
When the operating systemneeds something done, it communicates with the device driver, whichcommunicates with the device controller, which, in turn, operates thedevice itself.Bus ConnectionsThe glue that holds device controllers to device drivers is an I/O bus. Atthe hardware level, a bus is a set of wires that communicates data – bothusable data and control data – between connections. These physicalconnections tie the device driver to the device controller. At the softwarelevel, a bus is seen as a connector that allows messages, requests, andtransfer of data between the operating system and an I/O device.The communication between a driver and a controller happens according to a protocol.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
