Re: Learning kernel programming with netbsd

["Michael Litchard" <michael%schmong.org@localhost>]

>  Then pick some reasonably small project (from the projects list on the
>  web site, or something of your own; historically a lot of people begin
>  by writing a device driver for some piece of hardware) and sit down to
>  get that working. And don't be afraid to ask for help.

Well, my dvd/cd rw device doesn't seem to be detected.
I shut acpi off, but that didn't help. Secretly I was hoping I needed to
modify a device driver, which would be cool. Maybe I should start there.
However, I suspect this may be too complicated for me as a first project.
I'm not sure. How do I start assessing? And would it be simpler
to work this out in i386 -current, instead of AMD64 -current?

                                                          Michael Litchard
On 6/29/08, David Holland <dholland+netbsd%eecs.harvard.edu@localhost> wrote:
> On Sat, Jun 28, 2008 at 12:48:36PM -0700, Michael Litchard wrote:
>
>  > The end goal here is to start making contributions to -current.
>   > Here's where I am at now.
>   > I have done some x86,RISC (using SPIM) and AVR assembler programming.
>   > I know C, and how to construct the data structures typically discussed
>   > in a first data structures class.
>   > so, given that, would anyone be willing to give me a series of tasks
>   > that will prepare me to meet my goal?
>
>
> I would say the first step is to learn a bit about how kernels are set
>  up; an OS textbook or the daemon book might help. (You can find this
>  all out by reading code, but there's a lot of code, and the high-level
>  organization isn't always that easy to see.)
>
>  Learn how userland interfaces to the kernel; read some of the more
>  obscure section 2 man pages and write a program that uses one or two
>  low-level features. For a few of the less obscure system calls (e.g.,
>  read, lseek) read the code in the kernel to see how the implementation
>  works and where things go.
>
>  Add some hacks to the kernel just for practice - e.g. add a new system
>  call that causes the kernel to print "hello" to the console. Or
>  something like that. You'll never commit this but it'll get you some
>  practice building and running test kernels.
>
>  Then pick some reasonably small project (from the projects list on the
>  web site, or something of your own; historically a lot of people begin
>  by writing a device driver for some piece of hardware) and sit down to
>  get that working. And don't be afraid to ask for help.
>
>  When we teach students this stuff we give them a toy OS with key
>  pieces missing or half-written and have them write those pieces. You
>  can't do that with NetBSD (the pieces are all already there) so you
>  have to pick projects from less fundamental parts of the system.
>
>  You could also do the toy OS thing yourself first and then move across
>  to NetBSD.
>
>
>  --
>    - David A. Holland / dholland+netbsd%eecs.harvard.edu@localhost
>