-
Notifications
You must be signed in to change notification settings - Fork 0
/
doubts.txt
66 lines (30 loc) · 6.28 KB
/
doubts.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
1. Do we store USER_AREA_PAGE block in DISK_MAP_TABLE
2. Inuput of GET_CODE_PAGE
3. Input of RELEASE_BLOCK (whether PID passed or not)
4. In RELEASE_BLOCK do we decrement the entry of DISK_FREE_LIST or nake it 0.(also if DISK_FREE_LIST contains entries 0 & 1 or the number of processes sharing that block)
5. Do we directly use "print" in exception handler or use TERMINAL_WRITE of DEVICE_MANAGER module. (IMP!!! if using TERMONAL_WRITE.. remember to save values of Exception REGS. in stack and pop them back after terminal write ....ie, along with saving R0, R1, R2, R3..etc do for EC, EIP, EPN etc.)
6. IMP!!!!! In exception handler when we call GET_CODE_PAGE shouldnt we also push EPN EMA etc. since GET_CODE PAGE might schedule another process which MIGHT generate another exception so values of Exception REGISTERS might change...
7. IMP!!!!! while allocating HEAP pages and code pages in exhandler we set reference bit to one. But while assigning HEAP page in fork do we need to set reference bit to 1 or 0 (Himanshu said in ex_handler page was referenced thenn page fault so we set reference bit to 1 there but here it is not the case...we are loading heap pages even when it was not requested for)
8. A process can be in CREATED state from 2 sources... either from FORK or INIT process created on boot. If a process is in CREATED from FORK then BP is stored on top of KERNEL_STACK, but it is not done so when INIT is CREATED on boot up. But while scheduling in a process in created state we restore the BP from top of KErnwL stack to BP. Wouldn't this cause any problem to the INIT bein gscheduled for the first time.
7. In EXIT_SYS CALL we call EXIT_PROCESS also upon exit sys call the PER_PROCESS_RESOUURCE_TABLE must be invalidated, SEMAPHOREs and FILES opemed by itmust be closed etc. ...But this doesn't seem to happen.
8. !!>>>>VVIMP<<<<In!! According to the specification of expos the KERNEL mem pages must always have count = 1 in the MEM_FREE_LIST. But when EXEC is execiuted from init (Ex. shell), RELEASE PAGE of the code page of init (page 65) occurs, hand hence it's MEM_FREE_COUNT becomes 0 ans MEM_FREE_COUNT is incremented. So now it is showing up as a free page as indicated by MEM_FREE_COUNT but it can never be allaocted by GET_FREE_PAGE, so it the entire physical mem is actually full then it can lead to problems. Also during fork, the mem_FREE_COUNT of the init process increases to more than one.
9. In RELEASE_SEMAPHORE function of process manager module at one place it ios mentioned that it takes only SEM_IND as arg while at other place it is mentioned that it takes currPID also. (!!....I have taken both....!!)
10. In Shell_2 the shell forks and parent shell waits for the child shell to complete execc of given command (wait happens using wait and signal systemcall), but the execed child may fork furthur, and the original shell(whlch execed) might exit but it's other children might still continue execution, but since parernt shell was waiting only for its original child and since now that has exited, shell can be scheduled again even if the other children of execcing shell have not exited. (example in parevod.xsm and 3forks.xsm).
11. in create systemcall, if a file with that name is already present, then we retirn 0 indincating success, but what if the given permission with create is different from the permission of the already existing file with same name, (same is the case with user and file type).
12. Last word not loaded in DATA files using xfs-interface. Ex. in sample.dat
But Akash's numbers.dat was loading properly but not my numbers.dat
13. After ACQUIRE_INODE in delete and create system call why we donot check if inode was ACQUIRED or not...(remember we do chech this in write and read syscalls after accquiring inode)
14. A serious flaw in the write systemcall design is there which allows ROOT and DATA files to be written, which should not be so according to the system specification.
NOTES...WHICH MIGHT CAUSE PROBLEMS LATER..!!! REFER IN CASE OF FACING ANY PROBLEM...!!!
1. In exec syscall_handler DISK_MAP_TABLE updated only for code pages and not for STACK AND HEAP pages. (Himanshu told we would do that in that in the pager module).
2. In excep handler prints are too large.
3. In fork reference bit in alloacted HEAP, STACK, USER_AREA_PAGE etc, pages.
4. Unusual poppin in FORK while allocating STACK and USER_AREA_PAGE of childi
5. A process can be in CREATED state from 2 sources... either from FORK or INIT process created on boot. If a process is in CREATED from FORK then BP is stored on top of KERNEL_STACK, but it is not done so when INIT is CREATED on boot up. But while scheduling in a process in created state we restore the BP from top of KErnwL stack to BP. Wouldn't this cause any problem to the INIT bein gscheduled for the first time.i
6. In EXIT_SYS CALL we call EXIT_PROCESS also upon exit sys call the PER_PROCESS_RESOUURCE_TABLE must be invalidated, SEMAPHOREs and FILES opemed by itmust be closed etc. ...But this doesn't seem to happen.
7. !!>>>>VVIMP<<<<In!! According to the specification of expos the KERNEL mem pages must always have count = 1 in the MEM_FREE_LIST. But when EXEC is execiuted from init (Ex. shell), RELEASE PAGE of the code page of init (page 65) occurs, hand hence it's MEM_FREE_COUNT becomes 0 ans MEM_FREE_COUNT is incremented. So now it is showing up as a free page as indicated by MEM_FREE_COUNT but it can never be allaocted by GET_FREE_PAGE, so it the entire physical mem is actually full then it can lead to problems. Also during fork, the mem_FREE_COUNT of the init process increases to more than one.
8. in create systemcall, if a file with that name is already present, then we retirn 0 indincating success, but what if the given permission with create is different from the permission of the already existing file with same name, (same is the case with user and file type).
9. Last word not loaded in DATA files using xfs-interface. Ex. in sample.dat
But Akash's numbers.dat was loading properly but not my numbers.dat
10. After ACUIRE_INODE in delete system call why we donot check if inode was ACQUIRED or not...(remember we do chech this in write and read syscalls after accquiring inode)
11. A serious flaw in the write systemcall design is there which allows ROOT and DATA files to be written, which should not be so according to the system specification.