Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!uwm.edu!cs.utexas.edu!uunet!pipex!uknet!zaphod.axion.bt.co.uk!lessen From: lessen@axion.bt.co.uk (Lee Essen) Newsgroups: comp.os.386bsd.development Subject: Re: kernel hacking tips Date: 12 May 1993 10:12:32 GMT Organization: BT Laboratories Lines: 26 Distribution: world Message-ID: <1sqiig$nht@zaphod.axion.bt.co.uk> References: <1993May11.192459.1618@ucsu.Colorado.EDU> <1sq7vkINNnai@fstgds01.tu-graz.ac.at> NNTP-Posting-Host: jammy.axion.bt.co.uk |> > |> > 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? |> |> You can simply look in the pccons.c file how the X-server gains permission |> to do I/O instructions (in function pc_xmode_on). You just have to place |> an ioctl to just give you I/O permission in any driver (I've used the |> console driver), call the ioctl from your user-level program and you can |> use inb and outb in this program (You can take the inb and outb routines |> from locore.s). |> If you try to use inb/outb from user level without previously gaining |> permission will abort your program. 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! Lee.