Apr
23
# Linux下的文件锁
Linux下有两种不同的文件锁机制,一种是通过 `flock` 系统调用锁定整个文件,另一种是通过 `fcntl` 系统调用完成更细粒度的记录锁(锁定文件中的一个区间)
## open 系统调用
Linux下,在最初打开一个文件的时候,最终都是落到 `open` 这个系统调用上。
open系统调用 (@./fs/open.c) 里头做了很多事情,跟文件锁有关的主要是分配了一个 `struct file` 对象,并且给该对象的 `struct inode *inode` 和 `struct file_operations *f_op` 成员赋值。
其中 inode 是对应文件系统分配的(比如 ext4 文件系统的分配函数是 fs/ext4/inode.c 中的 `ext4_iget`),其中也包含了一个 `struct file_operations *` 类型的成员 `i_fop`,即针对该文件系统文件操作的函数指针集合。
以上提到的两次 `struct file_operations` 对象包含 `flock` 和 `lock` 两个函数指针,分别用于上述的两种不同锁机制。
内核在内存中只会给一个文件分配一个 `struct inode` 对象,不同进程打开同一个文件时,都会单独分配一个 `struct file` 对象,且 `file->inode` 指向该文件的 inode 对象。其中 `file->f_op` 实际上就是在 open 系统调用过程中,从 `inode->i_fop` 拷贝过来的。(open -> do_sys_open -> do_filp_open -> path_openat -> do_last -> vfs_open -> do_dentry_open: `f->f_op = fops_get(inode->i_fop)`)
## flock 加锁
内核首先根据第一个参数 fd 找到内核中的 `struct file` 对象,判断 `file->f_op->flock` 指针是否有效,如果有效(说明是文件系统指定了加锁机制,例如 fs/fuse/file.c 中指定了 `fuse_file_flock` 函数,而ext2/3/4都没有指定),就调用该指针指向的函数来执行加锁操作;如果不存在,则执行`flock_lock_file_wait` -> `flock_lock_inode` (@ fs/locks.c)。
如果文件系统没有指定加锁机制,那么 `flock_lock_inode` 会尝试给该文件对应的 inode 加文件锁(加锁机制比较琐碎,我没看得太细,大致是获取 `inode->i_flctx->flc_lock` 这个spinlock,然后增删改查 `inode->i_flctx->flc_flock` 这个链表,但是可以看出全是内存操作)。
如果文件系统指定了加锁机制,那么就要具体考察对应的加锁机制是否是持久化在磁盘上了;不过从加锁这个需求本身去考察,大多数情况下应当是期望能够快速完成,除了特殊情况,可以认为只是在内存中操作,并没有持久化到磁盘。
## fcntl 加锁
与 `flock` 类似,区别在于判断的函数指针是 `file->f_op->lock` ,如果不存在的话,则调用 `posix_lock_file` 尝试对该 inode 加记录锁,也是在 `inode->i_flctx` 上面倒腾,不过用的是 `inode->i_flctx->flc_lock` 这个链表,具体操作更复杂一些,还要考虑记录锁区间的交叉等问题。
## 结论
具体情况取决于文件系统是否使用了指定的加锁机制,如果有,要单独分析。
如果没有,所有的锁都是在内存中维护的,如果断电,锁自动失效。这样也比较符合通常的理解。
另外,针对文件的加锁行为一般都是进程执行的,进程退出(包括意外退出)时,exit 系统调用会调用 `exit_files` 函数清理该进程打开的所有文件。
Linux下有两种不同的文件锁机制,一种是通过 `flock` 系统调用锁定整个文件,另一种是通过 `fcntl` 系统调用完成更细粒度的记录锁(锁定文件中的一个区间)
## open 系统调用
Linux下,在最初打开一个文件的时候,最终都是落到 `open` 这个系统调用上。
open系统调用 (@./fs/open.c) 里头做了很多事情,跟文件锁有关的主要是分配了一个 `struct file` 对象,并且给该对象的 `struct inode *inode` 和 `struct file_operations *f_op` 成员赋值。
其中 inode 是对应文件系统分配的(比如 ext4 文件系统的分配函数是 fs/ext4/inode.c 中的 `ext4_iget`),其中也包含了一个 `struct file_operations *` 类型的成员 `i_fop`,即针对该文件系统文件操作的函数指针集合。
以上提到的两次 `struct file_operations` 对象包含 `flock` 和 `lock` 两个函数指针,分别用于上述的两种不同锁机制。
内核在内存中只会给一个文件分配一个 `struct inode` 对象,不同进程打开同一个文件时,都会单独分配一个 `struct file` 对象,且 `file->inode` 指向该文件的 inode 对象。其中 `file->f_op` 实际上就是在 open 系统调用过程中,从 `inode->i_fop` 拷贝过来的。(open -> do_sys_open -> do_filp_open -> path_openat -> do_last -> vfs_open -> do_dentry_open: `f->f_op = fops_get(inode->i_fop)`)
## flock 加锁
内核首先根据第一个参数 fd 找到内核中的 `struct file` 对象,判断 `file->f_op->flock` 指针是否有效,如果有效(说明是文件系统指定了加锁机制,例如 fs/fuse/file.c 中指定了 `fuse_file_flock` 函数,而ext2/3/4都没有指定),就调用该指针指向的函数来执行加锁操作;如果不存在,则执行`flock_lock_file_wait` -> `flock_lock_inode` (@ fs/locks.c)。
如果文件系统没有指定加锁机制,那么 `flock_lock_inode` 会尝试给该文件对应的 inode 加文件锁(加锁机制比较琐碎,我没看得太细,大致是获取 `inode->i_flctx->flc_lock` 这个spinlock,然后增删改查 `inode->i_flctx->flc_flock` 这个链表,但是可以看出全是内存操作)。
如果文件系统指定了加锁机制,那么就要具体考察对应的加锁机制是否是持久化在磁盘上了;不过从加锁这个需求本身去考察,大多数情况下应当是期望能够快速完成,除了特殊情况,可以认为只是在内存中操作,并没有持久化到磁盘。
## fcntl 加锁
与 `flock` 类似,区别在于判断的函数指针是 `file->f_op->lock` ,如果不存在的话,则调用 `posix_lock_file` 尝试对该 inode 加记录锁,也是在 `inode->i_flctx` 上面倒腾,不过用的是 `inode->i_flctx->flc_lock` 这个链表,具体操作更复杂一些,还要考虑记录锁区间的交叉等问题。
## 结论
具体情况取决于文件系统是否使用了指定的加锁机制,如果有,要单独分析。
如果没有,所有的锁都是在内存中维护的,如果断电,锁自动失效。这样也比较符合通常的理解。
另外,针对文件的加锁行为一般都是进程执行的,进程退出(包括意外退出)时,exit 系统调用会调用 `exit_files` 函数清理该进程打开的所有文件。
Mar
11
Let's Encrypt项目进入Public Beta已经好久拉,不过因为使用dnspod作为域名的解析服务提供商,该项目官方刚开始的时候并不被支持(总是报错),所以拖了好久,今天才终于搞起来。
用起来还真是超简单:
1. 获取证书
$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto certonly -w /path/to/www-root felix021.com www.felix021.com
没有什么意外的话,获取到的证书就存在 /etc/letsencrypt/live/felix021.com/ 下面
2. 配置nginx
最简单的就是加上三行:
但是比较推荐的做法是增加一个80端口redirect到https的配置:
然后执行 service nginx reload ,就生效了。
p.s. 对于我使用的bo-blog博客系统,还有一个坑,就是需要在blog设置里面将URL路径的http换成https,否则使用相对路径引用的css等静态文件资源还是会引用到http去(这是多么奇葩的一个特性啊...)
3. 定期更新
该项目提供的整数有效期只有90天,似乎短了点,但是实际上因为提供了命令行自动更新的方式,并不会造成多大困然,反而可以缩短因为证书泄漏而导致的风险期(貌似也提供了revoke功能,不过我没尝试)。因此官方宣称证书的有效期未来可能会进一步缩短。
想要renew证书,最直接的方式就是前面的certonly命令带上完整参数再跑一次。官方还提供了一个更简单的"letsencrypt renew"命令,会读取上次的配置来重新获取证书。
基于此可以写一个简单的renew脚本,放到root的crontab里,每个月跑一次就好拉。记得renew完要service nginx reload就好啦。
用起来还真是超简单:
1. 获取证书
$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto certonly -w /path/to/www-root felix021.com www.felix021.com
没有什么意外的话,获取到的证书就存在 /etc/letsencrypt/live/felix021.com/ 下面
2. 配置nginx
最简单的就是加上三行:
引用
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/felix021.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/felix021.com/privkey.pem;
ssl_certificate /etc/letsencrypt/live/felix021.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/felix021.com/privkey.pem;
但是比较推荐的做法是增加一个80端口redirect到https的配置:
引用
server {
listen 80;
server_name felix021.com www.felix021.com;
return 301 https://www.felix021.com$request_uri;
}
listen 80;
server_name felix021.com www.felix021.com;
return 301 https://www.felix021.com$request_uri;
}
然后执行 service nginx reload ,就生效了。
p.s. 对于我使用的bo-blog博客系统,还有一个坑,就是需要在blog设置里面将URL路径的http换成https,否则使用相对路径引用的css等静态文件资源还是会引用到http去(这是多么奇葩的一个特性啊...)
3. 定期更新
该项目提供的整数有效期只有90天,似乎短了点,但是实际上因为提供了命令行自动更新的方式,并不会造成多大困然,反而可以缩短因为证书泄漏而导致的风险期(貌似也提供了revoke功能,不过我没尝试)。因此官方宣称证书的有效期未来可能会进一步缩短。
想要renew证书,最直接的方式就是前面的certonly命令带上完整参数再跑一次。官方还提供了一个更简单的"letsencrypt renew"命令,会读取上次的配置来重新获取证书。
基于此可以写一个简单的renew脚本,放到root的crontab里,每个月跑一次就好拉。记得renew完要service nginx reload就好啦。
Dec
25
== 卸载OneDrive ==
C:\windows\syswow64\onedrivesetup.exe /uninstall
== 卸载 Cortana ==
== 禁用Win+S ==
== 从“此电脑”删除垃圾链接(图片、视频等) ==
== 禁用锁屏界面 ==
组策略-》计算机配置-》管理模版-》控制面板-》个性化-》不显示锁屏
p.s. 周年更新以后这个方法失效了,得这么用:
本地安全策略 -> 软件限制策略 -> 新建路径规则, 路径填写“C:\Windows\SystemApps\Microsoft.LockApp_cw5n1h2txyewy”,安全级别“不允许”
== 禁止自动更新 ==
不让我设置禁止自动重启,那只好禁止自动更新了。
services.msc -> windows update -> 禁止
== windows图片查看器 ==
== 图片查看器背景色发黄 ==
显示设置->高级显示设置->显示适配器属性->颜色管理
设备:选择显示器,勾上“使用我对此设备的设置”,“添加(A)...",选择 “sRGB IEC61966-2.1”,"设置为默认配置"
== 垃圾APP ==
有些右键就卸载掉了(但实际上文件还在),这样删比较干净点。
打开Powershell执行:
Get-AppxPackage -name Microsoft.ZuneMusic | remove-appxpackage
Get-AppxPackage -name Microsoft.XboxApp | remove-appxpackage
Get-AppxPackage -name Microsoft.WindowsMaps | remove-appxpackage
Get-AppxPackage -name Microsoft.BingWeather | remove-appxpackage
Get-AppxPackage -name Microsoft.ZuneVideo | remove-appxpackage
Get-AppxPackage -name Microsoft.BingSports | remove-appxpackage
Get-AppxPackage -name Microsoft.3DBuilder | remove-appxpackage
p.s. 打包下载
C:\windows\syswow64\onedrivesetup.exe /uninstall
下载文件 (已下载 1106 次)
== 卸载 Cortana ==
下载文件 (已下载 1198 次)
== 禁用Win+S ==
下载文件 (已下载 1155 次)
== 从“此电脑”删除垃圾链接(图片、视频等) ==
下载文件 (已下载 1109 次)
== 禁用锁屏界面 ==
组策略-》计算机配置-》管理模版-》控制面板-》个性化-》不显示锁屏
p.s. 周年更新以后这个方法失效了,得这么用:
本地安全策略 -> 软件限制策略 -> 新建路径规则, 路径填写“C:\Windows\SystemApps\Microsoft.LockApp_cw5n1h2txyewy”,安全级别“不允许”
== 禁止自动更新 ==
不让我设置禁止自动重启,那只好禁止自动更新了。
services.msc -> windows update -> 禁止
== windows图片查看器 ==
下载文件 (已下载 1136 次)
== 图片查看器背景色发黄 ==
显示设置->高级显示设置->显示适配器属性->颜色管理
设备:选择显示器,勾上“使用我对此设备的设置”,“添加(A)...",选择 “sRGB IEC61966-2.1”,"设置为默认配置"
== 垃圾APP ==
有些右键就卸载掉了(但实际上文件还在),这样删比较干净点。
打开Powershell执行:
Get-AppxPackage -name Microsoft.ZuneMusic | remove-appxpackage
Get-AppxPackage -name Microsoft.XboxApp | remove-appxpackage
Get-AppxPackage -name Microsoft.WindowsMaps | remove-appxpackage
Get-AppxPackage -name Microsoft.BingWeather | remove-appxpackage
Get-AppxPackage -name Microsoft.ZuneVideo | remove-appxpackage
Get-AppxPackage -name Microsoft.BingSports | remove-appxpackage
Get-AppxPackage -name Microsoft.3DBuilder | remove-appxpackage
p.s. 打包下载
下载文件 (已下载 1065 次)
Dec
17
好早以前看到过这个项目,不过当时没有测试成功,昨天晚上看了一下,有点眉目了,先记录一点东西。
1. 项目主页:http://usbip.sourceforge.net/ ,但是这里实际上已经没有再维护了,内核模块已经merge到linux kernel(drivers/usb/usbip)。这里有提供经过ReactOS(这个神奇的项目)签名的windows驱动程序(windows下只有client,没有server),但是不知道四年过去了还能不能用……
2. ubuntu默认安装没有相关模块,需要安装 linux-image-extras ,然后 cd /lib/modules/[KERNEL_VER]/kernel/drivers/usb/usbip && sudo insmod *.ko
3. ubuntu源里的usbip包已经是很老的版本,无法利用新的内核模块,会提示“usbipd requires usbip_common_mod.ko and usbip.ko kernel modules”,实际上userspace tool也已经挪到kernel source里了,位于 linux-source/tools/usb/usbip,编译方法可参考该目录下的README文件,类似于:
但是我是直接下载的kernel source,没有安装在系统目录,所以在编译的时候会提示 libsrc/usbip_common.h 找不到 linux/usbip.h ,解决方法很简单,把那一行改为 #include "usbip.h" ,然后把 linux-source/include/uapi/linux/usbip.h 复制到 libsrc 目录,再编译就行了(对,就是这么粗暴简单)。
4. update@2015-12-25:在linux下测试成功。windows的driver废弃太久,已经不能支持新版代码的协议了。
p.s. 还有一个收费的商业项目 usb-over-ethernet ,有free trial版本,但是没尝试过。
p.s. 2. 还有一个开源的项目SPICE,有一个 usbredir 模块 http://www.spice-space.org/page/UsbRedir ,不过好像还不完善。
1. 项目主页:http://usbip.sourceforge.net/ ,但是这里实际上已经没有再维护了,内核模块已经merge到linux kernel(drivers/usb/usbip)。这里有提供经过ReactOS(这个神奇的项目)签名的windows驱动程序(windows下只有client,没有server),但是不知道四年过去了还能不能用……
2. ubuntu默认安装没有相关模块,需要安装 linux-image-extras ,然后 cd /lib/modules/[KERNEL_VER]/kernel/drivers/usb/usbip && sudo insmod *.ko
3. ubuntu源里的usbip包已经是很老的版本,无法利用新的内核模块,会提示“usbipd requires usbip_common_mod.ko and usbip.ko kernel modules”,实际上userspace tool也已经挪到kernel source里了,位于 linux-source/tools/usb/usbip,编译方法可参考该目录下的README文件,类似于:
引用
./autogen.sh
./configure --with-usbids-dir=/usr/share/misc/
sudo make install
./configure --with-usbids-dir=/usr/share/misc/
sudo make install
但是我是直接下载的kernel source,没有安装在系统目录,所以在编译的时候会提示 libsrc/usbip_common.h 找不到 linux/usbip.h ,解决方法很简单,把那一行改为 #include "usbip.h" ,然后把 linux-source/include/uapi/linux/usbip.h 复制到 libsrc 目录,再编译就行了(对,就是这么粗暴简单)。
4. update@2015-12-25:在linux下测试成功。windows的driver废弃太久,已经不能支持新版代码的协议了。
p.s. 还有一个收费的商业项目 usb-over-ethernet ,有free trial版本,但是没尝试过。
p.s. 2. 还有一个开源的项目SPICE,有一个 usbredir 模块 http://www.spice-space.org/page/UsbRedir ,不过好像还不完善。
Dec
6
友情提示:本文不一定适合阅读,如果执意要读,请备好晕车药。
== 题记 ==
"Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don't."
-- Tim Peters
== 起因 ==
这句话听起来就很诱人,曾经试图去理解它,但是因为没有实际的需求,就因为烧脑子而放弃了。不妨摘录一段Python document里关于metaclass的概述,简直就是绕口令:
昨天心血来潮想写一个带class initializer的class,发现绕不过metaclass了,于是又翻出来看。
== 概述 ==
其实是要理解metaclass的本质,无非是要时刻牢记两点:1. Python中一切皆对象; 2. class也是一个对象,它的class就是metaclass。
举例来说:
其中第一个print很好理解:a是一个A的实例,有自己的id(其实就是内存地址)、a的class是A。
第二个print就有点烧脑子了:A是一个class,也有自己的id(因为A也是一个对象,虽然print出来的时候没有明确说),A的class是type。
而第三个就晕乎了:type是一个type,也有自己的id(因为type也是一个对象),type的class是type,也就是它自己。
再回想上面提到的两点:A是一个对象,它的class是metaclass。也就是说 type 是一个metaclass,而A类是type类的一个对象。
唉,本来想好好解释的,没想到还是说成绕口令了。算了,反正我懂了,继续。
== type ==
没有仔细了解type是什么的同学可能会以为type是一个函数:type(X)用于返回X的类对象。
然而并不完全是这样的:在python里,X(args)可能是调用一个函数,也可能是在实例化一个X的对象——而很不幸地,type(X)实际上是介于二者之间的一个调用:虽然type是一个class,但是它的__call__方法是存在的,于是python把它当成一个函数来调用,实际调用到了源码中的type_call;type_call调用了type.__new__试图初始化一个type类的实例,然而type.__new__(位于源码中的type_new函数)发现卧槽居然只有一个参数,于是就返回了这个参数的type(源码是这么写的:"return (PyObject *) Py_TYPE(x);",并没有生成新的对象)。也就是说,本来是个函数调用,里面却是要初始化一个对象,然而最后返回的却不是初始化的对象!尼玛那个特殊情况为毛不放到函数调用里面啊,开发者脑抽了吗!
感到脑抽的同学可以暂时忽略上面那段话,跟本文没太大关系。继续。
实际上type是在builtin模块中定义,指向源码中PyType_Type对象的一个引用:
这个PyType_Type又是个什么鬼?好吧,继续贴源码
注意2点:
0. PyType_Type,也就是python里的type,是在源码中生成的一个对象;这个对象的类型是PyTypeObject,所以它恰好又是一个类,至于你信不信,反正我信了。后面我把它叫做类对象,注意:不是类的对象,而是类本身是一个对象。
1. PyVarObject_HEAD_INIT递归引用了自己(PyType_Type)作为它的type(在源码中,指定某个对象的type为X,就是指定了它在python环境中的class为X),所以前面第三个print中可以看到,type(type) == type(哈哈哈,写绕口令真好玩)
2. 在PyType_Type的定义指定了 tp_init = type_init 和 tp_new = type_new 这两个属性值。这是两个函数,也位于源码中的Object/typeobject.c。
关于第2点,在Python document中关于__new__方法的说明里有详细的介绍,这里简单总结一下:在new一个对象的时候,只会调用这个class的__new__方法,它需要生成一个对象、调用这个对象的__init__方法对它进行初始化,然后返回这个对象。
好吧,我发现不得不把简单总结展开,否则确实说不清楚。
== 实例化 ==
这是一个很有意思的设计:把实例化的流程暴露给码农,意味着码农可以在对象的生成前、生成后返回前两个环节对这个对象进行修改(【甚至】在__new__方法中生成并返回的对象并没有强制要求一定是该class的实例!不过在document里建议,如果要覆盖__new__方法,那么【应当】返回这个class的父类的__new__方法返回的对象)。这里还有一个非常tricky的地方:虽然没有明确指定,但是__new__方法被硬编码为一个staticmethod(有兴趣的话可以去翻type_new函数),它的第一个参数是需要被实例化的class,其余参数则是需要传给__init__的参数。
说起来非常枯燥,还是举一个例子吧,就用document里给出的Singleton:
代码并不复杂,但是可能有点玄乎,需要理解一下那个cls参数,前面说了,它是需要被实例化的class,也就是说,最后一行实际执行的是:
而DbConnection的__new__方法直接继承于Singleton, 所以实际调用的是
主要注意的地方,在上面这段代码的第六行,Singleton是继承于object(这里特指python中的那个object对象),因此调用了object.__new__(DbConnection)来生成一个对象,生成过程位于C源码中的object_new函数(Objects/typeobject.c),它会将新生成对象的type指定为DbConnection,然后直接返回。
Singleton.__new__在拿到了生成的DbConnection实例以后,将它保存在了DbConnection类的__it__属性中,然后对该实例进行初始化,最后返回。
可以看到,任何继承于Singleton类的子类,只要不覆盖其__new__方法,每个类永远只会被实例化一次。
好了,第2点暂告一段落,接下来回归正题,尼玛我都快忘了要讲的是metaclass啊。
== metaclass ==
还记的上面可以暂时忽略的那段话吗?type(X)是试图实例化type对象,但是因为只有一个参数,所以源码中只是返回了X的类。而type的标准初始化参数应当有三个:class_name, bases, attributes。最前面那个"class A(object): pass",python解释器实际的流程是:
1. 解析这段代码,得知它需要创建一个【类对象】,这个类的名字叫做'A', 它的父类列表(用tuple表示)是 (object,),它的属性用一个dict来表示就是 {} 。
2. 查找用于生成这个类的metaclass。(终于讲到重点了有木有!)
查找过程比较蛋疼,位于Python/ceval.c : build_class函数,按顺序优先采用以下几个:
2.1 定义中使用 __metaclass__ 属性指定的(本例:没有)
2.2 如果有父类,使用第一个父类的 __class__ 属性,也就是父类的metaclass(本例:object的class,也就是type)
2.2.1 如果第一个父类没有 __class__ 属性,那就用父类的type(这是针对父类没有父类的情况)
2.3 使用当前Globals()中的 __metaclass__ 指定的(本例:没有,不过2.2里已经找到了)
2.4 使用PyClass_Type
注:2.2.1和2.4中提到了没有父类,或者父类没有父类的情形,这就是python中的old-style class,在python2.2之前所有的对象都是这样的,而2.2之后可以继承于object类,就变成了new-style class。这种设计保持了向后兼容。
3. 使用metaclass来创建这个A类。由于A类的class就是metaclass,所以这个过程其实就是实例化metaclass的过程。本例中找到的metaclass是type,所以最终python执行的相当于这一句:
再回想一下前面提到的实例化过程,实际上这一句分成两步: 1. 调用type.__new__(type, 'A', (object,), {})生成type的一个实例(也就是A类对象);2. 调用type.__init__(A, 'A', (object,), {}) 对A类对象进行初始化。注意:这里调用的是type.__init__,而不是A.__init__:因为A是type的一个实例。
流程终于解释完啦,不过我觉得还是举个栗子会比较好。就用我看到的那个有点二二的栗子吧:定义一个class,把它的所有属性都改成全大写的。我感觉这个栗子唯一的作用就是用来当栗子了。还好还有这个作用,否则连出生的机会都没有。
== 栗子 ==
直接上代码好了:
请不要说“说好的metaclass呢!怎么变成了一个函数!我摔!”,回顾一下最最前面提到的一点:everything is an object in python。upper_meta作为一个函数,它也是一个对象啊。而metaclass也不过就是个对象,并没有本质上的差别——只要它被call的时候能接受name, bases, attrs这三个参数并返回一个类对象就行了。duck-typing的语言用起来就是有这样的一种不可言状的酸爽感。
理解了这一点,这段代码就能理解了,upper_meta返回了一个type类的实例——也就是Foo类,并且可以看到print出来的属性里头只有HELLO而没有hello。
考虑到可能有人不满意,想看使用class来作为metaclass的情形,我就勉为其难换个姿势再举一下这个栗子(真累)。
写的太长了,换了一个短一点的oneliner,但是效果不变(其实我就是想炫一下,不服来咬我呀)。
这段代码虽然形式上跟前面的upper_meta函数不一样,但是本质是一样的:调用了upper_meta('Foo', (object,), {'hello': 'world'}),生成了一个新的名为Foo的类对象。
理论上,故事讲到这里应该结束了,然而我想说,压轴戏还没上呢。
== 压轴戏 ==
我要把这栗子举得更高更远,也更符合实际开发的需求:继承。
这段代码太简单了,但是埋在下面的逻辑却太复杂了。
它的输出并不是{'HI': 'there'}, 而是{'hi': 'there'}。你print Bar.HELLO, Bar.__metaclass__都能得到预期的输出,但是偏偏没有HI,只有hi。
为什么?这真是个烧脑细胞的事情。我已经把所有的逻辑都展现出来了,甚至还做了特别的标记。然而即便如此,想要把这个逻辑理顺,也是一件非常有挑战性的事情,幸好我已经想明白了:苦海无涯,回头是岸。啊呸,应该是——学海无涯苦作舟,不想明白不回头。
我想说“甚至还做了特别标记”这句话的意思是,我还给【甚至】这两个字做了特别标记:在__new__方法中生成并返回的对象并没有强制要求一定是该class的实例!
问题的关键就在这里:前面两个栗子中给出的upper_meta,返回的并不是upper_meta的实例,而是type的实例,而是type的实例,而是type的实例。重说三。
什么意思?再看看代码,最后return的是type(name, bases, attrs),也就是说,Foo类对象并不是upper_meta的实例,而是type的实例(也就是说:虽然指定并被使用的metaclass是upper_meta,但是最终创建出来的Foo类的metaclass是type)。不信你print type(Foo)试试,结果就是type,而不是upper_meta。
为什么这会导致继承于Foo类的Bar类不能由upper_meta来搭建?Bar.__metaclass__不还是upper_meta吗?
这个问题就没有那么困难了,有兴趣的同学可以自己试着分析一下,没兴趣的大概也不会有耐心看到这里吧。
Bar.__metaclass__并不是Bar的原生属性,而是继承于Foo的——所以在print Bar.__dict__的时候看不到__metaclass__。也就是说,在试图创建Bar时,attrs里并没有__metaclass__属性,所以并不会直接采用upper_meta。再回顾一下选择metaclass的顺序就可以发现,实际上在2.2里会选择Foo的metaclass——Foo的metaclass是type,而不是指定的upper_meta。
解决方法很简单:关键就是前面被特别标记了的【应当】返回这个class的父类的__new__方法返回的对象。具体到代码应当是这样:
新增的__init__方法并不是必须的,有兴趣的同学可以跟上面的栗子对比一下,由于前面返回的是type类的实例,调用到的是type.__init__;而这样正确的写法就会调用到upper_meta.__init__。(p.s. super也是烧脑细胞的东西,但用于解决钻石继承的问很有意思,有兴趣的同学可以看看Cooperative methods and "super")
果然很烧脑细胞吧。
关于metaclass的选择,还有另外一个坑:在metaclass 2.3提到了,找不到metaclass的情况下,会使用Globals()中定义的__metaclass__属性指定的元类来创建类,那么为什么下面的代码却没有生效呢?
== class initializer ==
回到我最初的需求:我需要创建带class initializer的类。为什么会有这样的需求?最常见的metaclass的应用场景是对数据库的封装。举例来说,我希望创建一个Table类,所有表都是继承于这个类,同时我还想给每一个表都设置一个缓存dict(使用主键作为key缓存查询结果)。一个很自然的想法是这样的:
可惜这是错的。从输出结果就能看出来,返回的是一个Grade对象,而不是预期的Student对象。原因很简单:子类们并不直接拥有_pk_cache ,它们访问的是Table的_pk_cache ,而该dict只被初始化了一次。
当然,我可以在每一个继承于Table的class里新增一句 _pk_cache = {},但是这样的实现太丑了,而且一不注意就会漏掉导致出错。
所以我需要一个class initializer,在class被创建的时候,给它新增一个_pk_cache 。
在搞清楚了metaclass之后,解决方法特别简单:
完。(终于完结了,我写了一整个下午啊...)
== 题记 ==
"Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don't."
-- Tim Peters
== 起因 ==
这句话听起来就很诱人,曾经试图去理解它,但是因为没有实际的需求,就因为烧脑子而放弃了。不妨摘录一段Python document里关于metaclass的概述,简直就是绕口令:
引用
Terminology-wise, a metaclass is simply "the class of a class". Any class whose instances are themselves classes, is a metaclass. When we talk about an instance that's not a class, the instance's metaclass is the class of its class: by definition, x's metaclass is x.__class__.__class__. But when we talk about a class C, we often refer to its metaclass when we mean C.__class__ (not C.__class__.__class__, which would be a meta-metaclass; there's not much use for those although we don't rule them out).
昨天心血来潮想写一个带class initializer的class,发现绕不过metaclass了,于是又翻出来看。
== 概述 ==
其实是要理解metaclass的本质,无非是要时刻牢记两点:1. Python中一切皆对象; 2. class也是一个对象,它的class就是metaclass。
举例来说:
>>> class A(object): pass
...
>>> a = A()
>>> print (a, id(a), type(a))
(<__main__.A object at 0xb183d0>, 11633616, <class '__main__.A'>)
>>> print (A, id(A), type(A))
(<class '__main__.A'>, 11991040, <type 'type'>)
>>> print (type, id(type), type(type))
(<type 'type'>, 1891232, <type 'type'>)
...
>>> a = A()
>>> print (a, id(a), type(a))
(<__main__.A object at 0xb183d0>, 11633616, <class '__main__.A'>)
>>> print (A, id(A), type(A))
(<class '__main__.A'>, 11991040, <type 'type'>)
>>> print (type, id(type), type(type))
(<type 'type'>, 1891232, <type 'type'>)
其中第一个print很好理解:a是一个A的实例,有自己的id(其实就是内存地址)、a的class是A。
第二个print就有点烧脑子了:A是一个class,也有自己的id(因为A也是一个对象,虽然print出来的时候没有明确说),A的class是type。
而第三个就晕乎了:type是一个type,也有自己的id(因为type也是一个对象),type的class是type,也就是它自己。
再回想上面提到的两点:A是一个对象,它的class是metaclass。也就是说 type 是一个metaclass,而A类是type类的一个对象。
唉,本来想好好解释的,没想到还是说成绕口令了。算了,反正我懂了,继续。
== type ==
没有仔细了解type是什么的同学可能会以为type是一个函数:type(X)用于返回X的类对象。
然而并不完全是这样的:在python里,X(args)可能是调用一个函数,也可能是在实例化一个X的对象——而很不幸地,type(X)实际上是介于二者之间的一个调用:虽然type是一个class,但是它的__call__方法是存在的,于是python把它当成一个函数来调用,实际调用到了源码中的type_call;type_call调用了type.__new__试图初始化一个type类的实例,然而type.__new__(位于源码中的type_new函数)发现卧槽居然只有一个参数,于是就返回了这个参数的type(源码是这么写的:"return (PyObject *) Py_TYPE(x);",并没有生成新的对象)。也就是说,本来是个函数调用,里面却是要初始化一个对象,然而最后返回的却不是初始化的对象!尼玛那个特殊情况为毛不放到函数调用里面啊,开发者脑抽了吗!
感到脑抽的同学可以暂时忽略上面那段话,跟本文没太大关系。继续。
实际上type是在builtin模块中定义,指向源码中PyType_Type对象的一个引用:
//位于Python/bltinmodule.c
PyObject * _PyBuiltin_Init(void)
{
...
SETBUILTIN("type", &PyType_Type);
...
}
PyObject * _PyBuiltin_Init(void)
{
...
SETBUILTIN("type", &PyType_Type);
...
}
这个PyType_Type又是个什么鬼?好吧,继续贴源码
//位于Objects/typeobject.c
PyTypeObject PyType_Type = {
PyVarObject_HEAD_INIT(&PyType_Type, 0)
"type", /* tp_name */
...
type_init, /* tp_init */
0, /* tp_alloc */
type_new, /* tp_new */
...
};
PyTypeObject PyType_Type = {
PyVarObject_HEAD_INIT(&PyType_Type, 0)
"type", /* tp_name */
...
type_init, /* tp_init */
0, /* tp_alloc */
type_new, /* tp_new */
...
};
注意2点:
0. PyType_Type,也就是python里的type,是在源码中生成的一个对象;这个对象的类型是PyTypeObject,所以它恰好又是一个类,至于你信不信,反正我信了。后面我把它叫做类对象,注意:不是类的对象,而是类本身是一个对象。
1. PyVarObject_HEAD_INIT递归引用了自己(PyType_Type)作为它的type(在源码中,指定某个对象的type为X,就是指定了它在python环境中的class为X),所以前面第三个print中可以看到,type(type) == type(哈哈哈,写绕口令真好玩)
2. 在PyType_Type的定义指定了 tp_init = type_init 和 tp_new = type_new 这两个属性值。这是两个函数,也位于源码中的Object/typeobject.c。
关于第2点,在Python document中关于__new__方法的说明里有详细的介绍,这里简单总结一下:在new一个对象的时候,只会调用这个class的__new__方法,它需要生成一个对象、调用这个对象的__init__方法对它进行初始化,然后返回这个对象。
好吧,我发现不得不把简单总结展开,否则确实说不清楚。
== 实例化 ==
这是一个很有意思的设计:把实例化的流程暴露给码农,意味着码农可以在对象的生成前、生成后返回前两个环节对这个对象进行修改(【甚至】在__new__方法中生成并返回的对象并没有强制要求一定是该class的实例!不过在document里建议,如果要覆盖__new__方法,那么【应当】返回这个class的父类的__new__方法返回的对象)。这里还有一个非常tricky的地方:虽然没有明确指定,但是__new__方法被硬编码为一个staticmethod(有兴趣的话可以去翻type_new函数),它的第一个参数是需要被实例化的class,其余参数则是需要传给__init__的参数。
说起来非常枯燥,还是举一个例子吧,就用document里给出的Singleton:
class Singleton(object):
def __new__(cls, *args, **kwargs):
it = cls.__dict__.get("__it__")
if it is not None:
return it
cls.__it__ = it = object.__new__(cls) #注意
it.__init__(*args, **kwargs)
return it
def __init__(self, *args, **kwargs):
pass
class DbConnection(Singleton):
def __init__(self, db_config):
self._connection = AnyHowToConnectBy(db_config)
conn = new DbConnection(db_config)
def __new__(cls, *args, **kwargs):
it = cls.__dict__.get("__it__")
if it is not None:
return it
cls.__it__ = it = object.__new__(cls) #注意
it.__init__(*args, **kwargs)
return it
def __init__(self, *args, **kwargs):
pass
class DbConnection(Singleton):
def __init__(self, db_config):
self._connection = AnyHowToConnectBy(db_config)
conn = new DbConnection(db_config)
代码并不复杂,但是可能有点玄乎,需要理解一下那个cls参数,前面说了,它是需要被实例化的class,也就是说,最后一行实际执行的是:
DbConnection.__new__(DbConnection, db_config)
而DbConnection的__new__方法直接继承于Singleton, 所以实际调用的是
Singleton.__new__(DbConnection, db_config)
主要注意的地方,在上面这段代码的第六行,Singleton是继承于object(这里特指python中的那个object对象),因此调用了object.__new__(DbConnection)来生成一个对象,生成过程位于C源码中的object_new函数(Objects/typeobject.c),它会将新生成对象的type指定为DbConnection,然后直接返回。
Singleton.__new__在拿到了生成的DbConnection实例以后,将它保存在了DbConnection类的__it__属性中,然后对该实例进行初始化,最后返回。
可以看到,任何继承于Singleton类的子类,只要不覆盖其__new__方法,每个类永远只会被实例化一次。
好了,第2点暂告一段落,接下来回归正题,尼玛我都快忘了要讲的是metaclass啊。
== metaclass ==
还记的上面可以暂时忽略的那段话吗?type(X)是试图实例化type对象,但是因为只有一个参数,所以源码中只是返回了X的类。而type的标准初始化参数应当有三个:class_name, bases, attributes。最前面那个"class A(object): pass",python解释器实际的流程是:
1. 解析这段代码,得知它需要创建一个【类对象】,这个类的名字叫做'A', 它的父类列表(用tuple表示)是 (object,),它的属性用一个dict来表示就是 {} 。
2. 查找用于生成这个类的metaclass。(终于讲到重点了有木有!)
查找过程比较蛋疼,位于Python/ceval.c : build_class函数,按顺序优先采用以下几个:
2.1 定义中使用 __metaclass__ 属性指定的(本例:没有)
2.2 如果有父类,使用第一个父类的 __class__ 属性,也就是父类的metaclass(本例:object的class,也就是type)
2.2.1 如果第一个父类没有 __class__ 属性,那就用父类的type(这是针对父类没有父类的情况)
2.3 使用当前Globals()中的 __metaclass__ 指定的(本例:没有,不过2.2里已经找到了)
2.4 使用PyClass_Type
注:2.2.1和2.4中提到了没有父类,或者父类没有父类的情形,这就是python中的old-style class,在python2.2之前所有的对象都是这样的,而2.2之后可以继承于object类,就变成了new-style class。这种设计保持了向后兼容。
3. 使用metaclass来创建这个A类。由于A类的class就是metaclass,所以这个过程其实就是实例化metaclass的过程。本例中找到的metaclass是type,所以最终python执行的相当于这一句:
type('A', (object,), {})
再回想一下前面提到的实例化过程,实际上这一句分成两步: 1. 调用type.__new__(type, 'A', (object,), {})生成type的一个实例(也就是A类对象);2. 调用type.__init__(A, 'A', (object,), {}) 对A类对象进行初始化。注意:这里调用的是type.__init__,而不是A.__init__:因为A是type的一个实例。
流程终于解释完啦,不过我觉得还是举个栗子会比较好。就用我看到的那个有点二二的栗子吧:定义一个class,把它的所有属性都改成全大写的。我感觉这个栗子唯一的作用就是用来当栗子了。还好还有这个作用,否则连出生的机会都没有。
== 栗子 ==
直接上代码好了:
def upper_meta(name, bases, attrs):
new_attrs = {}
for name, value in attrs.items():
if not name.startswith('__'):
new_attrs[name.upper()] = value
else:
new_attrs[name] = value
return type(name, bases, new_attrs)
class Foo(object):
__metaclass__ = upper_meta
hello = 'world'
print Foo.__dict__
new_attrs = {}
for name, value in attrs.items():
if not name.startswith('__'):
new_attrs[name.upper()] = value
else:
new_attrs[name] = value
return type(name, bases, new_attrs)
class Foo(object):
__metaclass__ = upper_meta
hello = 'world'
print Foo.__dict__
请不要说“说好的metaclass呢!怎么变成了一个函数!我摔!”,回顾一下最最前面提到的一点:everything is an object in python。upper_meta作为一个函数,它也是一个对象啊。而metaclass也不过就是个对象,并没有本质上的差别——只要它被call的时候能接受name, bases, attrs这三个参数并返回一个类对象就行了。duck-typing的语言用起来就是有这样的一种不可言状的酸爽感。
理解了这一点,这段代码就能理解了,upper_meta返回了一个type类的实例——也就是Foo类,并且可以看到print出来的属性里头只有HELLO而没有hello。
考虑到可能有人不满意,想看使用class来作为metaclass的情形,我就勉为其难换个姿势再举一下这个栗子(真累)。
class upper_meta(type):
def __new__(cls, name, bases, attrs):
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return type(name, bases, attrs)
def __new__(cls, name, bases, attrs):
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return type(name, bases, attrs)
写的太长了,换了一个短一点的oneliner,但是效果不变(其实我就是想炫一下,不服来咬我呀)。
这段代码虽然形式上跟前面的upper_meta函数不一样,但是本质是一样的:调用了upper_meta('Foo', (object,), {'hello': 'world'}),生成了一个新的名为Foo的类对象。
理论上,故事讲到这里应该结束了,然而我想说,压轴戏还没上呢。
== 压轴戏 ==
我要把这栗子举得更高更远,也更符合实际开发的需求:继承。
class Bar(Foo):
hi = 'there'
print Bar.__dict__
hi = 'there'
print Bar.__dict__
这段代码太简单了,但是埋在下面的逻辑却太复杂了。
它的输出并不是{'HI': 'there'}, 而是{'hi': 'there'}。你print Bar.HELLO, Bar.__metaclass__都能得到预期的输出,但是偏偏没有HI,只有hi。
为什么?这真是个烧脑细胞的事情。我已经把所有的逻辑都展现出来了,甚至还做了特别的标记。然而即便如此,想要把这个逻辑理顺,也是一件非常有挑战性的事情,幸好我已经想明白了:苦海无涯,回头是岸。啊呸,应该是——学海无涯苦作舟,不想明白不回头。
我想说“甚至还做了特别标记”这句话的意思是,我还给【甚至】这两个字做了特别标记:在__new__方法中生成并返回的对象并没有强制要求一定是该class的实例!
问题的关键就在这里:前面两个栗子中给出的upper_meta,返回的并不是upper_meta的实例,而是type的实例,而是type的实例,而是type的实例。重说三。
什么意思?再看看代码,最后return的是type(name, bases, attrs),也就是说,Foo类对象并不是upper_meta的实例,而是type的实例(也就是说:虽然指定并被使用的metaclass是upper_meta,但是最终创建出来的Foo类的metaclass是type)。不信你print type(Foo)试试,结果就是type,而不是upper_meta。
为什么这会导致继承于Foo类的Bar类不能由upper_meta来搭建?Bar.__metaclass__不还是upper_meta吗?
这个问题就没有那么困难了,有兴趣的同学可以自己试着分析一下,没兴趣的大概也不会有耐心看到这里吧。
Bar.__metaclass__并不是Bar的原生属性,而是继承于Foo的——所以在print Bar.__dict__的时候看不到__metaclass__。也就是说,在试图创建Bar时,attrs里并没有__metaclass__属性,所以并不会直接采用upper_meta。再回顾一下选择metaclass的顺序就可以发现,实际上在2.2里会选择Foo的metaclass——Foo的metaclass是type,而不是指定的upper_meta。
解决方法很简单:关键就是前面被特别标记了的【应当】返回这个class的父类的__new__方法返回的对象。具体到代码应当是这样:
class upper_meta(type):
def __new__(cls, name, bases, attrs):
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return super(upper_meta, cls).__new__(cls, name, bases, attrs)
def __init__(cls, name, bases, attrs):
print >>sys.stderr, 'in upper_meta.__init__' #FOR TEST ONLY
def __new__(cls, name, bases, attrs):
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return super(upper_meta, cls).__new__(cls, name, bases, attrs)
def __init__(cls, name, bases, attrs):
print >>sys.stderr, 'in upper_meta.__init__' #FOR TEST ONLY
新增的__init__方法并不是必须的,有兴趣的同学可以跟上面的栗子对比一下,由于前面返回的是type类的实例,调用到的是type.__init__;而这样正确的写法就会调用到upper_meta.__init__。(p.s. super也是烧脑细胞的东西,但用于解决钻石继承的问很有意思,有兴趣的同学可以看看Cooperative methods and "super")
果然很烧脑细胞吧。
关于metaclass的选择,还有另外一个坑:在metaclass 2.3提到了,找不到metaclass的情况下,会使用Globals()中定义的__metaclass__属性指定的元类来创建类,那么为什么下面的代码却没有生效呢?
def __metaclass__(name, bases, attrs):
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return type(name, bases, attrs)
class Foo(object):
hello = 'world'
print Foo.__dict__
attrs = dict([(n if n.startswith('__') else n.upper(), v) for n, v in attrs.items()])
return type(name, bases, attrs)
class Foo(object):
hello = 'world'
print Foo.__dict__
== class initializer ==
回到我最初的需求:我需要创建带class initializer的类。为什么会有这样的需求?最常见的metaclass的应用场景是对数据库的封装。举例来说,我希望创建一个Table类,所有表都是继承于这个类,同时我还想给每一个表都设置一个缓存dict(使用主键作为key缓存查询结果)。一个很自然的想法是这样的:
class Table(object):
_pk_cache = {}
@classmethod
def cache(cls, obj):
cls._pk_cache[obj.pkey()] = obj;
@classmethod
def findByPk(cls, pkey):
return cls._pk_cache[pkey]
def __init__(self, pkey, args):
self._pkey = pkey
self._args = args
type(self).cache(self)
def pkey(self):
return self._pkey
def __repr__(self):
return type(self).__name__ + ':' + repr(self._args)
class Student(Table):
pass
class Grade(Table):
pass
s1 = Student(1, 's1')
g1 = Grade(1, 'g1')
print Student.findByPk(1)
_pk_cache = {}
@classmethod
def cache(cls, obj):
cls._pk_cache[obj.pkey()] = obj;
@classmethod
def findByPk(cls, pkey):
return cls._pk_cache[pkey]
def __init__(self, pkey, args):
self._pkey = pkey
self._args = args
type(self).cache(self)
def pkey(self):
return self._pkey
def __repr__(self):
return type(self).__name__ + ':' + repr(self._args)
class Student(Table):
pass
class Grade(Table):
pass
s1 = Student(1, 's1')
g1 = Grade(1, 'g1')
print Student.findByPk(1)
可惜这是错的。从输出结果就能看出来,返回的是一个Grade对象,而不是预期的Student对象。原因很简单:子类们并不直接拥有_pk_cache ,它们访问的是Table的_pk_cache ,而该dict只被初始化了一次。
当然,我可以在每一个继承于Table的class里新增一句 _pk_cache = {},但是这样的实现太丑了,而且一不注意就会漏掉导致出错。
所以我需要一个class initializer,在class被创建的时候,给它新增一个_pk_cache 。
在搞清楚了metaclass之后,解决方法特别简单:
class TableInitializer(type):
def __new__(cls, name, bases, attrs):
attrs['_pk_cache'] = {}
return super(TableInitializer, cls).__new__(cls, name, bases, attrs)
class Table(object):
__metaclass__ = TableInitializer
... #以下不变
def __new__(cls, name, bases, attrs):
attrs['_pk_cache'] = {}
return super(TableInitializer, cls).__new__(cls, name, bases, attrs)
class Table(object):
__metaclass__ = TableInitializer
... #以下不变
完。(终于完结了,我写了一整个下午啊...)
Oct
29
转置二维数组:
utf-8字符串转为utf-8字符数组:
按显示宽度截取utf-8字符串
让进程在后台运行(detached process),出乎意料地简单
function transpose($array) {
array_unshift($array, null);
return call_user_func_array('array_map', $array);
}
array_unshift($array, null);
return call_user_func_array('array_map', $array);
}
utf-8字符串转为utf-8字符数组:
function utf8_str2arr($str)
{
preg_match_all("/./u", $str, $arr);
return $arr[0];
}
{
preg_match_all("/./u", $str, $arr);
return $arr[0];
}
按显示宽度截取utf-8字符串
function substr_width($str, $start, $width)
{
$arr = utf8_str2arr($str);
$arr_ret = [];
$i = 0;
while ($width > 0 and $i < count($arr))
{
$arr_ret[] = $arr[$start + $i];
if (strlen($arr_ret[$i]) == 1) //ascii,width=1
$width -= 1;
else
$width -= 2;
$i++;
}
if ($width < 0)
array_pop($arr_ret);
return join('', $arr_ret);
}
{
$arr = utf8_str2arr($str);
$arr_ret = [];
$i = 0;
while ($width > 0 and $i < count($arr))
{
$arr_ret[] = $arr[$start + $i];
if (strlen($arr_ret[$i]) == 1) //ascii,width=1
$width -= 1;
else
$width -= 2;
$i++;
}
if ($width < 0)
array_pop($arr_ret);
return join('', $arr_ret);
}
让进程在后台运行(detached process),出乎意料地简单
pclose(popen("nohup $cmd &", 'r'));
Oct
16
在Windows下用惯了Secure CRT的Clone Session功能,切换到mac下面,还真有点怀念。于是搜了一下,发现达到类似的效果倒是也不难。
1. mkdir ~/.ssh/cm_socket
2. 创建 ~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/cm_socket/%r@%h:%p
3. 之后只要是相同的 user@host:port 都会共用一个tcp connection,不需要再输入密码了。
p.s. 补充说明一下,通常来说,能登录服务器也就意味着可以建立信任关系,那么clone session的意义就减少了很多,但是仍然有两个优势:
1. 类似B公司的relay机器,必须使用token认证才能登录的,信任关系不能满足需求(Google Authenticator这样的两步认证方案也类似)
2. 对于延迟比较高的机器,直接复用tcp connection,可以减少相当多的时间(tcp三次握手、ssh认证的各种交互等)。
1. mkdir ~/.ssh/cm_socket
2. 创建 ~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/cm_socket/%r@%h:%p
3. 之后只要是相同的 user@host:port 都会共用一个tcp connection,不需要再输入密码了。
p.s. 补充说明一下,通常来说,能登录服务器也就意味着可以建立信任关系,那么clone session的意义就减少了很多,但是仍然有两个优势:
1. 类似B公司的relay机器,必须使用token认证才能登录的,信任关系不能满足需求(Google Authenticator这样的两步认证方案也类似)
2. 对于延迟比较高的机器,直接复用tcp connection,可以减少相当多的时间(tcp三次握手、ssh认证的各种交互等)。
Aug
18
前一段时间在京东众筹购入了一款名为"光棍一号T02"的电视棒,Intel Atom Z3735F(1.33G*4) + 2GB + 32GB,之所以下单,最主要是因为他们家宣称可以支持ubuntu(因为看起来好像就是intel Compute Stick的贴牌产品,而后者是可以支持ubuntu的)。可是到手了以后,问了众筹方才知道,原来安装镜像是不公开的,需要在发货前说明,他们装好再寄过来(跟Compute Stick一个尿性,据说是因为第三方的驱动问题)。没办法,只能自己动手了。
在网上有找到一篇文章:Install Ubuntu 14.04 LTS on the 2GB Intel Compute Stick,里面提供了一个64bit的ubuntu 14.04镜像以及相应的步骤,可以直接安装到2GB内存的Compute Stick上;以及对安装32位UEFI支持的一些说明和提示。
情况是这样的,Intel Compute Stick 2GB+32GB版本出厂预装的是Win8,Ubuntu版本只有1GB内存+16GB存储,所以大神们琢磨着弄一个ubuntu到windows版本上去,可是intel官方因为第三方驱动的原因不开放镜像,于是他们自己做了一个。从文章里可以知道,stick可以在UEFI里面选择启动的系统是32bit的win8还是64bit的ubuntu,也就是说可以按需向操作系统提供32/64位的uefi接口。可是手头的这个T02只有一个非常简单的32bit的uefi,所以整个过程就比较蛋疼了,下面记录一下,备忘。
1. 准备相关材料:http://pan.baidu.com/s/1qWN0jIO
包括 (a) 安装镜像 ubuntu14.04_z3735f.iso (b) 启动盘制作工具rufus-2.2p.exe (c) 支持32位efi的grub启动器 bootia32.efi (d) 安装后用的grub.tar.gz
2. 制作启动盘
使用rufus把iso写入到一个U盘里。把wubi.exe删掉,然后把 bootia32.efi 放到 EFI/BOOT/ 下面
3. 安装使用启动盘启动T02,可以先通过"try ubuntu"体验一下效果。
(a) 如果希望直接安装的话,建议选择"install ubuntu",比较快且不容易出错。
(b) 安装中进行分区的时候选择“使用整个磁盘”,这样会自动使用GPT分区并且创建一个EFI分区。由于本身内存空间有限,建议不要考虑双系统共存了。
(c) 安装期间建议不要插入TF卡,速度超慢。不要安装到TF卡上。
==》 安装完以后不要急着重启
4. 复制文件
(a) 把启动盘上的 bootia32.efi 拷贝到新系统的 [挂载点]/boot/efi/EFI/ubuntu 下面去。
(b) 把grub.tar.gz的内容解压到新系统的随便一个目录中(比如 /home 下面)
5. 重启,进入EFI Shell(因为新系统中没有包含配置好的32位的启动程序,会自动进入到EFI Shell中)
6. 进入grub shell:根据前面列出文章中的Troubleshooting,按顺序执行:
(a) fs0: (注意冒号)
(b) cd EFI\ubuntu
(c) bootia32.efi (于是就引入了一个裸的grub shell)
7. 进入initrd中的准系统:在grub shell下面执行
(a) linux (hd0,gpt2)/vmlinuz
(b) initrd (hd0,gpt2)/initrd.img
(c) boot
于是就进入了initrd中的
8. 安装支持32位efi的grub(这一步可能有点坑)
(a) chroot到rootfs
$ mkdir -p /rootfs
$ mount -o rw -t ext4 /dev/mmcblk0p2 /rootfs
$ mount -t vfat /dev/mmcblk0p1 /rootfs/boot/efi/
$ mount --bind /dev /rootfs/dev
$ cd /rootfs
$ chroot .
(b) 安装grub-ia32
这一步记得不是很清楚了,因为各种deb包有奇怪的依赖关系,总之大概是这样的:
$ cd /home
$ dpkg -i *.deb
根据报错信息按需卸载系统中存在的package(dpkg --remove xxx),然后再重新执行上一句直到安装成功。
【注意】安装成功以后、在/rootfs/efi/EFI/ubuntu下面应该有 grubia32.efi 这个启动器。
(c) 重启进入efi shell
是的,因为efi配置里面还是grubx64.efi
9. 从EFI Shell启动进入系统
> fs0:
> cd EFI\ubuntu
> grubia32.efi
一切顺利的话,这里就可以启动进入ubuntu了(真心不容易啊)。
10. 更新EFI配置(依然是参考文章的Troubleshooting)
$ sudo apt-get install efibootmgr #安装EFI配置编辑器
$ sudo efibootmgr -v #查看当前的efi配置(可以看到启动器是grubx64.efi,这个不对!)
$ sudo efibootmgr -b 0003 -B #删除所有的EFI启动配置
$ sudo efibootmgr -b 0002 -B
$ sudo efibootmgr -b 0001 -B
$ sudo efibootmgr -b 0000 -B
$ sudo efibootmgr -c -d /dev/mmcblk0 -p 1 -l \\EFI\\ubuntu\\grubia32.efi -L ubuntu #加入新的启动配置
$ sync
大功告成!
==== 后记 ====
启动以后就可以按需安装各种package拉,运行速度还不错,wifi没问题,显卡驱动正常(可以调整分辨率),但是声音和蓝牙驱动貌似还是有问题,不过对于一个server来说都是小问题。稍微麻烦一点的是wifi的延迟不太正常,局域网每两次ping的响应,差不多都会有一次是1000ms, 一次是2ms,但是加上一个有线USB网卡以后就都一切正常(这是什么病啊。。),接下来再试用几天看看拉。
@2015-08-19
T02是Intel Atom Z3735f (BayTrail)方案(x86_64 1.33GHz*4 + 2GB ram + 32GB rom),手头有一个2012年8月份入手的mk802(居然已经3年了,依然在勤恳地工作!感谢它!),全志A10的方案(Cortex A8 1GHz*1 + 1GB ram + 4GB rom),二者都安装上了Ubuntu Desktop版,正好作个对比。
实际使用上二者性能上的差距还是蛮直观的,ssh登录的时候,T02马上就进入shell,MK要卡几秒;在桌面程序上,比如Chrome,启动速度、页面加载速度什么的,感受很明显。下面是一些简单的测试数据:
1. 最简单的,编译一个 busy.c 源码(main里面只有一行 while(1)):
T02:0.124s
MK:0.251s
2. 编译bash
以前自己打过patch的一个bash的tar.gz
2.1 解压
T02:0.598s
MK:1.552s
2.2 configure
T02:1min
MK:1min56s
2.3 make
T02:2min16s(make),45s(make -j4)
MK:5m26s
3. CPU温度/频率@T02
这个只测T02:一个720p视频播放、5个busy.c的a.out,测试是否有风扇对着吹的情况
无风扇:81°C/81°C/87°C/87°C,500MHz*4(自动降频)
有风扇:72°C/72°C/79°C/79°C,1333MHz*4(继续吹可能还会再降点温)
在网上有找到一篇文章:Install Ubuntu 14.04 LTS on the 2GB Intel Compute Stick,里面提供了一个64bit的ubuntu 14.04镜像以及相应的步骤,可以直接安装到2GB内存的Compute Stick上;以及对安装32位UEFI支持的一些说明和提示。
情况是这样的,Intel Compute Stick 2GB+32GB版本出厂预装的是Win8,Ubuntu版本只有1GB内存+16GB存储,所以大神们琢磨着弄一个ubuntu到windows版本上去,可是intel官方因为第三方驱动的原因不开放镜像,于是他们自己做了一个。从文章里可以知道,stick可以在UEFI里面选择启动的系统是32bit的win8还是64bit的ubuntu,也就是说可以按需向操作系统提供32/64位的uefi接口。可是手头的这个T02只有一个非常简单的32bit的uefi,所以整个过程就比较蛋疼了,下面记录一下,备忘。
1. 准备相关材料:http://pan.baidu.com/s/1qWN0jIO
包括 (a) 安装镜像 ubuntu14.04_z3735f.iso (b) 启动盘制作工具rufus-2.2p.exe (c) 支持32位efi的grub启动器 bootia32.efi (d) 安装后用的grub.tar.gz
2. 制作启动盘
使用rufus把iso写入到一个U盘里。把wubi.exe删掉,然后把 bootia32.efi 放到 EFI/BOOT/ 下面
3. 安装使用启动盘启动T02,可以先通过"try ubuntu"体验一下效果。
(a) 如果希望直接安装的话,建议选择"install ubuntu",比较快且不容易出错。
(b) 安装中进行分区的时候选择“使用整个磁盘”,这样会自动使用GPT分区并且创建一个EFI分区。由于本身内存空间有限,建议不要考虑双系统共存了。
(c) 安装期间建议不要插入TF卡,速度超慢。不要安装到TF卡上。
==》 安装完以后不要急着重启
4. 复制文件
(a) 把启动盘上的 bootia32.efi 拷贝到新系统的 [挂载点]/boot/efi/EFI/ubuntu 下面去。
(b) 把grub.tar.gz的内容解压到新系统的随便一个目录中(比如 /home 下面)
5. 重启,进入EFI Shell(因为新系统中没有包含配置好的32位的启动程序,会自动进入到EFI Shell中)
6. 进入grub shell:根据前面列出文章中的Troubleshooting,按顺序执行:
(a) fs0: (注意冒号)
(b) cd EFI\ubuntu
(c) bootia32.efi (于是就引入了一个裸的grub shell)
7. 进入initrd中的准系统:在grub shell下面执行
(a) linux (hd0,gpt2)/vmlinuz
(b) initrd (hd0,gpt2)/initrd.img
(c) boot
于是就进入了initrd中的
8. 安装支持32位efi的grub(这一步可能有点坑)
(a) chroot到rootfs
$ mkdir -p /rootfs
$ mount -o rw -t ext4 /dev/mmcblk0p2 /rootfs
$ mount -t vfat /dev/mmcblk0p1 /rootfs/boot/efi/
$ mount --bind /dev /rootfs/dev
$ cd /rootfs
$ chroot .
(b) 安装grub-ia32
这一步记得不是很清楚了,因为各种deb包有奇怪的依赖关系,总之大概是这样的:
$ cd /home
$ dpkg -i *.deb
根据报错信息按需卸载系统中存在的package(dpkg --remove xxx),然后再重新执行上一句直到安装成功。
【注意】安装成功以后、在/rootfs/efi/EFI/ubuntu下面应该有 grubia32.efi 这个启动器。
(c) 重启进入efi shell
是的,因为efi配置里面还是grubx64.efi
9. 从EFI Shell启动进入系统
> fs0:
> cd EFI\ubuntu
> grubia32.efi
一切顺利的话,这里就可以启动进入ubuntu了(真心不容易啊)。
10. 更新EFI配置(依然是参考文章的Troubleshooting)
$ sudo apt-get install efibootmgr #安装EFI配置编辑器
$ sudo efibootmgr -v #查看当前的efi配置(可以看到启动器是grubx64.efi,这个不对!)
$ sudo efibootmgr -b 0003 -B #删除所有的EFI启动配置
$ sudo efibootmgr -b 0002 -B
$ sudo efibootmgr -b 0001 -B
$ sudo efibootmgr -b 0000 -B
$ sudo efibootmgr -c -d /dev/mmcblk0 -p 1 -l \\EFI\\ubuntu\\grubia32.efi -L ubuntu #加入新的启动配置
$ sync
大功告成!
==== 后记 ====
启动以后就可以按需安装各种package拉,运行速度还不错,wifi没问题,显卡驱动正常(可以调整分辨率),但是声音和蓝牙驱动貌似还是有问题,不过对于一个server来说都是小问题。稍微麻烦一点的是wifi的延迟不太正常,局域网每两次ping的响应,差不多都会有一次是1000ms, 一次是2ms,但是加上一个有线USB网卡以后就都一切正常(这是什么病啊。。),接下来再试用几天看看拉。
@2015-08-19
T02是Intel Atom Z3735f (BayTrail)方案(x86_64 1.33GHz*4 + 2GB ram + 32GB rom),手头有一个2012年8月份入手的mk802(居然已经3年了,依然在勤恳地工作!感谢它!),全志A10的方案(Cortex A8 1GHz*1 + 1GB ram + 4GB rom),二者都安装上了Ubuntu Desktop版,正好作个对比。
实际使用上二者性能上的差距还是蛮直观的,ssh登录的时候,T02马上就进入shell,MK要卡几秒;在桌面程序上,比如Chrome,启动速度、页面加载速度什么的,感受很明显。下面是一些简单的测试数据:
1. 最简单的,编译一个 busy.c 源码(main里面只有一行 while(1)):
T02:0.124s
MK:0.251s
2. 编译bash
以前自己打过patch的一个bash的tar.gz
2.1 解压
T02:0.598s
MK:1.552s
2.2 configure
T02:1min
MK:1min56s
2.3 make
T02:2min16s(make),45s(make -j4)
MK:5m26s
3. CPU温度/频率@T02
这个只测T02:一个720p视频播放、5个busy.c的a.out,测试是否有风扇对着吹的情况
无风扇:81°C/81°C/87°C/87°C,500MHz*4(自动降频)
有风扇:72°C/72°C/79°C/79°C,1333MHz*4(继续吹可能还会再降点温)