<snip>
One obstacle, here, will be low-level hardware
configuration. While in the case of Aruduino, you have a simple
interface which interacts directly with the bare metal to give you, say
I2C acesss, on Linux things are more complicated. There are a lot of moving parts in low-level
configuration, between configuration of the SPI controller to the
pinmuxing to multiplexing the bus between multiple drivers, there are
lots of moving parts to get interacting before the ease of the Ardunio
will be realized on the BeagleBone.
This is something that really will need to be worked on. Currently, it
seems few people realize the importance of, say, being able to bring up
an SPI interface with spidev without rebooting. But this is necesary if
the BeagleBone is to reach the exposure of Arduino.
Just what we needed, a use case! You see, once DT conversion is complete
and it becomes that standard way to boot Beagle*, it doesn't solve this
"bring up an SPI interface with spidev _without rebooting_ problem. A
complete DT solution does allow you to edit your dts, define your SPI
slave devices, and reboot an unmodified kernel to have those slaves bind
to the spidev protocol driver then you're off and running. As an
incremental step, this is vastly simpler for many things since modifying
the kernel scares people to no end.
So, let's talk no reboot...
Today you have the kernel interface spi_new_device() such that one can
load a device specific module, register an additional spi_device with
the appropriate parameters, and then use the userspace bind/unbind
interface to bind it with the spidev protocol driver.
But you're going to tell me that's icky and sure, it is icky to the
Arduino crowd. It does hint at a short-term way to manage this for the
Beagle community though in that you *do* have all raw kernel interfaces
exported in order to instantiate things at runtime.
That said, the proper solution is to add a SPI subsystem feature in the
kernel that exposes a new userspace API in the SPI sysfs hierarchy that
allows one to hotplug a spi_device instance via a sysfs entry. IMHO,
that's the only thing missing from the kernel POV and I guess I'll add
it to my TODO list.
The rest is up to the userspace javascript folks. 
Anyways, it would be nice if we could start a discussion of what is
necessary to make this process more dynamic. Sure, dynamically binding
and unbinding drivers while fooling with pinmux after boot isn't trivial,
but it's not impossible. In fact, I believe that most of the kernel
interfaces already exist in some form or another (e.g. pinmuxing can be
done at runtime through debugfs; we'd probably want a better defined
interface though). Thoughts anyone?
The pinctl subsystem with the optional pinmux driver backend will deprecate
the omap-specific pinmux interface, so you can check off the "better
defined interface part". The rest is an exercise in userspace code.
-Matt