Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!umd5.umd.edu!elea.umd.edu!mark From: mark@elea.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.development Subject: Re: kernel hacking tips Date: 12 May 1993 20:05:24 GMT Organization: University of Maryland Lines: 35 Distribution: world Message-ID: <1srla4$r6q@umd5.umd.edu> References: <1993May11.192459.1618@ucsu.Colorado.EDU> <1sq7vkINNnai@fstgds01.tu-graz.ac.at> <1sqiig$nht@zaphod.axion.bt.co.uk> NNTP-Posting-Host: elea.umd.edu In article <1sqiig$nht@zaphod.axion.bt.co.uk> lessen@axion.bt.co.uk (Lee Essen) writes: > >It's not quite that simple!! The majority of device drivers have to respond to >IRQ's, how do you do that? > >I've been trying to develope an ST01/02 SCSI driver and I had to give up because >I got so fed up of rebooting. > >If there is a solution to this I'de be *VERY* interested to hear it! Sure, there's a solution. You make "loadable device drivers". I started on this a while ago, but I ran into 2 problems - 1) I don't really know how the 386/486 and netbsd interrupt handling works, and 2) right now, I'm stuck with enough hard problems at work that the _last_ thing I want to do when I get home is find some more. :) I made a system call and some user level programs that let you load a .o file into the kernel and execute a function in it. The object file you load has full access to kernel memory and it knows all the kernel functions and variables. It works fine for calling the kernel printf() and a few other things. It _needs_ (and does _not_have_) these features that I consider necessary to be useful: - a way to get interrupts to call the loaded code - a way to get system calls to call the loaded code Anyway, it exists as a bunch of hacks that I made to 386bsd 0.1 + some patch kit or another. If you want to see how it works, send me mail. Mark. mark@roissy.umd.edu