From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <138575260804151127u2a902d42pe83e57073a8c1c6e@mail.gmail.com>
Date: Tue, 15 Apr 2008 20:27:53 +0200
From: "hugo rivera" <uair00@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
In-Reply-To: <ed75eac8ba38d04f552bd776cf8b6d32@9srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e8c0f31395ada733a656d2cc0aa4748d@quanstro.net>
	<ed75eac8ba38d04f552bd776cf8b6d32@9srv.net>
Subject: Re: [9fans] Writing drivers in Plan 9
Topicbox-Message-UUID: 8e4869a2-ead3-11e9-9d60-3106f5b1d025

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
>
>
>