udev的rules定制和调试

       udev的rules定制和调试

        在定制项目中，对外设的热插拔的管理基本都在udev/systemd-udev来管理。这里没有对基本的udev使用/rules书写进行介绍。

        1. udev的rules可能的位置

        /lib/udev/rules.d -- udev默认/预置的rules

        /etc/udev/rules.d/ -- 定制的rules， 优先级高于/lib/udev/rules.d，官方建议客户写的rules都放这里

        至于放在哪个位置，自己决定就好，既然你在修改系统就应该知道你在做什么

        2. 定制自己的rules

        定制热插拔的事件，具体到rules就是：

          1）过滤到正确的udev事件。

          2）指定执行的动作，rules里的“RUN”，通常是脚本（毕竟要完成一个功能，绝大多数场景都不是一个命令能搞定的）

        3.到这里就要设计到rules的调试了

          1）如何知道要过滤的是条件？

          2）如何将必要的参数传递给RUN执行的脚本？

        方法1:

        udevadm monitor -p

        -- 监测所以的kernel/udevd的热插拔事件， -p选项很有必要，打印出本次热插拔事件的一些属性

       è¿™é‡Œå°±æ˜¯æ¯”较设备插入和拔出时的事件属性的不同，可作为过滤的条件

        比如：

        rules文件对于规则：

        到这里很多时候就能满足要求了，如果还有解决不里的场景，就要进一步修改过滤条件。

        man udev里会有绝大部分的关键字的信息（想全部的就只能去撸源码）。

       æ–¹æ³•2:

        通过在RUN指定的脚本里传递参数，来找到设备存在和不存在的属性差异。

        比如：

        参考信息：

        a）、udev 规则的匹配键

        ACTION： 　　 　　　　　　事件 (uevent) 的行为，例如：add( 添加设备 )、remove( 删除设备 )。

        KERNEL： 　　 　　　　　　内核设备名称，例如：sda, cdrom。

        DEVPATH：　　　　　　　  设备的 devpath 路径。

        SUBSYSTEM： 　　　　　　 设备的子系统名称，例如：sda 的子系统为 block。

        BUS： 　　　　　　　　　　 设备在 devpath 里的总线名称，例如：usb。

        DRIVER： 　　　　 　　　　 设备在 devpath 里的设备驱动名称，例如：ide-cdrom。

        ID： 　　　　　　　 　　　　设备在 devpath 里的识别号。

        SYSFS{ filename}： 　　　　设备的 devpath 路径下，设备的属性文件“filename”里的内容。

        　　　　　　　　　　　　　　　例如：SYSFS{ model}==“STSS”表示：如果设备的型号为 STSS，则该设备匹配该 匹配键。

        　　　　　　　　　　　　　　　在一条规则中，可以设定最多五条 SYSFS 的 匹配键。

        ENV{ key}： 　　　　　　 　 环境变量。在一条规则中，可以设定最多五条环境变量的 匹配键。

        PROGRAM：　　　　　　　　调用外部命令。

        RESULT： 　　　　　　　　  外部命令 PROGRAM 的返回结果。

        b）、udev 的重要赋值键

        NAME：　　　　　　　　　　　在 /dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效，之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值，udev 将使用内核设备名称来产生设备文件。

        SYMLINK：　　　　　　　　　 为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件，所以为了不覆盖系统默认的 udev 规则所产生的文件，推荐使用符号链接。

        OWNER, GROUP, MODE：　　为设备设定权限。

        ENV{ key}：　　　　　　　　　导入一个环境变量。

        c）、udev 的值和可调用的替换操作符

        Linux 用户可以随意地定制 udev 规则文件的值。例如：my_root_disk, my_printer。同时也可以引用下面的替换操作符：

        $kernel, %k：　　　　　　　　设备的内核设备名称，例如：sda、cdrom。

        $number, %n：　　　　　　　 设备的内核号码，例如：sda3 的内核号码是 3。

        $devpath, %p：　　　　　　　设备的 devpath路径。

        $id, %b：　　　　　　　　　　设备在 devpath里的 ID 号。

        $sysfs{ file}, %s{ file}：　　  设备的 sysfs里 file 的内容。其实就是设备的属性值。

        $env{ key}, %E{ key}：　　　一个环境变量的值。

        $major, %M：　　　　　　　　设备的 major 号。

        $minor %m：　　　　　　　　设备的 minor 号。

        $result, %c：　　　　　　　　PROGRAM 返回的结果。

        $parent, %P：　　　　　　    父设备的设备文件名。

        $root, %r：　　　　　　　　  udev_root的值，默认是 /dev/。

        $tempnode, %N：　　　　　　临时设备名。

        %%：　　　　　　　　　　　　符号 % 本身。

        $$：　　　　　　　　　　　　　符号 $ 本身。

        对比一下和man里的差别，$sysfs{ file}，这个在实际解决问题的时候是很有用的。

        这种方法适合调试系统启动的时候对rules的调试，这个过程中是没得udevadmin monitor使用的。（当然，可以尝试自己写一个systemd启动服务，这就涉及到启动的时机、关联、影响，实际操作会比预想的复杂）

        这里提两个点：

        1. env - 可以是udev事件里的属性（-p打印的）

        2. $sysfs{ file}, 这里的file就是在系统/sys目录下对应的节点下的文件，有些情况下只能在sysfs的file的内存才能准确区分事件。

使用lerna管理monorepo及发npm包实战教程

       在维护多个package项目的同学来说，都会面临一个选择：这些package是放在一个仓库里维护还是放在多个仓库里单独维护。数量较少的时候，多个仓库维护不会有太大问题，但是当package数量逐渐增多时，一些问题逐渐暴露出来。十1001的源码多少

       因此，我们需要找寻一条新的道路来管理我们的项目，一个理想的开发环境可以抽象成这样：“只关心业务代码，可以直接跨业务复用而不关心复用方式，调试时所有代码都在源码中。”

       在前端开发环境中，多 Git Repo，多 npm 则是这个理想的阻力，它们导致复用要关心版本号，调试需要npm link。而这些是电视直播手机版源码Lerna + MonoRepo 最大的优势。

       什么是lerna

       用于管理具有多个包的JavaScript项目的工具。这个介绍可以说很清晰了，引入lerna后，上面提到的问题不仅迎刃而解，更为开发人员提供了一种管理多packages javascript项目的方式。

       什么是monorepo

       Monorepo 的全称是 monolithic repository，即单体式仓库，与之对应的是 Multirepo(multiple repository)，这里的“单”和“多”是指每个仓库中所管理的模块数量。

       Multirepo 是比较传统的做法，即每一个 package 都单独用一个仓库来进行管理。例如：Rollup, ...

       Monorep 是把所有相关的 package 都放在一个仓库里进行管理，每个 package 独立发布。例如：React, Angular, Babel, Jest, Umijs, Vue ...

       了解了基本概念后，详细介绍下使用方法与api。

       常用命令

       我们需要全局安装lerna工具。ios 音乐播放器源码

       为所有项目安装依赖，类似于npm/yarn i

       提交对项目的更新 运行该命令会执行如下的步骤：

       使用lerna 初始化项目

       类似npm init命令

       为packages文件夹下的package安装依赖

       卸载依赖

       比对包是否发生过变更

       显示packages下的各个package的version

       清理node_modules

       lerna run 运行npm script，可以指定具体的package。

       lerna.json解析

       version：当前库的版本

       useWorkspaces: 是否使用workspace来管理依赖 npmClient： 允许指定命令使用的client， 默认是 npm， 可以设置成 yarn command.publish.ignoreChanges：可以指定那些目录或者文件的变更不会被publish command.bootstrap.ignore：指定不受 bootstrap 命令影响的包 command.bootstrap.npmClientArgs：指定默认传给 lerna bootstrap 命令的参数 command.bootstrap.scope：指定那些包会受 lerna bootstrap 命令影响 packages：指定包所在的目录

       使用lerna的基本工作流

       环境配置

       初始化一个lerna工程

       在本地目录下初始化一个lerna工程。 1、创建一个空的文件夹，命名为my-app：

       2、初始化 通过cmd进入相关目录，进行初始化

       3、添加一个测试package 默认情况下，package是放在packages目录下的。但是自己想做一个组件库，改为了components

       4、安装各packages依赖 这一步操作，linux俄罗斯方块源码官网上是这样描述的 在当前的Lerna仓库中引导包。安装所有依赖项并链接任何交叉依赖项。

       5、发布 在发布的时候，就需要git工具的配合了。 所以在发布之前，请确认此时该lerna工程是否已经连接到git的远程仓库。你可以执行下面的命令进行查看。 本篇文章的代码托管在Github上。因此会显示此远程链接信息。 如果你还没有与远程仓库链接，请首先在github创建一个空的仓库，然后根据相关提示信息，进行链接。

       第一次publish前我们需要执行

       在输入用户名及密码之后执行这条命令

       你就可以根据cmd中的提示，一步步的最牛妖股指标源码发布packges了。 实际上在执行该条命令的时候，lerna会做很多的工作。

       到这里为止，就是一个最简单的lerna的工作流了。但是lerna还有更多的功能等待你去发掘。生成的packages如下：

       工作模式

       lerna有两种工作模式,Independent mode和Fixed/Locked mode，在这里介绍可能会对初学者造成困扰，但因为实在太重要了，还是有必要提一下的。 lerna的默认模式是Fixed/Locked mode，在这种模式下，实际上lerna是把工程当作一个整体来对待。每次发布packges，都是全量发布，无论是否修改。但是在Independent mode下，lerna会配合Git，检查文件变动，只发布有改动的packge。

       使用lerna提升开发流程体验

       接下来，我们从一个demo出发，了解基于lerna的开发流程。

       项目初始化

       我们需要维护一个UI组件库，其包含2个组件，分别为House（房子）和Window（窗户）组件，其中House组件依赖于Window组件。

       增加依赖

       接下来，我们来为组件增加些依赖，首先House组件不能只由Window构成，还需要添加一些外部依赖（在这里我们假定为lodash）。我们执行：

       这句话会将lodash增添到House的dependencies属性里 我们还需要将Window添加到House的依赖里，执行：

       自动检测到window隶属于当前项目，直接采用symlink的方式关联过去。 symlink:符号链接，也就是平常所说的建立超链接，此时House的node_modules里的Window直接链接至项目里的Window组件，而不会再重新拉取一份，这个对本地开发是非常有用的。

       发布到npm

       接下来，我们只需要简单地执行lerna publish，确认升级的版本号，就可以批量将所有的package发布到远程。 默认情况下会推送到系统目前npm对应的registry里，实际项目里可以根据配置package.json切换所使用的npm客户端。

       更新模块

       接下来，我们变更了Window组件，执行一下lerna updated，便可以得知有哪些组件发生了变更。

       我们可以看到，虽然我们只变更了window组件，但是lerna能够帮助我们检查到所有依赖于它的组件，对于没有关联的组件，是不会出现在更新列表里的，这个对于相比之前人工维护版本依赖的更新，是非常稳健的。

       集中版本号或独立版本号

       截止目前，我们已经成功发布了2个package，现在再新增一个Tree组件，它和其他2个package保持独立，随后我们执行lerna publish，它会提示Tree组件的版本号将会从0.0.0升级至1.0.0，但是事实上Tree组件仅仅是刚创建的，这点不利于版本号的语义化，lerna已经考虑到了这一点，它包含2种版本号管理机制。

       如果需要各个组件维护自身的版本号，那么就使用independent模式，只需要去配置leran.json即可。

       TIPS:

       yarn workspaces 命令 在根目录安装 npm 包，以 lodash 为例：

       总结

       lerna不负责构建，测试等任务，它提出了一种集中管理package的目录模式，提供了一套自动化管理程序，让开发者不必再深耕到具体的组件里维护内容，在项目根目录就可以全局掌控，基于npm scripts，可以很好地完成组件构建，代码格式化等操作，并在最后一公里，用lerna变更package版本，将其上传至远端。

       lerna最佳实践

       项目地址： GitHub - Mrrabbitan/virtualList 为了能够使lerna发挥最大的作用，根据这段时间使用lerna 的经验，总结出一个最佳实践。下面是计划实现的一些特性。

       工具整合 在这里引入的工具都是为了解决一个问题，就是工程和代码的规范问题。

       Happy Hacking~~~