From owner-freebsd-hackers@freebsd.org Fri Jul 29 16:55:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21A34BA7DDB for ; Fri, 29 Jul 2016 16:55:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73191792 for ; Fri, 29 Jul 2016 16:55:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id f6so113308195ith.0 for ; Fri, 29 Jul 2016 09:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=kQxXCLTPF1+GhFXQLrjCmieLCUIKjLvgfm7pN1WJsjY=; b=YENu939FhcxTsqdaLAgnwaD6StwdZceKAfNTmbC3m1eG6zPcTuFP/UcSb2p5GwwzYn +K+AWw62B9KkLX7fasNIoncr4McBG0NyrIflVlHMV8fNU24YB/qtQFXyKTVYOSzzNMxk srpFdr+AftFImaqw8BnFr4ttJ1GUN8hF1nM+2AJK0RS0rogln7g7Yyt0w2GZwiU6KVwz 5Z4jIMnZStu84n17EFU5mU6vkkFCtrTdwo98Kw9eh6ekNBwPxIbHsMI1NLvjPhACrWis ld6H3r34nldqAakNd4ToS+wBd1pQDN3awjBr6Fq/UZCKFVRsQkdljmtpb6rGce9Z0HwM WuQA== X-Gm-Message-State: AEkoouu7j4OYl1ttfLouZeMCta2dEQuwSaxgdiFpc0fbSCsjhXDlzUybueYtMxbwQeoK9w== X-Received: by 10.36.189.7 with SMTP id x7mr7964317ite.97.1469811350333; Fri, 29 Jul 2016 09:55:50 -0700 (PDT) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com. [209.85.214.41]) by smtp.gmail.com with ESMTPSA id f9sm7529740ioi.2.2016.07.29.09.55.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 09:55:50 -0700 (PDT) Received: by mail-it0-f41.google.com with SMTP id u186so198082180ita.0 for ; Fri, 29 Jul 2016 09:55:50 -0700 (PDT) X-Received: by 10.36.189.7 with SMTP id x7mr7964291ite.97.1469811349884; Fri, 29 Jul 2016 09:55:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.233.67 with HTTP; Fri, 29 Jul 2016 09:55:49 -0700 (PDT) In-Reply-To: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> References: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> From: Conrad Meyer Date: Fri, 29 Jul 2016 09:55:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Modify user space from kernel. To: Adam Starak Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:55:57 -0000 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 wrote: > 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= 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 napisa=C5=82= (a): > >>> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wr= ote: >>> Hello! >>> >>> 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. >>> >>> 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 f= rom >>> kernel to user space without knowing the size of it? >>> >>> 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. >> >> Hey Adam, >> >> That is the usual way to do it. Just curious =E2=80=94 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