Date: Fri, 29 Jul 2016 18:49:55 +0200 From: Adam Starak <starak.adam@gmail.com> To: cem@freebsd.org Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Modify user space from kernel. Message-ID: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> In-Reply-To: <CAG6CVpWdZMYqKLzz1H70Hq_SXF1eeOcEy0%2BiU6DYMVkAkqgAhg@mail.gmail.com> References: <CAAz%2B7vqLgd5GSBfFMdD-xsAsEoujgPh8ZdKY4xZ1LO0h30OmSQ@mail.gmail.com> <CAG6CVpWdZMYqKLzz1H70Hq_SXF1eeOcEy0%2BiU6DYMVkAkqgAhg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My project is focused on nvlist. I'm improving and expanding its usage. Nvli= st can be used in userland as well as in kernel. My goal is to establish com= munications between them via nvlist. That's why setting a fixed size or loop= ing doesn't satisfy me. It'll be some kind of IPC, not only for sysctl ofc.=20= Best regards, Adam Starak Dnia 29.07.2016 o godz. 18:05 Conrad Meyer <cem@freebsd.org> napisa=C5=82(a)= : >> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak <starak.adam@gmail.com> wrot= e: >> Hello! >>=20 >> 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= . >>=20 >> 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 da= ta >> (packed nvlist) into the user space. Is there any chance to pass data fro= m >> kernel to user space without knowing the size of it? >>=20 >> Right now, the implementation of __sysctl() function requests void pointe= r >> 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= . >=20 > Hey Adam, >=20 > That is the usual way to do it. Just curious =E2=80=94 why do you want to= > avoid that situation? >=20 > 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. >=20 > Best, > Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00058592-A469-440C-884E-5C057DAE2AB6>
