13-01-23-->8

每个进程都有一个非负整型表示的唯一进程ID。

系统有一些专用的进程:

ID为0的进程常为调度进程(swapper),改进程是内核的一部分,不执行任何磁盘上的程序,因此也被称为系统进程。

ID为1的进程常为init进程,在自举过程(bootstrap procedure)结束由内核调用。负责在自举内核后启动一个UNIX系统。init通常读与系统有关的初始化文件(/etc/rc*文件或/etc/inittab文件,以及/etc/init.d中的文件),并将系统引导到一个状态(例如多用户)。init进程绝不会终止,它是一个普通的用户进程,不是内核的系统进程,但是它以超级用户特权运行。


fork,子进程是父进程的副本。子进程获得父进程数据空间、堆和栈的副本。父子进程不共享这些存储空间部分,他们共享正文段。

由于fork之后经常跟随一个exec,所以现在很多实现使用了写时复制(COW)技术。


以前知识:write函数是不带缓冲的。

                    标准I/O库是带缓冲的。如果标准输出连到终端设备,则它是行缓冲的,否则它是全缓冲的。


文件共享



vfork与fork一样都创建一个子进程,但是它并不将父进程的地址空间完全复制到子进程中,因为子进程会立即调用exec(或exit),于是也就不会访问该地址空间。而且vfork保证子进程先运行,在它调用exec或exit之后父进程才可能被调度运行。


进程的终止,不管经过哪种方式终止,最后都会执行内核中的同一段代码。这段代码为相应进程关闭所有打开描述符,释放它所使用的存储器等。

在任意一种情况下,该终止进程的父进程都能用wait或waitpid函数取得其终止状态


僵尸进程:一个已经终止,但是其父进程尚未对其进行善后处理(获取终止子进程的有关信息,释放它占用的资源)的进程。


wait,waitpid函数

当一个进程正常或异常终止时,内核就向其父进程发送SIGCHLD信号。

pid_t wait(int * statloc);

pid_t waitpid(pid_t pid, int* statloc , int options);

区别:1.在一个子进程终止前,wait使其调用者阻塞,而waitpid有一个选项,可使调用者不阻塞。

            2.waitpid并不等待在其调用之后的第一个终止子进程,它有若干个选项,可以控制它所等待的进程。


程序清单8-5结果:



6种exec:

调用exec并不创建新进程,所以前后的进程ID并未改变。exec只是用一个全新的程序替换了当前程序的正文,数据,堆和栈段。

记忆exec函数的参数:字母p表示取filename作为参数,并用PATH环境变量寻找可执行文件。字母l表示取一个参数表,它与字母v互斥。v表示取一个argv[]。最后,字母e表示取envp[]数组,而不使用当前环境。

在执行exec前后实际用户ID和实际组ID保持不变,而有效ID是否改变取决于所执行程序文件的设置用户ID位和设置组ID位是否设置。如果新程序的设置用户ID位已设置,则有效用户ID编程程序文件所有者的ID,否则有效用户ID不变。对组ID的处理方式与此相同。




更改用户ID和组ID

int setuid(uid_t uid);设置实际用户ID和有效用户ID

int setgid(gid_t gid);设置实际组ID和有效组ID

1)进程有超级用户特权。setuid将实际用户ID,有效用户ID,以及保存的设置用户ID设置为uid;

2)若无超级用户特权,但uid=实际用户ID或保存的设置用户ID,则setuid只讲有效用户设置为uid;

3)若以上两个条件都不满足,则error设置为EPERM,并返回-1。


关于内核所维护的三个用户ID,需注意:

1)只有超级用户进程可以更改实际用户ID。e.g.login是一个超级用户进程,可在用户登录时,设置实际用户ID。

2)仅当对程序文件设置了设置用户ID时,exec函数才会设置有效用户ID。

3)保存的设置用户ID是由exec复制有效用户ID而得来的。


解释器文件

起始行的形式是 #!pathname [optional-argument]  e.g.常见 #!/bin/sh

 对这种文件的识别是由内核作为exec系统调用处理的一部分来完成的。内核使调用exec函数的进程实际执行的是该解释器文件第一行中的pathname所指定的文件。


system函数

int system(const char * cmdstring);

system在其实现中调用了fork,exec,waitpaid。



进程会计

acct函数用于启动和禁用进程会计。accton命令使用此函数。

会计文件中记录的顺序对应于进程终止的顺序,而不是它们启动的顺序。


用户标识

char *getlogin(void); 用此函数通常可以获取用户登录时使用的名字。

给出登录名后,就可以使用getpwnam在口令文件中查找用户的相应记录。



RE5C86L1:/ # ls -la /dev/block/by-name total 0 drwxr-xr-x 2 root root 1700 2025-01-01 13:05 . drwxr-xr-x 6 root root 3960 2025-01-01 13:05 .. lrwxrwxrwx 1 root root 16 2025-01-01 13:05 audio_dsp_a -> /dev/block/sdc25 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 audio_dsp_b -> /dev/block/sdc53 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 boot_a -> /dev/block/sdc36 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 boot_b -> /dev/block/sdc64 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 boot_para -> /dev/block/sdc49 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu1_a -> /dev/block/sdc31 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu1_b -> /dev/block/sdc59 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu2_a -> /dev/block/sdc32 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu2_b -> /dev/block/sdc60 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu3_a -> /dev/block/sdc33 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cam_vpu3_b -> /dev/block/sdc61 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cdt_engineering_a -> /dev/block/sdc48 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 cdt_engineering_b -> /dev/block/sdc69 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 dpm_a -> /dev/block/sdc27 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 dpm_b -> /dev/block/sdc55 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 dtbo_a -> /dev/block/sdc39 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 dtbo_b -> /dev/block/sdc67 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 expdb -> /dev/block/sdc7 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 flashinfo -> /dev/block/sdc72 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 frp -> /dev/block/sdc8 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 gz_a -> /dev/block/sdc34 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 gz_b -> /dev/block/sdc62 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 init_boot_a -> /dev/block/sdc38 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 init_boot_b -> /dev/block/sdc66 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 lk_a -> /dev/block/sdc35 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 lk_b -> /dev/block/sdc63 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 logo -> /dev/block/sdc50 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 mcupm_a -> /dev/block/sdc30 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 mcupm_b -> /dev/block/sdc58 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 md1img_a -> /dev/block/sdc23 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 md1img_b -> /dev/block/sdc51 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 metadata -> /dev/block/sdc17 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 misc -> /dev/block/sdc1 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 nvcfg -> /dev/block/sdc9 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 nvdata -> /dev/block/sdc10 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 nvram -> /dev/block/sdc43 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 ocdt -> /dev/block/sdc44 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 oplus_custom -> /dev/block/sdc6 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 oplusreserve1 -> /dev/block/sdc3 lrwxrwxrwx 1 root root 15 2025-01-01 13:04 oplusreserve2 -> /dev/block/sdc4 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 oplusreserve3 -> /dev/block/sdc5 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 oplusreserve5 -> /dev/block/sdc45 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 oplusreserve6 -> /dev/block/sdc46 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 otp -> /dev/block/sdc22 lrwxrwxrwx 1 root root 15 2025-01-01 13:05 para -> /dev/block/sdc2 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 param -> /dev/block/sdc47 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 persist -> /dev/block/sdc18 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 pi_img_a -> /dev/block/sdc26 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 pi_img_b -> /dev/block/sdc54 lrwxrwxrwx 1 root root 23 2025-01-01 13:05 preloader_a -> /dev/block/mmcblk0boot0 lrwxrwxrwx 1 root root 23 2025-01-01 13:05 preloader_b -> /dev/block/mmcblk0boot1 lrwxrwxrwx 1 root root 30 2025-01-01 13:05 preloader_emmc_a -> /dev/block/by-name/preloader_a lrwxrwxrwx 1 root root 30 2025-01-01 13:05 preloader_emmc_b -> /dev/block/by-name/preloader_b lrwxrwxrwx 1 root root 22 2025-01-01 13:05 preloader_raw_a -> /dev/block/mapper/pl_a lrwxrwxrwx 1 root root 22 2025-01-01 13:05 preloader_raw_b -> /dev/block/mapper/pl_b lrwxrwxrwx 1 root root 30 2025-01-01 13:05 preloader_ufs_a -> /dev/block/by-name/preloader_a lrwxrwxrwx 1 root root 30 2025-01-01 13:05 preloader_ufs_b -> /dev/block/by-name/preloader_b lrwxrwxrwx 1 root root 16 2025-01-01 13:05 proinfo -> /dev/block/sdc42 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 protect1 -> /dev/block/sdc19 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 protect2 -> /dev/block/sdc20 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 scp_a -> /dev/block/sdc28 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 scp_b -> /dev/block/sdc56 lrwxrwxrwx 1 root root 14 2025-01-01 13:05 sda -> /dev/block/sda lrwxrwxrwx 1 root root 14 2025-01-01 13:05 sdb -> /dev/block/sdb lrwxrwxrwx 1 root root 14 2025-01-01 13:05 sdc -> /dev/block/sdc lrwxrwxrwx 1 root root 16 2025-01-01 13:05 sec1 -> /dev/block/sdc41 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 seccfg -> /dev/block/sdc21 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 spmfw_a -> /dev/block/sdc24 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 spmfw_b -> /dev/block/sdc52 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 sspm_a -> /dev/block/sdc29 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 sspm_b -> /dev/block/sdc57 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 super -> /dev/block/sdc70 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 tee_a -> /dev/block/sdc40 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 tee_b -> /dev/block/sdc68 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 userdata -> /dev/block/sdc71 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 vbmeta_a -> /dev/block/sdc11 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 vbmeta_b -> /dev/block/sdc14 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 vbmeta_system_a -> /dev/block/sdc12 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 vbmeta_system_b -> /dev/block/sdc15 lrwxrwxrwx 1 root root 16 2025-01-01 13:04 vbmeta_vendor_a -> /dev/block/sdc13 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 vbmeta_vendor_b -> /dev/block/sdc16 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 vendor_boot_a -> /dev/block/sdc37 lrwxrwxrwx 1 root root 16 2025-01-01 13:05 vendor_boot_b -> /dev/block/sdc65如何查看preloader_a和preloder_b的实际物理地址
最新发布
12-31
<think>我们想要查看preloader_a和preloader_b的实际物理地址。在Android/Linux系统中,/dev/block/by-name目录下的文件是符号链接,指向实际的块设备节点(如/dev/block/mmcblk0pX)。要得到实际物理地址,通常指的是该分区在eMMC或UFS存储上的起始扇区号(sector offset)和大小。 根据之前的引用,我们知道preloader_raw.img等分区存在,并且根据引用[3]中我们可以看到一些分区信息(如/dev/block/mmcblk0p54对应/metadata)。但是,preloader分区通常不会挂载到文件系统,因此使用`df`命令(如引用[3])是看不到的。 我们可以通过以下步骤获取preloader_a和preloader_b的实际物理地址: 1. 首先,确定preloader_a和preloader_b在/dev/block/by-name下的符号链接指向的实际块设备节点。 2. 然后,通过读取块设备节点的信息来获取其在存储设备上的起始扇区。 具体方法: 步骤1:在设备上执行命令,查看符号链接指向。 使用`adb shell`进入设备,然后使用`ls -l`命令查看: ```bash adb shell ls -l /dev/block/by-name | grep preloader ``` 示例输出可能如下: ``` lrwxrwxrwx 1 root root 10 1970-01-01 08:00 preloader_a -> /dev/block/mmcblk0p1 lrwxrwxrwx 1 root root 10 1970-01-01 08:00 preloader_b -> /dev/block/mmcblk0p2 ``` 步骤2:获取物理地址(起始扇区和大小) 在Linux中,我们可以使用`cat /proc/partitions`来查看所有分区的块数(每个块大小为1KB),但这并不直接给出扇区地址。另一种方法是使用`sgdisk`或`gdisk`工具(如果设备支持)来查看分区表。然而,很多Android设备可能没有这些工具。 另一种方法是直接读取`/sys/block/mmcblk0/mmcblk0pX/start`文件,其中X是分区号(例如p1、p2)。该文件中的数字就是该分区在mmcblk0设备上的起始扇区(通常扇区大小为512字节)。 例如,对于`/dev/block/mmcblk0p1`,我们可以查看: ```bash adb shell cat /sys/block/mmcblk0/mmcblk0p1/start ``` 该命令会输出一个数字,就是起始扇区号。 同样,大小信息可以通过`/sys/block/mmcblk0/mmcblk0p1/size`获取。 但是,请注意:有些设备可能有多个存储设备(如mmcblk0, mmcblk1等),我们需要确定preloader分区所在的块设备。通常,preloader分区位于主存储设备(boot device)上,即`mmcblk0`。 因此,具体操作: 1. 获取preloader_a和preloader_b对应的实际块设备节点(例如:/dev/block/mmcblk0p1和/dev/block/mmcblk0p2)。 2. 然后通过`/sys/block/mmcblk0/<分区名称>/start`读取起始扇区。 注意:如果设备上没有`/sys/block/mmcblk0`,可能需要根据实际设备调整(比如可能是`sda`等,但Android设备通常是mmcblk0)。 另外,我们也可以使用`cat /proc/emmc`(如果存在)来查看所有eMMC分区信息,包括起始地址和大小。但并非所有设备都支持。 综合以上,我们可以这样操作: 首先,获取preloader_a和preloader_b的块设备节点: ```bash adb shell ls -l /dev/block/by-name | grep -E 'preloader_a|preloader_b' ``` 假设输出: ``` preloader_a -> /dev/block/mmcblk0p1 preloader_b -> /dev/block/mmcblk0p2 ``` 然后,分别获取这两个分区的起始扇区: ```bash adb shell cat /sys/block/mmcblk0/mmcblk0p1/start adb shell cat /sys/block/mmcblk0/mmcblk0p1/size adb shell cat /sys/block/mmcblk0/mmcblk0p2/start adb shell cat /sys/block/mmcblk0/mmcblk0p2/size ``` 这样,我们就得到了起始扇区和扇区数量(大小)。 注意:由于设备可能没有root权限,有些操作可能需要root。如果设备没有root,可能无法读取这些文件。在未root的设备上,可以尝试通过fastboot模式获取分区表信息: ```bash fastboot oem partition ``` 但并非所有设备都支持该命令。 另外,在Android的bootloader模式下,可以使用: ```bash fastboot getvar all ``` 来查看分区信息,但通常不包括每个分区的扇区地址。 如果设备已经root,也可以使用`parted`命令(如果设备上有): ```bash adb shell su parted /dev/block/mmcblk0 unit s print ``` 该命令会打印整个分区表,包括每个分区的起始扇区和结束扇区。 总结方法: 1. 通过ADB获取符号链接指向(需要设备在线,不需要root) 2. 通过sysfs获取起始扇区和大小(需要设备在线,不需要root,但需要内核提供sysfs接口,通常有) 3. 如果无法通过ADB获取,且设备可以进入fastboot,尝试fastboot命令(需要设备支持) 4. 如果设备已root,使用parted命令(如果安装)获取完整分区表。 根据引用[1]中,我们注意到有preloader_raw.img,这通常是一个分区镜像,但我们的目标是在设备上查看实际分区的物理地址。 因此,我们提供ADB命令的方法(不需要root,但需要内核支持sysfs)作为首选。 注意:有些设备可能将preloader分区放在不同的块设备上(比如bootdevice),但符号链接已经指向了正确的设备节点。 操作步骤总结: 1. 连接设备,确保adb可用。 2. 执行: ```bash adb shell ls -l /dev/block/by-name | grep -E 'preloader_a|preloader_b' ``` 3. 记录下指向的实际节点,比如`/dev/block/mmcblk0p1`和`/dev/block/mmcblk0p2`。 4. 然后分别查询这两个节点的起始扇区: ```bash adb shell cat /sys/block/mmcblk0/mmcblk0p1/start adb shell cat /sys/block/mmcblk0/mmcblk0p1/size adb shell cat /sys/block/mmcblk0/mmcblk0p2/start adb shell cat /sys/block/mmcblk0/mmcblk0p2/size ``` 例如,输出可能是: ``` 0 # preloader_a的起始扇区 1024 # preloader_a的大小(扇区数) 1024 # preloader_b的起始扇区 1024 # preloader_b的大小(扇区数) ``` 注意:扇区大小通常是512字节,所以preloader_a大小为1024*512=512KB。 如果`/sys/block/mmcblk0`下没有对应的分区节点(比如设备是分区的,但sysfs结构不同),可以尝试: ```bash adb shell cat /sys/block/*/mmcblk0p1/start ``` 或者,更一般地,我们也可以直接使用`/sys/block/mmcblk0/mmcblk0p1/start`,其中`mmcblk0`是设备,`mmcblk0p1`是分区节点。 如果设备上没有这些文件,则可能需要root权限,或者尝试其他方法(如fastboot)。 另外,根据引用[2]中,我们看到了构建镜像时的一些参数,但这对查看设备上的实际物理地址没有直接帮助。 因此,我们给出ADB命令的解决方案。 最后,生成相关问题: </think> ### 查看preloader分区物理地址的方法 要查看 `/dev/block/by-name` 下 `preloader_a` 和 `preloader_b` 的实际物理地址,请按照以下步骤操作: #### 1. **获取块设备节点** 首先确定符号链接指向的实际块设备节点: ```bash adb shell ls -l /dev/block/by-name | grep preloader ``` 示例输出: ``` lrwxrwxrwx 1 root root 15 2023-11-15 10:00 preloader_a -> /dev/block/mmcblk0p1 lrwxrwxrwx 1 root root 15 2023-11-15 10:00 preloader_b -> /dev/block/mmcblk0p2 ``` #### 2. **查询物理地址** 通过 `/sys` 文件系统获取物理扇区地址: ```bash # 查询preloader_a的物理地址 adb shell cat /sys/block/mmcblk0/mmcblk0p1/start # 起始扇区 adb shell cat /sys/block/mmcblk0/mmcblk0p1/size # 扇区数量 # 查询preloader_b的物理地址 adb shell cat /sys/block/mmcblk0/mmcblk0p2/start adb shell cat /sys/block/mmcblk0/mmcblk0p2/size ``` #### 3. **计算物理地址范围** 物理地址计算公式: $$ \text{起始地址(字节)} = \text{起始扇区} \times 512 \\ \text{结束地址(字节)} = (\text{起始扇区} + \text{扇区数量}) \times 512 - 1 $$ 例如输出: ``` # preloader_a 起始扇区: 0 扇区数量: 4096 ``` 则地址范围为: $$0 \times 512 = 0 \text{ (0x0)}$$ $$(4096 \times 512) - 1 = 2,097,151 \text{ (0x1FFFFF)}$$ #### 4. **验证分区信息(可选)** 使用 `dmesg` 检查内核加载时的分区信息: ```bash adb shell dmesg | grep -i "preloader.*partition" ``` 典型输出: ``` [ 0.123456] preloader_a: partition @ sector 0, size 4096 sectors [ 0.123457] preloader_b: partition @ sector 4096, size 4096 sectors ``` #### 注意事项 1. 需要 **ADB调试权限** 和 **root权限**(部分设备需 `adb root`) 2. 扇区大小默认为 512 字节(可通过 `adb shell cat /sys/block/mmcblk0/queue/hw_sector_size` 确认) 3. 若使用 UFS 存储,设备名可能为 `sda` 而非 `mmcblk0` > 关键点:preloader分区通常位于存储设备起始位置(如0x0-0x1FFFFF),因它是设备启动时最先加载的固件[^1]。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值