Re: [9fans] Writing drivers in Plan 9

["hugo rivera" <uair00@gmail.com>]

Thanks for your feedback.
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>:
> > 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 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
>
>
>