From owner-freebsd-questions@freebsd.org Wed Dec 16 20:58:13 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 45DB1A49ECC for ; Wed, 16 Dec 2015 20:58:13 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (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 E34AF1255 for ; Wed, 16 Dec 2015 20:58:12 +0000 (UTC) (envelope-from bmcgover@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1536; q=dns/txt; s=iport; t=1450299492; x=1451509092; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=W3d0lvlxmTgCGE4BHYpjI0+91SfbxHVpRnnNsZhL680=; b=DvRvEreXJVcjAX/95zIyf0P34VbP9+o8rmMq6i2VQIpUEAWtcMyWD63S v10JuFAi8J4hIUnx2H4uPgCx8N2OJk9JCusdftcd61i3E3j55IOdis4kO ratFiudU6bV/u6z6k/X2e4sicpGcfYHvBP3wgextuKSUUNXp0s83tHbjl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgAyz3FW/4kNJK1egzpSc71yAQ2BY?= =?us-ascii?q?4c8OBQBAQEBAQEBfwuEOzoxIAE+QicEG4gnnCOheAEBCAIBIIZWiT+EfgWWfAG?= =?us-ascii?q?NQJ0hAR8BAUKEBIR8gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,438,1444694400"; d="scan'208";a="59645640" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 20:58:11 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBGKwAC0027385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Dec 2015 20:58:11 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Dec 2015 15:58: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; Wed, 16 Dec 2015 15:58:10 -0500 From: "Brian McGovern (bmcgover)" To: "freebsd-questions@freebsd.org" Subject: Standardizing digital, analog control points in the kernel? Thread-Topic: Standardizing digital, analog control points in the kernel? Thread-Index: AQHROER4ZNUKP3vhHEekUG/XZyb8Zg== Date: Wed, 16 Dec 2015 20:58:10 +0000 Message-ID: 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.131.65.20] 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: Wed, 16 Dec 2015 20:58:13 -0000 All, This is a question that I'm sure could span multiple lists and multiple p= erspectives; for example, there is probably significant input to be had fro= m -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 poin= ts, 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 o= n adding more devices which provide control points without needing to provi= de server or applications bits, UI writers and control applications can wor= ry about looking pretty and communicating through a language-independent in= terface, and so forth. The question I have is whether a.) Anyone is looking at doing something s= imilar, 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 thinkin= g of something like ucom, where the low-level hardware drivers plug in to i= t to provide a generic user interface on top)? -B =