Date: Wed, 16 Dec 2015 17:48:05 -0500 From: "Michael B. Eichorn" <ike@michaeleichorn.com> To: "Brian McGovern (bmcgover)" <bmcgover@cisco.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Standardizing digital, analog control points in the kernel? Message-ID: <1450306085.1103.45.camel@michaeleichorn.com> In-Reply-To: <b45ed5b6d5d74a35b6e7af0fdae84110@XCH-RTP-005.cisco.com> References: <b45ed5b6d5d74a35b6e7af0fdae84110@XCH-RTP-005.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 industrial 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1450306085.1103.45.camel>