descript.ion 是什么文件呀？

分类: 电脑/网络

问题描述:

它无缘无故出现在我装图片的文件夹里

解析:

用过ACDSee的人无不被它强大而实用的看图功能所折服，其方便的描述信息功能就是其中之一。你可以为任何格式的图片加上自己的文字注释，方便检索和增添许多情趣。只要将鼠标指向一个图像文件，就可以显示出图像的文件名、大小、规格和描述信息，是不是为照片增色不少？

加入和修改描述信息非常简单，在用ACDSee浏览图片时，选中一个图片文件，单击鼠标右键，在右键菜单中选中“描述”，即可d出描述信息编辑器，让你随心所欲添加文字信息。

但现在的问题是，当把一张图片从一个文件夹复制或移动到另一个文件夹中时，描述信息能否随图片一起带过去呢？答案是只要你是在ACDSee的文件管理界面中进行拷贝或移动 *** 作，描述信息就能随图片一同移动；但如果你是在Windows资源管理器或其他方式进行拷贝或移动（如用DOS模式） *** 作的话，则描述信息会丢失。这又是为什么呢？经过摸索，终于发现了其中的秘密。

原来，所有这些描述信息，都是保存在一个隐藏文件中的，这个隐藏文件在图片所在的目录中，文件名为descript.ion，可以用文件编辑器（如记事本）开打，下面为一个descript.ion的内容：

图1． 何事让汝蹙蛾眉

图2． 我的篮子怎么样

图3． 让我好好看看

……

好了，现在你知道它的规则了。那么，除了复制图片时不要忘记复制这个descript.ion文件外，你还想到了什么呢？哈哈，对了，我们也可以利用这一原理，更直接地编辑图片的描述信息。

方法是：在图片文件夹中新建文本文档，然后按上述格式描述你的图片，完毕后，将该文本文件重新命名为descript.ion，再用ACDSee打开这个图片文件夹，怎么样，是不是很有成就感呢？

what is ION?

ION  内存管理从android4.0开始被引入

ION模块是可扩展的（API都是统一的），支持各种形式的内存分配方式，可以表述不同的硬件资源和他们的一些限制

ION 支持连续与不连续内存的分配

ION 给Kernel and User space processes提供了相应的APIs

当前支持的memory type

ION_HEAP_TYPE_CARVEOUT - memory (PMEM style) for larger physically contiguous allocations

ION_HEAP_TYPE_SYSTEM_CONTIG - physically contiguous for small physical allocations

ION_HEAP_TYPE_SYSTEM - virtually contiguous but physically discontiguous memory

ION_HEAP_TYPE_IOMMU - memory region allocated through IOMMU API.

ION heap 的大小根据每个设备自身的内存情况而定，但是都要实现下面的回调：

   struct ion_heap_ops {

        int (*allocate) (struct ion_heap *heap,

                       struct ion_buffer *buffer, unsigned long len,

                       unsigned long align, unsigned long flags)

        void (*free) (struct ion_buffer *buffer)

        int (*phys) (struct ion_heap *heap, struct ion_buffer *buffer,

               ion_phys_addr_t *addr, size_t *len)

        struct scatterlist *(*map_dma) (struct ion_heap *heap,

                       struct ion_buffer *buffer)

        void (*unmap_dma) (struct ion_heap *heap,

        struct ion_buffer *buffer)

        void * (*map_kernel) (struct ion_heap *heap,

        struct ion_buffer *buffer)

        void (*unmap_kernel) (struct ion_heap *heap,

        struct ion_buffer *buffer)

        int (*map_user) (struct ion_heap *heap, struct ion_buffer *buffer,

                       struct vm_area_struct *vma)

   }

方法phys()，返回的是的物理地址和buffer的长度，但必须是连续的物理buffer，如果没有连续的物理buffer，是不能提供改回调。

map_kernel() and unmap_kernel()，把物理内存映射到kernel virtual address space.

map_user(),映射物理内存到用户空间，为啥没有unmap_user()方法呢，因为映射到用户空间，是以FD（文件描述符）的形式映射的，当FD close了就自动unmap。

ION可以释放内存嘛？

答案是否定的。它主要的是提供给applications间共享内存。

ION和PMem可以共存嘛？

可以，但是不能共享buffers.

userspace是如何使用ION？

1：open ION device-------open("/dev/ion", O_RDONLY),返回一个FD(相当于ION client)

2:  客户端要填充如下数据结构，除了handle,也就是你要申请的data：

struct ion_allocation_data {

        size_t len

        size_t align

        unsigned int flags

        struct ion_handle *handle

   }

3: user space clients 用ioctl跟ION通信

int ioctl(int client_fd, ION_IOC_ALLOC, struct ion_allocation_data *allocation_data)

返回的FD的buffer。

4：FD可以通过Binder机制进行进程间的share

如何查看ION的使用量

for example:

>adb shell

 #mount -t debugfs NONE /d

 #cd /d/ion/

 #ls

 922

 vmalloc

 ...

 # cat vmalloc

 cat vmalloc

 client pid size

 total bytes currently allocated: 0

 # cat 922

 cat 922

 heap_name: size_in_bytes : handle refcount : buffer

 client refcount: 1

ION 和DMABUF的比较：

Feature ION DMABUF

Memory Manager RoleION replaces PMEM as the manager of provisioned memory pools. The list of ION heaps can be extended per device.DMABUF is a buffer sharing framework, designed to integrate with the memory allocators in DMA mapping frameworks, like the work-in-progress DMA-contiguous allocator, also known as the Contiguous Memory Allocator  (CMA). DMABUF exporters have the option to implement custom allocators.

User Space Access ControlION offers the /dev/ion interface for user-space programs to allocate and share buffers. Any user program with ION access can cripple the system by depleting the ION heaps. Android checks user and group IDs to block unauthorized access to ION heaps.DMABUF offers only kernel APIs. Access control is a function of the permissions on the devices using the DMABUF feature.

Global Client and Buffer DatabaseION contains a device driver associated with /dev/ion. The device structure contains a database that tracks the allocated ION buffers, handles and file descriptors, all grouped by user clients and kernel clients. ION validates all client calls according to the rules of the database. For example, there is a rule that a client cannot have two handles to the same buffer.The  DMA debug facility  implements a global hashtable,dma_entry_hash, to track DMA buffers, but only when the kernel was built with theCONFIG_DMA_API_DEBUG option.

Cross-architecture UsageION usage today is limited to architectures that run the Android kernel.DMABUF usage is cross-architecture. The  DMA mapping redesign preparation patchset  modified the DMA mapping code in 9 architectures besides the ARM architecture.

Buffer SynchronizationION considers buffer synchronization to be an orthogonal problem.DMABUF provides a pair of APIs for synchronization. The buffer-user callsdma_buf_map_attachment()whenever it wants to use the buffer for DMA . Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to the exporter via a call todma_buf_unmap_attachment().

Delayed Buffer AllocationION allocates the physical memory before the buffer is shared.DMABUF can defer the allocation until the first call todma_buf_map_attachment(). The exporter of DMA buffer has the opportunity to scan all client attachments, collate their buffer constraints, then choose the appropriate backing storage.

上一篇文章，在解析初始化GraphicBuffer中，遇到一个ion驱动，对图元进行管理。首先看看ion是怎么使用的：

我们按照这个流程分析ion的源码。

如果对ion使用感兴趣，可以去这篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744

本文基于Android的Linux内核版本3.1.8

遇到什么问题欢迎来本文讨论 https://www.jianshu.com/p/5fe57566691f

什么是ion？如果是音视频，Camera的工程师会对这个驱动比较熟悉。最早的GPU和其他驱动协作申请一块内存进行绘制是使用比较粗暴的共享内存。在Android系统中使用的是匿名内存。最早由三星实现了一个Display和Camera共享内存的问题，曾经在Linux社区掀起过一段时间。之后各路大牛不断的改进之下，就成为了dma_buf驱动。并在 Linux-3.3 主线版本合入主线。现在已经广泛的运用到各大多媒体开发中。

首先介绍dma_buf的2个角色，importer和exporter。importer是dma_buf驱动中的图元消费者，exporter是dma_buf驱动中的图元生产者。

这里借用大佬的图片：

ion是基于dma_buf设计完成的。经过阅读源码，其实不少思路和Android的匿名内存有点相似。阅读本文之前就算不知道dma_buf的设计思想也没关系，我不会仔细到每一行，我会注重其在gralloc服务中的申请流程，看看ion是如何管理共享内存，为什么要抛弃ashmem。

我们先来看看ion的file_operation:

只有一个open和ioctl函数。但是没有mmap映射。因此mmap映射的时候一定其他对象在工作。

我们关注显卡英伟达的初始化模块。

文件：/ drivers / staging / android / ion / tegra / tegra_ion.c

module_platform_driver实际上就是我之前经常提到过的module_init的一个宏,多了一个register注册到对应名字的平台中的步骤。在这里面注册了一个probe方法指针，probe指向的tegra_ion_probe是加载内核模块注册的时候调用。

先来看看对应的结构体：

再来看看对应ion内的堆结构体：

完成的事情如下几个步骤：

我们不关注debug模式。其实整个就是我们分析了很多次的方法。把这个对象注册miscdevice中。等到insmod就会把整个整个内核模块从dev_t的map中关联出来。

我们来看看这个驱动结构体：

文件：/ drivers / staging / android / ion / ion_heap.c

这里有四个不同堆会申请出来，我们主要来看看默认的ION_HEAP_TYPE_SYSTEM对应的heap流程。

其实真正象征ion的内存堆是下面这个结构体

不管原来的那个heap，会新建3个ion_system_heap，分别order为8，4，0,大于4为大内存。意思就是这个heap中持有一个ion_page_pool 页资源池子，里面只有对应order的2的次幂，内存块。其实就和伙伴系统有点相似。

还会设置flag为ION_HEAP_FLAG_DEFER_FREE，这个标志位后面会用到。

文件：/ drivers / staging / android / ion / ion_page_pool.c

在pool中分为2个链表一个是high_items，另一个是low_items。他们之间的区分在此时就是以2为底4的次幂为分界线。

文件：/ drivers / staging / android / ion / ion.c

因为打开了标志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此会初始化两个回收函数。

文件：/ drivers / staging / android / ion / ion_heap.c

此时会创建一个内核线程，调用ion_heap_deferred_free内核不断的循环处理。不过由于这个线程设置的是SCHED_IDLE，这是最低等级的时间片轮转抢占。和Handler那个adle一样的处理规则，就是闲时处理。

在这个循环中，不断的循环销毁处理heap的free_list里面已经没有用的ion_buffer缓冲对象。

文件：/ drivers / staging / android / ion / ion_system_heap.c

注册了heap的销毁内存的方法。当系统需要销毁页的时候，就会调用通过register_shrinker注册进来的函数。

文件：/ drivers / staging / android / ion / ion_page_pool.c

整个流程很简单，其实就是遍历循环需要销毁的页面数量，接着如果是8的次幂就是移除high_items中的page缓存。4和0则销毁low_items中的page缓存。至于为什么是2的次幂其实很简单，为了销毁和申请简单。__free_pages能够整页的销毁。

文件：/ drivers / staging / android / ion / ion.c

主要就是初始化ion_client各个参数，最后把ion_client插入到ion_device的clients。来看看ion_client结构体：

核心还是调用ion_alloc申请一个ion缓冲区的句柄。最后把数据拷贝会用户空间。

这个实际上就是找到最小能承载的大小，去申请内存。如果8kb申请内存，就会拆分积分在0-4kb，4kb-16kb，16kb-128kb区间找。刚好dma也是在128kb之内才能申请。超过这个数字就禁止申请。8kb就会拆成2个4kb保存在第一个pool中。

最后所有的申请的page都添加到pages集合中。

文件：/ drivers / staging / android / ion / ion_page_pool.c

能看到此时会从 ion_page_pool冲取出对应大小区域的空闲页返回上层，如果最早的时候没有则会调用ion_page_pool_alloc_pages申请一个新的page。由于引用最终来自ion_page_pool中，因此之后申请之后还是在ion_page_pool中。

这里的处理就是为了避免DMA直接内存造成的缓存差异(一般的申请，默认会带一个DMA标志位)。换句话说，是否打开cache其实就是，关闭了则使用pool的cache，打开了则不使用pool缓存，只依赖DMA的缓存。

我们可以看另一个dma的heap，它是怎么做到dma内存的一致性.

文件： drivers / staging / android / ion / ion_cma_heap.c

能看到它为了能办到dma缓存的一致性，使用了dma_alloc_coherent创建了一个所有强制同步的地址，也就是没有DMA缓存的地址。

这里出现了几个新的结构体，sg_table和scatterlist

文件：/ lib / scatterlist.c

这里面实际上做的事情就是一件：初始化sg_table.

sg_table中有一个核心的对象scatterlist链表。如果pages申请的对象数量<PAGE_SIZE/sizeof(scatterlist),每一项sg_table只有一个scatterlist。但是超出这个数字就会增加一个scatterlist。

用公式来说：

换句话说，每一次生成scatterlist的链表就会直接尽可能占满一页，让内存更好管理。

返回了sg_table。

初始化ion_handle，并且记录对应的ion_client是当前打开文件的进程，并且设置ion_buffer到handle中。使得句柄能够和buffer关联起来。

每当ion_buffer需要销毁，

---