android graphics

1.graphics system is based on pipeline
2.A-->B-->rendering
3.in android there is the concept of surfaces,layers
4.its kind of stack arrangement where we see things that are on top
5.a layer can have multiple surfaces and multiple windows
6.a surface gets pushed to hardware for rendering

protocol state machine

below are some state handling scenarios
1.before sending connection request, complete comes
2.before connection request pending, complete comes
3.without a previous connection, connection reconfiguration comes
4.without a previous connection, close comes
5.without sending a connection request accept or reject comes

baseline for some of the in/out requests, checking of states are mandatory
some of them passes through this first layer, another layer of checking


sometimes state transition calls are synchronous
1.nas connection request may call rrc connection request and wait till it is completed
before changing its state

work flow

1.total work progress should follow the ratio of 80/20
2. 80 on abstract level -- tgt
3. 20 on paper -- code

storage media

1.boot sector
contains an execitable program within 512 bytes
contains a partition table

2.Partition table
contains entries for the different types of file systems distributes over the entire disk space
contains the addressible max space for the filesystem

Max number of primary partitions is 4

May be chaining of partition tables are possible

msi, msix basic idea

1.legacy system motherboards have the pci interrupt lines hardwired to cpu's in 1 to 1 manner in a SMP system
2.so if a device was allocated INT A line its interrupt would endup on proc 1
3.though the interrupt post processing can happen on any proc x because of DPC
4.msi,msi-x provides mechanism to dynamically decide the destination of an interrupt
5.there is a junction to which the interrupts are routed and where it is decided upon the cpu on which it will end
6. the whole process is transparent to the software
7. in this method additional pre specified context informations can also be specified with the interrupt

8. earlier interrupt handler used to take device_object as the incoming parameter
9. now it will be possible to associate context parameter to different interrupt lines , so that
for that line you will get a corresponding context
10.for eg assume that we have 6 receive queues, that have been programmed to transfer interrupts to 3 lines
11. so every time data comes to a receive queue, interrupt handler with corresponding queue context or device object with a queue number as parameter will be called.

c++ protocol

1. base class level specialization may be required
2. default contexts can increase in number based on specialization
3. demux,mux contexts can vary in implementation based on separate threads or live thread system

engineering everywhere

needs
1.a remote repo
2.basic environment, browser, bin cache(pkg), lib cache(pkg), ide, toolchains should be present in remote repo
3.fast download of the above to local repo
4.local repo has hooks to make the contents active on a button click
5.local repo has a rsync option so that any updation to its contents can be synced to remote repo

way to achieve this
1.use debootstrap , chroot method ... try first on usb pen drive

issues
1.typical remote repo size will be in gb's