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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
