[src] cvs commit: src/sys/dev/fdc fdc.c fdc_isa.c fdc_pccard.c fdcvar.h src/sys/modules/fdc Makefile

[M. Warner Losh]

In message: <40ECD124.6070109 at root.org>
            Nate Lawson <nate at root.org> writes:
: M. Warner Losh wrote:
: > In message: <20040707175502.M94870 at root.org>
: >             Nate Lawson <nate at root.org> 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