From owner-freebsd-arch  Thu Jan  4 21:28:20 2001
From owner-freebsd-arch@FreeBSD.ORG  Thu Jan  4 21:28:18 2001
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from caspian.scsiguy.com (caspian.scsiguy.com [63.229.232.105])
	by hub.freebsd.org (Postfix) with ESMTP id 9137737B400
	for <freebsd-arch@freebsd.org>; Thu,  4 Jan 2001 21:28:17 -0800 (PST)
Received: from caspian.scsiguy.com (localhost [127.0.0.1])
	by caspian.scsiguy.com (8.11.1/8.11.1) with ESMTP id f055SGU00338
	for <freebsd-arch@freebsd.org>; Thu, 4 Jan 2001 22:28:17 -0700 (MST)
	(envelope-from gibbs@caspian.scsiguy.com)
Message-Id: <200101050528.f055SGU00338@caspian.scsiguy.com>
To: freebsd-arch@freebsd.org
Subject: Inheritance in new-bus.
Date: Thu, 04 Jan 2001 22:28:16 -0700
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
Sender: gibbs@caspian.scsiguy.com
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I've finished a first pass at making cardbus a "sub-class" of pci.
Patches for this have been distributed to a few developers and will
appear hear as soon as I finish the "play by play" for the formal
post to -arch.  In doing this work, I ran into several small issues
that I have not resolved to my satisfaction.  My hope is that this
forum will have some ideas.

Method Inheritance
==================
In my patches, cardbus.c is now 518 lines long.  Most of this is
copyright and the method table.  Like most "sub-classes", cardbus
need only specialize a few methods of pci.  In a true object oriented
environment, you would overload the method and perhaps even call into
the parents implementation of that method as part of implementing
the new method.  In new-bus, method tables are constructed by hand.
This means that the cardbus code must fill in the appropriate pci
method in its own table in the case of no-override.  When the pci
method table is changed, chances are high that the cardbus method
table will require a similar update.  One could imagine devclasses
with the concept of a parent and having kobj handle the magic for
you.  This would be difficult to implemement in the case of multiple
parents.  Cardbus, for example, will be a subclass of "card services"
at some point.  If the method tables were broken down in terms of
distinct interfaces, single inheritance *per interface* would probably
be sufficient.

Ivar namespace
==============
All busses exporting ivars do so by listing their ivar codes in a
simple enumeration.  This makes it imposible to write an implemenation
of the ivar method that looks like this:

static int
cardbus_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
{
        struct cardbus_devinfo *dinfo;

        dinfo = device_get_ivars(child);
        switch (which) {
        case CARD_IVAR_CIS_FUNCTION:
                dinfo->cis_function = value;
                break;
        case CARD_IVAR_VENDOR_STR:
                return (cardbus_update_str(&dinfo->vendor_str,
                                           (const char *)value));
        case CARD_IVAR_CLASS_STR:
                return (cardbus_update_str(&dinfo->class_str,
                                           (const char *)value));
        case CARD_IVAR_MODEL_STR:
                return (cardbus_update_str(&dinfo->model_str,
                                           (const char *)value));
        case CARD_IVAR_REVISION_STR:
                return (cardbus_update_str(&dinfo->revision_str,
                                           (const char *)value));
        default:
                return (pci_write_ivar(dev, child, which, value));
        }
        return 0;
}

The CARD ivars clash with the PCI ivars and cardbus_write_ivar()
returns the wrong data 50% of the time.  As a temporary kludge,
I've started the CARD ivar enumeration at 10000, but we should
probably transition to a scheme similar, if not more robust, than
the way ioctls are defined.

In general, I've been very pleased with the new bus framework.
It still needs to be documented better (especially in regards
to resource allocation/activateion/deactivateion/release/delete),
and it still needs multi-pathing, but its pretty cool stuff.

--
Justin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message