* sched_clock generic for all architectures
@ 2014-10-30 13:12 Hemanth Kumar
2014-11-01 14:41 ` Choosing the right environment Philipp Muhoray
0 siblings, 1 reply; 6+ messages in thread
From: Hemanth Kumar @ 2014-10-30 13:12 UTC (permalink / raw)
To: kernelnewbies
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,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Choosing the right environment
2014-10-30 13:12 sched_clock generic for all architectures Hemanth Kumar
@ 2014-11-01 14:41 ` Philipp Muhoray
2014-11-18 15:03 ` Gusman Dharma Putra
0 siblings, 1 reply; 6+ messages in thread
From: Philipp Muhoray @ 2014-11-01 14:41 UTC (permalink / raw)
To: kernelnewbies
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141101/e0a402b9/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Choosing the right environment
2014-11-01 14:41 ` Choosing the right environment Philipp Muhoray
@ 2014-11-18 15:03 ` Gusman Dharma Putra
2014-11-18 15:24 ` Saket Sinha
0 siblings, 1 reply; 6+ messages in thread
From: Gusman Dharma Putra @ 2014-11-18 15:03 UTC (permalink / raw)
To: kernelnewbies
------ Original Message ------
From: "Philipp Muhoray" <philipp.muhoray@gmail.com>
To: kernelnewbies at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141118/8881e750/attachment-0001.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Choosing the right environment
2014-11-18 15:03 ` Gusman Dharma Putra
@ 2014-11-18 15:24 ` Saket Sinha
2014-11-18 15:36 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 6+ messages in thread
From: Saket Sinha @ 2014-11-18 15:24 UTC (permalink / raw)
To: kernelnewbies
> - 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Choosing the right environment
2014-11-18 15:24 ` Saket Sinha
@ 2014-11-18 15:36 ` Valdis.Kletnieks at vt.edu
2014-11-18 16:24 ` Philipp Muhoray
0 siblings, 1 reply; 6+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-11-18 15:36 UTC (permalink / raw)
To: kernelnewbies
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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141118/2a8ecd85/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Choosing the right environment
2014-11-18 15:36 ` Valdis.Kletnieks at vt.edu
@ 2014-11-18 16:24 ` Philipp Muhoray
0 siblings, 0 replies; 6+ messages in thread
From: Philipp Muhoray @ 2014-11-18 16:24 UTC (permalink / raw)
To: kernelnewbies
Am 2014-11-18 um 16:36 schrieb Valdis.Kletnieks at 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-18 16:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-30 13:12 sched_clock generic for all architectures Hemanth Kumar
2014-11-01 14:41 ` Choosing the right environment Philipp Muhoray
2014-11-18 15:03 ` Gusman Dharma Putra
2014-11-18 15:24 ` Saket Sinha
2014-11-18 15:36 ` Valdis.Kletnieks at vt.edu
2014-11-18 16:24 ` Philipp Muhoray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).