4.14 linux

2018-01-26 19:28:16 petpig0312 阅读数 698
正如所承诺的,Linux内核维护者Greg Kroah-Hartman今天发布了针对长期支持的Linux 4.14,4.9,4.4和3.18内核系列的一系列新更新。

这些新内核在他们之前发布的一个星期后,添加了更多的x86更新,以保护用户不受本月初的Meltdown和Spectre安全漏洞的影响。他们还包括各种更新的GPU,InfiniBand,USB,加密,声音,网络驱动程序,以及一些核心网络变化。

Linux kernel 4.14.14总共改变了130个文件,其中2524个插入和542个删除,Linux kernel 4.9.77个LTS改变了112个文件,其中2306个插入和466个删除,Linux kernel 4.4.112个LTS改变了90个文件,1811个插入和523个删除,Linux kernel 3.18.92更改了38个文件,其中487个插入和192个删除。

Linux内核4.14.14,4.9.77,4.4.112和3.18.92更新发布Linux内核4.14.14,4.9.77,4.4.112和3.18.92更新发布

相关:内核开发者称应更新Linux内核应对 Meltdown 和 Spectre漏洞  http://www.linuxidc.com/Linux/2018-01/150204.htm

所有用户必须尽快更新他们的系统

正如Greg Kroah-Hartman在本月早些时候发布的关于Linux内核中的Meltdown和Spectre补丁状态的更新中指出的那样,用户必须习惯于随时保持系统的最新状态,特别是当一个新的内核版本可用。因此,如果您收到这些内核,请立即更新您的系统。

我们强烈建议所有操作系统供应商为其GNU/Linux发行版下载和编译Linux 4.14.14,4.9.77,4.4.112或3.18.92内核,并将它们作为稳定软件存储库中的更新发布,供用户安装他们尽快。您可以从kernel.org获取这些新内核版本的源代码。

更新的git树在

    • git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
    • git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
    • git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y
    • git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y
2019-01-13 11:20:27 qq_18737805 阅读数 388

Linux-4.14内核是全志H3的主线内核,是一个非常纯净的内核。而以前使用多半是基于全志公司定制开发的linux3.4,发现它并没有支持设备树。

  • 编译安装uboot

 安装交叉编译器

推荐使用的交叉编译器arm-cortexa9-linux-gnueabihf-4.9.3.tar.xz

tar xf arm-cortexa9-linux-gnueabihf-4.9.3.tar.xz //解压
export PATH=~/4.9.3/bin:$PATH //编译器的路径加入到PATH
arm-linux-gcc -v //查看是否安装成功

 编译uboot

下载U-boot源码,并切换分支:

git clone https://github.com/friendlyarm/u-boot.git -b sunxi-v2017.x --depth 1

编译u-boot

apt-get install swig python-dev python3-dev //设置环境
make nanopi_h3_defconfig ARCH=arm CROSS_COMPILE=arm-linux-    //配置
make ARCH=arm CROSS_COMPILE=arm-linux- //编译

编译完成后在u-boot源码中会生成u-boot-sunxi-with-spl.bin 和u-boot.bin 前者是与启动方式有关 后者与启动方式无关的bootloader

  • 下载, 编译linux内核

下载Linux内核源码,并切换分支:

git clone https://github.com/friendlyarm/linux.git -b sunxi-4.14.y --depth 1

编译内核:

cd linux
touch .scmversion
make sunxi_defconfig ARCH=arm CROSS_COMPILE=arm-linux- //配置内核
make zImage dtbs ARCH=arm CROSS_COMPILE=arm-linux-
//编译内核和设备树

编译完成后会在arch/arm/boot/目录下生成zImage,并且在arch/arm/boot/dts/目录下生成dtb文件

  •  制作刷机包

制作一个 512M 的空白映象文件:

dd if=/dev/zero of=fs_nanopi-m1_512M.img bs=1M count=512

把映象文件设置为“回环设备”:

sudo losetup /dev/loop0  fs_nanopi-m1_512M.img

分区:第一个分区格式化成FAT文件系统,来转载内核和设备树,大小设置成30M 第二个分区格式化成ext4文件系统,我们使用前面使用buildroot构建的文件系统,大小设置成256M 可以参看在nanopi-neo构建文件系统相关章节 第一个分区前面偏移20M,前面的无名分区放uboot 使用fdisk命令分区

sudo fdisk /dev/loop0
分区完后可以看到分区信息

识别分区, 并格式化:

sudo partprobe /dev/loop0
$ sudo mkfs.vfat -I /dev/loop0p1
$ sudo mkfs.ext4 /dev/loop0p2

烧写 bootloader

cd u-boot
$ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/loop0 bs=1k seek=8
$ sudo dd if=u-boot.bin of=/dev/loop0 bs=1k seek=16400

烧写内核和设备树

cd linux
sudo mount -t vfat /dev/loop0p1 /mnt
sudo arch/arm/boot/zImage arch/arm/boot/dts/sun8i-h3-nanopi-m1.dtb /mnt
sudo umount /mnt

烧写文件系统

cd ~/build_root/nfs_root
sudo mount /dev/loop0p2 /mnt
sudo cp * -rfd /mnt
sudo umount /mnt

卸载回环设备, 烧写 TF 卡

sudo losetup -d /dev/loop0

卸载完后将得到映像文件fs_nanopi-m1_512M.img,用工具 win32diskimager 把它烧到 TF 卡中,此 TF 卡即可用来启动 nanopi-m1

板子上电后,有uboot启动信息,但不能启动内核,还需设置两个重要的环境变量bootcmd和bootargs。设置前者就是把内核和dtb从TF卡上读取到指定的内存位置,然后从指定位置启动内核并在指定的内存解析dtb文件。后者指定了根文件系统位于哪个分区

setenv bootcmd "fatload mmc 0:1 46000000 zImage;fatload mmc 0:1 47000000 sun8i-h3-nanopi-m1.dtb;bootz 46000000 0:0 47000000"
setenv bootargs "root=/dev/mmcblk1p2 rw console=ttyS0,115200"
saveenv

设置完成后,即可正确进入文件系统

  •  更新内核 和设备树

    在开发过程中需要调试板子,需要不断更新内核和设备树文件。启动进入文件系统后 mount /dev/mmcblk1p1 /mnt 出现ascii not found 还需指定字符集 mount -t vfat -o iocharset=cp437 /dev/mmcblk1p1 /mnt

使用cp zImage /mnt 然后 umount /mnt 重启后即可以看到内核被更新了 cp sun8i-h3-nanopi-m1.dtb /mnt    umount /mnt 重启后即可以看到设备树文件被更新了

2018-08-25 20:16:54 cui841923894 阅读数 748

源于https://kernelnewbies.org/Linux_4.14

1.支持更大的内存
原始x86-64平台受限于4级分页的限制,最大支持256TiB的虚拟地址空间和64TiB的物理地址空间。现在我们已经碰到了这个限制:一些供应商现在开始提供64TiB内存的服务器。因此内核x86平台支持5级分页,突破了128PiB虚拟地址空间和4PiB物理地址空间的限制,This “ought to be enough for anybody”。
详情:https://lwn.net/Articles/717293/

2.添加AMD安全内存加密功能
安全内存加密技术可以通过页表将内存页加密。标记为加密的内存页面在从DRAM读取时会自动解密,并在写入DRAM时自动加密。因此,安全内存加密技术可用于保护DRAM的物理内容免受来自系统的攻击。
详情:https://lwn.net/Articles/686808/#sme

3.ORC unwinder更好地内核跟踪器
“unwinder“,指打印已经执行的函数列表(栈信息,调用图,调用栈)。内核虽然有一个unwinder并且运行良好,但是它一般都不可靠,会导致功能问题。同时它还需要”frame pointers“(CONFIG_FRAME_POINTERS)来打印完整的调用栈,这使得GCC向内核每个函数添加检测代码,内核可执行代码大小增加约3.2%。并且在工作负载比较大的情况下会降低内核的性能。
相比之下,ORC unwinder不需要任何地方插入代码,因此不会影响内核运行性能。
详情:
https://lwn.net/Articles/728339/
http://www.codeblueprint.co.uk/2017/07/31/the-orc-unwinder.html

4.Btrfs和Squashfs支持zstd压缩方式
zstd压缩方式在压缩速度和质量之前有更好的表现,它接近lz4的压缩速度,并且质量接近lzma。zstd解压缩的速度是zlib的两倍以上。
详情:https://github.com/facebook/zstd

5.未来GPU的异构内存管理 (https://lwn.net/Articles/684916/

6.支持异步缓冲I/O
此版本中preadv2(2)加入RWF_NONBLOCK标志,允许用户空间应用程序绕过线程池的队列操作,从而缓解缓冲I/O的阻塞。

7.增强SMP和cpufreq之间协调
在Linux中,任务调度事件通知到cpufreq子系统,cpufreq可以在任务需要时增加频率,并实现良好的交互性。但是,当调度发生在不同的CPU时,不会调用到cpufreq,例如在另一个CPU中创建新进程时。此版本使任务调度可以通知到远程CPU的cpufreq子系统。
详情:https://lwn.net/Articles/732740/

8.CGroup支持线程模式
此版本中,cgroup v2支持线程模式,以支持某些进程的线程需要跨组分发资源。默认情况下,进程的所有线程都属于同一个cgroup,该cgroup看做管理资源的资源域。但线程模式允许线程分布在子树的同时仍然共享资源。
详情:https://lwn.net/Articles/729215/
这里写图片描述

2018-11-13 15:08:33 rikeyone 阅读数 649

idle进程是内核创建的第一个进程,也常常被叫做swapper 进程:


asmlinkage __visible void __init start_kernel(void)
{
    char *command_line;
    char *after_dashes;

    set_task_stack_end_magic(&init_task);

idle进程也是唯一一个不是通过fork产生的进程,他是静态定义的一个进程,init_task就是它的任务结构体。在start_kernel函数的最后:

asmlinkage __visible void __init start_kernel(void)
{
......

/* Do the rest non-__init'ed, we're now alive */
rest_init();

}

rest_init函数中会创建我们系统的第一个用户空间进程,那就是大名鼎鼎的pid为1的init进程。init进程是所有用户空间进程的祖先进程,而idle进程是所有进程的祖先进程。



static noinline void __ref rest_init(void)

{

    struct task_struct *tsk;

    int pid;

    

    rcu_scheduler_starting();

    /*

     * We need to spawn init first so that it obtains pid 1, however

     * the init task will end up wanting to create kthreads, which, if

     * we schedule it before we create kthreadd, will OOPS.

     */

    pid = kernel_thread(kernel_init, NULL, CLONE_FS);


 static int __ref kernel_init(void *unused)
 {
     int ret;

 
     kernel_init_freeable();
     /* need to finish all async __init code before freeing the memory */
     async_synchronize_full();
     ftrace_free_init_mem();
     free_initmem();
     mark_readonly();
     system_state = SYSTEM_RUNNING;
     numa_default_policy();
     rcu_end_inkernel_boot();

     if (ramdisk_execute_command) {
         ret = run_init_process(ramdisk_execute_command);
         if (!ret)
             return 0;
         pr_err("Failed to execute %s (error %d)\n",
                ramdisk_execute_command, ret);
     }

     /*

      * We try each of these until one succeeds.

      *

      * The Bourne shell can be used instead of init if we are

      * trying to recover a really broken machine.

      */

     if (execute_command) {

         ret = run_init_process(execute_command);

         if (!ret)

             return 0;

         panic("Requested init %s failed (error %d).",

               execute_command, ret);

     }

     if (!try_to_run_init_process("/sbin/init") ||

         !try_to_run_init_process("/etc/init") ||

         !try_to_run_init_process("/bin/init") ||

         !try_to_run_init_process("/bin/sh"))

         return 0;

 

     panic("No working init found.  Try passing init= option to kernel. "




在init进程创建完成后,该进程还会创建kthreadd进程,最后进入do_idle,也就是我们所说的idle进程所做的事情,让cpu 进入idle状态。

void cpu_startup_entry(enum cpuhp_state state)
{
    /*

     * This #ifdef needs to die, but it's too late in the cycle to

     * make this generic (arm and sh have never invoked the canary

     * init for the non boot cpus!). Will be fixed in 3.11

     */

#ifdef CONFIG_X86 

    /*

     * If we're the non-boot CPU, nothing set the stack canary up

     * for us. The boot CPU already has it initialized but no harm

     * in doing it again. This is a good place for updating it, as

     * we wont ever return from this function (so the invalid

     * canaries already on the stack wont ever trigger).

     */

    boot_init_stack_canary();
#endif
    arch_cpu_idle_prepare();
    cpuhp_online_idle(state);
    while (1)
        do_idle();
}