From owner-freebsd-questions@freebsd.org Thu Dec 17 14:54:19 2015 Return-Path: Delivered-To: freebsd-questions@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 5A1FDA4A37B for ; Thu, 17 Dec 2015 14:54:19 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28670143F for ; Thu, 17 Dec 2015 14:54:18 +0000 (UTC) (envelope-from bmcgover@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5225; q=dns/txt; s=iport; t=1450364059; x=1451573659; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K7GwCDg9pkTCipwJjguQV651/08hFakmPcxUj1M/538=; b=mXtW6uO1kAtXm5qOqJTg+Hfo+7y7Ix1Tp8P+5zwxiCvjEOcEe/MbhKU6 mtQZdVZVZnC0dy7dCjV5IH/cPccS+hxzLDNwc24uB9DoAQlZFqBQXXPvZ Pdh34oGwNNoCFEPe+O66QKU8UaFbNZ9sHixRJ0TwLn/erzbaec4Cwop+M k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAXzHJW/5pdJa1egzpSbQa9awENg?= =?us-ascii?q?WKGDQKBNjgUAQEBAQEBAYEKhDQBAQEEOjEeAgEIEQQBAQEeEDIdCAIEARIIiCe?= =?us-ascii?q?9PwEBAQEBAQEBAQEBAQEBAQEBARuGVoR+hD4EhH4Fh12PIAGNQJ0jASABAUKCE?= =?us-ascii?q?R2BVnKDdIEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,441,1444694400"; d="scan'208";a="56437053" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2015 14:54:11 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tBHEsBBO024028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2015 14:54:11 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Dec 2015 09:54:10 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Thu, 17 Dec 2015 09:54:10 -0500 From: "Brian McGovern (bmcgover)" To: "Michael B. Eichorn" , "freebsd-questions@freebsd.org" Subject: RE: Standardizing digital, analog control points in the kernel? Thread-Topic: Standardizing digital, analog control points in the kernel? Thread-Index: AQHROER4ZNUKP3vhHEekUG/XZyb8Zp7Oiu+AgACx0wA= Date: Thu, 17 Dec 2015 14:54:10 +0000 Message-ID: <7a59c80486f6471a84f5e87ac3485aa4@XCH-RTP-005.cisco.com> References: , <1450306085.1103.45.camel@michaeleichorn.com> In-Reply-To: <1450306085.1103.45.camel@michaeleichorn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.249.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:54:19 -0000 >________________________________________ >From: Michael B. Eichorn [ike@michaeleichorn.com] >Sent: Wednesday, December 16, 2015 5:48 PM >To: Brian McGovern (bmcgover); freebsd-questions@freebsd.org >Subject: Re: Standardizing digital, analog control points in the kernel? > >On Wed, 2015-12-16 at 20:58 +0000, Brian McGovern (bmcgover) wrote: >> All, >> This is a question that I'm sure could span multiple lists and >> multiple perspectives; for example, there is probably significant >> input to be had from -arm. However, I'm going to ask here to try to >> get the biggest collection of feedback. >> >> I've been working with a number of I/O capable devices for awhile - >> Pis, Beaglebones, for example, but also a lot of the USB Velleman >> boards, X-10, Insteon, etc. >> >> I've been contemplating a project to consolidate the various >> control points, with a certain amount of metadata, at the userland >> level and provide a standardized interface - most likely through a >> network socket via XML, some form of HTTP, a combination, or >> something else entirely. The reason would be to sufficiently abstract >> the various layers so that domain experts could focus on specific >> areas - for example, device driver writers could focus on adding more >> devices which provide control points without needing to provide >> server or applications bits, UI writers and control applications can >> worry about looking pretty and communicating through a language- >> independent interface, and so forth. >> >> The question I have is whether a.) Anyone is looking at doing >> something similar, and b.) if anyone is looking at doing something >> similar inside the kernel as a device driver, filesystem, or other >> variation (e.g. I'm thinking of something like ucom, where the low- >> level hardware drivers plug in to it to provide a generic user >> interface on top)? >> >> -B > >This is an interesting idea and I think that a unified method for >handling I/O would be very useful. It sounds like you are mostly >talking about maker, home automation, and internet-of-things type devices,= but it might have applications for scientific data acquisition and industr= ial control as well. >Also such a stack should support realtime computing. Interestingly it >appears that RTLinux died in 2011 so this could be an advantage for >FreeBSD in IoT and Maker devices. Realtime is, in my opinion as a >mechanical engineer, essential for any system that might control an >appliance/drone/robot, or for that matter data acquisition in general. > >That said, I do like the idea of separating the application logic and >the gui out from the details of the individual devices being used. My commercial work experience in the space was commercial building automati= on via Andover Controls devices back in the late 80s/early 90s (Andover has= since been acquired by Schnider electric) which ran over BACnet. What I'm hoping to do as the primary goal of my work is to define a network= layer protocol for the data exchage. That way, if drivers and userland var= y on FreeBSD vs. Linux vs. fill-in-another-OS, it theoretically doesn't mat= ter - a Linux based UI should be able to control a protocol compliant Raspb= ian system, or a FreeBSD box. Similarly, if you want to use C, or C++, or P= ython, or Java, or fill-in-another-language to connect to the network and c= hat with a device, it doesn't matter. At the end of the day, users should b= e able to select best-in-class for the various layers, and plug it together= . In designing, I'm stuck at the point of having a fairly common layer pointi= ng at the network, and bolt-on "device drivers" for the various flavors of = I/O. For example, the Beaglebone ADC has a driver which operates via sysctl= (); the digital pins use GPIO. Vellemen USB boards, X-10, and Insteon inter= faces are basically USB serial streams, each with their own proprietary com= mand/response protocols. Hence, as a secondary goal, I'm curious to explore setting up a common fram= e work for the typical types of I/O one typically sees in this space - Digi= tal I/O, Analog I/O, potentially things like driver enforced tri-state. In terms of "Real Time", I dislike the term mostly because it becomes terri= bly abused to mean what the engineer wants it to mean. Using the definition= of "of or relating to a system in which input data is processed within mil= liseconds so that it is available virtually immediately as feedback, e.g., = in a missile guidance or airline booking system." (Google definition, shoul= d you want to trace my steps), its not impossible, but its well outside the= scope. Most operating systems have large, asynchronous components, and the= network will have all kinds of random variations on timing. Unless you man= aged everything on and off the wire, you may get that kind of response most= of the time, maybe even every time, but I doubt it'll be warrantied. Further, "correct" systems have to have other considerations - power on sta= tes, loss-of-control failsafes, and so on, most of which are either above o= r below the layer interfaces. -B=