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!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.questions Subject: Re: Good manuals? Date: 8 Jul 1993 22:36:25 GMT Organization: University of Maryland Lines: 29 Distribution: world Message-ID: <21i7h9$e34@umd5.umd.edu> References: <1993Jun30.034017.12142@henson.cc.wwu.edu> <741895288snz@awfulhak.demon.co.uk> NNTP-Posting-Host: roissy.umd.edu In article <741895288snz@awfulhak.demon.co.uk> Brian@awfulhak.demon.co.uk writes: > >As for inner workings, try 'Writing a UNIX Device Driver' by Janet I. Egan >& Thomas J. Teixeira, published by 'John Wiley & Sons Inc.'. It's a bit >out of date, but explains just about all of the 'inner workings'. Again, >it's SYSV, and it's also fairly old (1988), but it's good. If you look a little closer, you'll notice that this book is based on a course developed by MASSCOMP to teach people to do drivers for their system. It was for a largely BSD-based system, but the authors did a good job of getting some SYSV info in it too. I found it to be very informative. There's a second edition out now. I didn't get it, but I consider the first edition to be better than any of the other device driver books I saw in a local bookstore a few weeks ago. There's one in particular by George Parjari (sp?) that appears to be based on Xenix/SCO. I wouldn't suggest that you not get his book, but don't let his be your _only_ book. He kind of skips things that _I_ consider important, but sometimes that makes it easier to understand. You need to go back and fill in the details though. BEWARE: I have never seen a *good* reference for writing device drivers for *any* system. You usually have to figure out a lot for yourself. It's kind of sink-or-swim, and you *will* sink a lot. I offer you these two bits of advice: 1- Hang in there. Most people take quite a while to learn. 2- Make lots of backups. Mark S.