昨天，我们几个来自Delphix、Nexenta、Joyent和其他地方的人在OpenStorage峰会之前召开了会议，作为illumos hackathon的一部分。当时的想法是让一群illumos编码器在一个房间里，集思广益地提出一些小项目的想法，然后在一天的时间里休息下来去实现它们。这是一个想法，至少在现实中，我们不知道会发生什么，也不知道结果会怎样。可以说，黑客马拉松是一个惊人的成功。房间里有很多很酷的想法，还有很多伟大的导师，他们可以带领人们穿越陌生的领域。对于我的小项目（由ahl建议），我通过一个新的print（）操作在DTrace中实现了MDB的：：print功能。现在，我们有trace（）操作，但在处理结构时，结果有些不太有用，因为它退化为traceem（）：#dtrace-qn'开始{trace（`p0）；退出（0）}'0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef0:00 00 00 00 00 00 00 00 00 02 c3 fb ff ff ff ff ff……..`。。。。。。。10： c8 c9 c6 fb ff ff ff ff 00 00 00 00 00 00 00 00 00 00。。。。。。。。。。。。。。。。20： b0 ad 14 c6 00 ff ff ff 00 00 00 00 00 02 00 00 00。。。。。。。。。。。。。。。。...结果并不理想，我们最终会丢弃所有有用的过程类型信息。对dtrace稍作调整，并从mdb_print.c中抄袭，我们可以做得更好：#dtrace-qn'开始{print（`p0）；退出（0）}'程序{结构vnode*p_exec=0struct as*p_as=0xfffffffffbc30260struct plock*p_lock=0xfffffffffbc6c9c8kmutex_t p_c锁={无效*[1]_不透明=[0]}结构cred*p_cred=0xffffff00c614adb0int p_swapcnt=0char p_stat='02'....好多了！现在，我们是怎么到那里的？答案是通过libdtrace、内核dtrace实现、CTF和位域的可怕经历。行动还是不行动？我要回答的第一个问题是用户可见界面应该是什么。显然，这应该是一个与trace（）在同一级别上的操作，允许任意的D表达式，但只需保留结果的类型，稍后再打印。在简单地考虑了print（）（表示"print type"）之后，我决定只使用print（），因为这似乎是合乎逻辑的，我的第一个倾向是创建一个新的DTRACEACT_print，云服务器买哪个好，但是经过与Adam的讨论，我们认为这是无关的-行为与DTRACEACT_DIFEXPR（trace的内部名称）相同，多线云主机，但只需要输入信息。从镜子里看出来的类型和格式真正的问题是，我们编译的（dtrace语句）和我们使用的（dtrace epid和records）是两个完全不同的东西，twain永远不会相遇。在我们准备在dt_cc.c中生成DIFEXPR语句时，大数据时代是什么意思，我们手头有CTF数据。我们不想更改生成的DIF，只需在另一端进行后处理，所以我们只需要一些方法返回dt_consumer_cpu（）中的类型信息。我们不能简单地将其挂起dtrace语句，因为那样会破坏匿名跟踪（并违反dtrace体系结构的其余部分来引导）。谢天谢地，printf（）和相关操作已经解决了这个问题，因为出于同样的原因，我们需要保留原始格式字符串。为此，手机网站自助建站，我们使用动作特定的整型参数，并使用它指向DOF字符串表，在那里我们保存原始格式字符串。我只需劫持dtrace_dof_create（）并让它对类型信息执行相同的操作，对吗？要是能这么简单就好了。这里有两个复杂的问题：有很多代码显式地将这些字符串视为printf字符串，并将它们解析为内部的argv样式表示。假装我们的类型只是格式字符串，会在这段代码中引起各种各样的问题。所以我不得不修改libdtrace，以便更明确地将其视为原始的"字符串数据"，该数据（可选）与DIFEXPR操作一起使用。即使有了它，我发送下来的格式也没有从内核中返回。因为参数是特定于操作的，所以需要修改内核以识别dtrace_ecb_action_add中的新参数。有了这个更改，当使用CPU缓冲区时，我能够在userland中获得格式字符串。位域，或者为什么D编译器要花费我一个小时的生命有了跟踪数据和类型字符串之后，我继续复制mdb:：print代码，首先从apptrace（结果证明是完全垃圾），然后一点一点地修复它。最后，在调整了一两个小时的代码之后，我让它看起来非常像相同的：：print输出。但是当我给它输入一个klwp_t结构时，我发现user_desc_t structure位字段没有正确打印：#dtrace-n'开始{print（*（（user_desc_t*）0xffffff00cb0a4d90））；退出（0）}'dtrace:描述"BEGIN"与1个探测器匹配CPU ID功能：名称0 1:开始用户描述{无符号多头美元=0xcff3000000ffff无符号长美元lobase=0xcff300000无符号长usd_midbase=0xcff300无符号长usd_类型=0xcff3无符号长usd_dpl:64=0xcff3无符号长美元_p:64=0xcff3无符号长usd_hilimit=0xcf无符号长usd_avl:64=0xcf无符号多头美元长：64=0xcf无符号多头美元_def32:64=0xcf无符号多头美元：64=0xcf无符号多头美元=0}我花了一个小时来调试，结果发现CTF ID与我期望的底层对象不匹配。我最后追踪到这样一个事实：D编译器通过处理/usr/lib/dtrace文件，从系统头文件中获取自己的klwp_t版本。但它会破坏位字段，云服务器价格比较，给用户留下一个微妙的错误数据。将类型切换为genunix`user_desc'无法解决此问题。下一步是什么考虑到这个特性的有用性，接下来的步骤是清理代码，对其进行复查，并将其推到illumos门。希望它能很快到达你附近的illumos发行版。下面是最后一个print（）调用：#dtrace-n'zio公司_完成：输入{print（*args[0]）；退出（0）}'dtrace:描述'zio'_完成：输入'匹配1个探针CPU ID功能：名称0 42594济奥_完成：进入zio{zbookmark_t io_峎书签={uint64_t zb_objset=0uint64_t zb_对象=0int64_t zb_泴level=0uint64_t zb_blkid=0}自始至终属性={enum zio_checksum zp_checksum=zio_checksum_继承enum zio_compress zp_compress=zio_compress_继承dmu_object_type_t zp_type=dmu_OT_无uint8\u t zp_级别=0uint8\u t zp_copies=0uint8_t zp_重复数据删除=0uint8_t zp_dedup_verify=0}zio_type_t io_type=zio_类型_NULLenum zio_child io_child_类型=zio_child_VDEVint io_cmd=0uint8\u t io_优先级=0uint8_t io_reexecute=0uint8_t[2]io_状态=[0x1，0]uint64_t io_txg=0spa_t*io_spa=0xffffff00c6806580blkptr_t*io_bp=0blkptr_t*io_bp_覆盖=0业务伙伴副本={dva_t[3]黑色dva=[数字电视{uint64_t[2]dva_字=[0，0]},...