可能是 tempdb 空间用尽或某个系统表不一致_一个逻辑空间控制的例子：uacce生命周期管理...

等不了SVA的进展，最近我们的兄弟开始上传WarpDrive的内核实现(uacce)了。内核Maintainer Greg K. H.对其中一个地方提了如下意见：Greg Kroah-Hartman: Re: [PATCH v2 2/2] uacce: add uacce driver。

有兄弟看不懂这个意见是什么意思。我把这个作为一个例子，一方面解释Greg是什么意思，另一方面说明一下，如何在设计中控制自己的逻辑空间。

我们最初定义uacce这个对象，目的不是创建一个设备，而是定义一个“接口”：你有一个加速器，这个加速器可以提供特定的用户接口，我们把控制这个接口的数据结构综合在一个地方，就叫struct uacce。所以uacce->dev最初就叫dev，因为这是它的backup device，而不是它的parent device，因为它本来就不是一个device，不属于设备名称空间的一部分。

但为了暴露uacce的接口到用户态，我们创建了cdev，cdev要求背后有backup device。这个device就不可能是那个加速器的device，因为那个device已经被device model管理了，里面有自己的管理模型。所以我们在uacce中再创建了一个device，纯为了支撑cdev的模型而已。

但按照惯例，我们的device和uacce综合在一起，uacce就变成一个device了。所以Greg提了一个意见：“你的uacce就不应该叫uacce，而应该叫uacce_device”。我们也接受了，这就意味了，我们整个名称空间的定义就修改了，uacce不再是一个“接口”，而是一个接受device生命周期管理的设备对象。我们未来需要认为，某个加速器的驱动，如果注册为一个uacce，本质就是为自己创建了一个虚拟的子设备，这个子设备叫uacce_device。

那么uacce_device就受Linux Device Model的直接控制了，它的生命周期管理就应该遵循Linux Device Model的原则（基于refcount决定资源的最后释放）。

在这种情况下，我们在uacce_device中又内联了一个cdev对象进去，这个对象也有自己的refcount，也有它自己的生命周期管理的。这两个流程是无法总保持一致的，我们总会出现cdev接口已经放弃了，但暂时因为某个device管理流程的控制，uacce_device一时不能释放的情形。这种情形现在还没有发生，但我们不能认为它就不会发生了。我们为长远着想，从一开始就不能让这种情形发生。

Greg这种经验老道的，一眼就能看破这种破绽，估计也是看多了。他的要求是，要不你内联device，变成一个uacce_device，要不你内联cdev，变成一个uacce_cdev，不能同时拥有这两个身份。大部分Linux Kernel核心Maintainer都有这种能力，这其实就是架构控制的能力。他们不是在关心你的代码现在能不能跑，而是你的代码能生存多久。如果你不知道为什么现代操作系统这么难开发，也许这里能看到一点端倪。

我们要能对上这样的讨论，就有必要总从整个逻辑空间的自恰的角度来考量这些问题，而不能用眼前的代码有没有问题来想问题。每个外部接口的修改，都要和原始的名称空间定义对照，保证逻辑一直是通的。否则就会鸡同鸭讲，半天都对不上号。对方让你修改什么，你就仅仅修改那一个地方，其他地方的概念没有跟上，这样的交流是长久不了的。你要接受对方一个意见，要从概念空间一致开始分析，这样所有需要调整的接口和实现都会跟上，而不是越改越偏离。