From owner-cvs-all Mon Jul 3 7:28:10 2000 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id C9F7337B8F2; Mon, 3 Jul 2000 07:28:02 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id QAA06435; Mon, 3 Jul 2000 16:27:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nick Hibma Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys bus.h bus_private.h src/sys/kern subr_bus.c In-reply-to: Your message of "Mon, 03 Jul 2000 15:02:03 BST." Date: Mon, 03 Jul 2000 16:27:59 +0200 Message-ID: <6433.962634479@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Nick Hibma wri tes: >> In fact: I object to newbus allocating the softc for exactly the >> reason this one is needed: There may be a 1:N or N:1 correspondence >> between softc's and newbus devices. In this case I have two >> newbus devices for one softc. (Well, actually I have two newbus >> devices for five softc's, but lets not get into that) > >As you have noticed yourself the problem is not having the same softc >but the fact that you can't claim all the appropriate newbus devices in >one go. No, there are other problems than that. If I decide to implement a "persistent device" model for a removeable device, for instance to be able to do fall-over from one hardware device to another, then it doesn't work that the softc is tied to the newbus instance, since the drivers "logical" instance survives the hardware going away. Example: Hot-plug. My cPCI card fails, I pull it and plug another one in, I will very likely not want to loose my softc in that case. The "1-newbus-instance : 1-device-instance" assumption is a grave mistake, and we shall not lock our selves down in a dogmatic postulate about how the world is according to our perception, rather we need to be flexible enough to handle all the weird shit (TM) out there. >Bottom line: the conceptual design of your driver doesn't fit newbus. Bottom line: newbus has a simplistic view of hardware which unfortunately doesn't adequatly describe several pieces of attractive hardware and features currently on the market. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message