From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 04:07:35 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E5C4EC1 for ; Sun, 15 Feb 2015 04:07:35 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 66E8A1C1 for ; Sun, 15 Feb 2015 04:07:35 +0000 (UTC) Received: by mail-yk0-f181.google.com with SMTP id 200so10755519ykr.12 for ; Sat, 14 Feb 2015 20:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qoBf0MS5adPSdAHrQ2fyr/pv+36DnQL+yn49Z6Gkw7c=; b=fbLGfbGJTxdzjdA/XldZmkWmBa209ZUiySvpKTNaAb8tacx87iAV36YaKpST/PPhMd mN1AR8MF6Y6DDbKCyrtAkcuxNUeO8P5JRGEuwjkSsXqtV8vLWF8+nRu2myArLKSBn86g LBSsBoMW2t4SQRV1rg10VWxRlcf9Nb+7UvxIQwBERGeCM8WpvBSUwVbWTxPyxKZIyNsp ttCkefYHDoqvX6qaMeNusYjRvezfpK77rZczTgOT+2Khk0x1f8N70KdH+kfYEbyTP808 ja+oO+hFbJ0W3jMcFhVpyvDQAGiTV0l85xGORzd4GEURCAylDmsk5+HhuxxhlTf+3JmZ POeA== X-Received: by 10.236.37.99 with SMTP id x63mr12881445yha.108.1423973253974; Sat, 14 Feb 2015 20:07:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.118.13 with HTTP; Sat, 14 Feb 2015 20:07:02 -0800 (PST) In-Reply-To: References: From: Yue Chen Date: Sat, 14 Feb 2015 23:07:02 -0500 Message-ID: Subject: Re: Suggestions for communication between FreeBSD user-space and kernel modules To: Ryan Stone Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 04:07:35 -0000 Thank you so much for replying. I forgot to mention that I need to send several Megabytes of structured "uint64_t" data. Is the "ioctls" approach good to handle this situation, or "mmap" is better? And for > "2) In the cdevsw structure, implement the ioctl method. This method will be called when the userland application calls ioctl(2)", the ioctl method will be automatically called, right? Thanks again. On Sat, Feb 14, 2015 at 9:53 PM, Ryan Stone wrote: > The two main interfaces for passing data between userland and the > kernel in FreeBSD are syctls and ioctls (there are others but their > use is rather specialized). > > sysctls are typically the simplest to set up, but aren't well suited > for passing around complex structured data. sysctls are very easy to > read and write from the command line, though, so they're popular for > exposing individual tuning parameters. The kernel interfaces for > creating sysctls are documented here: > > https://www.freebsd.org/cgi/man.cgi?query=sysctl&apropos=0&sektion=9&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > > https://www.freebsd.org/cgi/man.cgi?query=sysctl_add_oid&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > > > ioctls are a little more complicated to use, but are more flexible in > what kind of data they can accept. The man pages for this aren't as > good, but the basic steps are: > > 1) Create a device node in /dev by calling make_dev() > ( > https://www.freebsd.org/cgi/man.cgi?query=make_dev&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > ) > 2) In your userland application, call open(2) to get a file descriptor > and then ioctl(2) on the file descriptor to pass data to/from the > kernel > 2) In the cdevsw structure, implement the ioctl method. This method > will be called when the userland application calls ioctl(2) > 3) The request argument using the macros in . _IOW is > for ioctls that send data from userland to the kernel, _IOR is for > ioctls that fetch data from the kernel and _IOWR is for ioctls that > both send data from userland to the kernel and fetch data back in a > single call. Try to use unique values for your ioctls requests. > > > > Some of the other possible methods include include mmap, which can be > used to create shared memory between the kernel and userland; > netgraph, which is networking-focused interface; and sockets, which > can be a tricky interface to use correctly in the kernel. >