Modify user space from kernel.

[Conrad Meyer]

Hi Adam,

You could create a pipe or socket if there will be continuous IPC
between kernel and userspace.  Sockets have defined behavior around
message boundaries.

For that approach, you could look at the implementation of sys_socket
or sys_pipe2.  Or maybe the best approach is just to define some new
address family.  I'm not sure what the standards allow.

Best,
Conrad

On Fri, Jul 29, 2016 at 9:49 AM, Adam Starak <starak.adam at gmail.com> wrote:
> My project is focused on nvlist. I'm improving and expanding its usage. Nvlist can be used in userland as well as in kernel. My goal is to establish communications between them via nvlist. That's why setting a fixed size or looping doesn't satisfy me. It'll be some kind of IPC, not only for sysctl ofc.
>
> Best regards,
> Adam Starak
>
> Dnia 29.07.2016 o godz. 18:05 Conrad Meyer <cem at freebsd.org> napisał(a):
>
>>> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak <starak.adam at gmail.com> wrote:
>>> Hello!
>>>
>>> My name is Adam. I participate in Google Summer of Code this year. I came
>>> up with a big problem, which doesn't allow me to go further in my project.
>>>
>>> I made a new syscall, which is going to retrieve sysctl data and put it
>>> inside the nvlist. And here my problem is. I need to move somehow this data
>>> (packed nvlist) into the user space. Is there any chance to pass data from
>>> kernel to user space without knowing the size of it?
>>>
>>> Right now, the implementation of __sysctl() function requests void pointer
>>> and size in order to get data. If allocated memory is too low, it returns
>>> ENOMEM and you need to realloc the data. I wanted to avoid this situation.
>>
>> Hey Adam,
>>
>> That is the usual way to do it.  Just curious — why do you want to
>> avoid that situation?
>>
>> Your other option might be to put an upper limit on the size of the
>> result, and pass a buffer of that size in from userspace.  But then
>> you are artificially limited to some arbitrary size and must
>> preallocate a large buffer even in the case that the output is small.
>>
>> Best,
>> Conrad