见 https://forum.xda-developers.com/galaxy-s5/general/fix-es-file-explorer-root-error-t3382537
原因是他们的root权限使用模块似乎只会寻找/system/xbin/su作为唯一的测试文件。。
然后TWRP有时只会把su装到/su/bin目录下，就和ES文件浏览器读的位置错开了= =
这个时候不论是用软链接还是直接把文件复制过去都行。然后ROOT工具箱就开启成功了。
Windows的局域网文件共享用的是SMB服务，使用139和445这两个端口。（没错，就是WannaCry最喜欢的那个）
之前被WannaCry病毒搞怕了，于是手动建立了两条防火墙规则，屏蔽了139和445端口的TCP和UDP连接，而最近需要局域网传文件，又得把这个服务打开。
开了之后结果没有任何反应，用局域网ip访问自己都说是远程服务器不响应连接。然后telnet了一下，连接失败。后来考虑看看是不是服务的问题，用了本地回环地址，结果居然能telnet连接，更是可以用资源管理器访问。然后由于有局域网远程连接的需要，有线网卡上配置了一个单独的网段，结果用这个ip可以访问到共享文件。（emm，日常上网用的是无线网卡）
然后咕果上查了一大堆，有以下几个解决方案：
除开2看起来不像是Windows自带的服务之外，其余的依次从头到尾试了一遍。最后一个重启网卡服务协议是啥呢，一个在巨硬论坛上找到的邪门方法。说是先把网卡-属性-Microsoft网络的文件和打印机共享勾去掉，保存，再重新点进来勾上就好了。但是在我的实际使用过程中，并未奏效。到是啥呢，顺手禁用然后重新启用了一下网卡，然后就可以访问了。
然后就可以访问了。
？？？？？？
然后就可以访问了？？？这是什么神仙操作？？？
（顺便说一句，在测试各种解决方案之前重启过很多次计算机，然而并没有用）
https://www.cnblogs.com/xiami-xm/articles/8417526.html
由于GEM5需要从原始的Linux内核可执行文件启动，不能使用压缩过的vmlinuz，所以一开始的想法是从当前发行版的软件包管理器下载压缩过的内核，然后从里面解压出完整版本的来。在Stackoverflow上看到了两种方法：
zImage和bzImage都是指的使用gzip压缩的内核，有无b的主要区别在于内核文件的大小，实际上b就代表big。作为第一个在裸处理器上运行的程序，内核显然不能指望有其他程序能够替自己解压缩，因而vmlinuz是包含有gzip自解压的代码的。也就是说，vmlinuz文件至少由压缩的内核和预操作（比如解压）代码组成。在承认这些部分的数据是各自连续的情况下，可以通过在其中寻找gzip的文件头，来寻找压缩内核的位置，然后解压即可获得原始内核。借用原文中的例子：
> od -A d -t x1 vmlinuz | grep '1f 8b 08 00' 0024576 24 26 27 00 ae 21 16 00 1f 8b 08 00 7f 2f 6b 45
其中1f 8b 08 00是gzip文件的文件头，标识一个合法的gzip文件开头。
很幸运，在当前的vmlinuz中似乎还是只含有一个gzip文件，而这个文件正是我们所需要的，经过gzip压缩的vmlinux。
> dd if=vmlinuz bs=1 skip=24584 | zcat > vmlinux 1450414+0 records in 1450414+0 records out 1450414 bytes (1.5 MB) copied, 6.78127 s, 214 kB/s
使用dd命令，从指定位置复制数据出来，bs=1表示每次的数据操作量为1字节，使用这个值能够较为简便地确定开始位置（od命令所提供的偏移量就是以字节为单位的）。比如上文中的0024576表示十六进制数据“24”相对文件首部的偏移量为24576 * 1字节 = 24576字节。将偏移量定位到gzip文件首部的“1f”，相对“24”向后偏移了8字节，故dd中的命令偏移量设置为24576 + 8 = 24584。使用管道将二进制内容直接发送到zcat，在命令行内完成文件的解压，得到预期中的vmlinux文件。
scripts目录下的extract-vmlinux脚本来完成操作。不过这个我没试过。几乎完全参考自：https://blog.csdn.net/u012822903/article/details/64506037
下载所需系统的Minimal（最小版本），或者Cloud Image（云镜像），不用安装的那种
使用util目录下的gem5img.py生成镜像：python2 util/gem5img.py init /path/to/your/img <size>
其中size表示镜像大小，一般单位为MB。根据原文，使用了root权限建立镜像。
挂载镜像：
先用losetup将文件挂载为系统可识别的设备，然后再用mount命令挂载为磁盘分区。
gem5img.py可以自动完成这一系列工作：sudo util/gem5img.py mount /path/to/your/img /mount/folder
把Linux系统上的文件树复制过去，如果是压缩文件的话直接解压到根目录即可
设置串口作为GEM5与虚拟系统的默认通信方式：
建立etc/init/tty-gem5.conf：
# ttyS0 - getty # #This service maintains a getty on ttyS0 from the point the system is # started until it is shut down again, unless there is a script passed to gem5. # If there is a script, the script is executed then simulation is stopped. start on stopped rc RUNLEVEL=[12345] stop on runlevel [!12345] console owner respawn script # Create the serial tty if it doesn't already exist if [ ! -c /dev/ttyS0 ] then mknod /dev/ttyS0 -m 660 /dev/ttyS0 c 4 64 fi # Try to read in the script from the host system /sbin/m5 readfile > /tmp/script chmod 755 /tmp/script if [ -s /tmp/script ] then # If there is a script, execute the script and then exit the simulation exec su root -c '/tmp/script' # gives script full privileges as root user in multi-user mode /sbin/m5 exit else # If there is no script, login the root user and drop to a console # Use m5term to connect to this console exec /sbin/getty --autologin root -8 38400 ttyS0 fi end script
按照目标架构，编译好m5文件放到sbin目录下：
由于不同架构下的编译方式可能不一样，make的时候要用-f选项指定目标平台所对应的Makefile。
系统内安装应用
不知道为啥要链接三个目录，但是这里不是用ln，因为非系统底层的文件系统映射，并不是所有软件都能较好支持。
这里用mount的bind选项：
sudo /bin/mount -o bind /dev dev
sudo /bin/mount -o bind /sys sys
sudo /bin/mount -o bind /proc proc然后用chroot来模拟对另一套文件系统的操作：sudo chroot /path/to/mounted/root /bin/bash
这时的bash就会按照新的伪根目录进行操作了，有root权限。内核还是宿主系统的，显然。
操作完成之后要卸载镜像，在此之前需要先把上面的三个目录umount一下。
/boot目录下的。Ubuntu的最小版本可以通过apt下载对应的内核，但是这个方法并不适用于GEM5。GEM5的启动方式是直接执行内核，因而内核必须是一个完整的文件，静态编译且保留符号才可运行，所以在镜像外部准备一个未经压缩的完整Linux内核，在启动时指定为参数即可。现在发行版提供的大多是vmlinuz，是将原始版本vmlinux脱去符号、再经gzip压缩后的版本，还原后由于没有符号不能用于GEM5，还原方法打算另开一文简述（已经写好了->参见这里）。所以考虑一下自己编译吧。写在草稿纸上，之前的工作早晚会被埋没了。
之前看了一下SSD的I/O调度算法，发现里面大有文章。
看的还是Stan Park的论文：https://dblp.org/rec/html/conf/fast/ParkS12
该论文有15页。该论文的中心内容为作者自行研发的一套SSD I/O调度器，为了体现出其性能的优越性，作者将其与一些常见的Linux I/O调度器进行了性能比较，包括应用程序综合性能和读写公平程度两大方面。毕竟，这个I/O调度器的目的是为了解决由SSD基本结构造成的读写不公平性。（读写操作共用相同队列，但是写入时间要远远长于读取时间，按照最短任务，最先执行Shortest Job First, SJF的理论来看，让大量耗时较短的读取操作等待耗时较长的写入操作完成，会对性能有相当大的负面影响；当然也不能一味地优先读取，这样对写入也不公平，让一定时间内的读取任务优先执行即可）
NOOP 仿佛是No Operation的缩写。（= =）正如其名字一样，一个队列，先来先走，不做任何操作。在实际情况下根据算法实现者的考虑，可能会对任务按照地址进行一定的顺序重排，这样能够减少一定的I/O时间（最明显的是机械硬盘，连续读取省去了磁头机械臂移动带来的额外等待耗时），但整体思路就是按先来后到发送I/O请求。
CFQ
Linux下经常使用的一个I/O调度器，全名为Completely Fair Queueing，即完全公平队列。采用类似模拟的方法计算任务的发送顺序，给每个任务建立一个单独的请求队列，然后分配相同的时间片给每个队列用以执行请求。由于公平性问题在网络（不是社交网络，理解成设备之间通信的网络比较好）上也有需求，可以借鉴一下CFQ在网络上的解决方法：由于网络层传输数据是按照包来的，显然在包头定义完长度之后整个包的大小就确定了，包的传输中断的话会被对方主机认为包损坏，因而在网络层包不可拆。所以采用这么一个办法：用计算机模拟包的预计传输时间，每次发送预计完成最早的包，在宏观上就有着近似的效果。但是由于我没有深入研究Linux上的具体实现方法，在磁盘I/O上的具体规则如何有待考证。
WFQ
Weighted Fair Queueing，加权公平队列，是CFQ的一种改版，可以为不同优先级的队列分配对应合适的时间片长度。
Deadline https://blog.csdn.net/hs794502825/article/details/24664259 照着链接看了一下源码，没看完，说的太具体了，讲的是在Linux系统中的实现，而不是算法本身的思路。
Anticipation 翻译为中文是预测。该算法主要针对在HDD上运行、需要连续读取数据的应用。如上文NOOP中略微提到过的请求重排序一样，该算法会在单次I/O请求结束后较短的时间内，强制空闲I/O设备，等待可能出现的连续地址的请求。这样对于某些加载-处理类型的任务较为友好。解决的问题是“假空闲”：一个任务的I/O请求执行完毕后，可能还没有发送下一请求；此时系统认为该程序程序暂时不需要I/O，开始处理其他程序的I/O请求。而可能恰恰在1-2ms后，该任务发出了下一I/O请求，可是却需要等到其他任务的请求执行完成后才能得到处理。（个人举例是MD5校验码的计算：MD5计算可以使用当前已计算的部分，即已经获得的部分内容的MD5码，追加需要计算部分的数据进行计算。这样做的目的是节约内存，不然一次加载整个文件的话，有的设备内存会吃不消。则程序的运行流程可视为：读取数据-合并至已有的部分数据MD5-读取数据-继续合并MD5，直至整个文件加载完成，完成整个文件的MD5计算）似乎Anticipation的等待时间典型值为6ms。但是由于该方法使用场景过于狭窄（尤其是现在多任务系统，而且不会都是连续读取型请求，所以强制空闲反而可能降低整体I/O效率），所以现在的Linux内核基本上都是不用这个的，仅作为替选方案存在于<=4.x版本的Linux内核中。
Deficit一词直译为赤字，引申为赊欠，表示在一个Round Robin轮回中没有使用完的时间可以加到下一轮回。没有用完分配时间的原因是，原子性的任务耗时若是小于可用的剩余时间，将不能执行，因而有很大概率会剩下零散的时间片。若是忽略每个程序可能剩下的不等资源片，又会在整体上表现出资源分配的不公平性。因而，采取占用一点资源的方式，记录下每个任务所剩下的未使用资源，在下一个周期补上，能够有效地弥补其公平性。