-On [20000124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
>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).
man 9 driver.
>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.
Trust me, writing modules is the _least_ of your worries. If I can
write a module then every^H^H^H^H^Hcluefull people can. =)
/usr/src/sys/modules
>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...
[Not looking at the source code for those I dare say:] But they are not
using any busspace/newbus functionality for all I know. And cannot be
compared to the `real' drivers IMHO.
>> 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)?
If you refer to pcm attaching to sbc or gusc. But those are pseudo
busses if I understood everything correctly, the same goes for miibus
and related busses (ppbus, smbus, iicbus).
>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
>:-).
Ehm, a tutorial covering the bus types. You have no idea how much you
can write about ISA and PCI alone.
>But it gets complicated from there on. Writing a tutorial on even a
>subsection of CAM would be very time-consuming.
Write a reference so that we can finally convert the last drivers to
CAM/newbus. =)
>Julian had a device skeleton generator way back, I don't know if there
>is a newbus equivalent or not.
I think Peter [Wemm] wrote a skeleton one.
>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.
Yeah yeah, coming up. Stop whining. ;)
Hey, wait a sec, you said yesterday that you were bored. Nice task for
you DCS ;)
--
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Ain't gonna spend the rest of my Life, quietly fading away...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
