[9fans] Writing drivers in Plan 9
hugo rivera
I've been using Inferno and Plan 9 for almost a year. I certainly love
Plan 9's ideas and concepts, and I'd be glad to finally move forward
and leave Unix behind, but for now it is imposible for me, since my
work does not allow me this (I do data analysis for some physics
experiment using Cern's ROOT).
Anyway, I've always wanted to learn to write drivers and I did try it
a few years ago, using NetBSD, but I could not find time to complete
the task, so I leaved it unfinished. I want to start again, but this
time using Plan 9. So, I want to ask you for some pointers about how
doing this. Please, bear in mind, that I am a complete newbie when it
comes about writing drivers.
Saludos
Hugo
a...@9srv.net
think a really nice way to get into driver development is
with emu drivers for Inferno. The basic structure is the
same as for native OS drivers in either system: implement
a small set of entry points (fooattach, fooread, &c),
making use of the dev* defaults where appropriate. It's
then a much smaller step to move into native hardware
drivers for Plan 9 or Inferno. And when you do get to that
point, take a look at Inferno's os/port/devXXX.c; it's a
template for what you need to implement. In any case,
the devtab (look for '^Dev') towards the end of any driver
will tell you what you really need. It's a much nicer,
constrained set for Inferno and Plan 9 than any unix.
Anthony
erik quanstrom
a few thoughts from inexperience
0. pick something you want to use.
1. you must have a datasheet. reading other drivers for the same
h/w can be very misleading before you're done.
2. implement as few features as you need to get the hardware
working for your purposes. it's likely the other stuff will never
be needed,
3. set up an whole plan 9 environment which can pxeboot
your target machine. if you're like me, you'll be rebooting
quite a bit.
4, this is still true
The most effective debugging tool is still careful thought,
coupled with judiciously placed print statements.
-Kernighan, 1978
- erik
erik quanstrom
i think this confuses implementing a Dev interface with writing
a device driver. for many devices, the Dev interface is already
taken care of. for example, serial, ethernet, disk devices using
sd implement an interface to devsd, ethernet.
i don't buy the thesis that talking to hardware is always hard.
talking to some hardware can be hard. for exampe, the aoe driver
doesn't talk to hardware, it talks to the ethernet drivers. yet it's
the largest driver i've written, largely because it implements its own
dev interface.
i think it's a mistake to think hardware == hard, software interfaces
== easy.
- erik
a...@9srv.net
> a device driver. for many devices, the Dev interface is already
> taken care of. for example, serial, ethernet, disk devices using
> sd implement an interface to devsd, ethernet.
i think the Dev interface is still the right place to start, in terms of
understanding things.
for the benifit of the original question, the Dev interface (that
common set of entry points i was talking about) is the common
kernel interface that all device drivers have to go through at some
point. i think part of erik's point (which is correct) is that many of
the things people are commonly writing drivers for - disk
controllers, ethernet cards, and vga cards being probably the most
common examples - already have that interface covered, and
there's a separate interface that the hardware-specific part needs
to talk to.
> i don't buy the thesis that talking to hardware is always hard.
> talking to some hardware can be hard. for exampe, the aoe driver
> doesn't talk to hardware, it talks to the ethernet drivers. yet it's
> the largest driver i've written, largely because it implements its own
> dev interface.
but working with Dev doesn't need to be so complex; it depends, at a
minimum, on what the job you're trying to do is. dup and env
both implement at least most of their own Dev interface (as opposed
to relying on many of the default stubs), but are reasonably short and
easy to understand. devaoe's hardly a fair comparison; it's not only
the largest driver you've written, it's the largest dev*.c in the system.
> i think it's a mistake to think hardware == hard, software interfaces
> == easy.
agreed. but it's also a mistake, at least in the context of Plan 9, to
assume that device drivers inherently involve hardware. about a third
of the things in section three of the manual don't.
anthony
hugo rivera
Now, I think I am going to start by trying to understand a little
about the Dev interface you talk about, and then continue to write a
real driver for a gamepad that I have.
Is there any documentation that describes this Dev interface?
This is a usb gamepad, so probably I have to deal with a Dev interface
related to the usb ports, am I right?
Hugo
2008/4/15, a...@9srv.net <a...@9srv.net>:
erik quanstrom
> Now, I think I am going to start by trying to understand a little
> about the Dev interface you talk about, and then continue to write a
> real driver for a gamepad that I have.
> Is there any documentation that describes this Dev interface?
> This is a usb gamepad, so probably I have to deal with a Dev interface
> related to the usb ports, am I right?
>
> Hugo
probablly not. the usb stuff is all accessable from userland. usbd
runs in user space as do all the clients of usb -- usb/disk usb/mouse, etc.
- erik
hugo rivera
> runs in user space as do all the clients of usb -- usb/disk usb/mouse, etc.
So, this means that I never have to deal with usb interfaces?
Can you point me some documentation about this?
Hugo
erik quanstrom
> Can you point me some documentation about this?
>
> Hugo
it should be in the manul pages. try
; lookman usb
- erik
hugo rivera
> ; lookman usb
Great! thanks
Hugo
Tom Lieber
> Anyway, I've always wanted to learn to write drivers and I did try it
> a few years ago, using NetBSD, but I could not find time to complete
> the task, so I leaved it unfinished. I want to start again, but this
> time using Plan 9. So, I want to ask you for some pointers about how
> doing this. Please, bear in mind, that I am a complete newbie when it
> comes about writing drivers.
Did you do it? How did it go?
--
Tom Lieber
http://AllTom.com/
hugo rivera
my job in the university and preparing me for some tests in October.
Hopefully I can start this thing in November.
2008/9/3 Tom Lieber <all...@gmail.com>:
--
Saludos
Hugo