On 1/27/14, 9:43 PM, "Charles Steinkuehler" <[email protected]> wrote:
>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. Hi Charles, I understand where you are coming from and I don¹t want to overly complicate things for you. I only made the proposal because I see several configuration tools migrating to NetLink. Consider nftables [1] which replaces iptables, iw [2] replaces iwconfig, iproute2 [3] replaces net-tools (ifconfig, netstat, route, etc) and many more. [1] http://netfilter.org/projects/nftables/ [2] http://wireless.kernel.org/en/users/Documentation/iw [3] http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2 I think what you propose is a good interim solution, but perhaps the Beagle community should start thinking about how to make I/O use on the BBB as simple as Arduino. At the moment, it is far too complicated for new users. Regards, John > >-- >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. -- 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.
