Modify user space from kernel.

[Adam Starak]

Hey,
That's also pretty cool idea, because nvlist can be easily transferred over sockets. Thank you all guys for your fast response. 

Best regards,
Adam Starak

Dnia 29.07.2016 o godz. 18:55 Conrad Meyer <cem at freebsd.org> napisał(a):

> 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