Date: Wed, 16 Jan 2002 10:26:07 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: K S Sreeram <sreeram@tachyontech.net> Cc: hackers@freebsd.org Subject: Re: New DOC/FAQ entry.. kernel contribution guidance Message-ID: <Pine.BSF.4.21.0201160952030.82675-100000@InterJet.elischer.org> In-Reply-To: <3C45A9B9.5DCDA320@tachyontech.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jan 2002, K S Sreeram wrote: > Hi > > My name is K.S.Sreeram, and i am very much interested in contributing to > the [...] Sounds like you are ideally suited to this....:-) here are some starting tips. Tip 1: "no-one is going to ask you to do some particular thing". We are all volunteers and as such we don't ask or tell anyone to do this or that.. just pick something intersting and do it. Tip 2: Get you environment set up first and then slowely start playing with things you will need: A mirror of the cvs tree (via cvsup) A lot of disk space. Maybe 3 or 4 Gig spare. A small (may be old) test machine. (If you cannot afford a test machine, I have used a virtual test machine by running vmware). Learn CVS. I cannot stress this too much! Tip 3: "no-one is going to ask you to do some particular thing". Tip 4: Experience compiling different options in and out of the kernels. Just experiment with it to find out how it works Always compile your tets kernels with teh debug flag "config -g MYNAME" Get experience booting alternate kernels (for when yours doesn't). Tip 5: Get experience in the kernel debuggers (ddb and gdb) The man ddb page doesn't really match the reality. with the DDB option in the kernel, you an just type sysctl debug.enter_debugger=ddb to drop into the debugger, or, if you are on teh console, you can do <CTL><ALT><ESC> Get experience with the remote gdb. You need 2 machines for this. (or use vmware and the 'nmdm' (nullmodem) device, which I do on my laptop) Connect them so that com 2 is connected to a serial port in the main machine and have the following in the test machone's /boot/device.hints hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" hint.sio.1.flags="0xc0" Then when you go to ddb you can then type gdb it will say "will use gdb at next trap" or something similar. do a singl step (s) and it will apparently freeze. it hasn't really, it's waiting on the serial port for gdb. On the main machine, put the following in a .gdbinit in teh kernel compile directory: file kernel.debug set remotebaud 9600 target remote /dev/ttyd0 Then in that directory, enter gdb. It will connect to the test machine and you will be able to single step etc. or you can do: sysctl debug.enter_debugger=gdb to enter the gdb directly. Also you can enter the ddb VERY EARLY by adding -d to the boot command from the loader. > boot -d to ented ddb or > boot -d -g to make it go straight to gdb. Tto end gdb and go back to ddb use "det" (short for detatch). To make ddb reboot you can do: call boot 0 or panic Tip 6: "no-one is going to ask you to do some particular thing". Tip 7: use -current for all your stuff, and use a tree you've checked out of your CVS mirror to do it all. That way you can instantlyu generate diffs and keep it up to date with -current using 'cvs diff -u' and 'cvs update' The patches so derived will be perfect for sending to others. tip 8: "no-one is going to ask you to do some particular thing". pick somethign that intersts you, and find out who else is intersted in that and then start communicating with them. send them patches about your ideas and co-operate. really it's up to you.. we provide the tools and you do what you want with them. Pleas mail me if yuo have questions (I think this should be a FAQ) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0201160952030.82675-100000>