Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!agate!boulder!ucsu!rintintin.Colorado.EDU!galbrait From: galbrait@rintintin.Colorado.EDU (GALBRAITH JOHN) Subject: Re: kernel hacking tips Message-ID: <1993May11.192459.1618@ucsu.Colorado.EDU> Sender: news@ucsu.Colorado.EDU (USENET News System) Nntp-Posting-Host: rintintin.colorado.edu Organization: University of Colorado, Boulder References: <PC123.93May11105430@bootes.cus.cam.ac.uk> <1so4eaINNibt@fstgds01.tu-graz.ac.at> Date: Tue, 11 May 1993 19:24:59 GMT Lines: 32 In article <1so4eaINNibt@fstgds01.tu-graz.ac.at> chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes: < stuff deleted > >YES ! >Use julians bootblocks (available on the agate mirrors). >You can specify the boot device (wd0, fd0, sd0, wd1,...), the boot kernel >(386bsd, vmunix,...) and some boot flags (-s for singleuser, -d to jump into >the kernel debugger before probing for devices). >Very very useful, and much less painful than a fixit floppy. > >To test my kernel mods, I also use the kernel debugger to single-step through >my routines (for low-level code), look at variables, or change debugging >flags during runtime. Also to create environments to test special cases. > > > Christoph This is great news. Thanks for the advice. However, you still have to reboot (and wait for the fsck and the mounts, and ...) every time you actually try out new changes right? Has anybody tried to cheat and write a driver that does nothing but give you access to an outb() and inb() instruction? This might speed development for a big project. The new driver gets written and debugged before it is ever added to the kernel so you don't have to constantly reboot. Or what about doing an inline assembly call to outb with no kernel support at all? john galbrait@rintintin.colorado.edu