From owner-freebsd-current  Thu May 15 04:20:09 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id EAA13631
          for current-outgoing; Thu, 15 May 1997 04:20:09 -0700 (PDT)
Received: from pcnet1.pcnet.com (root@pcnet1.pcnet.com [204.213.232.3])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA13626
          for <current@FreeBSD.ORG>; Thu, 15 May 1997 04:20:07 -0700 (PDT)
Received: from rigel (ts3-pt14.pcnet.com) by pcnet1.pcnet.com (4.1/SMI-4.1)
	id AA20473; Thu, 15 May 97 07:13:03 EDT
Message-Id: <337AF110.41C67EA6@iworks.InterWorks.org>
Date: Thu, 15 May 1997 07:18:40 -0400
From: "Daniel M. Eischen" <deischen@iworks.InterWorks.org>
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 3.0-CURRENT i386)
Mime-Version: 1.0
To: Poul-Henning Kamp <phk@dk.tfs.com>
Cc: current@FreeBSD.ORG
Subject: Re: Backwards compatibiliy for isa_driver
References: <3857.863692129@critter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Poul-Henning Kamp wrote:
> 
> >>
> >> 1) define a database that supports all types of devices and buses
> >>
> >> 2) use "methods" to access the data without knowledge about the actual forma
> >t
> 
> I actually have built a general registry for FreeBSD two times.
> First one died because it was a mess at run time, Second one because
> I had chosen option 1) above.
> 
> Here is my intended design next time I attempt this:
> 
> 1. A node can contain a value and/or be the parent of other nodes.
> 
> 2. The identity of a node is a string consisting of names separated
>    by ".".  the names must be valid C identifiers.
> 
> 3. The type of a value is identified with a pointer to a method
>    implementation, which provides the following methods:
> 
>         ascii2native(...)
>         native2ascii(...)
>         lookup(...)
>         getnext(...)
>         ...
> 
> 4. All nodes are marked either "pinned" or "pageable"
> 
> 5. A "getnext" operator along the lines of SNMP can traverse the
>    tree.
> 
> ..and by this time I usually give stop and realize that this looks a
> hell of a lot like a filesystem and decide that I should probably
> implement it to look like a filesystem from userland...

Have you looked at how Sun Solaris does similar things?

  ddi_prop_exists(9F)
  ddi_prop_get_int(9F)
  ddi_prop_lookup_int_array(9F)
  ddi_prop_lookup_string(9F)
  ddi_prop_lookup_string_array(9F)
  ddi_prop_lookup_byte_array(9F)
  ddi_prop_update_int(9F)
  ddi_prop_update_int_array(9F)
  ddi_prop_update_string(9F)
  ddi_prop_update_string_array(9F)
  ddi_prop_update_byte_array(9F)
  ddi_prop_remove(9F)
  ddi_prop_remove_all(9F)

The device driver also has a prop_op entry point to allow for special
case conditions, like a value that can change frequently.

As for naming conventions, Sun recommends IEEE1275-1994, the standard
for boot firmware.

Dan Eischen
deischen@iworks.InterWorks.org