From owner-freebsd-doc Mon Jan 24 0:48:45 2000 Delivered-To: freebsd-doc@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B72011571A; Mon, 24 Jan 2000 00:48:09 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p14-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.143]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id RAA28178; Mon, 24 Jan 2000 17:47:57 +0900 (JST) Message-ID: <388C0FED.706330D0@newsguy.com> Date: Mon, 24 Jan 2000 17:40:13 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Bill Maniatty Cc: Jeroen Ruigrok/Asmodai , FreeBSD-doc@FreeBSD.ORG, maniatty@cs.albany.edu, freebsd-hackers@FreeBSD.ORG, Greg Lehey Subject: Re: Learning the FreeBSD Kernel References: <200001231648.LAA53658@cs.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Maniatty wrote: > > First we want to get the mechanism of driver installation down, then > try our hands at writing our own driver. I fear that if we roll our own > driver software we may find that if we have errors (not that we ever have > errors mind you :-) we may not be able to isolate the cause. This is > why I was leaning towards reinstalling a working driver first. You won't have any trouble at all with basic driver installation. In fact, this is driver skeleton, that can be templated (and used to... but I don't know if we have newbus templates or not). Notice that most developers use kld to develop their drivers. Not having to recompile the kernel and reboot really helps. :-) There exists one tutorial-style guide to writing kld's. It's a "hacking" guide to the use of kld's as a way to introduce back-doors in FreeBSD, and though it's somewhat "unclean" wrt to interface description, it's an effective tutorial. I'm sure it can be found from FreeBSD's web site. As a next step, I suggest writing "virtual" drivers, not bound to any hardware. There are many such drivers in the tree. As a trivial example, and a favorite of many, the screen savers. The above will get you proficient with the basics of writing device drivers, but still leave a lot out. Let's see... > > Definately not an ethernet card. *g* > > Seems no-one can keep up with Bill Paul in that aspect. =) > > We probably could not compete :-), but we are interested in ethernet > card drivers (at some point) and would like to learn. > > > You could try usb devices and contact Nick Hibma for his expertise on > > that area. > > How mature is the USB driver technology? If it is pretty preliminary > we may wish to visit that later. Please recall that we are on a learning > curve here. If we support ethernet cards on USB, I'd say it's pretty mature. :-) Anyway, here is what virtual drivers won't teach: how to get resources, which will vary from bus to bus, how to interact with some of the kernel subsystems... How does one write a tun device? How does one write a network device? How does one write a network protocol? How does one write a CAM device (more than one type exist -- some virtual and some not)? How does one write a bus device? When to write a bus (newpcm uses a bus of it's own, if I'm not mistaken)? These problems are mostly distinct from each other, and their usefulness varies. Certainly, a tutorial covering newbus and the main bus types (usb, isa, pci) would be useful and not too difficult to write. CardBus and PCMCIA would be very useful, but we'll have to finish that first :-). But it gets complicated from there on. Writing a tutorial on even a subsection of CAM would be very time-consuming. I assume the same can be said of network devices in general. It will probably not be viable to cover more than one such subject, and their usefulness would be somewhat restricted. On the other hand, it is precisely this kind of tutorial that is mostly needed, since all of what I mentioned before can be dealt with on the fly, just by copying source from existing devices. Now... let me see if I can recall some of the gotcha's (notice that I have never written a newbus device driver). Writing a device driver to exotic devices, as long as you have the documentation for it, is really simple. It's when you have to interact to kernel subsystems that steepens the learning curve. Getting a MYDEVICE into memory is trivial. Just steal the skeleton from the source of some existing device. Julian had a device skeleton generator way back, I don't know if there is a newbus equivalent or not. As long as a device is just inb/outb (I seem to recall newbus have a replacement for these), things are mostly trivial. Covering what you can and cannot do in an interrupt context, the exact working of our spl*() functions (not just theory, but the practice of when to use them and when not to), transfering data to/from user space, setting up dma transfers, and what exactly happens in a tsleep() (DURING the tsleep(), mind you :) are the FAQs, I think. Also, how to create a kernel thread to lighten the load on the interrupt handler (ie, queue work to be done outside the interrupt context) would be very useful too, and it's not too much black magic. Documenting the available debugging tools and useful debugging techniques would be mostly welcome. Aside from "how do I use the kernel debugger", use of tools such as truss, and loading symbol tables to kld's (see Greg Lehey's documentation on debugging vinum) would be useful tutorials. Once you got the above, and possibly created some useful driver templates in the process, I'd say choose a subsystem, and start some in-depth tutorial. Stay away from FS work, as our interfaces are bound to change. CAM is very stable, and SCSI drivers are always useful, so that's one possible field. Network devices would probably take less time, though (that's a wild guess on my part, though). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "2 b or not to b" meaning varies depending on whether one uses the 79 or the 83 standard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message