Re: What to do with 3c59x.c?

[Jeff Garzik]

Andrew Morton wrote:
> 
> Jeff Garzik wrote:
> >
> > Andrew Morton wrote:
> > > - The consensus here seems to be that I should continue to generate
> > > drivers/net/3c59x.o as well as drivers/net/pcmcia/3c575_cb.o. Fair
> > > enough.
> >
> > The stumbling block seems to be pcmcia.  If we can get pcmcia to load
> > 3c59x.o for all its 3com needs, then there should be no reason why
> > 3c575_cb.o continues to live.
> >
> > > - I don't want to copy a single .o file into two places because the
> > > source _should_ be compiled twice.
> >
> > What makes you think this?  The source should not need to be compiled
> > twice.  The PCI driver interface is designed to seamlessly support
> > hotplug and non-hotplug.
> 
> One example: 3c59x.o could have been compiled for static (non-modular)
> use.  Copying that onto 3c575cb.o and insmodding it wouldn't work very
> well :)

For that case, the driver is already present, so PCMCIA should not load
anything at all.  Thus, a missing 3c575_cb.o is correct for this case.

I still maintain there is absolutely no reason why the source needs to
be compiled twice.

> I believe the path of least resistance is to separately compile the same
> source into two objects. This preserves pcmcia config compatibility and
> allows for different compile options for 3x59x.o and 3c575_cb.o.

But you do not need different compile options.

> The problem of mapping a driver name to an interface name for cardmgr is
> still spinning around.  I don't know enough to make any useful comments
> on this.

We have devfs for everything but network interfaces (and their names). 
Maybe just special case network device naming and be done with it.

	Jeff

-- 
Jeff Garzik              | Nothing cures insomnia like the
Building 1024            | realization that it's time to get up.
MandrakeSoft, Inc.       |        -- random fortune