On Mon, Apr 19, 2010 at 11:48:02AM -0400, Adam M. Dutko wrote: > On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert <[email protected]>wrote: > > > > > ... <snip> ... > > > > Hopefully this is useful for somebody. > > > > It is, thank you. > > With regard to the other questions I peppered everyone with... :-) > > 1) Are there areas that are easier for "relative newbies" to start in versus > other areas? I know this depends on a lot of things, to include experience. > Hypothetically, someone that has some C experience, but not a lot of kernel > (and subsystem) experience. Is it better to start from the bottom up like > bootstrap to init? or is it better to start with memory management? network > drivers? What is usually the best area from a learning and future utility > perspective?
If you're going after userland stuff, the advice I've given (and where I started) is to read libc; it's the basis of userland programming, and illustrates some of the tricks you can do with C. For the kernel side, I'd say start looking at the system calls (cd /usr/src/sys/kern && grep -n ^sys_ *.c). Everything else is just going deeper into the rabbit hole. And if you value your sanity, stay out of anything resembling filesystems. > > 2) Is there something like an "openbsd janitors" project where newbies can > start contributing small patches? similar to the Linux janitors project? Not at all. The philosophy behind not having one is that it's considered dangerous to farm out work to the inexperienced (and this exact topic has been brought up before, usually by people whining that we didn't make them feel special enough by not having one). Read, understand, find an issue, post a patch, get told why it's wrong, fix it, repeat. - Bert
