@GBr I'm talking with the DesignNews folks about that. I've got a lot of material from my in-class seminars and embedded systems conference/embedded Linux conference talks. So, I suspect there will be more stuff later.
@GBr Folks have tried to use portage in the past for embedded distros with somewhat mixed results. Building everything from scratch is a good idea (Yocto uses that concept with bitbake), but it can take several days to build a complete distro with portage. It just depends on what you're used to I guess. I know folks who love portage. I've not had enough time on it to give an opinion one way or the other.
@GBr look in the kernel source tree in <kernel>/drivers/char/mem.c to see an example of remap_pfn_range. You can embedd that code in your own driver's mmap() callback from the file operations table. Then use the user-space mmap() call to call the driver to do the mapping. It's pretty straightforward once you look at the mem.c code.
@adse True, Yocto has a Linaro layer. So, you could build Linaro using Yocto's bitbake interface. Canonical uses Linaro to produce Ubuntu for the ARM. But, that's not Linaro's sole purpose. The concern I have for Yocto is that WindRiver, Mentor, MontaVista and Intell all have their hands in the mix. Cooperation among such fierce competitors is always an intersting thing to watch. Hopefully, they can continue to set aside their differences for the betterment of the community.
I reviewed Linaro for a while. It seems to be targeted only at making Ubuntu flavors running on ARM. I am also reviewing Yocto. They claim to have a Linaro layer as well. So I believe Yocto will be beneficial to leanr then as you can take advantage of Linaro via its layers?
@GBr For debugfs, you'd need to allocate the maximum buffer size and leave it there. Then you could have a size variable and the actual buffer as two separate values to handle the variable buffer part. Or, you could use remap_pfn_range() in the kernel and mmap() from user-space to just map the buffer directly into the user's address space. Debugfs is probably less prone to errors though.
Ahh, yes... The Yocto Project. The goal of Yocto is to be able to create the smallest kernel possible (yocto is the smallest unit in the metric system). They have been working to modify the OpenEmbedded bitbake system to make it more usable. So, for that, I applaud their efforts. Bitbake is terribly convoluted IMHO. So, anything that simplifies it is a step in the right direction. For building small distros, I think Yocto is a good project. But, I also like Linaro for ARM platforms. Either way, I don't think you can go wrong. But, Linaro has more of an ARM focus whereas Yocto has more of an x86 focus (it does ARM too, but not as strong an ARM platform as Linaro IMHO).
I've used SUSE in the past with great results. It tends to be KDE window manager centric. But, that's way better than Ubuntu's Ubiquity interface IMHO. The furture of SuSE is mirky at this point since the Attachmate acquisition. But, it's still a solid Distro.
Using /proc does not require the kernel to be compiled for debugging. Using debugfs does not require the debugging symbols either, but it's often not enabled in a mainline distro. Do the "mount" sequence from the charts and you'll find out quickly if debugfs was compiled in your kernel...
@jamesdeutch Debugfs is used to simply export data. Procfs is used if you want to exercise a callback into the kernel code. So, debugfs is realtively passive whereas procfs is very active. Procfs is also limited to just 1 page in memory (4K on 32-bit) whereas debugfs has no such limitation.
@mkreich Those two calls were just names. You could have called them "fred" and "barney" as long as you referece them properly in the module_init() and module_ext() calls correctly. Also, you'll compile them against a particular kernel. This uses the makefile approach of a one-line makefile and the make -C <path to kernel source> $PWD module
Distros to learn from include Linux Mint, Ubuntu, Fedora and OpenSuSE. I use Linux Mint myself because it's based on Ubuntu, but closer to the Debian look and feel for things like kernel configuration. BTW, the Linux kernel configuration command I was using is "make xconfig" from withing the Linux kernel sources (available from kernel.org).
someone mentioned several docs/books yesterday - included one to IBM Redbook about System Tap: SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems http://www.redbooks.ibm.com/abstracts/redp4469.html
AYE, x86, PowerPC, ARM (Openmoko, Beagleboard xM, iMX53). Using Openembedded as the Linux distribution (Angstrom & Poky), also Android (cupcake and Froyo on Openmoko, and the newest ones on the Freescale and TI boards). The PowerPC was on a Xilinx Virtex II FPGA
@email@example.com: Your hyperlink to The PTR Group worked perfectly for me. I actually clicked the hyperlink you provided in this chat window and it immediately took me to the PTR Group website. Could your IT organization somehow be blocking it?
several Linux systems - other than unreachable (e.g. TV, Blueray/DVD players, printers, etc) - several dev systems (Ubuntu), mostly virtual machines, also router, Patriot Memory Box Office (media player), and several unRAID systems
@Charles, presentation text has been running into the slide footer last three days. Difficult to read. Slightly smaller font would not be a problem and would make the last line or two readable. Content is great, would just like to read it all. Thx.
@Michael, Will we talk about kernel memory allocation during this week? Is it just malloc or is it fixed max size or is it maloc in userspace and a poiner or..? I'm thinking if iimplementing buffers that are allowed to vary alot in size.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.