Hi Gerg, I want know why this two commit id is not backported v3.10 1 . sched_clock: Make ARM's sched_clock generic for all architectures 2 . arch_timer: Move to generic sched_clock framework where as the 1 commit is already backported v3.11 I back ported these two commit id 3.10 arm cortex-a9 boot's fine, Is there any issue with this commit's if it is backported to v3.10. Regards,
Hello there, After reading LDD and LKD, I feel ready to start some actual kernel hacking. Therefore I wanted to ask you what environment I should use in the beginning. I have several options, but I'm not sure on which one to set up my workspace: - I could develop directly on and against my main machines (desktop/laptop) – This is probably not a good idea, since they are used in „production“ and I don't want to mess things up there - I could go with a virtual machine on one of my main machines – But I'm not quite sure whether the hardware-abstraction will give me troubles when hacking on hardware drivers (which I want to start with) - I could also use my Raspberry Pi – I'm only afraid that the slightly different environment (SD card instead of hard disk, ARM instead of x86, limited I/O) could turn out to be a larger obstacle than I thought - I have some pretty old stand alone desktops which I could use – But the hardware is so old (2004ish) I think my preference is the Raspberry Pi, because I would work on actual modern hardware without worrying about messing things up. Are there some drawbacks I'm not considering? Or am I just overthinking this? What did you use in the beginning? Best regards, Philipp
------ Original Message ------ From: "Philipp Muhoray" <philipp.muhoray@gmail.com> To: kernelnewbies@kernelnewbies.org Sent: 11/1/2014 9:41:36 PM Subject: Choosing the right environment
Hello there,
After reading LDD and LKD, I feel ready to start some actual kernel hacking. Therefore I wanted to ask you what environment I should use in the beginning. I have several options, but I'm not sure on which one to set up my workspace:
- I could develop directly on and against my main machines (desktop/laptop) – This is probably not a good idea, since they are used in „production“ and I don't want to mess things up there
- I could go with a virtual machine on one of my main machines – But I'm not quite sure whether the hardware-abstraction will give me troubles when hacking on hardware drivers (which I want to start with)
- I could also use my Raspberry Pi – I'm only afraid that the slightly different environment (SD card instead of hard disk, ARM instead of x86, limited I/O) could turn out to be a larger obstacle than I thought
- I have some pretty old stand alone desktops which I could use – But the hardware is so old (2004ish)
I think my preference is the Raspberry Pi, because I would work on actual modern hardware without worrying about messing things up. Are there some drawbacks I'm not considering? Or am I just overthinking this? What did you use in the beginning?
Best regards,
Philipp
Raspberry Pi is better option since you can add customization by using unallocated pin.
Best regards, Gusman
- I could go with a virtual machine on one of my main machines – But I'm not quite sure whether the hardware-abstraction will give me troubles when hacking on hardware drivers (which I want to start with)
Developing on virtual machine(you can try VirtualBox) is the best option, if you intend to hack into device drivers. Working on the Raspberry Pi, would also involve porting, cross-compiling issues. If you are comfortable with them, then you can try that but LDD and LKD aims more to x86 platform drivers than any other platform. Regards, Saket Sinha
On Tue, 18 Nov 2014 20:54:05 +0530, somebody said:
- I could go with a virtual machine on one of my main machines – But I'm not quite sure whether the hardware-abstraction will give me troubles when hacking on hardware drivers (which I want to start with)
If you're hacking at hardware drivers, you *hopefully* have the hardware to test with. At that point, the *biggest* question is "What does that hardware plug into?". If it's a USB device, you have lots of options for the host hardware. If it's a PCI card, you need a system that has PCI slots. If you're hacking on the Raspberri Pi camera driver, you're kind of going to need a Pi. And so on....
Am 2014-11-18 um 16:36 schrieb Valdis.Kletnieks@vt.edu:
On Tue, 18 Nov 2014 20:54:05 +0530, somebody said:
- I could go with a virtual machine on one of my main machines – But I'm not quite sure whether the hardware-abstraction will give me troubles when hacking on hardware drivers (which I want to start with) If you're hacking at hardware drivers, you *hopefully* have the hardware to test with. At that point, the *biggest* question is "What does that hardware plug into?". If it's a USB device, you have lots of options for the host hardware. If it's a PCI card, you need a system that has PCI slots. If you're hacking on the Raspberri Pi camera driver, you're kind of going to need a Pi. And so on....
Actually I wanted to hack on hardware I don't have so that you guys could test it, but your idea seems good as well. Just kidding, of course I'll check first what HW I have laying around; then I play with it. By now I'm developing in VirtualBox, doing the Eudyptula challenge. I think it's the most convenient option so far. And thanks for answering me. I almost thought my question was too stupid/naive to be answered.
participants (5)
-
Gusman Dharma Putra -
Hemanth Kumar -
Philipp Muhoray -
Saket Sinha -
Valdis.Kletnieks＠vt.edu