On 1/27/2014 11:08 PM, John Syn wrote:
> 
> From:  William Hermans <[email protected]>
> 
>> I think Charles is doing something that is useful. But I have also never 
>> heard
>> of netlink, which also sounds very interesting and seems like something akin
>> to IPC between user / kernel modes. However, I think both could be useful for
>> different situations.
> 
> I’m proposing a solution that solves several problems not addressed by
> Device Tree Overlays. For example, sysfs is simplex and user space apps must
> poll the sysfs interface for changes on the kernel side. IOCTL has the same
> problem. I know that Charles is also working with Xenomai and this solution
> that could possible provide a two way interface to Xenomai drivers. Here is
> an article that helps explain the benefits of Netlink over IOCTL and by
> extension sysfs. 
> 
> http://www.linuxjournal.com/article/7356

I'll be the first to admit that device tree overlays are not the best
way to handle dynamic hardware definition.  Device tree is fine, but it
is intended to be static.  Trying to press device tree into use as a
poor man's hot-plug is IMHO generally a fools errand, and I've said so
here before.  Not only will this never get pulled upstream, but there
are issues maintaining the code (see for instance the 3.12 kernel that
doesn't yet have a working cape manager).

That said, device tree overlays is what we have for the moment, and all
I'm trying to do is provide a way for individuals to access the many
various hardware features of the BeagleBone Black without having to
craft their own device trees or write kernel drivers.  The limitations
with sysfs you're referring to are valid, but not really related to the
problem I'm trying to solve.  I'm not mandating you use sysfs to access
the GPIO pins, for example, I'm just providing a way to setup all the
I/O without having to iterate through exporting each one individually
(which leaves no way to easily control pin multiplexing) or crafting a
device tree of your own.  Once enabled and setup, the hardware can be
controlled via the usual methods, sysfs or otherwise.  The UARTs get
/dev/ entries, for instance, and I memory map the GPIO registers and
communicate with them directly via the PRU and hard real-time Xenomai tasks.

-- 
Charles Steinkuehler
[email protected]

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to