My question is about passing data from kernel to a user space program. I want to implement a system call "get_data(size, char *buff, char **meta_buf)". In this call, buff is allocated by user space program and its length is passed in the size argument. However, meta_buf is a variable length buffer that is allocated (in the user space program's vm pages) and filled by kernel. User space program will free this region.
我的问题是将数据从内核传递到用户空间程序。我想实现一个系统调用“get_data(size,char * buff,char ** meta_buf)”。在此调用中,buff由用户空间程序分配,其长度在size参数中传递。但是,meta_buf是一个可变长度的缓冲区,它被分配(在用户空间程序的vm页面中)并由内核填充。用户空间计划将释放该地区。
(I cant allocate data in user space as user space program does not know size of the meta_buff. Also, user space program cannot allocate a fixed amount of memory and call the system call again and again to read the entire meta data. meta_data has to be returned in one single system call)
(我无法在用户空间中分配数据,因为用户空间程序不知道meta_buff的大小。此外,用户空间程序无法分配固定数量的内存并反复调用系统调用来读取整个元数据.meta_data必须在一个系统调用中返回)
- How do I allocate memory for a user space program from kernel thread? (I would even appreciate if you can point me to any other system call that does a similar operation - allocating in kernel and freeing in user space)
- Is this interface right or is there a better way to do it?
如何从内核线程为用户空间程序分配内存? (如果您能指出我执行类似操作的任何其他系统调用 - 在内核中分配并释放用户空间,我甚至会感激不尽)
这个界面是对的还是有更好的方法呢?
1 个解决方案
#1
11
Don't attempt to allocate memory for userspace from the kernel - this is a huge violation of the kernel's abstraction layering. Instead, consider a few other options:
不要试图从内核为用户空间分配内存 - 这严重违反了内核的抽象分层。相反,请考虑其他一些选项:
- Have userspace ask how much space it needs. Userspace allocates, then grabs the memory from the kernel.
- Have userspace mmap pages owned by your driver directly into its address space.
- Set an upper bound on the amount of data needed. Just allocate that much.
让用户空间询问它需要多少空间。用户空间分配,然后从内核中获取内存。
将驱动程序拥有的用户空间mmap页面直接放入其地址空间。
设置所需数据量的上限。只需分配那么多。
It's hard to say more without knowing why this has to be atomic. Actually allocating memory's going to need to be interruptible anyway (or you're unlikely to succeed), so it's unlikely that going out of and back into the kernel is going to hurt much. In fact, any write to userspace memory must be interruptible, as there's the potential for page faults requiring IO.
如果不知道为什么这必须是原子的,就很难说更多。实际上分配内存无论如何都需要中断(或者你不太可能成功),因此不太可能走出和重新进入内核会受到太大伤害。事实上,任何对用户空间内存的写入都必须是可中断的,因为存在需要IO的页面错误的可能性。
#1
11
Don't attempt to allocate memory for userspace from the kernel - this is a huge violation of the kernel's abstraction layering. Instead, consider a few other options:
不要试图从内核为用户空间分配内存 - 这严重违反了内核的抽象分层。相反,请考虑其他一些选项:
- Have userspace ask how much space it needs. Userspace allocates, then grabs the memory from the kernel.
- Have userspace mmap pages owned by your driver directly into its address space.
- Set an upper bound on the amount of data needed. Just allocate that much.
让用户空间询问它需要多少空间。用户空间分配,然后从内核中获取内存。
将驱动程序拥有的用户空间mmap页面直接放入其地址空间。
设置所需数据量的上限。只需分配那么多。
It's hard to say more without knowing why this has to be atomic. Actually allocating memory's going to need to be interruptible anyway (or you're unlikely to succeed), so it's unlikely that going out of and back into the kernel is going to hurt much. In fact, any write to userspace memory must be interruptible, as there's the potential for page faults requiring IO.
如果不知道为什么这必须是原子的,就很难说更多。实际上分配内存无论如何都需要中断(或者你不太可能成功),因此不太可能走出和重新进入内核会受到太大伤害。事实上,任何对用户空间内存的写入都必须是可中断的,因为存在需要IO的页面错误的可能性。