-
Notifications
You must be signed in to change notification settings - Fork 1
/
OS_Introduction.txt
1286 lines (1034 loc) · 61 KB
/
OS_Introduction.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1. operating system can seen as a set of system s/w components
that manage h/w and logical resources in the system on
behalf of applications and users
- users can be developers
- users can be administrators(normal / abnormal)
- users can just be basic users of the computing !!
- there are hybrid users as well !!!
- how do we define system software components
of a computing system ???
- s/w components that may be used to provide
environment and functionality to application
s/w components !!!
- icompiler/assembler and related !!!
- CLI / GUI interfaces !!
- system libraries !!!
- you may use it for more control
- you may use it to develop your own libraries !!!
- s/w components that initialize h/w resources !!!
- device drivers
- I/O subsystems
- s/w components that manage h/w resources !!!
- I/O subsystems
- file system manager - manages disk space!!!
- this component will not directly deal/control hw
components - it will depend on other components
for such hw control !!
- physical memory manager - a critical component that
may be involved in certain sensitive activities !!!
- CPU scheduler - has direct control over the
applications and other system components !!
- virtual memory manager - swap-space management !!
- this component provides control and flexibility
in the case of sensitive applications !!!
- virtual address / logical address to
physical address mapping
- this is useful in memory protection
in processes !!!
- performance issues related to VMM
in embedded and real time systems !!!
- loading applications/processes larger
than physical memory size of the system !!
- you may fine tune the physical memory
and swap space of a given computing system
as per the applications' requirement !!!
- s/w components that provide interface between
user and computing system !!!
- CLI/GUI interfaces
- system libraries
- system utilities/tools !!!
- task utilities - to control/terminate
certain applications in the system !!!
- as a developer - managing own
processes/threads !!!
- file system defragmenter !!!
- system parameters tuning using
special utilities !!!
- operating system parameters can
be tuned as per requirements of
the administrator or developer !!!
- in Linux, you will be dealing with
procfs and sysfs !!!
- as we progress and do more practicals,
serveral utilities will be used - you may
learn one after another !!!
- these system utilitie invariably use
system libraries and interact with
core system components !!!
- s/w components that make up the core and non-core
parts of the operating system - core components
are mainly responsible for initializing and
managing the h/w resources and providing
services to non-core components, applications
and users - non core components are libraries,
utilities/tools and execution frameworks that enable
the users/developers/administrators to interface
and utilitize the core services of operating system !!
- core components may be more priviliged than
non core components !!!
- what does it mean by more priviliged, here ???
- most core components can interact with
h/w resources/controllers, directly !!!
- core components may have access to
all parts of the system memory !!!
- certain core components may be given
higher priority and accordingly more
cpu time !!
- core components can directly interact
and allocate memory from the physical
memory manager !!!
- core components are very essential for the
computing system and non core components and
applications may not be able to function without
the former !!!
2. operating system also provides an environment in which developers
can develop and build applications
- software development kits, if any !!!
- you will learn more when you work in the lab !!!
3. operating system also provides a controlled environment in which
applications can be loaded and executed
- scheduling several active applications, in a multitasking
environment !!processes are typically used !!!
- support inter process communication
- manage server processes / server daemons !!!
- virtual memory environment !!!
you may or may not use this feature/mechanism!!
- depending upon application size, we may or may not use it !!!
- it also depends on deterministic requirements and
acceptance of non deterministic behaviour !!1
- why vm is popular in GPOS systems ???
- efficient multitasking and efficient usage of
physical memory !!!
- operating system manages multiprocessor, multitasking !!!
- why multiprocessing ???
- to increase throughput !!!
- several cpu resources are needed to implement
deterministic/responsive scheduling for several
processes/tasks !!!
- depending upon your requirement, you will come
across appropriate os services !!!
- in this case, os will provide certain
services without intervention of the
developer
- in this case, os will be provide certain
services to be used by the developer
, as needed !!! how does a operating
provide services to the developer ???
- mostly via system call APIs !!!
- in certain cases, services are offered
via system utilities !!!
- exception handling - fatal error handling
- applications or system sw components are
terminated by handling execptions with
strict rules - this enables developers
and users to rectify and fix the bugs !!!
- applications may crash for various reasons-
one could be a fatal exception - another
could be lack of resources
- what is the understanding of application
crash, in this context ??
- application is abnormally terminated
by the operating system !!!
- who is responsible for crashing
the application ??
- operating system / cpu may be
involved in generating exceptions !!!
- how is the crashing achieved ???
- forced termination by operating system
- what is the meaning of fatal exception
in this context ???
- this depends on how the processor
treats the illegal action of a
application !!! some very good
examples can be seen during memory
management !!!
- give a scenario for lack of resources
and crashing of the application ???
- this is typically not an exception !!!
- in a virtual memory system, when
virtual memory resources are
exhausted and certain processes
are still demanding for memory,
oeprating system may terminate
one or more such processes !!!
- not all types of application crashes are
possible in all computing environments -
certain computing environments may be
using robust techniques such that most '
of such crashes/abnormal terminations are
eliminated !!! ultimately, it depends on the
execution environment provided by the OS (RTOS)
and developers' skills !!!
- the execution environment may be fine
as per the requirements of the
computing system/applications !!-
- the above are true in the case of
any OS !!!
- it is also the responsibility of the operating
system to generate its own crash, if certain
core component misbehaves - this is a built in
intelligence !!! the intelligence is implemented
in the form of code , which includes a detailed
set of rules !!!
- why do operating systems crash ??
- unable to load a critical module/component of the
core of the OS !!!
unable to detect /initialize a
critical hw component in the system !!!
- what is a crash ??
- who is responsible for
generating a crash ???
- core components will have check points in their
code and they generate the crashes, if a check
fails !!
- secure environments such that applications
can be executed securely !!! mainly, applications are
executed in well protected environments !!! what does this
mean ???
- can one application arbitrarily interfere with
another application ???
- different, isolated address spaces(memory spaces)
- MMU unit of the processor and critical
core data structures !!! we will see the
details during memory management !!!
- system calls and system space management of
critical data structures !!!
- how is this achieved ??? these are achieved
using processor's capabilities - in fact,
many interesting features of operating
system are due to processors' capabilities !!1 - it uses more than MMU capability of the
processor !!!
- ofcourse, operating system can program/reprogram
these facilties as per its requirements - processors
provide such a suitable interfacing !!!
- many of these low level control code
are present in the HAL of the operating
system core !!!
4. operating system is made up of several components - it is a very
long list and each component is quite complex and may require
a separate study of its own - one good example is memory subsystem
- another complex and vast sub-system is I/O
- our study will mainly focus on certain core
components - once you understand the working
and usage of core components understanding
non-core components is easier - even understanding
other core components becomes easier !!!
- typical operating system books focus on core
components - other professional books that
deal with certain services of an operating system
may deal more with non core components !!!
- your case may involve studying a specific RTOS and
its interfaces - it may also involve studying and
using a specific add on component in that RTOS , which
may be useful in your domain/work !!!
Note:(analogy could be a processor chip or any other
peripheral controller chip !!!)
- can you see the system data structures/objects ??
- say a process descriptor, for instance !!!
- humanly, not !!! may be a super -human !!
- micro level details cannot be seen !!!
- can you access system data structures/objects ???
- via system utilities and system calls !!!
- can we literally access using our code ???
- kernel debuggers
- writing your own system call code or
writing your own kernel module !!! this is
typically achieved using system space coding
and you may need to such work, if required !!!
5. most components interact with each other and do not exist as
stand alone components - understanding one component may depend
on one or more other components - depth of study will differ
depending upon our requirements
6. all the components co-exit in a layered and hierarchical form,
in the system - although there is no strict layering or hierarchy,
there is a general model that is used for our study - one aspect
is layering and another aspect is modularity !!!
- what is the meaning of layering ??
- a component is dependent on another component !!!
- flow of control / commands / data is strict
and higher levels to lower levels or vice versa !!!
- what is the benefit of layering ???
- changes / updates in one layer may have minimal
effect on other higher/lower layers !!!
- a standard set of interfaces which are mostly
static / may undergo minor changes !!!
- still, to work with a layer, it is better to understand
the functionalities / limitations of higher/lower layers !!!
- important requirement for system sw developer !!!
what is
layering and what is modularity ???
- core features can be added or removed as needed !!! drivers
/I/o subsystems/filesystems(filesystem managers)/
network protocols and many more !!!
- one or more modules may be added or removed from
a layer, in the system - this will be done as
per the requirement of the user/developer/administrator !!
- configuration and rebuilding of the core(restart system!!!)
- adding/removing kernel modules to the core of the system !!!
(no need to restart the system - run-time dynamic loading )
7. some of the layers interact very closely with the h/w controllers -
one such is HAL - hardware abstraction layer - I/O subsystem and
device drivers are major contributors to interaction with h/w
controllers !!!
- HAL is a layer/component of core of operating system !!!
- I/O subsystem manages drivers and devices(logically)
- HAL is written in machine language
- drivers are more in high-level language and specific
to a specific device controller - drivers use HAL
to accomplish their work
- there are many other core components that interact/ use
HAL to accomplish their work
- depending upon underlying processor arch./board, HAL
will be different for a given operating system - if
a given OS has a specific HAL for a specific
arch/board, that OS can be loaded to manage the correponding
arch/board - otherwise, it is not possible !!!
Note : in what ways GPOs may be different from RTOS ??
in what ways GPOS may be different from EOS ???
in what ways a given GPOS may be different from another GPOS ??
in what ways a given RTOS is different from another RTOS ???
- say for example, a given RTOS may implement
interrupt handler as an asynchronous method, not a task !!!
- another RTOS may implement interrupt handler as
a kernel thread/task !!!
- hw timer management may be different
- sw timer management may be different
- one RTOS may provide system space tasks only
- another RTOS may provide user-space tasks and system space
tasks !!!
- whenever we discuss about os differences, it will be
more on their core services, not on add on services -
it does not mean, add on services should not be discussed-
it is the core services that have more impact when there
are changes and add on services can come and go !!!
- in many contexts, core services are said to be part
of microkernel of the operating system !!! or in some
contexts, people may just use the term kernel !!!
8. study of certain components of OS may help a developer understand
his build environment and execution environment - functional and
performance issues may be better understood, if OS architecture and
components are understood !!!
- for example:
- uniprocessor vs multiprocessor
- services will be used different depending
upon requirements - say, throughput vs determinism !!!
- 32-bit vs 64-bit
- address width and data width
- data types will be large
- processing speed and throughput
- amount of memory space supported will be large
- very large applications can be supported !!!
- the binary formats used will be different !!
- x86 vs ARM vs PPC
- HAL will be very different
- processing capacities are different
- little endian vs big endian
9. one such component is memory manangement - another may be cpu scheduling
- yet another may be process management - the list continues -
when certain services of operating system are needed directly or
indirectly, understanding the operating system behaviour may
help us use the services reasonably !!!
10. operating systems provide their services via system call APIs - these
(application programming interface / application programmer's interface)
system call APIs are implemented using system library and system
call interface layer of the operating system !!! system call APIs
are dependent on interrupt handling mechanism of the underlying
h/w and operating system as well !!!
- we may use operating system services directly or indirectly !!!
- we will be abe to use and able to use efficiently, if
we understand the working of ther services and their limitations!!!
- we will be able to understand problems and bugs !!!
- we may be able to increase performance of our applications!!!
- by using certain special services directly, if needed !!!
11. for the above reasons and also for understanding other activities
of the operating system, interrupt mechanism and interrupt handling
must be understood !!!
- if you are a real time systems engineer, you better learn
about interrupt handling and many such low level mechanisms !!!
- this will enable you to understand critical control sections
in a computing system and enable to fine tune computing
for real time programming !!!
12. operating system may be seen as kernel , libraries and utilities,
in a computing system - kernel contains the core components of the
operating system - typically, process mgmt.subsystem,
physical mm. mgmt.subsystem ,
virtual mem. mgmt., file management subsystems, logical file management
subsystem, I/O subsystems , device drivers, interrupt subsystem,
IPC subsystems, Timer subsystem and many more !!!
- HAL is the lowest layer (logically) in the core
components that interacts very closely with processor
and may be responsible for the following activities:
- MMU management / interaction
- low-level interrupt handling
- HAL will be doing the first level hw
context saving
- HAL may be involved in interacting with
interrupt controller(s)
- HAL may be involved in controlling
processor's hw interrupt enabling/disabling
- low - level system call handling
- low level process context switching
- low-level exception handling
- many I/O subsystem related - we will see more
of this during I/O buses !!!
- there can be several I/O subsystems in the core
of the OS
- each I/O subsystem is responsible for managing
devices and drivers under the given category of
devices !!
- it is typically the I/O subsystems and device drivers
that interact with HAL as well - other components
also interact, as required !!!
- I/o subsystem and drivers are more to do
with peripheral controllers and their
management
- HAL just helps in interaction with peripheral
controllers !!!
- on the other hand, HAL is also responsible
for managing / interacting with processor
/interrupt controllers with the help
of other subsystems of the core of the OS !!!
- subsystems and managers are used interchangeably !!!
- there are many subsystems and many components !!
- what is a subsystem ??
- kernel is the system here !!! kernel is a subsystem
of OS
- OS is a s/w subsystem of computing system !!!
- computing system will be a subsystem of your real system !!!
that real system may be a plant in the industry !!!
- a component in a kernel is known as subsystem
- there can be one or more components managed
by a subsystem - a good example for a component is device driver!!
- one more good subsystem is interrupt subsystem !!!
- one more good component is a specific scheduling policy/
algorithm !!! there can be several scheduling policies(components) implemented in a given kernel of an operating system !!!these make up
the scheduling subsystem (generic scheduler)
Note: there are typically 2 types of kernel architectures !!!
one is known as monolithic kernel architecture
and the other is known as microkernel architecture !!!
- in this discussion, we will be looking at practical
usage of such architectures rather than the theoretical
definitions !!!
- monolithic kernel arch:
- all the core components are said to be built
together into a single large image that is
loaded into the main memory,when the system
is started/booted !!! during the life of a
system boot, all the core components reside
in the main memory and cannot be unloaded !!!
- this is a less flexible arrangement for
most systems !!!
- to provide flexibility and convenience, a microkernel/
modular kernel arch. was introduced !!!
- most essential core components are built
into a single image that is loaded during
the system startup/booting !!
- additional core components can be added/removed
from the system space as per the system's
requirements !!! this may be done manually or
automated !!!
- in certain microkernels, a core component may
be added and this core component may contain
one or more tasks !!! this is little more than
a module !!!
- what is the difference between a module
and a module that may contain several
tasks ???
- a typical module contains just
methods and data - when loaded,
these methods and data are loaded
into system space !!!
- a more sophisticated module may
create several tasks, when loaded
- this is in addition to loading
methods and data into system space !!!
13. the following is the summary of the big picture in
linux_kernel_internals_concepts_intro.pdf !!!
- system call interface layer provides a trap handler that is
invoked whenever a system call API is invoked - as per the
system call API and its rules, trap handler with the help
of system call table (also located in system call interface layer)
will invoke appropriate system call system routine in the
appropriate sub-system of the kernel - in the example shown,
process management subsystem is in use !!!
- in the same picture, process management subsystem is shown as
dependent on HAL layer - process management subsystem is
also supposed to contain cpu scheduler, in this picture -
in our discussions, cpu scheduler will be treated as a separate
subsystem - cpu scheduler also is dependent on HAL layer for
some of its activities - one such is process context switching !!!
- the top most layer of memory management may be treated as
process memory manager/virtual memory manager !! lower layer
of memory management may be treated as physical memory manager!!!
- top most layer of file management may be treated as logical
file manager - this is supposed to manage different file system
managers, which will inturn be responsible for managing different
types of file systems !!!
- block device management may be treated as an I/O subsystem and
device drivers for various block devices are also managed via
block device management !!!
- block devices have certain rules for data transfer - they can
transfer data with the kernel in multiples of appropriate
block size - they cannot transfer arbitrarily sized data
- in the same picture, character/ byte devices are shown - character
devices may transfer data in arbitrary sizes as per their requirements - this is one of the major differences with respect to block devices-
we will se more of this during file management !!!
- this picture is not complete - there are many other subsystems and
their own hierarchy and layering - still, this picture can be a
good starting point !!!
14. following is the summary for the class room big picture :
- in the picture, there is a dotted line at the top separating
user-space and system-space !!!
- user-space may be seen as a set of memory regions with a
set of attributes !!
- system space may be seen as a set of memory regions with a
set of attributes !!
- the attribute settings are taken care by the kernel, as per
rules of h/w(processor) and OS !!
- these attributes are managed by memory management subsystem -
it is accordingly set for user-space attributes or system space
attributes !! processor is responsible for these attributes
and operating system exploits these attributes !!! this is
achieved using a set of data structures and certain settings
in the data structures !!!
- in addition, there is a separation between the 2 spaces and
their respective components via priviliges - user-space and
its components have lesser priviliges and system-space and
its components have higher priviliges - this privilige setting
is controlled via a set of control bits in one of the processor's
registers - again, this control is also done by kernel - we will
see more of this during interrupt handling and system call
handling !!!
- user-space and system space division is one mechanism-
achieved using a h/w technique - this is more to do with
attributes set with respect to memory regions - we see
more of this during memory management !!!
- lesser privilige of user-space components vs
higher privilige of system-space components is
a different mechanism - achieved using another
h/w technique - this is more to do with cpu's
privilige settings !!!
- however, they are related !!!
- system-space components(when processor is executing in priviliged mode)
have the following priviliges:
- can access any part of the memory of the system
as per rules of the system
- can access any machine instruction of the underlying
architecture
- can access peripheral h/w controllers and
registers as per rules - can also access any control register
of the underlying processor !!
- user-space components have the following restrictions:
- can access only user-space regions of memory
- cannot access all machine instructions of the underlying
architecture
- what happens is a priviliged machine instruction
is used in an user-space component ??
- processor will generate hw exception and
os will handle the exception !!!
- cannot access h/w controllers and registers without
system calls and help of the kernel components !!
15. interrupt management !!!
- system-space manages interrupt table in the interrupt
subsystem !!
- interrupt table is a highly architecture specific table -
it is managed by interrupt subsystem with the help of
HAL
- for each interrupt type/no., a particular entry is maintained
in the interrupt table
- let us assume that hw interrupts and hw interrupts
that are maskable !!!
- what do we mean by different types of interrupts /
interrupt nos. ???
- different interrupts with different priorities
- different hw interrupts are associated/bound
with different I/O controllers !!!
- one interrupt may be associated with a hw timer
- one interrupt may be associated with network
controller
- one interrupt may be associated with a
custom I/O card used for monitoring certain
sensors !!!
- one interrupt handler is maintained by interrupt type/no.
in one entry of the interrupt table - this applies to
every interrupt no/type in the computing system - typically,
address of the interrupt handler is stored in a given
entry of the interrupt table !!!
- it is the responsibility of the kernel to setup a control
register of the processor to point to the system's interrupt
table - whenever a h/w interrupt signal of a particular
interrupt type/no. is generated, processor fetches the corresponding
interrupt handler's address from the interrupt table known
to it !!!
- let us assume an application is currently executing on the
processor and a timer h/w interrupt is generated by the
timer h/w controller !!
- processor does the following , in response to interrupt
signal :
- typically other h/w interrupts are blocked/masked and
not serviced when a particular h/w interrupt
is being serviced !!
- it does a cpu mode switch and a stack switch -
cpu mode is switched from less priviliged to
more priviliged - stack is switched from user-space
to system-space
- we will be studying about cpu's privilige mode
of operation and cpu's less priviliged mode
of operation, in the next set of slides !!!
- what is stack memory area in this context ??/
- what is the use of user-space stack ??
- needed for user-space code execution !!!
- what is the use of system space stack ??
- process contexts may be saved in system space
stack during interrupt handling
- system stack is used for executing interrupt
handlers
- system stack is used for executing system space
code on behalf of processes - one good case is
a system call API execution by the process !!!
- stack switching is done as per rules of the kernel
and help of h/w - certain register(s) may be modified !!
- current execution context of the application is saved
in the system stack !!- cpu registers are saved - meaning,
this is good enough to save the application's execution
context !!
- cpu executes a jump to the address of the corresponding
interrupt handler and starts execution of the interrupt
handler !!!
- let us assume handler completes its job(??) and
executes a special machine instruction !!
- this special machine instruction will reverse the
actions taken when an interrupt was generated - meaning,
cpu mode is switched back to less priviliged mode from
priviliged mode of operation !!!
registers(old execution context ) is restored - cpu
jumps back to an instruction in the application and
resumes execution of application normally
- this sequence of actions are repeated for every h/w
interrupt and several such interrupts may occur
in one second - these activities are seamless to
the user and developer of the system, but they
do productive work on behalf of device-drivers and
applications !!
Note: priviliged mode of processor vs less priviliged mode of
processor is critical for understanding certain aspects
of operating system - we will see more along with
system space and user space features !!!!
- processor is executing in less priviliged mode - can
we say that active applications/processes execute when
processor is in less priviliged mode !!
- processor is executing in priviliged mode - can we say
that components of core of operating system execute
when processor is executing in priviliged mode !!!
- privilige here means, corresponding components/code
can interact with any hw controller and processor !!!
- meaning, they have full privilige to manipulate hw
resources !!!
- they have full priviliges in using resources !!!
- they have privilige to access any part of the
computing system's memory space !!!
16. system call APIs use interrupt mechanism to implement
their special jumps - system call APIs use a special machine
instruction of the underlying architecture to implement
a special jump similar to h/w interrupts - in this case,
h/w signal is not generated by an external peripheral, but
a special jump is generated by a machine instruction !!
- most of the steps mentioned for h/w interrupt handler
are also applicable for this mechanism
- there are certain differences between the two mechanisms-
one such is in the interrupt handling part
- in the case of system call APIs, the corresponding interrupt
handler will pass control of execution to appropriate
system call system routine of appropriate subsystem - this
is done with the help of system call no. passed by
system call API and using system call table
- each I/O interrupt has one interrupt handler in the
interrupt table
- all system call APIs end up accessing the same
system call interrupt handler - it is the responsibility
of the system call interrupt handler to invoke appropriate
system call service routine
- in a modern day OS, there can be several system call APIs -
easily, 100s of APIs - each is assigned a fixed system call
no. and encoded in its system call API
- there is one entry for each system call API in the system
call table and it is indexed by the corresponding system
call no. - the corresponding entry contains pointer to
corresponding system call system routine !!
- additional system call APIs and their code may
be added by a skilled developer, if needed !!!
- a typical RTOS system may provide certain special,
sophisticated system call APIs that can provide
more control for the applications and these
system call APIs may not be typically available
in a typical GPOS system !!!!
- we will be using the term system call(s) very often -
this means, a system call API and its associated
system call system routine !!!
- we be saying that a system call is executing - this
means, a system call API is invoked and corresponding
system call system routine is executing in system space !!!
Note: why interrupt handlers, interrupt subsystem, system call
table and system call system routines are loaded in system space ???
- these are expected to be priviliged !!
- these components must be isolated and protected
from user-space developers !!!
Note: one of the best ways to learn operating systems/(gpos/rtos)
is to learn around an entity or a mechanism that provides
functionally useful services to applications !!! one such
entity that you may benefit for study as well work is
the process !!! one more such entity that you may benefit
is the memory resource !!!
17. process management !!
- who is responsible for the creation of the first process ???
- kernel is responsible for creating the initial set
of processes - particularly, init process is the first
user-space process created by the kernel without user's
intervention !!! although, the init process may be
customized by operating system developer !!! these system processes
are typically created during boot up of the operating system !!!
- eventually, this first process will execute certain system
scripts and provide us an environment for building our
applications and loading our applications !!!
- once such an environment is created, any further processes are
created directly or indirectly via system call APIs !!
- before understanding process creation, termination and its
states, we must understand what is a process from system
point of view - this is typically known as process management
activities !!!!
- from a user space point of view, process is an active application
or a program !!!
- refer to a slides in day1 !!!
18. following is the description of a process from a system point of
view :
- each process in the system is represented and managed via a
process descriptor in the system space !!!process manager
is responsible for creating pds and managing pds !!!
- what is a pd, in computing terms - the best term is
pd can be called as a system object !!!
- each process in the system is allocated an unique process descr.
(pd) - each pd contains information/details of a process and
also contains several nested objects , which in turn describe
several resources and information
- pd typically contains following info :
- process id
- process state
- scheduling parameters - policy, priority and time-slice
details
- maintains system stack address - run-time context
is maintained for a process in system - stack -
can you name a process state when system stack is used ???
- blocked state //waiting state !!!
- during system call jump/execution !!!
- during interrupt handling / execution !!!
- maintains addresses of active files of this process
- maintains memory descriptor
- memory descriptor maintains other descriptors that
describe virtual memory and physical memory of
the process
- pd contains fields that help the system to maintain
several lists of pds as per state information
- ready state - maintains all pds in ready state
in a ready queue !!! one ready queue exists
per processor !!!
- different waitqueues exits for different
resources !!! one waitqueue may exist
per I/O data channel !!!
Note: pd maintains info. on behalf of a process and pd is the
representative of the process and used by the system,
when needed !!!
- pd may contain credentials of a process - this
is typical in a multi-user environment - based on
the credentials, a process may have more privilige or
less privilige(do not confuse this with processor
privilige)
- all pds of active applications/processes are maintained
in a table or a list - if it is a table, it is known
as pd table - if it is a list , it is known as master
pd list - table is static in nature and list is more
dynamic in nature - lists are more popular in modern
systems
- a typical GPOS may use a list
- a typical RTOS may use a table !!!
- in the case of a table, it is preallocated
- in the case of a list, it is dynamically allocated !!
- in addition to the pd list or table, system also
maintains a ready list/ready queue of pds - these
are pds whose state is ready - meaning, waiting
for scheduler to select the process for cpu assigment -
this assumes that other resources are available !!
- in addition, system also maintains several waiting lists/
waiting queues for h/w and logical resources - when a
specific request for a resource cannot be satisfied,
system adds the corresponding pd to corresponding
wait queue !!
- can a pd be in master list and ready list ??
- yes
- can a pd be in master list and a wait queue/list ??
- yes
- can a pd be in ready list and a wait list ???
- no - this is not practical as per their states !!
- each pd is assigned an unique id known as pid - most
process system calls and kernel space code use pid
to identify a process / pd - we will be encountering
pid usage in many scenarios
Note : a process may be defined as below :
- an active application that is loaded in the user-space of
the system and is managed with the help of system objects -
system objects include pd and related nested objects -
pd mainly maintains info. for managing the process and nested
objects manage info related to resource management for the
process - in short, a process will have memory allocated
in user space for code/data/heap/stack/other segments and
in system space for pd and related objects !!!
- an active instance of an application is typically known as
process
- process is an operating system entity controlled by the
process manager and other subsystems !!!
Note: operating systems are more comfortable using ids rather
than names - for most entities, operating systems will
be using ids rather than names !!!
Note: after a process is created, it objects are created, state of
pd is set to ready and pd is added to ready queue of the
current processor's scheduler!!!
Note: scheduler may viewed as following :
- a set of methods to implement the scheduling policy or polices
- a set of objects/data structures used to manage ready queue
,pds and other run time scheduling information !!!
- when a process is created, it is added to ready, but may
not scheduled, immediately - it also depends on the implementation
and scheduling parameters !!! again, these may differ from one
OS to another OS - may differ from gpos to RTOS !!!!
- scheduler() is responsible for moving a process from
ready state to running state - meaning, scheduling the
process !!! who is responsible for scheduling the scheduler ???
- in most operating systems(including RTOS), scheduler
is typically invoked after a hw interrupt and after
completing the processing of interrupt handler on behalf
of a given hw interrupt event !!!
- in addition, in most operating systems(including RTOS),
scheduler is typically invoked after a system call
API or a system API - however, for the current discussion,
let us assume the first case - meaning, hw interrupt processing
followed by scheduler() getting invoked !!!
- system APIs are provided by components/layers of
system space - a component may use system API of
another component or layer - you may come across
these in RTOS systems as well, depending upon
the work and the environment offered by respective
RTOS !!!
- state of a process is another important info. used
by the system in maintaining processes - typically
following states are common:
- Ready
- Running
Note: if a process is said to be scheduler on the processor, what
does this really mean ??? let us assume that scheduler decides
which process must be scheduled on the processor based on
a scheduling policy - in our case, let us assume that it
is first come first serve and let us also assume that
a fixed time slice/quantum is given to the process, when it is scheduled !!!
- this involves dispatching the process on the processor !!!
- loading the processor's registers with the values
of the context of the process stored in the system
stack of the process !!! these registers may include
program counter, stack pointer, general purpose registers
and several control registers of the processor
- we will see some more fine details during another context
of discussing !!!
- once a process is dispatched by the scheduler on to the
processor, whatever happens to the process instructions/data
inside the processor, operating system is immune or ignorant !!!
- blocked/waiting
- stopped
- a developer or administrator may wish to explicitly and forcibly
stop a process for convenience and resume the process when
needed !! when a process is stopped,
it is moved from ready queue and pd's state is set to stopped -
it is not maintained in any wait queue - its resources are not
freed - still managed in the pd and when resumed, pd will be
moved to ready queue
- depending upon the environment that you may work, you may not
see stopped state - however, just be aware !!!
- terminated
- may have encountered a fatal exception
- we may forcibly terminate a process
- if a process has completed its work,
it may terminate voluntarily using a
process termination system call API !!
- a developer may have to code this explicitly
or compiler may add this system call API ,
implicitly !!!
- first 2 are known as abnormal terminatiomn
- last one is known as normal termination
- whether normal or abnormal termination, all
resources of the process are freed back to
the system !!!
- the above are commonly used states - other states do
exist in real systems and they may be extensions of
common states - in a typical Linux system, following
states are in use :
- Running/runnable
- interruptible wait
- uninterruptible wait
- stopped
- terminated
- dead
????
- when a process is running on the cpu(after scheduling),
it may request for resources - if the resource is available,
process will be allocated the resource and it will
progress - if the resource is not available, kernel
changes the state of the process to one of the wait
states and also adds the process to the appropriate
wait queue !!!
- resources may be of different types
- reading data from a file on disk is
is also one type of resource requirement
- trying to allocate memory /dynamically
is also one type of resource requirment
- trying to access an I/o device for
data is also one type of resource requirement
- trying to acquire a lock is also one type of
resource requirement !!1
-depending on the context , you may encounter
several such situations !!!
- in a typical operating system, a process
may request for resource via system call APIs !!!
- in a typical RTOS environment, you may use
sw timers to implement precise delays/time outs !!!