From owner-freebsd-mobile Mon Sep 20 16:34:28 1999 Delivered-To: freebsd-mobile@freebsd.org Received: from ringer.cisco.com (ringer.cisco.com [144.254.142.11]) by hub.freebsd.org (Postfix) with ESMTP id 66A6214C23 for ; Mon, 20 Sep 1999 16:34:13 -0700 (PDT) (envelope-from amcrae@cisco.com) Received: (amcrae@localhost) by ringer.cisco.com (8.8.4-Cisco.1/8.6.5) id JAA25398; Tue, 21 Sep 1999 09:33:30 +1000 (EST) From: Andrew McRae Message-Id: <199909202333.JAA25398@ringer.cisco.com> Subject: Re: Combo 100Base-T Ethernet/10 BaseT Ethernet/Modem/ISDN cards To: freebsd-xircom@lovett.com Date: Tue, 21 Sep 1999 09:33:30 +1000 (EST) Cc: billf@jade.chc-chimes.com, ade@lovett.com, freebsd-mobile@FreeBSD.ORG In-Reply-To: <199909202222.QAA21019@harmony.village.org> from "Warner Losh" at Sep 20, 99 04:22:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Here's a sketch of my world view, which matches the newconfig code a >little: > > isa <-> pcic <-> pccard slot 0 <-> driver(s) for card in slot 0 > pccard slot 1 <-> driver(s) for card in slot 1 > >or the more complicated card bus: > pci <-> cbb <-> pccard slot 0 <-> driver(s) for card in slot 0 > pccard slot 1 <-> driver(s) for card in slot 1 > card bus slot 0 <-> driver(s) for card in slot 0 > card bus slot 1 <-> driver(s) for card in slot 1 > >The card bus machines would provide attachments to both a pccard slot >(for pccard devices in a card bus capable slot) and a card bus slot. >Multiple children would be allowed per slot to support multi-function >cards. It is my understanding that these cards share an interrupt, >but otherwise function indepenently. One consideration and design pattern that has worked here at cisco is to consider the slot/card as two distinct objects, one a `slot' and the other as a `plugin' (the thing that goes into a slot). Separating the semantics of slot and plugin allows separate methods to operate on the slot and the card, and provides a better abstraction for the object definitions. It also makes the code more extensible. In your world model, the plugin would appear: pci <-> cbb <-> pccard slot 0 <-> plugin for card <-> driver pccard slot 1 <-> card bus slot 0 <-> plugin for card +-> driver 1 +-> driver 2 The plugin can be designed as a base class for interaction with the slot (card services, interrupts etc.) and the plugin can have a derived portion to act as a container for the devices existing on the card. Cheers, AMc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message