I'm into something about writing a "Mock GPU driver" for Linux based systems. What I mean is that, simply I want to write a driver (Behind X-server obviously) to answer X's API calls with some debugging messages.
In other words I want to fool Linux about having an actual GPU. So I can make a test-bed for GUI-accelerated packages in console based systems.
Right now, if I execute a GUI-accelerated package in Linux console based systems; it'll simply dies due to lack of a real GPU (or a GPU driver better I'd say).
So I want to know:
Is it even possible? (Writing a GPU driver to fool Linux about having an actual GPU)
What resources do you recommend before getting my hands dirty in code?
Is there any similar projects around the net?
PS: I'm an experienced ANSI-C programmer but I don't have any clue in real Kernel/Driver development under *nix (read some tutorials about USB driver development though), so any resources about these areas will be really appreciated as well. Thanks in advance.
What you are looking for is actually part of Xorg server suite, and it is called Xvfb (virtual framebuffer).
If you're not afraid of a bit complex bash, you can take a look at Gentoo's virtualx.eclass for an use example (we use it to run tests which require X11).
A good place to start is the Mesa project - it implements OpenGL in software. It has a way to trick the OS into thinking that it is the OpenGL driver.
Related
I am just learning linux kernel programming with the LINUX KERNEL DEVELOPMENT book(I am beginner linux kernel programming but not on linux programming). It is possible to test programs in a kernel machine with VMware viritual on Ubuntu without damage my system ?
Yes you can safely test kernel modules on a virtual machine!
I'll give you some links that may help:
watch this site
http://free-electrons.com/
in particular this book:
http://free-electrons.com/doc/books/ldd3.pdf
Also this guide:
http://www.tldp.org/HOWTO/Module-HOWTO/
An embedded distro is even better
An Ubuntu guest is fine, but I prefer to keep things minimal and use an embedded distro, as this will make things:
simpler and easier to understand and control
faster
In particular, I recommend using:
Buildroot, which is highly configurable, documented and maintained, also builds host QEMU so easy to patch it up (e.g. to add your own devices since out-of-tree devices are not possible yet ?)
QEMU emulator: small comprehensible source, ARM support, official Android emulator, kernel GDB support
Embedded distros can generate rootfs images smaller than 10MiB, and it becomes possible to understand the entire userland setup, which will make it easier to focus on the kernel.
I have made a setup to make everything as automated as possible: https://github.com/cirosantilli/linux-kernel-module-cheat
I've been using a VM for a long time for Linux kernel programming and I've never had any problem. Actually, if you manage to violate the protections of a VM then you will probably be hired by Oracle or VMWare :D
However, I recommend you to read this post: https://security.stackexchange.com/questions/23452/is-it-safe-to-use-virtual-machines-when-examining-malware
OK, so I recently purchased an Acer T232HL touch screen display to hook up to my Macbook Pro as a secondary monitor. To give you an idea, here's my setup.
OS X doesn't support this monitor in any way, so as you can see in the screenshot I'm actually running Windows 8 through VMware, which proxies the USB connection to Windows perfectly where the touch events are supported. But obviously this isn't ideal.
There's at least one 3rd party driver for OS X that looked sort of promising, but it doesn't seem to support multitouch from this device, it's expensive, and generally was a pain to get working to the small degree it was. There's also mt4j but best I could tell after running their examples, it doesn't support this device at all.
So here's my question: what exactly am I in for if I wanted to write a driver for this thing? I'm mostly a web developer with years of experience with Ruby, Objective-C (and a little C), Javascript, etc. I have never ventured into any kind of hardware programming, so from the surface this feels like an interesting while intimidating challenge.
I know at some level I need to read data from USB. I know this will probably mean trying to reverse engineer whatever protocol they're using for the touch events (is it possible this will be entirely custom?). However I haven't got a clue where to start - would this be a kernel extension? In C, I presume? Would love a high level overview of the moving parts involved here.
Ultimately I want to use the touch screen to drive a specialized web interface (running in Chrome), so ideally I could proxy the touch events straight to Chrome without the OS actually moving the mouse cursor to the touch location (so have the UI behave just as it would on an iPad), but regardless of whether this is technically possible, I'd love to start with just getting something working.
You're going to want to start with Apple's I/O Kit documentation. You can hope that the touchscreen isn't completely custom, though there must be some part that's not standard USB HID, or it would work already. If there are any linux (or other open source) drivers available, you'll have the advantage that somebody already did some of the reverse engineering for you. As an alternative to the I/O Kit, you might also want to look into libusb, which might make your brain hurt less when getting started. If you end up needing to write a kext, that might not help you anymore, though.
As to some of your specific questions:
would this be a kernel extension?
Maybe, maybe not. I'm not really up on the Mac OS X driver situation, but I did write some totally user-space USB code for OS X many years ago. Maybe you'll be as lucky.
In C, I presume?
Probably. I/O Kit itself is written in a subset of C++, so you can probably use that too, if you prefer.
is it possible this will be entirely custom?
Unfortunately, yes, it's possible.
Good luck!
I'm in my third year studying computer science, so I should probably actually know the answer to this question already, but nonetheless, I don't. Anyway, I'm taking the OS course for my degree currently and we've been been covering a lot of new programming concepts like signals, semaphores, and threads in C. Unfortunately, my prof is covering all of these in a Linux/OS X perspective. What this means for me, being on a 64-bit windows machine, is that things like installing an alarm signal, or using semaphores and pthreads won't compile or run on my machine (as far as I can tell).
Anyway, currently I have just been doing my assignments in a VM running Linux, which has worked well so far, but I much prefer the Windows environment for coding.
So, after that heavy winded introduction, my question is, as you might have already guessed, is there a way to code with all these features (alarm signals, semaphores, pthreads, etc.) and be able to compile and test them in Windows? I'm fully aware that the Windows OS does not support the alarm signal and has limited POSIX capability, but I've heard rumors tossed around about cygwin (which I did try to get to work, but not very hard :P) and micro Linux kernels that you can run in the background to use these features.
Anyway, if anyone can give me maybe a list of options they would recommend (preferably not stick with your VM, even though I'm thinking that might be my best option) and maybe some tips, pros, cons, maybe a setup guide, or really any non-empty subset of these options I would really appreciate it. Also, before you ask, we have to use C and the above mentioned programming features in our assignments, so there's no switch to Java or code in win32 option unfortunately :(
Thanks in advance to anyone who can lend some words of wisdom :)
The basic principles are all there in Windows but done differently. And I recommend that, if you're going to program for Windows, you do this in the Windows API rather than through an emulation layer like Cygwin. If anything at all you'll quickly learn that different operating systems take a different approach to signalling and process handling.
First thing to be aware of is that threads are much more lightweight in Windows while processes are significantly more heavyweight. With that in mind Windows programs operate most efficiently when using threads. There is the concept of the CriticalSection that you should become very familiar with. And the Semaphore Object. Keep reading the API and you'll find a wealth of information about these topics - the Microsoft documentation is actually rather good. A key thing to understand about the Windows API is that you almost always have to "create/get" a new object (and obtain a handle) before you can use it. And Windows doesn't like programs having too many handles.
Personally I like the POSIX API and have a love for Linux. But I do appreciate that if you want to do things properly in Windows you should be using the Windows OS API - they have thought about this carefully even though the results and methods may be somewhat different.
PS Windows doesn't have the "alarm". It is perhaps the single most prohibitive barrier to simply porting Unix/Linux utilities to Windows. (That and the fact that Windows processes have to "bootstrap" Internet/socket support before using it whereas Linux processes are good to go).
There's MinGW-w64 - a Windows port of the GNU toolchain - and Pthreads-win32, a POSIX wrapper of the Windows threading API.
I'm using these via the mingw64-x86_64 Cygwin cross-compiler packages (which currently provide the somewhat dated gcc 4.5.3) instead of directly for two reasons: First, I need other stuff from the GNU toolbox, and second because of the package manager.
I'm not sure to what degree Pthreads-win32 complies to POSIX, but I can confirm that LLVM and Clang both compile with this setup.
Can anyone suggest some good references for writing a touchpad driver for linux. Where would I get hardware documentation from. I have read most of the linux device driver books and now I want to take it to the next level.
Are you sure there is no current support for your sentelic in linux kernel? Take a look at Documentation/input/sentelic.txt in Linux source code. If it does not give you direct answers, you'll be able to see how to implement something similar instead. Take a look at its sources, too.
Moreover, if you are not really, really familiar with Linux kernel programming yet, you can read Linux Device Drivers (freely available), Linux Kernel Mode Programming (available, too) and Linux Kernel Development. Some of those sources are somewhat dated, but will give you right ideas about development.
I like programming challenges, and writing a kernel seems a programming challenge.
Unfortunately, kernels are particularly hard to test because they are basically the core of operating systems and so they can't be easily ran on top of an operating system.
However, I know about applications called Virtual Machines that can emulate computer hardware.
What is the easiest/best way to develop and test kernels(C+Assembly) using Virtual Machines?
While BOCHS seems to be better at letting you know when something goes horribly wrong with your pet OS... it is very slooooow! I use VirtualPC for general purpose testing and BOCHS when things get murky.
Also, you will more than likely be booting the OS every 2 minutes, so it helps to have some sort of automated way to build a boot image & fire off the Virtual PC.
I built a GRUB boot floppy image with all the necessary stuff to get it to boot the Kernel.Bin from the root. I use a batch file to copy this file to the virtual project directory, use FAT Image Generator to copy my kernel to the image. Then just launch the VirtualPC project. Vola!
Excerpt from my batch file:
COPY Images\Base.vfd Images\Boot.vfd /Y
fat_imgen.exe modify Images\Boot.vfd -f Source\Bin\KERNEL.BIN
COPY Images\Boot.vfd Emulators\VirtualPC\ /Y
START Emulators\VirtualPC\MyOS.vmc
One last suggestion: Set the VirtualPC process priority to low - trust me on this one!
I'd be happy to exchange some code!
Tools: DGJPP, NASM, GRUB.
Code: osdev.org, osdever.net
You might be interested in looking at HelenOS. Its a from scratch microkernel that has been ported to many architectures (boots just fine on bare metal) developed using simulators such as Simics and QEMU.
We use a static grub that is copied to the final ISO during the build process. Some things just have to be that way until the OS becomes self hosting. I highly recommend NOT implementing your own userspace C library unless you really do want to do everything from scratch .. you'll become self hosting much sooner :)
Though Simics is non-free, I highly recommend it (and its built in debugging/profiling tools) while making your kernel. Once you have some kind of kernel console and logger in place, QEMU does a very nice job.
It's straightforward. Set up a virtual machine, write your kernel, copy it to the virtual machine, boot the virtual machine.
You'll need to be more specific if you want more specific advice.
Probably just setting up a machine (x86, I guess), and then investigate exactly how it behaves during boot. There should be one or more files in the host machine's file system that act as the virtual machine's file system, and then you'd need to put some boot sector information there that causes your in-development kernel to boot.
That would of course mean that the build system on the host has a way to write the kernel to the virtual machine's file system, which might vary in difficulty.
Picking one at random, bochs seems to support editing the boot media from the outside using standard tools like dd etc.
The first question that you need to ask yourself is what hardware architecture are you targeting? I'll assume for the sake of this discussion that you are targeting the IA_32 architecture, which would probably be a wise choice as there is plenty of readily-available documentation on that processor.
If you're truly serious about this undertaking, then you will definitely want to run your debug/code/build/deploy cycle against an emulator or VM. Someone mentioned BOCHS, which is very popular. If emulation speed is your thing, there is also an emulator called Qemu that is faster than BOCHS.
I'd suggest that your development environment run under Linux or Windows, which again would probably be a wise choice due to the available documentation for those dev environments.
Make is your friend. Use it to automate the build/execute process. I'd advise you to pick your toolsets/compilers up front, and spend some time learning them well. It will save you in the long run.