From owner-cvs-all@FreeBSD.ORG Thu Jul 8 05:14:50 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9DC516A4CE; Thu, 8 Jul 2004 05:14:50 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 005E843D2F; Thu, 8 Jul 2004 05:14:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i685E5eg078509; Wed, 7 Jul 2004 23:14:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 07 Jul 2004 23:14:15 -0600 (MDT) Message-Id: <20040707.231415.69059806.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <40ECD124.6070109@root.org> References: <20040707175502.M94870@root.org> <20040707.211512.109983259.imp@bsdimp.com> <40ECD124.6070109@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: [src] cvs commit: src/sys/dev/fdc fdc.c fdc_isa.c fdc_pccard.c fdcvar.h src/sys/modules/fdc Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2004 05:14:50 -0000 In message: <40ECD124.6070109@root.org> Nate Lawson writes: : M. Warner Losh wrote: : > In message: <20040707175502.M94870@root.org> : > Nate Lawson writes: : > : On Wed, 7 Jul 2004, Nate Lawson wrote: : > : > M. Warner Losh wrote: : > : > > I went the route of 'exposing' the softc, because that's how newbus : > : > > works: it manages the softc, and in order to manage the softc you have : > : > > to expose its size. I treid to express that in the reviews, but I : > : > > guess that got lost in the shuffle. Bruce doesn't like it, but we do : > : > > it all over the place and the world hasn't come to the end. Anyway, : > : > > after the set of mail that was sent out, I thought that I was supposed : > : > > to commit the simple split, then you were going to specialize things : > : > > for acpi. That's why I went ahead and committed this. phk's recent : > : > > changes to fdc reminded me to merge this stuff.... : > : > : > : > What about instead exposing the size through a extern const int and used : > : > that to set the softc size in the device initialization? The internals : > : > of the softc aren't really needed. : > : > : > : > My code uses a softc size of zero and has a function in fdc.c that is : > : > called by bus attachments that allocates it and does a : > : > device_set_softc(). This mostly works. : > : : > : Actually, I forgot to ask -- are you ok with me committing my code which : > : hides the softc and uses device_set_softc() privately within fdc.c to : > : manage it? We'll still need fdcvar.h to hold function definitions. : > : > What does the hiding gain us? Is it worth the extra code size? In : > the case of struct resource, it makes sense to hid it from the drivers : > so that we can change it. But it seems like there's little to gain : > from doing that in the case of the floppy controller. : : My general concern was about adding more global symbols and tying bus : attachments more closely with the structure of the softc. Global : symbols is an issue if we collide with other names. Avoiding ties with : the softc structure would prevent future layering violations. In my : work to separate them, there weren't many problems yet. (The main one : was the use of a bus-specific write function and the various flags like : PNP and PCMCIA). My concern was in letting it get worse, plus I've : already written the code. :) I'll send you a diff to consider. I'm planning on adding DMA pointer functions as well. This will allow us to have FDC w/o isa. Not a huge deal, but it was a direction that I'd planned on going. I don't view these as layering violations. We have a number of bus attachments that know and understand parts of the softc. Many bus attachments will set flags in the softc and the main driver responds to that. ed is one that comes to mind (but ed supports a few too many different types of cards). The bus specific write function actually insulates the bus specific code from the bus idnependent code. When looking at the pc98 fdc driver, a few more of these would make it possible to merge the pc98 drivers back in. I'd also like to separate out fd from fdc.c into its own set of files, but I'm still designing that separation. This too will help bring the pc98 back in, and I think make acpi stuff easier to do. However, I'll be happy to review any changes you'd like to send me. Warner