9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: a@9srv.net
To: 9fans@9fans.net
Subject: Re: [9fans] Writing drivers in Plan 9
Date: Tue, 15 Apr 2008 12:07:01 -0400	[thread overview]
Message-ID: <ed75eac8ba38d04f552bd776cf8b6d32@9srv.net> (raw)
In-Reply-To: <e8c0f31395ada733a656d2cc0aa4748d@quanstro.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



  reply	other threads:[~2008-04-15 16:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15  8:40 hugo rivera
2008-04-15 11:28 ` a
2008-04-15 13:43   ` erik quanstrom
2008-04-15 16:07     ` a [this message]
2008-04-15 18:27       ` hugo rivera
2008-04-15 18:31         ` erik quanstrom
2008-04-15 18:50           ` hugo rivera
2008-04-15 18:54             ` erik quanstrom
2008-04-15 19:06               ` hugo rivera
2008-04-15 13:23 ` erik quanstrom
2008-09-03 21:50 ` Tom Lieber
2008-09-04  6:36   ` hugo rivera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed75eac8ba38d04f552bd776cf8b6d32@9srv.net \
    --to=a@9srv.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).