I should probably make it clearer as to what I mean by "bad" in the context of learning. I love to learn, I think learning is a very good thing. What I really meant is that something like this is something else you have to know, before using it. Which is not always convenient of efficient. Sometimes, it can be though . . .
On Thu, Oct 8, 2015 at 10:24 PM, William Hermans <yyrk...@gmail.com> wrote: > I do not see where it says mmap() is not so great. I do see where they > imply that mmap() is slower than mmap() + DMA. Which does, can, or > otherwise makes sense. The block copy idea is also pretty cool, but not > unique to iio. > > Here is my take on that set of slides: > > > 1. It is already written. > 2. It is very probably well thought out. > 3. It *is* yet another abstraction layer - Pluses, and minus. > 4. It is possibly supported. Good if so, bad if not. > 5. built into or can be built into the kernel if supported. > 6. Does use interrupts apparently, so will incur some kind of penalty. > > > Do I think it would be a cool / good thing to have in the kernel( > optionally ) ? No doubt - Yes. But would I use it ? I'm still not > convinced. But of course I see most, many or potentially all abstraction > layers as initially bad. Bad in that it is something else to learn / > understand. Bad that you get a lot of extra stuff typically built in that > you do not need. Which leads to bloat, and potential performance issues. > Also bad that sometimes it's more convenient to just use such an > abstraction layer, than fully understand it, which can lead to many, many > frustrating problems to solve. Very few abstraction layers convince me > otherwise, but I would guess that iio would be one to do so. If not, well > it is an interesting idea in of it's self to merit a second look, or four. > In fact, I already had thought iio was worth revisiting later, after > learning about it a few days ago - While exploring the BBB's ADC's. > > > On Thu, Oct 8, 2015 at 9:57 PM, Rick Mann <rm...@latencyzero.com> wrote: > >> There's a good slide presentation on why mmap() isn't so great, and they >> talk about the changes they made to the underlying driver and the ioctl() >> calls they added. libiio wraps those ioctl calls. >> >> >> http://events.linuxfoundation.org/sites/events/files/slides/iio_high_speed.pdf >> >> It's not what I envision a proper user-space API should look like, but >> it's much closer. I'm hoping I can write one on top of it, perhaps >> expanding iio. But when I refer to libiio, I'm also including the necessary >> updates to the iio driver system. >> >> > On Oct 8, 2015, at 21:33 , William Hermans <yyrk...@gmail.com> wrote: >> > >> > Yeah wow, I already said that, hah ! Too much going on . . . >> > >> > On Thu, Oct 8, 2015 at 9:32 PM, William Hermans <yyrk...@gmail.com> >> wrote: >> > Rick, also for what it's worth. Getting it compiled and working on a >> system does seem very straight forward and is shown step by step on that >> landing page you linked to. >> > >> > On Thu, Oct 8, 2015 at 9:30 PM, William Hermans <yyrk...@gmail.com> >> wrote: >> > Not sure I understand what you're getting at, but I've read that iio >> has at least two methods of access. Slow( sysfs ), and fast( mmap()). I'm >> not sure that the "fast" method driver exists for our board here in the >> context of the ADC's but certainly the slow sysfs method does. As for the >> rest of the things mentioned on that landing page you pasted a link to . . >> . it seems that he steps are very straight forward to get working, and >> indeed laid out on that exact page. >> > >> > What are you wanting to do with iio ? The idea of the library does >> intrigue me too. But I'm, not exactly sure I have the time to learn >> yet-another-abstraction-layer . . . >> > >> > On Thu, Oct 8, 2015 at 8:37 PM, Rick Mann <rm...@latencyzero.com> >> wrote: >> > libiio (along with additional stuff in the kernel that doesn't appear >> to be in 4.1.x-ti) provides for fast ADC access, rather than getting at it >> through sysfs. >> > >> > > On Oct 8, 2015, at 20:07 , William Hermans <yyrk...@gmail.com> wrote: >> > > >> > > I believe the ADC already uses a libiio "driver". Assuming it is the >> same thing I'm thinking of. But for instance when you load the ADC device >> tree file, it in turn loaded the iio:device0 object for the ADC. >> > > >> > > Like demonstrated on my blog post here: >> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/ >> > > >> > > With that said, I do not purport to know very much about it. Just >> that it exists. >> > > >> > > On Thu, Oct 8, 2015 at 7:06 PM, Rick Mann <rm...@latencyzero.com> >> wrote: >> > > What would it take to get libiio: >> > > >> > > >> https://wiki.analog.com/resources/tools-software/linux-software/libiio >> > > >> > > Into the BBB kernels? I think this would be amazing. >> > > >> > > >> > > -- >> > > Rick Mann >> > > rm...@latencyzero.com >> > > >> > > >> > > -- >> > > 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 beagleboard+unsubscr...@googlegroups.com. >> > > For more options, visit https://groups.google.com/d/optout. >> > > >> > > >> > > -- >> > > 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 beagleboard+unsubscr...@googlegroups.com. >> > > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > Rick Mann >> > rm...@latencyzero.com >> > >> > >> > -- >> > 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 beagleboard+unsubscr...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > >> > >> > -- >> > 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 beagleboard+unsubscr...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Rick Mann >> rm...@latencyzero.com >> >> >> -- >> 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 beagleboard+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
