Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run?

[Miles Lane <miles@megapathdsl.net>]

Bill Nottingham wrote:


>>> There's also the cardbus->hotplug/pcmcia->cardmgr mess for
>>> the time being, but that's a whole different story (and
>>> a non-trivial one to clean up)...
>> 
>> I think the plan of record for 2.4 is to make hotplug handle cardbus
>> and pcmcia_cs/cardmgr handle pcmcia.  If anyone thinks it's
>> something else, please speak up!
> 
> 
> That's rather ugly (cardmgr will still print messages for everything
> that's inserted), inconsistent in UI (cardmgr beeps, etc., hotplug
> doesn't), and just generally odd from an end-user's perspective
> (You see, if you plug *that* card into the slot, you need cardmgr
> running; if you plug that other card in, you need hotplug.)

This isn't true.  The 2.4.x kernel drivers should handle virtually
all Cardbus *and* PCMCIA devices.  At least, that's what David
Hinds told me.  So, if you compile a 2.4.x kernel with Cardbus
and i82365 and build the necessary drivers, you should be able 
to load the modules and use your PCMCIA devices.  You'd just
build pcmcia_cs support in order to get the cardmgr and cardctl
programs and the various config and opts files.  If you do this,
then pcmcia_cs shouldn't do any "beeping" during the boot process,
because all PC Cards will be configured by /sbin/hotplug.

> It's actually not too hard to make cardmgr work fine with 2.4.

David Hinds' recent cardmgr releases should already have the 
work-around built in to not attempt to configure any devices 
that 2.4.x kernel hotplugging will handle.  NOTE:  This is *not* 
just for Cardbus PC Cards.  There are 2.4.x in-kernel drivers 
that do handle PCMCIA cards.  For example, for PCMCIA cards.  
I build:

    ls /lib/modules/2.4.2/kernel/drivers/net/pcmcia/

	3c574_cs.o  aironet4500_cs.o  netwave_cs.o  pcnet_cs.o
	smc91c92_cs.o  xirc2ps_cs.o  3c589_cs.o  fmvj18x_cs.o
	nmclan_cs.o  ray_cs.o  wavelan_cs.o  xircom_tulip_cb.o

     ls /lib/modules/2.4.2/kernel/drivers/char/pcmcia/

	serial_cb.o  serial_cs.o

As a reminder, here is David Hinds list of work items related
to getting PCMCIA support into the kernel (the recent design
work done by Adam Richter, Oliver Neukum and others overhauls
portions of this list):

 > To include 16-bit PCMCIA cards in the hotplug framework
 > would require few driver changes; the only mandatory
 > changes would be in how drivers register themselves and
 > are hooked up with appropriate devices:
 >
 > -- Make up pcmcia_device_id and pcmcia_driver types, and
 > write new register/unregister calls to parallel PCI and
 > USB drivers.  This would eventually take over for the "ds"
 > module and cardmgr.
 >
 > -- Rewrite all PCMCIA client drivers to have
 > MODULE_DEVICE_TABLE entries and use the new driver
 > services.  This can all be done incrementally, with
 > ds/cardmgr handling old-style drivers.
 >
 > -- The CIS override functionality in the PCMCIA package
 > is unpleasant to support in a completely in-kernel framework.
 >
 > Missing functionality in the hot plug framework:
 >
 > -- Only new network devices generate /sbin/hotplug events
 > now.  Modify all other device types to also do so: the ones
 > currently handled by PCMCIA include serial, parallel, SCSI
 > (all types), and IDE.
 >
 > -- There is no mechanism to request a card eject in the new
 > framework.  This is required for clean shutdown of SCSI and
 > IDE adapters.
 >
 > -- The PCMCIA device configuration scripts have a lot of
 > capabilities that the hotplug scripts do not have yet.
 > At the moment, the extent of device-specific hotplug
 > configuration is running "ifup".
 >
 > Missing functionality in the 2.4 PCMCIA drivers:
 >
 > -- The yenta driver can't handle CardBus adapter cards for
 > desktop systems.  Many require explicit overrides for the
 > default interrupt delivery settings, and a few require other
 > special bridge settings.
 >
 > -- The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA
 > bridges any more.  Some of the PCI code in the old i82365
 > driver needs to be put back.

Anyhow, I am looking forward to seeing a restatement of this
list by Adam Richter and Oliver Neukum in light of their
recent discussions.

	Miles


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel