Date: Sat, 30 Jul 2016 09:25:56 +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: <A7A09582-1A7D-45A3-B838-DE006F4F0FFA@gmail.com> In-Reply-To: <CAG6CVpWh_EbepcA8kHxxBuUfMctHJiYtsTGNEedoJQazAZrOHQ@mail.gmail.com> References: <CAAz%2B7vqLgd5GSBfFMdD-xsAsEoujgPh8ZdKY4xZ1LO0h30OmSQ@mail.gmail.com> <CAG6CVpWdZMYqKLzz1H70Hq_SXF1eeOcEy0%2BiU6DYMVkAkqgAhg@mail.gmail.com> <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> <CAG6CVpWh_EbepcA8kHxxBuUfMctHJiYtsTGNEedoJQazAZrOHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey, That's also pretty cool idea, because nvlist can be easily transferred over s= ockets. Thank you all guys for your fast response.=20 Best regards, Adam Starak Dnia 29.07.2016 o godz. 18:55 Conrad Meyer <cem@freebsd.org> napisa=C5=82(a)= : > Hi Adam, >=20 > You could create a pipe or socket if there will be continuous IPC > between kernel and userspace. Sockets have defined behavior around > message boundaries. >=20 > 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. >=20 > Best, > Conrad >=20 >> On Fri, Jul 29, 2016 at 9:49 AM, Adam Starak <starak.adam@gmail.com> wrot= e: >> My project is focused on nvlist. I'm improving and expanding its usage. N= vlist can be used in userland as well as in kernel. My goal is to establish c= ommunications between them via nvlist. That's why setting a fixed size or lo= oping doesn't satisfy me. It'll be some kind of IPC, not only for sysctl ofc= . >>=20 >> Best regards, >> Adam Starak >>=20 >> Dnia 29.07.2016 o godz. 18:05 Conrad Meyer <cem@freebsd.org> napisa=C5=82= (a): >>=20 >>>> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak <starak.adam@gmail.com> wr= ote: >>>> Hello! >>>>=20 >>>> My name is Adam. I participate in Google Summer of Code this year. I ca= me >>>> up with a big problem, which doesn't allow me to go further in my proje= ct. >>>>=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 d= ata >>>> (packed nvlist) into the user space. Is there any chance to pass data f= rom >>>> kernel to user space without knowing the size of it? >>>>=20 >>>> Right now, the implementation of __sysctl() function requests void poin= ter >>>> and size in order to get data. If allocated memory is too low, it retur= ns >>>> ENOMEM and you need to realloc the data. I wanted to avoid this situati= on. >>>=20 >>> Hey Adam, >>>=20 >>> That is the usual way to do it. Just curious =E2=80=94 why do you want t= o >>> 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?A7A09582-1A7D-45A3-B838-DE006F4F0FFA>