Adding PCMCIA support to the kernel tree -- developers needed.

Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Hi,

I asked David Hinds to write up an outline of the things that
will be needed to get PCMCIA support cleanly and completely
integrated into the kernel tree.

David has expressed that he'll not be able to participate in
this work.  He has his hands full with his day job and his 
role as maintainer/developer of the pcmcia-cs package.

David, I would appreciate one additional layer of information that is
not present in your list.  Would add the names of a few representative 
devices for each of your bullet points?  For example, for the last 
list item, what are the names of the major (non-CardBus) PCI-to-PCMCIA 
bridges?

Here is David's list:

> To include 16-bit PCMCIA cards in the hot plug 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.

This list does seem to break out the work into chunks that can
be tackled more or less independently.

Anyone willing to sign up for some of this effort?

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Jeff Garzik]

On Fri, 2 Feb 2001, Miles Lane wrote:
> I asked David Hinds to write up an outline of the things that
> will be needed to get PCMCIA support cleanly and completely
> integrated into the kernel tree.
> 
> David has expressed that he'll not be able to participate in
> this work.  He has his hands full with his day job and his 
> role as maintainer/developer of the pcmcia-cs package.
[...]
> Anyone willing to sign up for some of this effort?

I'll convert all the network drivers once a design is agreed upon.

	Jeff





_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Fri, 2 Feb 2001, Miles Lane wrote:

> > -- The CIS override functionality in the PCMCIA package is unpleasant
> >    to support in a completely in-kernel framework.

How often is this used?

> > -- There is no mechanism to request a card eject in the new framework.
> >    This is required for clean shutdown of SCSI and IDE adapters.

It's arguable that this is a bug in the SCSI and IDE drivers. Users _do_ 
just pull cards out. We should deal with it, not oops and die. This is a 
fundamental part of what hotplugging means, especially to users of 
consumer devices.

> > -- 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.

Or specific drivers for the PCI drivers need to be provided. The i82365 
driver with all the PCI stuff is a horrible mess. I tried putting back the 
non-CardBus PCI support at one point. It was ugly, and didn't work. 
Someone's now working on a driver for the Intel i82092AA bridge, and I 
think that's the best answer for the other PCI-PCMCIA bridges too, rather 
than merging it back into the ISA i82365 code.

> Anyone willing to sign up for some of this effort?

I'm trying to get some time to work on it, yes. 

I was actually coming to the conclusion that I'd prefer just to ditch the
whole of the existing PCMCIA support and rewrite it from scratch as a kind
of hot-pluggable isapnp, which is basically what it is (when you remember
that PCMCIA != CardBus).

-- 
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Jeff Garzik wrote:
> 
> On Fri, 2 Feb 2001, Miles Lane wrote:
> > I asked David Hinds to write up an outline of the things that
> > will be needed to get PCMCIA support cleanly and completely
> > integrated into the kernel tree.
> >
> > David has expressed that he'll not be able to participate in
> > this work.  He has his hands full with his day job and his
> > role as maintainer/developer of the pcmcia-cs package.
> [...]
> > Anyone willing to sign up for some of this effort?
> 
> I'll convert all the network drivers once a design is agreed upon.

Would you write up a proposal for this design that we could work
from to come to a agreed design?  You are probably the best person
to start this process.

Thanks!
	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Sat, Feb 03, 2001 at 07:27:26PM +0000, David Woodhouse wrote:
> 
> How often is this used?

Fairly rarely; there are currently around 15 types of cards that have
override files for broken CIS information.

> It's arguable that this is a bug in the SCSI and IDE drivers. Users _do_ 
> just pull cards out. We should deal with it, not oops and die. This is a 
> fundamental part of what hotplugging means, especially to users of 
> consumer devices.

I would probably agree.  Dealing with hot eject of a block device is
fairly hard, though; beyond having the driver not oops, you also have
to potentially deal with mounted filesystems going away.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Sat, 3 Feb 2001, David Hinds wrote:

> Fairly rarely; there are currently around 15 types of cards that have
> override files for broken CIS information.

So is it reasonable to use the same kind of fixup approach that we do with 
broken PCI devices? If the core code _really_ has to know about it it 
does, else the driver fixes it up?

> I would probably agree.  Dealing with hot eject of a block device is
> fairly hard, though; beyond having the driver not oops, you also have
> to potentially deal with mounted filesystems going away.

Excuses, excuses :) It all wants fixing. Until you can have half-witted 
consumers plugging and unplugging PCMCIA devices at will, PCMCIA support 
on embedded consumer devices in Linux just isn't worth having.

-- 
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

David Woodhouse wrote:

> > > -- There is no mechanism to request a card eject in the new framework.
> > >    This is required for clean shutdown of SCSI and IDE adapters.
> 
> It's arguable that this is a bug in the SCSI and IDE drivers. Users _do_ 
> just pull cards out. We should deal with it, not oops and die. This is a 
> fundamental part of what hotplugging means, especially to users of 
> consumer devices.

That sounds like two related mechanisms, not one.  A "clean shutdown"
request to a driver is a different thing than a "device is gone" notification,
even if sometimes the end state will be similar.

I pretty much think both are needed ... clean shutdown is pretty similar
to what should be done before a power management suspend, right?
There are a bunch of other reasons to have a clean shutdown call.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Hinds wrote:
> 
> On Sat, Feb 03, 2001 at 07:27:26PM +0000, David Woodhouse wrote:
> >
> > How often is this used?
> 
> Fairly rarely; there are currently around 15 types of cards that have
> override files for broken CIS information.

Would you enumerate these or else explain how we can gather
this information ourselves?  Is it just a matter of reading
driver code or looking in specific configuration files in the
pcmcia-cs package?

> > It's arguable that this is a bug in the SCSI and IDE drivers. Users _do_
> > just pull cards out. We should deal with it, not oops and die. This is a
> > fundamental part of what hotplugging means, especially to users of
> > consumer devices.
> 
> I would probably agree.  Dealing with hot eject of a block device is
> fairly hard, though; beyond having the driver not oops, you also have
> to potentially deal with mounted filesystems going away.

It seems like we should both:

1.  Not OOPS when cards are ejected without warning

2.  Have a cardmgr equivalent that schedules a device removal,
    triggering notices to a user to (for example) unmount 
    partitions before removing a cardbus card.  

It seems like there has been general agreement that a cardmgr
replacement is needed, but (IIRC) the replacement hasn't been
well-defined.  Can we start nailing this down, so we can begin
work on building it?

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Keith Owens]

FWIW there has been some discussion between kernel developers about
redesigning the module load/unload mechanism.  Rusty Russell points out
that controlling module use counts by exporting the module structure
via the owner field does not work when the use count needs to be
manipulated from an interrupt.  In Rusty's case he is thinking about
netfilter, but the same point applies to hot unplugging.

Current thinking is to change modules so they have four required
functions, instead of the current two functions.

  init:		Allocate resources.
  register:	Make services available.
  unregister:	Remove services.
  exit:		Deallocate resources.

Module startup automatically calls init then register.  Conditional
shutdown checks for zero use count, calls unregister then flushes any
other cpus that had just entered the module.  If the flush was
successful, call exit.  If the flush was unsuccessful (somebody just
started using the module), call register to make the services available
again.

There is also an unconditional shutdown mode.  Call unregister and even
if the module is still in use, do not call register again.  When the
use count finally goes to zero, the exit routine is called and the
module is removed.

I think this will help hot unplugging.  When the device disappears, the
driver internally marks its hardware as unusable and schedules an
unconditional shutdown of itself, all out of the interrupt handler.

Unconditional shutdown calls unregister which stops any new code
entering the module.  The driver returns -EIO for all outstanding
requests which will eventually result in the outstanding users calling
close() or its equivalent and leaving the module.  When the use count
finally goes to zero, exit releases the resources and the module is
removed.  For built in code we do almost the same, the only difference
is that built in code is not removed from memory.


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Woodhouse wrote:

[...]
> > > -- 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.
> 
> Or specific drivers for the PCI drivers need to be provided. The i82365
> driver with all the PCI stuff is a horrible mess. I tried putting back the
> non-CardBus PCI support at one point. It was ugly, and didn't work.
> Someone's now working on a driver for the Intel i82092AA bridge, and I
> think that's the best answer for the other PCI-PCMCIA bridges too, rather
> than merging it back into the ISA i82365 code.

Well, would care to elaborate on what the PCI mess is, exactly?  

I like the idea of not overloading drivers, if overloading leads to 
horribly complex or unmaintainable code.  Is there any generic code in
the 
i82365 driver that you think should be split out and included in drivers
for the various bridge drivers?

[...]
> I was actually coming to the conclusion that I'd prefer just to ditch the
> whole of the existing PCMCIA support and rewrite it from scratch as a kind
> of hot-pluggable isapnp, which is basically what it is (when you remember
> that PCMCIA != CardBus).

Why do you think the codebase needs to be jettisoned?

Which do you think should happen first:  you develop an exploratory 
implementation or have a general discussion of design issues?

My preference would be, if we decide to start fresh, that Linus
participate 
in the design process.  This worked well during the early design stage
for
the /sbin/hotplug design.

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Sat, Feb 03, 2001 at 06:00:05PM -0800, Miles Lane wrote:

> > Fairly rarely; there are currently around 15 types of cards that have
> > override files for broken CIS information.
> 
> Would you enumerate these or else explain how we can gather
> this information ourselves? 

/etc/pcmcia/cis/*.dat are the override files; they are referenced
from /etc/pcmcia/config.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Sat, 3 Feb 2001, Miles Lane wrote:

> Well, would care to elaborate on what the PCI mess is, exactly?  

See attached patch. 

> I like the idea of not overloading drivers, if overloading leads to 
> horribly complex or unmaintainable code.  Is there any generic code in
> the 
> i82365 driver that you think should be split out and included in drivers
> for the various bridge drivers?

Some, yes. But I'm not sure there's enough there to justify doing so.

> Why do you think the codebase needs to be jettisoned?

It appears to be based on the PCMCIA spec. It allows for silly legacy 
drivers which work with only certain IRQs and IO addresses - sort of 
ioremap(MAP_FIXED) stuff. It's complex, racy, overdesigned, the layering 
is wrong... oh and it uses sleep_on() :)

I don't want that to come across as a criticism of David Hinds; there are 
reasons why some of it was specified like that, and maybe the code for 
other operating systems actually requires some of the stuff which appears 
in Linux to be superfluous. 

In another conversation, Linus has agreed with my assessment. 

> Which do you think should happen first:  you develop an exploratory 
> implementation or have a general discussion of design issues?

I'm in the middle of writing JFFS2 at the moment. An exploratory 
implementation isn't going to happen for a while. I think a discussion of 
design issues is worth having.

Bearing in mind that it's first thing on a Sunday morning and I haven't 
really fleshed this out very much yet (i.e. be kind), here's my basic 
idea.

Remove cardmgr completely. It doesn't do anything that can't be done from
an improved /sbin/hotplug usermodehelper.

We use the 'hotplug isapnp' concept. Pick fields which can be used in 
place of manufacturer and device ID to identify devices and match them 
with drivers. PCMCIA devices actually have mfr and device IDs - I'm not 
sure how reliable they are. They can also have a text string.

As with PCI, drivers register with the core PCMCIA code a pcmcia_device_id
table which identifies a superset of the devices they want to drive.  
Further elimination is done by the driver's probe() routine, which can 
check the CIS if it needs to, or check for the existing of the letters 
'modem' in the text string, etc. 

Upon arrival of a card, the CIS is parsed by the core code and turned into 
a set of resource structs in the pcmcia_dev_t, just like PCI. If 
necessary, a driver can fix these up before calling 
pcmcia_enable_device(). We probably want a way for resources to be enabled 
individually, rather than in one go with pcmcia_enable_device. Especially 
because some of them (attribute memory space/normal memory space) are 
mutually exclusive. 

The 'bus' abstraction is useful - see include/pcmcia/bus_ops.h. But also 
'grep --context=2 doesn include/linux/mtd/map.h' :) But now might not be 
the time to push that, as apparently Linus doesn't like it. I don't want 
that argument to get in the way. 

Core PCMCIA code has functions for parsing a CIS, doing the necessary 
resets and delays when cards are inserted, etc. Nothing on top of the 
socket drivers like ds.o at the moment. 

Expose the CIS to userspace via /proc/bus/pcmcia as a whole. We don't care 
if we have to duplicate the CIS parsing code in userspace and it's 
already in the kernel. 

Some way for userspace to override which driver gets to 'bind' to a
particular card? Maybe, but not with the ugly 'bind' stuff we already
have, and not by requiring userspace to get involved every time. Maybe
just 'echo drivername > /proc/bus/pcmcia/00/driver' and use 'drivername'
as an extra field to match in the core code when seeking a driver to go
with any particular card?


-- 
dwmw2




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Sun, 4 Feb 2001, David Hinds wrote:

> /etc/pcmcia/cis/*.dat are the override files; they are referenced
> from /etc/pcmcia/config.

So there's enough information in the real CIS to identify the offending 
device? What problems are fixed by the replacement CIS structures? Missing 
resources &c? Anything which couldn't be overloaded by a driver in its 
probe() routine before attempting to activate the card?


-- 
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> Module startup automatically calls init then register.  Conditional
> shutdown checks for zero use count, calls unregister then flushes any
> other cpus that had just entered the module.  If the flush was

Flushing ? How ?

> successful, call exit.  If the flush was unsuccessful (somebody just
> started using the module), call register to make the services available
> again.

Doing so means that there's a time where the device is unregistered
illegitimately. Wouldn't it be simpler to take the big kernel lock for the 
check ? The unregistering would have to take it anyway.

> There is also an unconditional shutdown mode.  Call unregister and even
> if the module is still in use, do not call register again.  When the
> use count finally goes to zero, the exit routine is called and the
> module is removed.

This is definitely needed, but why two calls for that ? It would be easier to
provide a callback to be called when the use count reaches zero.

> I think this will help hot unplugging.  When the device disappears, the
> driver internally marks its hardware as unusable and schedules an
> unconditional shutdown of itself, all out of the interrupt handler.

Is that really necessary ? Can't a kernel thread be used ? It is much easier
than coding in interrupt.

> Unconditional shutdown calls unregister which stops any new code
> entering the module.  The driver returns -EIO for all outstanding
> requests which will eventually result in the outstanding users calling
> close() or its equivalent and leaving the module.  When the use count
> finally goes to zero, exit releases the resources and the module is
> removed.  For built in code we do almost the same, the only difference
> is that built in code is not removed from memory.

That is wise.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Sat, 3 Feb 2001, Miles Lane wrote:

> Well, would care to elaborate on what the PCI mess is, exactly?  

Er... I seem to have lied about the patch being attached. 

Index: i82365.c
=================================RCS file: /net/passion/inst/cvs/linux/drivers/pcmcia/Attic/i82365.c,v
retrieving revision 1.1.2.15
diff -u -r1.1.2.15 i82365.c
--- i82365.c	2000/11/17 09:35:49	1.1.2.15
+++ i82365.c	2000/11/19 17:31:07
@@ -142,6 +142,18 @@
 MODULE_PARM(wakeup, "i");
 #endif
 
+#ifdef CONFIG_PCI
+static int pci_irq_list[8] = { 0 };	/* PCI interrupt assignments */
+static int do_pci_probe = 1;		/* Scan for PCI bridges? */
+static int fast_pci = -1;
+static int irq_mode = -1;		/* Override BIOS routing? */
+
+MODULE_PARM(pci_irq_list, "1-8i");
+MODULE_PARM(do_pci_probe, "i");
+MODULE_PARM(fast_pci, "i");
+MODULE_PARM(irq_mode, "i");
+#endif
+
 MODULE_PARM(do_scan, "i");
 MODULE_PARM(poll_interval, "i");
 MODULE_PARM(cycle_time, "i");
@@ -153,11 +165,27 @@
 MODULE_PARM(setup_time, "i");
 MODULE_PARM(cmd_time, "i");
 MODULE_PARM(recov_time, "i");
+#if defined(CONFIG_ISA) && defined(CONFIG_PCI)
+int pci_csc = 1;		/* PCI card status irqs? */
+int pci_int = 1;		/* PCI IO card irqs? */
+MODULE_PARM(pci_csc, "i");
+MODULE_PARM(pci_int, "i");
+#elif defined(CONFIG_ISA) && !defined(CONFIG_PCI)
+#define pci_csc		0
+#define pci_int		0
+#elif !defined(CONFIG_ISA) && defined(CONFIG_PCI)
+#define pci_csc		0
+#define pci_int		1		/* We must use PCI irq's */
+#else
+#error "No bus architectures defined!"
+#endif
 
+
 /*==================================*/
 
 typedef struct cirrus_state_t {
     u_char		misc1, misc2;
+    u_char		ectl1;
     u_char		timer[6];
 } cirrus_state_t;
 
@@ -165,6 +193,17 @@
     u_char		ctl, ema;
 } vg46x_state_t;
 
+typedef struct o2micro_state_t {
+    u_char		mode_a;		/* O2_MODE_A */
+    u_char		mode_b;		/* O2_MODE_B */
+    u_char		mode_c;		/* O2_MODE_C */
+    u_char		mode_d;		/* O2_MODE_D */
+    u_char		mhpg;		/* O2_MHPG_DMA */
+    u_char		fifo;		/* O2_FIFO_ENA */
+    u_char		mode_e;		/* O2_MODE_E */
+} o2micro_state_t;
+
+
 typedef struct socket_info_t {
     u_short		type, flags;
     socket_cap_t	cap;
@@ -176,9 +215,15 @@
 #ifdef CONFIG_PROC_FS
     struct proc_dir_entry *proc;
 #endif
+    u_char		pci_irq_code;
+    u_char		revision;
+#ifdef CONFIG_PCI
+    struct pci_dev	*dev;
+#endif
     union {
 	cirrus_state_t		cirrus;
 	vg46x_state_t		vg46x;
+	o2micro_state_t		o2micro;
     } state;
 } socket_info_t;
 
@@ -216,6 +261,18 @@
     IS_IBM, IS_RF5Cx96, IS_VLSI, IS_VG468, IS_VG469,
     IS_PD6710, IS_PD672X, IS_VT83C469,
 #endif
+#ifdef CONFIG_PCI
+    /*
+     * There are many cards which were supported by the i82365 driver
+     * in the standalone package, but which are not listed here.
+     * This is because they are CardBus-capable and hence now supported
+     * by the Yenta driver.
+     */
+    IS_I82092AA, IS_OM82C092G, 			/* Intel 82092-based */
+    IS_PD6729, IS_PD6730, 			/* Cirrus */
+    IS_OZ6729, IS_OZ6730, 			/* O2Micro  */
+    IS_UNK_PCI
+#endif
 } pcic_id;
 
 /* Flags for classifying groups of controllers */
@@ -251,7 +308,86 @@
     { "Cirrus PD672x", IS_CIRRUS },
     { "VIA VT83C469", IS_CIRRUS|IS_VIA },
 #endif
+#ifdef CONFIG_PCI
+    { "Intel 82092AA", IS_PCI },
+    { "Omega Micro 82C092G", IS_PCI },
+    { "Cirrus PD6729", IS_CIRRUS|IS_PCI },
+    { "Cirrus PD6730", IS_CIRRUS|IS_PCI },
+    { "O2Micro OZ6729", IS_O2MICRO|IS_PCI|IS_VG_PWR },
+    { "O2Micro OZ6730", IS_O2MICRO|IS_PCI|IS_VG_PWR },
+    { "Unknown", IS_PCI|IS_UNKNOWN },
+#endif
+};
+
+#ifdef CONFIG_PCI
+static struct pci_device_id i82365_pci_ids[] = {
+	{	
+		vendor: PCI_VENDOR_ID_INTEL,
+		device: PCI_DEVICE_ID_INTEL_82092AA_0,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_I82092AA
+	}, {
+		vendor: PCI_VENDOR_ID_OMEGA,
+		device: PCI_DEVICE_ID_OMEGA_82C092G,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OM82C092G
+	}, {
+		vendor: PCI_VENDOR_ID_CIRRUS,
+		device: PCI_DEVICE_ID_CIRRUS_6729,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_PD6729
+	}, {
+		vendor: PCI_VENDOR_ID_CIRRUS,
+		device: PCI_ANY_ID,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: PCI_CLASS_BRIDGE_PCMCIA,
+		class_mask: 0xffff,
+		driver_data: IS_PD6730
+	}, {
+		vendor: PCI_VENDOR_ID_O2,
+		device: PCI_DEVICE_ID_O2_6729,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OZ6729
+	}, {
+		vendor: PCI_VENDOR_ID_O2,
+		device: PCI_DEVICE_ID_O2_6730,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OZ6730
+	}, {
+		vendor: PCI_ANY_ID,
+		device: PCI_ANY_ID,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: PCI_CLASS_BRIDGE_PCMCIA,
+		class_mask: 0xffff,
+		driver_data: IS_UNK_PCI
+	},
+	{ /* Terminating entry */ }
+};
+
+static int i82365_pci_probe(struct pci_dev *dev, const struct pci_device_id *id);
+static void i82365_pci_remove(struct pci_dev *dev);
+
+static struct pci_driver i82365_pci_drv = {
+	name:		"i82365",
+	id_table:	i82365_pci_ids,
+	probe:		i82365_pci_probe,
+	remove:		i82365_pci_remove,
+	suspend:	NULL,
+	resume:		NULL
 };
+#endif
 
 #define PCIC_COUNT	(sizeof(pcic)/sizeof(pcic_t))
 
@@ -315,6 +451,22 @@
     i365_set(sock, reg+1, data >> 8);
 }
 
+#ifdef CONFIG_PCI
+
+static int __init get_pci_irq(u_short s)
+{
+    socket_info_t *t = &socket[s];
+    u8 irq;
+
+    irq = t->dev->irq;
+    if ((irq = 0) && (pci_csc || pci_int))
+	irq = pci_irq_list[t - socket];
+    if (irq >= NR_IRQS) irq = 0;
+    t->cap.pci_irq = irq;
+    return irq;
+}
+
+#endif
 /*===================================
 
     Code to save and restore global state information for Cirrus
@@ -384,6 +536,23 @@
 	if (p->misc2 & PD67_MC2_FREQ_BYPASS)
 	    strcat(buf, " [freq bypass]");
 	}
+#ifdef CONFIG_PCI
+    } else {
+	p->misc1 &= ~PD67_MC1_MEDIA_ENA;
+	p->misc1 &= ~(PD67_MC1_PULSE_MGMT | PD67_MC1_PULSE_IRQ);
+	p->ectl1 &= ~(PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ);
+	flip(p->misc2, PD67_MC2_FAST_PCI, fast_pci);
+	if (p->misc2 & PD67_MC2_IRQ15_RI)
+	    mask &= (t->type = IS_PD6730) ? ~0x0400 : ~0x8000;
+	if ((irq_mode = 1) && get_pci_irq(s)) {
+	    /* Configure PD6729 bridge for PCI interrupts */
+	    p->ectl1 |= PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ;
+	    t->pci_irq_code = 3; /* PCI INTA = "irq 3" */
+	    buf += strlen(buf);
+	    sprintf(buf, " [pci irq %d]", t->cap.pci_irq);
+	    mask = 0;
+	}
+#endif
     }
     if (!(t->flags & IS_VIA)) {
 	if (setup_time >= 0)
@@ -459,7 +628,79 @@
 
 #endif
 
+/*===================================
+
+    Code to save and restore global state information for O2Micro
+    controllers, and to set and report global configuration options.
+    
+===================================*/
+
+#ifdef CONFIG_PCI
+
+static void __init o2micro_get_state(u_short s)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+
+    if (((socket[s].revision & 0xff) = 0x34) || 
+	((socket[s].revision & 0xff) = 0x62)) {
+	p->mode_a = i365_get(s, O2_MODE_A_2);
+	p->mode_b = i365_get(s, O2_MODE_B_2);
+    } else {
+	p->mode_a = i365_get(s, O2_MODE_A);
+	p->mode_b = i365_get(s, O2_MODE_B);
+    }
+    p->mode_c = i365_get(s, O2_MODE_C);
+    p->mode_d = i365_get(s, O2_MODE_D);
+}
+
+static void o2micro_set_state(u_short s)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+
+    if (((socket[s].revision & 0xff) = 0x34) || 
+	((socket[s].revision & 0xff) = 0x62)) {
+	i365_set(s, O2_MODE_A_2, p->mode_a);
+	i365_set(s, O2_MODE_B_2, p->mode_b);
+    } else {
+	i365_set(s, O2_MODE_A, p->mode_a);
+	i365_set(s, O2_MODE_B, p->mode_b);
+    }
+    i365_set(s, O2_MODE_C, p->mode_c);
+    i365_set(s, O2_MODE_D, p->mode_d);
+}
+
+static u_int __init o2micro_set_opts(u_short s, char *buf)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+    u_int mask = 0xffff;
 
+    p->mode_b = (p->mode_b & ~O2_MODE_B_IDENT) | O2_MODE_B_ID_CSTEP;
+    flip(p->mode_b, O2_MODE_B_IRQ15_RI, has_ring);
+    p->mode_c &= ~(O2_MODE_C_ZVIDEO | O2_MODE_C_DREQ_MASK);
+
+    if (p->mode_b & O2_MODE_B_IRQ15_RI) {
+	mask &= ~0x8000;
+	strcat(buf, " [ring]");
+    }
+    if (irq_mode != -1)
+	p->mode_d = irq_mode;
+    if (p->mode_d & O2_MODE_D_ISA_IRQ) {
+	strcat(buf, " [pci+isa]");
+    } else {
+	switch (p->mode_d & O2_MODE_D_IRQ_MODE) {
+	case O2_MODE_D_IRQ_PCPCI:
+	    strcat(buf, " [pc/pci]"); break;
+	case O2_MODE_D_IRQ_PCIWAY:
+	    strcat(buf, " [pci/way]"); break;
+	case O2_MODE_D_IRQ_PCI:
+	    strcat(buf, " [pci only]"); mask = 0; break;
+	}
+    }
+    return mask;
+}
+
+#endif
+
 /*===================================
 
     Generic routines to get and set controller options
@@ -475,6 +716,10 @@
     else if (t->flags & IS_VADEM)
 	vg46x_get_state(s);
 #endif
+#ifdef CONFIG_PCI
+    else if (t->flags & IS_O2MICRO)
+	o2micro_get_state(s);
+#endif
 }
 
 static void set_bridge_state(u_short s)
@@ -491,6 +736,10 @@
     if (t->flags & IS_VADEM)
 	vg46x_set_state(s);
 #endif
+#ifdef CONFIG_PCI
+    if (t->flags & IS_O2MICRO)
+	o2micro_set_state(s);
+#endif
 }
 
 static u_int __init set_bridge_opts(u_short s, u_short ns)
@@ -512,6 +761,10 @@
 	else if (socket[i].flags & IS_VADEM)
 	    m = vg46x_set_opts(i, buf);
 #endif
+#ifdef CONFIG_PCI
+	else if (socket[i].flags & IS_O2MICRO)
+	    m = o2micro_set_opts(s+i, buf);
+#endif
 	set_bridge_state(i);
 	printk(KERN_INFO "    host opts [%d]:%s\n", i,
 	       (*buf) ? buf : " none");
@@ -535,12 +788,15 @@
     DEBUG(2, "-> hit on irq %d\n", irq);
 }
 
-static u_int __init test_irq(u_short sock, int irq)
+static u_int __init test_irq(u_short sock, int irq, int pci)
 {
-    DEBUG(2, "  testing ISA irq %d\n", irq);
+    int csc = (pci) ? 0 : irq;
+
+    DEBUG(2, "  testing %s irq %d\n", pci?"PCI":"ISA", irq);
     if (request_irq(irq, irq_count, 0, "scan", irq_count) != 0)
 	return 1;
-    irq_hits = 0; irq_sock = sock;
+    irq_hits = 0;
+    irq_sock = sock;
     __set_current_state(TASK_UNINTERRUPTIBLE);
     schedule_timeout(HZ/100);
     if (irq_hits) {
@@ -550,7 +806,7 @@
     }
 
     /* Generate one interrupt */
-    i365_set(sock, I365_CSCINT, I365_CSC_DETECT | (irq << 4));
+    i365_set(sock, I365_CSCINT, I365_CSC_DETECT | (csc << 4));
     i365_bset(sock, I365_GENCTL, I365_CTL_SW_IRQ);
     udelay(1000);
 
@@ -560,7 +816,10 @@
     i365_set(sock, I365_CSCINT, 0);
     DEBUG(2, "    hits = %d\n", irq_hits);
     
-    return (irq_hits != 1);
+    if (pci)
+	    return (irq_hits = 0);
+    else
+	    return (irq_hits != 1);
 }
 
 #ifdef CONFIG_ISA
@@ -580,10 +839,10 @@
 	set_bridge_state(sock);
 	i365_set(sock, I365_CSCINT, 0);
 	for (i = 0; i < 16; i++)
-	    if ((mask0 & (1 << i)) && (test_irq(sock, i) = 0))
+	    if ((mask0 & (1 << i)) && (test_irq(sock, i, 0) = 0))
 		mask1 |= (1 << i);
 	for (i = 0; i < 16; i++)
-	    if ((mask1 & (1 << i)) && (test_irq(sock, i) != 0))
+	    if ((mask1 & (1 << i)) && (test_irq(sock, i, 0) != 0))
 		mask1 ^= (1 << i);
     }
     
@@ -611,6 +870,22 @@
 
 #endif /* CONFIG_ISA */
 
+#ifdef CONFIG_PCI
+static int __init pci_scan(u_short sock)
+{
+    socket_info_t *t = &socket[sock];
+
+    /* for PCI-to-PCMCIA bridges, just check for wedged irq */
+    irq_sock = sock; irq_hits = 0;
+    if (request_irq(t->cap.pci_irq, irq_count, 0, "scan", irq_count))
+	    return 1;
+    udelay(50);
+    free_irq(t->cap.pci_irq, irq_count);
+    DEBUG(2,"pci_scan: %d hits on IRQ %d\n", irq_hits, t->cap.pci_irq);
+    return (!irq_hits);
+}
+#endif /* CONFIG_PCI */
+
 /*==================================*/
 
 /* Time conversion functions */
@@ -629,7 +904,7 @@
 
 #ifdef CONFIG_ISA
 
-static int __init identify(u_short port, u_short sock)
+static int __init isa_identify(u_short port, u_short sock)
 {
     u_char val;
     int type = -1;
@@ -741,8 +1016,17 @@
     
     if (base = 0) printk("\n");
     printk(KERN_INFO "  %s", pcic[type].name);
-    printk(" ISA-to-PCMCIA at port %#x ofs 0x%02x",
-	       t->ioaddr, t->psock*0x40);
+#ifdef CONFIG_PCI
+    if (t->flags & IS_UNKNOWN)
+	    printk(" [%04x %04x]", t->dev->vendor, t->dev->device);
+    printk(" rev %02x", t->revision);
+    if (t->flags & IS_PCI)
+	    printk(" PCI-to-PCMCIA at slot %02x:%02x, port %#x",
+		   t->dev->bus->number, PCI_SLOT(t->dev->devfn), t->ioaddr);
+    else
+#endif
+	    printk(" ISA-to-PCMCIA at port %#x ofs 0x%02x",
+		   t->ioaddr, t->psock*0x40);
     printk(", %d socket%s\n", ns, ((ns > 1) ? "s" : ""));
 
 #ifdef CONFIG_ISA
@@ -754,13 +1038,27 @@
 	    mask |= (1<<irq_list[i]);
 #endif
     mask &= I365_MASK & set_bridge_opts(base, ns);
+#ifdef CONFIG_PCI
+    /* Can we use PCI interrupts for card status changes? */
+    if (pci_csc || pci_int) {
+	for (i = base; i < base + ns; i++)
+		if (!socket[i].cap.pci_irq || test_irq(i, socket[i].cap.pci_irq, 1)) break;
+	use_pci = (i=ns);
+    }
+#endif
 #ifdef CONFIG_ISA
     /* Scan for ISA interrupts */
     mask = isa_scan(base, mask);
-#else
-    printk(KERN_INFO "    PCI card interrupts,");
+#endif
+
+#ifdef CONFIG_PCI
+    if (!mask)
+	printk(KERN_INFO "    %s card interrupts,",
+	       (use_pci && pci_int) ? "PCI" : "*NO*");
+    if (use_pci && pci_csc)
+	printk(" PCI status changes\n");
 #endif
-        
+  
 #ifdef CONFIG_ISA
     /* Poll if only two interrupts available */
     if (!use_pci && !poll_interval) {
@@ -770,7 +1068,8 @@
 	    poll_interval = HZ;
     }
     /* Only try an ISA cs_irq if this is the first controller */
-    if (!use_pci && !grab_irq && (cs_irq || !poll_interval)) {
+    if (!(use_pci && pci_csc) && !grab_irq &&
+	(cs_irq || !poll_interval)) {
 	/* Avoid irq 12 unless it is explicitly requested */
 	u_int cs_mask = mask & ((cs_irq) ? (1<<cs_irq) : ~(1<<12));
 	for (cs_irq = 15; cs_irq > 0; cs_irq--)
@@ -785,7 +1084,7 @@
     }
 #endif
     
-    if (!use_pci && !isa_irq) {
+    if (!(use_pci && pci_csc) && !isa_irq) {
 	if (poll_interval = 0)
 	    poll_interval = HZ;
 	printk(" polling interval = %d ms\n",
@@ -798,6 +1097,8 @@
 	t[i].cap.features |= SS_CAP_PCCARD;
 	t[i].cap.map_size = 0x1000;
 	t[i].cap.irq_mask = mask;
+	if (!use_pci)
+	    t[i].cap.pci_irq = 0;
 	t[i].cs_irq = isa_irq;
     }
 
@@ -819,13 +1120,13 @@
 	return;
     }
 
-    id = identify(i365_base, 0);
-    if ((id = IS_I82365DF) && (identify(i365_base, 1) != id)) {
+    id = isa_identify(i365_base, 0);
+    if ((id = IS_I82365DF) && (isa_identify(i365_base, 1) != id)) {
 	for (i = 0; i < 4; i++) {
 	    if (i = ignore) continue;
 	    port = i365_base + ((i & 1) << 2) + ((i & 2) << 1);
 	    sock = (i & 1) << 1;
-	    if (identify(port, sock) = IS_I82365DF) {
+	    if (isa_identify(port, sock) = IS_I82365DF) {
 		add_socket(port, sock, IS_VLSI);
 		add_pcic(1, IS_VLSI);
 	    }
@@ -834,12 +1135,12 @@
 	for (i = 0; i < (extra_sockets ? 8 : 4); i += 2) {
 	    port = i365_base + 2*(i>>2);
 	    sock = (i & 3);
-	    id = identify(port, sock);
+	    id = isa_identify(port, sock);
 	    if (id < 0) continue;
 
 	    for (j = ns = 0; j < 2; j++) {
 		/* Does the socket exist? */
-		if ((ignore = i+j) || (identify(port, sock+j) < 0))
+		if ((ignore = i+j) || (isa_identify(port, sock+j) < 0))
 		    continue;
 		/* Check for bad socket decode */
 		for (k = 0; k <= sockets; k++)
@@ -857,6 +1158,47 @@
 
 #endif
 
+#ifdef CONFIG_PCI
+static void pcic_interrupt(int irq, void *dev,
+			   struct pt_regs *regs);
+
+static int i82365_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+    socket_info_t *s = &socket[sockets];
+    int type = id->driver_data;
+    unsigned long addr;
+    int ns;
+ 
+    dev->driver_data = (void *)sockets;
+    printk("i82365_pci_probe\n");
+
+    if (pci_enable_device(dev))
+	return -EIO;
+    
+    addr = dev->resource[0].start & ~1;
+    for (ns=0; ns < ((type = IS_I82092AA) ? 4 : 2); ns++) {
+	s[ns].dev = dev;
+	s[ns].cap.pci_irq = dev->irq;
+	pci_read_config_byte(dev, PCI_REVISION_ID, &s[ns].revision);
+	add_socket(addr, ns, type);
+    }
+
+    add_pcic(ns, type);
+    if (pci_csc && s[0].cap.pci_irq)
+	request_irq(dev->irq, pcic_interrupt, SA_SHIRQ, "i82365", pcic_interrupt);
+    return 0;
+
+}
+static void i82365_pci_remove(struct pci_dev *dev)
+{
+    u_short s = (u_short)dev->driver_data;
+    
+    if (pci_csc && socket[s].cap.pci_irq)
+	free_irq(dev->irq, pcic_interrupt);
+}
+
+#endif
+
 /*==================================*/
 
 static u_int pending_events[8];
@@ -980,6 +1322,20 @@
     *value |= (status & I365_CS_READY) ? SS_READY : 0;
     *value |= (status & I365_CS_POWERON) ? SS_POWERON : 0;
 
+#ifdef CONFIG_PCI
+    if (socket[sock].flags & IS_O2MICRO) {
+	status = i365_get(sock, O2_MODE_B);
+	*value |= (status & O2_MODE_B_VS1) ? 0 : SS_3VCARD;
+	*value |= (status & O2_MODE_B_VS2) ? 0 : SS_XVCARD;
+    } else if (socket[sock].type = IS_PD6729) {
+	status = pd67_ext_get(sock + (1-socket[sock].psock), PD67_EXTERN_DATA);
+	*value |= (status & PD67_EXD_VS1(socket[sock].psock)) ? 0 : SS_3VCARD;
+	*value |= (status & PD67_EXD_VS2(socket[sock].psock)) ? 0 : SS_XVCARD;
+    }
+    /* For now, ignore cards with unsupported voltage keys */
+    if (*value & SS_XVCARD)
+	*value &= ~(SS_DETECT|SS_3VCARD|SS_XVCARD);
+#endif
 #ifdef CONFIG_ISA
     if (socket[sock].type = IS_VG469) {
 	status = i365_get(sock, VG469_VSENSE);
@@ -1044,7 +1400,13 @@
     reg = i365_get(sock, I365_INTCTL);
     state->flags |= (reg & I365_PC_RESET) ? 0 : SS_RESET;
     if (reg & I365_PC_IOCARD) state->flags |= SS_IOCARD;
-    state->io_irq = reg & I365_IRQ_MASK;
+
+#ifdef CONFIG_PCI
+    if (socket[sock].cap.pci_irq)
+	    state->io_irq = socket[sock].cap.pci_irq;
+    else
+#endif
+	    state->io_irq = reg & I365_IRQ_MASK;
     
     /* speaker control */
     if (t->flags & IS_CIRRUS) {
@@ -1084,8 +1446,8 @@
     set_bridge_state(sock);
     
     /* IO card, RESET flag, IO interrupt */
-    reg = t->intr;
-    if (state->io_irq != t->cap.pci_irq) reg |= state->io_irq;
+    reg = t->intr | ((state->io_irq = t->cap.pci_irq) ?
+		     t->pci_irq_code : state->io_irq);
     reg |= (state->flags & SS_RESET) ? 0 : I365_PC_RESET;
     reg |= (state->flags & SS_IOCARD) ? I365_PC_IOCARD : 0;
     i365_set(sock, I365_INTCTL, reg);
@@ -1164,7 +1526,7 @@
     }
     
     /* Card status change interrupt mask */
-    reg = t->cs_irq << 4;
+    reg =  (t->cap.pci_irq ? t->pci_irq_code : t->cs_irq) << 4;
     if (state->csc_mask & SS_DETECT) reg |= I365_CSC_DETECT;
     if (state->flags & SS_IOCARD) {
 	if (state->csc_mask & SS_STSCHG) reg |= I365_CSC_STSCHG;
@@ -1261,6 +1623,13 @@
     mem->card_start = ((u_int)(i & 0x3fff) << 12) + mem->sys_start;
     mem->card_start &= 0x3ffffff;
     
+#ifdef CONFIG_PCI
+    /* Take care of high byte, for PCI controllers */
+    if (socket[sock].type = IS_PD6729) {
+	i365_set(sock, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	addr = i365_get(sock, PD67_EXT_DATA) << 24;
+    }
+#endif
     DEBUG(1, "i82365: GetMemMap(%d, %d) = %#2.2x, %d ns, %#5.5lx-%#5."
 	  "5lx, %#5.5x\n", sock, mem->map, mem->flags, mem->speed,
 	  mem->sys_start, mem->sys_stop, mem->card_start);
@@ -1290,6 +1659,13 @@
     if (i365_get(sock, I365_ADDRWIN) & I365_ENA_MEM(map))
 	i365_bclr(sock, I365_ADDRWIN, I365_ENA_MEM(map));
     
+#ifdef CONFIG_PCI
+    /* Take care of high byte, for PCI controllers */
+    if (socket[sock].type = IS_PD6729) {
+	i365_set(sock, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	i365_set(sock, PD67_EXT_DATA, (mem->sys_start >> 24));
+    }
+#endif
     base = I365_MEM(map);
     i = (mem->sys_start >> 12) & 0x0fff;
     if (mem->flags & MAP_16BIT) i |= I365_MEM_16BIT;
@@ -1332,6 +1708,12 @@
     char *p = buf;
     p += sprintf(p, "type:     %s\npsock:    %d\n",
 		 pcic[s->type].name, s->psock);
+#ifdef CONFIG_PCI
+    if (s->flags & (IS_PCI))
+	p += sprintf(p, "bus:      %02x\ndevfn:    %02x.%1x\n",
+		     s->dev->bus->number, PCI_SLOT(s->dev->devfn),
+		     PCI_FUNC(s->dev->devfn));
+#endif
     return (p - buf);
 }
 
@@ -1361,6 +1743,26 @@
     return (p - buf);
 }
 
+#ifdef CONFIG_PCI
+static int proc_read_pci(char *buf, char **start, off_t pos,
+			  int count, int *eof, void *data)
+{
+    struct pci_dev *dev = ((socket_info_t *)data)->dev;
+    char *p = buf;
+    u_int a, b, c, d;
+    int i;
+    
+    for (i = 0; i < 0xc0; i += 0x10) {
+	pci_read_config_dword(dev, i, &a);
+	pci_read_config_dword(dev, i+4, &b);
+	pci_read_config_dword(dev, i+8, &c);
+	pci_read_config_dword(dev, i+12, &d);
+	p += sprintf(p, "%08x %08x %08x %08x\n", a, b, c, d);
+    }
+    return (p - buf);
+}
+#endif
+
 static void pcic_proc_setup(unsigned int sock, struct proc_dir_entry *base)
 {
     socket_info_t *s = &socket[sock];
@@ -1370,15 +1772,26 @@
 
     create_proc_read_entry("info", 0, base, proc_read_info, s);
     create_proc_read_entry("exca", 0, base, proc_read_exca, s);
+#ifdef CONFIG_PCI
+    if (s->flags & IS_PCI)
+	create_proc_read_entry("pci", 0, base, proc_read_pci, s);
+#endif
     s->proc = base;
 }
 
 static void pcic_proc_remove(u_short sock)
 {
     struct proc_dir_entry *base = socket[sock].proc;
-    if (base = NULL) return;
+
+    if (base = NULL) 
+	return;
+
     remove_proc_entry("info", base);
     remove_proc_entry("exca", base);
+#ifdef CONFIG_PCI
+    if (socket[sock].flags & IS_PCI)
+	remove_proc_entry("pci", base);
+#endif
 }
 
 #else
@@ -1523,12 +1936,19 @@
     printk(KERN_INFO "Intel PCIC probe: ");
     sockets = 0;
 
+#ifdef CONFIG_PCI
+    if (do_pci_probe)
+	pci_register_driver (&i82365_pci_drv);
+#endif
 #ifdef CONFIG_ISA
     isa_probe();
 #endif
-
     if (sockets = 0) {
 	printk("not found.\n");
+#ifdef CONFIG_PCI
+	if (do_pci_probe)
+	    pci_unregister_driver (&i82365_pci_drv);
+#endif
 	return -ENODEV;
     }
 
@@ -1537,7 +1957,7 @@
     if (grab_irq != 0)
 	request_irq(cs_irq, pcic_interrupt, 0, "i82365", pcic_interrupt);
 #endif
-    
+
     if (register_ss_entry(sockets, &pcic_operations) != 0)
 	printk(KERN_NOTICE "i82365: register_ss_entry() failed\n");
 
@@ -1567,6 +1987,11 @@
     if (grab_irq != 0)
 	free_irq(cs_irq, pcic_interrupt);
 #endif
+#ifdef CONFIG_PCI
+    if (do_pci_probe)
+	pci_unregister_driver (&i82365_pci_drv);
+#endif
+
     for (i = 0; i < sockets; i++) {
 	/* Turn off all interrupt sources! */
 	i365_set(i, I365_CSCINT, 0);
Index: i82365.h
=================================RCS file: /net/passion/inst/cvs/linux/drivers/pcmcia/Attic/i82365.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 i82365.h
--- i82365.h	2000/06/07 10:38:28	1.1.2.2
+++ i82365.h	2000/11/19 17:31:07
@@ -132,4 +132,9 @@
 
 #define I365_REG(slot, reg)	(((slot) << 6) + reg)
 
+#define  O2_MODE_D_IRQ_MODE     0x03
+#define  O2_MODE_D_IRQ_PCPCI    0x00
+#define  O2_MODE_D_IRQ_PCIWAY   0x02
+#define  O2_MODE_D_IRQ_PCI      0x03
+
 #endif /* _LINUX_I82365_H */
-- 
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

Upon further reflection (and OK, maybe a cup of tea or two), I think I am
going to try to abstract the bus access functions. 

Rather than making pcmcia_enable_{device,resource} visible to the core 
code and card drivers to enable mapping of certain resources to the host,  
this should probably be handled internally to the socket driver.

Not everything nowadays is an i82365, the bridge chip the PCMCIA spec 
appears to have been written for. Many of the interesting toys I've 
encountered recently don't have to muck about with remapping address 
ranges - the SH3 expects you to map Area 5 and 6 to PCMCIA sockets and the 
IO/attribute lines are taken from the higher bits of the address. 

So the socket drivers should provide access functions for the socket's
address ranges - {attr,mem,io}_{read,write}{8,16,32} and
{attr,mem,io}_copy{to,from}. Mostly, they'll be a simple case of adding an
offset to the requested address and doing the requested operation.

For the now degenerate case where the bridge has to be configured to map
certain addresses, that can be handled internally to the socket driver
reasonably efficiently. The common case will be that the functions will
check, find that there's a window currently pointing at the right place,
and will use it. Sometimes they'll need to change one of the windows to
point at the requested address - but not often. 

I spent a long time trying to avoid this abstraction in the MTD code,
before someone eventually convinced me that unconditional branches really
aren't that difficult for modern CPUs to predict, and the increased
simplicity of the 'map' abstraction was better.

-- 
dwmw2




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Sun, Feb 04, 2001 at 10:00:24AM +0000, David Woodhouse wrote:
> 
> So there's enough information in the real CIS to identify the offending 
> device? What problems are fixed by the replacement CIS structures? Missing 
> resources &c? Anything which couldn't be overloaded by a driver in its 
> probe() routine before attempting to activate the card?

Problems like cards that say they are parallel port devices when they
are serial cards, cards that say they are serial devices when they are
multifunction ethernet/modem cards, and cards that have malformed data
structures that can't be interpreted at all.

Nothing that can't be overloaded in a driver.  But things that were
sufficiently ugly that I did not want to write special case code with
lots of hard-wired information.

I think it may also be more space-efficient to code this information
in CIS structures than to write special case code to handle all the
bugs.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Here's an overview of where we are now.

David Hinds wrote:

> On Wed, Jan 31, 2001 at 08:19:56PM -0800, Miles Lane wrote:
> 
>> Would you be willing to outline all the major things that
>> need to addressed to get full PCMCIA support in 2.5?
> 
> 
> Here is a short list:
> 
> To include 16-bit PCMCIA cards in the hot plug 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.

(Jeff Garzik has volunteered to make required changes to
the PCMCIA network device drivers.  Perhaps he could make
these pcmcia_device_id and pcmcia_driver changes to the 
network drivers, thus creating a reference implementation that 
could then migrate rapidly to the other driver families?)

> -- 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.

Yes.  This seems straightforward.

> -- The CIS override functionality in the PCMCIA package is unpleasant
>    to support in a completely in-kernel framework.

(Discussion has started on linux-hotplug-devel)

===============

> Missing functionality in the hotplug framework:

> 1. 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.

Is it true that doing this is fairly straightforward and
is it something that one person could do?

(No discussion or volunteers for this, yet)

--------------

> 2. There is no mechanism to request a card eject in the new framework.
>    This is required for clean shutdown of SCSI and IDE adapters.

(Rusty Russell and other kernel developers are looking into 
related improvements.  Also, discussion has started on 
linux-hotplug-devel)

--------------

> 3. 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".

Well, solving this problem for PCMCIA devices alone might
be the wrong way to go.  Don't want to meet the need for 
flexible configuration for the general case of all drivers 
for all devices on all hotpluggable busses, if possible?  
If so, then the interesting question is whether any 
configuration needs are unique to PCMCIA configuration.

Perhaps we need two things:  a good outline of the
configuration functionality in pcmcia-cs and a list
of the types of configuration handling we need for
the general hotplug system.

I'm afraid I don't have a very good handle on how this
should all work.  Suggestions?

===============
> Missing functionality in the 2.4 PCMCIA drivers:

> 1. 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.

Huh?  You mean that the driver can't handle _some_ Cardbus adapter
cards, right?  Mine work fine.  As for the issue of many drivers
requiring overrides and special settings, could you please give us
a few examples?  Also, if you would elaborate on why this is a flaw 
in yenta, that would be really helpful.  I'd also like to know if 
you have any thoughts regarding how this flaw might be fixed (vague 
handwaving would be okay, if others could extrapolate from it).

---------------

> 2. 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.

(David Woodhouse will explore fixing this problem)
(Discussion has started on linux-hotplug-devel)


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> Module startup automatically calls init then register.  Conditional
> shutdown checks for zero use count, calls unregister then flushes any
> other cpus that had just entered the module.  If the flush was

Flushing ? How ?

> successful, call exit.  If the flush was unsuccessful (somebody just
> started using the module), call register to make the services available
> again.

Doing so means that there's a time where the device is unregistered
illegitimately. Wouldn't it be simpler to take the big kernel lock for the 
check ? The unregistering would have to take it anyway.

> There is also an unconditional shutdown mode.  Call unregister and even
> if the module is still in use, do not call register again.  When the
> use count finally goes to zero, the exit routine is called and the
> module is removed.

This is definitely needed, but why two calls for that ? It would be easier to
provide a callback to be called when the use count reaches zero.

> I think this will help hot unplugging.  When the device disappears, the
> driver internally marks its hardware as unusable and schedules an
> unconditional shutdown of itself, all out of the interrupt handler.

Is that really necessary ? Can't a kernel thread be used ? It is much easier
than coding in interrupt.

> Unconditional shutdown calls unregister which stops any new code
> entering the module.  The driver returns -EIO for all outstanding
> requests which will eventually result in the outstanding users calling
> close() or its equivalent and leaving the module.  When the use count
> finally goes to zero, exit releases the resources and the module is
> removed.  For built in code we do almost the same, the only difference
> is that built in code is not removed from memory.

That is wise.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Hi David (H),

I am wondering how you managed to get adequate
test coverage for pcmcia-cs.  Did any manufactures
donate or loan equipment to you for testing?
If not, did you determine some subset of hardware
that you could use to exercise the majority of your
drivers' functionality?  If so, could you send me
a list of the devices you test with?

The point is that I'd like to volunteer to do
a large chunk of the testing for the in-kernel
PCMCIA support.  How would you suggest I go about
this?  If you can give me a list of hardware that
is most widely used in the pcmcia-cs user community,
I could go out and build a collection of those
devices.

Lastly, if you know pcmcia-cs users who might be
willing to climb out onto the bleeding edge, would
you ask them if they would be willing to help?

Many thanks!

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Jeff Garzik]

Miles Lane wrote:
> 
> Jeff Garzik wrote:
> >
> > On Fri, 2 Feb 2001, Miles Lane wrote:
> > > I asked David Hinds to write up an outline of the things that
> > > will be needed to get PCMCIA support cleanly and completely
> > > integrated into the kernel tree.
> > >
> > > David has expressed that he'll not be able to participate in
> > > this work.  He has his hands full with his day job and his
> > > role as maintainer/developer of the pcmcia-cs package.
> > [...]
> > > Anyone willing to sign up for some of this effort?
> >
> > I'll convert all the network drivers once a design is agreed upon.
> 
> Would you write up a proposal for this design that we could work
> from to come to a agreed design?  You are probably the best person
> to start this process.

I'm going to finish my current projects first :)

-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "Keith Owens" <kaos@ocs.com.au>
>
> FWIW there has been some discussion between kernel developers about
> redesigning the module load/unload mechanism.  Rusty Russell points out
> that controlling module use counts by exporting the module structure
> via the owner field does not work when the use count needs to be
> manipulated from an interrupt.  In Rusty's case he is thinking about
> netfilter, but the same point applies to hot unplugging.

I'm not sure I'd want module "use" count to be affected by plugging and
unplugging, but I'd like to have that kind of way to track the number of
devices associated with a module!  Normal users won't expect to see
devices become unusable (by driver removal) except by disconnecting,
for all that developers should still be able to hotswap the drivers that
aren't actively using the device.


> Current thinking is to change modules so they have four required
> functions, instead of the current two functions.
> 
>   init: Allocate resources.
>   register: Make services available.
>   unregister: Remove services.
>   exit: Deallocate resources.

I'll have to think on this a bit ... seems initially plausible, but it'll need
to fit neatly with suspend/resume and probe/disconnect processing
and I'll want to think about that.  All of those involve managing some
sort of resource or service.  I can't think of many resources/services
that really ought to be managed at the _module_ level rather than at
the granularity of individual devices ... except for modules that don't
hold device drivers, maybe!


> I think this will help hot unplugging.  When the device disappears, the
> driver internally marks its hardware as unusable and schedules an
> unconditional shutdown of itself, all out of the interrupt handler.

Maybe it won't be detected in_irq() though.  For example, USB device
drivers typically have their disconnect() routines called by real threads.
("khubd", except for root hubs.)

Also, there's the issue that modules can manage multiple devices.
Just because someone unplugged one <foo> adapter doesn't mean
the others should get brought down and the driver removed!!


> Unconditional shutdown calls unregister which stops any new code
> entering the module.  

Then clearly it should not be used with hot-unplug, since driver modules
are typically expected to handle multiple similar devices.  Unplug of one
mustn't affect the others.


>    The driver returns -EIO for all outstanding
> requests which will eventually result in the outstanding users calling
> close() or its equivalent and leaving the module.  When the use count
> finally goes to zero, exit releases the resources and the module is
> removed.  

Until that last "module is removed", it sounded like a reasonable
description of what a usb or pci disconnect() routine has to cause
when it's told that a device has gone away.


>    For built in code we do almost the same, the only difference
> is that built in code is not removed from memory.

I'd like to see that be "built-in modules or ones still coupled to
some connected device" ... so that when the last device owned
by the module goes away, it becomes eligible for removal.


- Dave




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

As we look into developing PCMCIA support in the
2.4/2.5 kernel trees, in addition to reading the
pcmcia-cs code to learn about problems with specific
devices that need to be handled, David Hinds also
a reference page that lists some a bunch of issues
that are in varying degrees of resolution:

	http://pcmcia-cs.sourceforge.net/ftp/BUGS

This may be a useful resource.  I'll see whether
David has time to update this page with a bit more
detailed explanations of the problems.  Some of the
items are pretty vague.  For example,

	the Asix AX88190 chipset, which has
	several serious bugs and incompatibilities
	that render the regular pcnet_cs driver
	unusable

It would be nice to know exactly what those bugs
and incompatibilities are.  :-)

Anyhow, I hope this helps,

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Woodhouse wrote:

> Upon further reflection (and OK, maybe a cup of tea or two), I think I am
> going to try to abstract the bus access functions. 

[...]

David, as you work on this design, would you include
a plan for supporting detection of devices that are
already plugged in at boot time?  This is something
that David Brownell is already working on for 
PCI/Cardbus and USB.  The solutions that DavidB is
exploring leverage the usbmodules and pcimodules tools.
We may need some corresponding tool to interact with 
the kernel PCMCIA stuff you are designing.

Please refer to David Brownell's message to 
linux-hotplug-devel (2-4-2001 @ 7:02PM).

BTW:  I'll be exploring your design over the next
few days and hope to at least have a bit of
constructive feedback for you.  BTW:  It would be
really great if you could talk the folks you are
working with on LKML into joining the linux-hotplug-devel
list.

Thanks for your hard work!

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Keith Owens]

On Sun, 4 Feb 2001 19:16:00 +0100, 
Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de> wrote:
>> Module startup automatically calls init then register.  Conditional
>> shutdown checks for zero use count, calls unregister then flushes any
>> other cpus that had just entered the module.  If the flush was
>
>Flushing ? How ?

Black magic :-).  See synchronize_kernel() in Rusty's recent patch for
hotswap cpus.

>> successful, call exit.  If the flush was unsuccessful (somebody just
>> started using the module), call register to make the services available
>> again.
>
>Doing so means that there's a time where the device is unregistered
>illegitimately.

Yes, this small race is inherent in the quiesce model for module
services.  Worst case is a few open() calls get -ENODEV, but that can
occur now during module unload and reload.

>Wouldn't it be simpler to take the big kernel lock for the 
>check ? The unregistering would have to take it anyway.

Only if the code that calls the module is also under BKL.  That has not
been true since 2.2, which is why module unloading has been such a
problem since then.

>> There is also an unconditional shutdown mode.  Call unregister and even
>> if the module is still in use, do not call register again.  When the
>> use count finally goes to zero, the exit routine is called and the
>> module is removed.
>
>This is definitely needed, but why two calls for that ? It would be easier to
>provide a callback to be called when the use count reaches zero.

If you leave the services registered, other code can reenter the
module.  To whole point of unregistering services is to prevent any new
uses of the module while we wait for the remnant use count to drop to
zero.

>> I think this will help hot unplugging.  When the device disappears, the
>> driver internally marks its hardware as unusable and schedules an
>> unconditional shutdown of itself, all out of the interrupt handler.
>
>Is that really necessary ? Can't a kernel thread be used ? It is much easier
>than coding in interrupt.

Something has to mark the hardware as unusable, say a flag which can be
set from the interrupt.  When I said "schedules an unconditional
shutdown of itself" I meant schedule the shutdown from the interrupt
but run the shutdown via a kernel thread.  The shutdown code could
sleep so it cannot be called directly from the interrupt.


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Keith Owens]

On Sun, 04 Feb 2001 17:56:13 -0800, 
David Brownell <david-b@pacbell.net> wrote:
>I'm not sure I'd want module "use" count to be affected by plugging and
>unplugging, but I'd like to have that kind of way to track the number of
>devices associated with a module!

I was thinking of the model of one device, one module.  But we have
another model as well, one module handling multiple devices.  All the
state is internal to the module and not visible to the rest of the
kernel.  I wonder if we need per-device register and unregister calls
as well as per-module.


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Mon, 5 Feb 2001, Miles Lane wrote:

> David, as you work on this design, would you include
> a plan for supporting detection of devices that are
> already plugged in at boot time?  This is something
> that David Brownell is already working on for 
> PCI/Cardbus and USB.

Have we considered the possibility that the kernel thread spawned by
exec_usermodehelper could sleep on a wait queue if invoked too early in
the boot sequence, and the kernel could call wake_up() on that wait queue
after the root filesystem is mounted? That way, we can just forget about 
this special case.

Or is that still too early in the boot sequence? Do we need to wait for 
other filesystems to be mounted?

> BTW:  I'll be exploring your design over the next
> few days and hope to at least have a bit of
> constructive feedback for you.

Thanks.

Now the listserver has finally seen fit to spit my ramblings back at me,
I'm not really sure whether the bus->read/write functions are a good idea.  

It depends how many existing drivers would need to be modified. For
drivers which are only PCMCIA, it's OK; but introducing that extra
overhead (little though it is) for existing drivers which handle devices
on multiple busses is less clearly the right thing to do. (Note that we
wouldn't do this for CardBus - only PCMCIA). Maybe we should go down the
pcmcia_enable_resource() route after all.

But then again... are we going to need this anyway for dealing with 
multiple PCI(/other) busses?

-- 
dwmw2




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Sun, 4 Feb 2001, Miles Lane wrote:

> I am wondering how you managed to get adequate
> test coverage for pcmcia-cs.  Did any manufactures
> donate or loan equipment to you for testing?
> If not, did you determine some subset of hardware
> that you could use to exercise the majority of your
> drivers' functionality?  If so, could you send me
> a list of the devices you test with?

In particular, do you know of any way of getting hold of real PCMCIA flash 
devices (i.e. not CompactFlash)? Is anyone still making them?

-- 
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> Have we considered the possibility that the kernel thread spawned by
> exec_usermodehelper could sleep on a wait queue if invoked too early in
> the boot sequence, and the kernel could call wake_up() on that wait queue
> after the root filesystem is mounted? That way, we can just forget about
> this special case.
>
> Or is that still too early in the boot sequence? Do we need to wait for
> other filesystems to be mounted?

Most certainly yes. You need proc and usbdevfs.
usr or devfs are conceivable, too. Even var might be needed.

If you wish to wait, why not wait for activation by sysctl ?

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Woodhouse wrote:

> On Sun, 4 Feb 2001, Miles Lane wrote:
> 
> 
>> I am wondering how you managed to get adequate
>> test coverage for pcmcia-cs.  Did any manufactures
>> donate or loan equipment to you for testing?
>> If not, did you determine some subset of hardware
>> that you could use to exercise the majority of your
>> drivers' functionality?  If so, could you send me
>> a list of the devices you test with?
> 
> 
> In particular, do you know of any way of getting hold of real PCMCIA flash 
> devices (i.e. not CompactFlash)? Is anyone still making them?

Hi David,

I have added Werner Heuser to the TO: since he
seems to be pretty knowledgeable about FlashCard
and SmartCard support.  Check out his webpage on
the subject, here:

http://mobilix.org/smart_linux.html

Cheers,
	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

Oliver responding to David W:

> > Have we considered the possibility that the kernel thread spawned by
> > exec_usermodehelper could sleep on a wait queue if invoked too early in
> > the boot sequence, and the kernel could call wake_up() on that wait queue
> > after the root filesystem is mounted? That way, we can just forget about
> > this special case.

I think that got batted around (I certainly thought about it) but it doesn't
offer a way to guarantee some behaviors that I think are important.
(Ones that the test12 patch, turning everything async, removed ...
though the comments in 'usb.c' aren't updated.)  Serializing the order
for event reports is a concern:  don't report unplugs before you
report the plug-in of that device, keep the device identifiers stable.

For example, I know that some folk have been using hotplugging in
setting security policies for the /proc/bus/usb/MMM/NNN device
files (used in user mode driver APIs).  To do that reliably, you must
know that the name passed through /sbin/hotplug (DEVICE variable
in the environment) is still going to point to the right device when
the per-device setup scripts run ... rather than pointing to some
different device.  "usbdevfs" is optional so that issue doesn't show
up in Linus' default kernel configuration, but that type of problem
should have a good solution.


> > Or is that still too early in the boot sequence? Do we need to wait for
> > other filesystems to be mounted?
> 
> Most certainly yes. You need proc and usbdevfs.

Design goal of USB hotplugging:  don't _require_ usbdevfs in
for most current devices.  It doesn't, but "usbmodules" does.
Maybe the next iteration of hotplug should do differently.

Of course, "hot" plugging is not the same thing as being present at
boot time ... I think of these two as separate technical problems,
which happen to need a common subroutine ("/sbin/hotplug usb"
being the current implementation).


> usr or devfs are conceivable, too. Even var might be needed.

Right now the /etc/init.d/hotplug script runs as part of the
normal setup sequence, with all those accessible.

The "boot time events" are all lost unless they can be inferred
from "usbdevfs" or (for PCI) "procfs".


> If you wish to wait, why not wait for activation by sysctl ?

That is, sysctl to set the kernel "hotplug" string?  Would that
then invoke "/sbin/hotplug start", or would something else
need to make sure all the relevant subsystems are well enough
initialized?

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

I suspect the way this "ought" to be done will involve some chitchat
between the bus driver (USB, PCI, ...) and the module subsystem,
and not be visible to most device drivers.

It might be as simple as the module use count is today, but tracking
devices not opens.  Developers would have a way to tell "rmmod"
to ignore device count ... maybe "module device count goes to zero"
could enable autoclean, not "module open count goes zero" as it
stands today.  (Just thinking out loud about the details, I'm not sure
how that new model you sketched applies to use/open counts.)

- Dave


----- Original Message ----- 
From: "Keith Owens" <kaos@ocs.com.au>
To: <linux-hotplug-devel@lists.sourceforge.net>
Sent: Monday, February 05, 2001 2:13 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.


> On Sun, 04 Feb 2001 17:56:13 -0800, 
> David Brownell <david-b@pacbell.net> wrote:
> >I'm not sure I'd want module "use" count to be affected by plugging and
> >unplugging, but I'd like to have that kind of way to track the number of
> >devices associated with a module!
> 
> I was thinking of the model of one device, one module.  But we have
> another model as well, one module handling multiple devices.  All the
> state is internal to the module and not visible to the rest of the
> kernel.  I wonder if we need per-device register and unregister calls
> as well as per-module.
> 
> 
> _______________________________________________
> 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


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Woodhouse wrote:

> On Sun, 4 Feb 2001, Miles Lane wrote:
> 
> 
>> I am wondering how you managed to get adequate
>> test coverage for pcmcia-cs.  Did any manufactures
>> donate or loan equipment to you for testing?
>> If not, did you determine some subset of hardware
>> that you could use to exercise the majority of your
>> drivers' functionality?  If so, could you send me
>> a list of the devices you test with?
> 
> In particular, do you know of any way of getting hold of real PCMCIA 
> flash devices (i.e. not CompactFlash)? Is anyone still making them?

Not sure if this might be of any interest to you:

http://www.everythinglinux.com.au/item.php3?id=MG6469&start=0&max=8&invcata@&invcatb=7&back=%2Fcategory.php3%3Fprodtype%3Dnormal%26invcata%3D40%26invcatb%3D7%26back%3D%252Fcat.php3%253Ftt%253D981442005%2526invcata%253D40%2526invcataname%253DHardware%2526invcatadesc%253DHardware%252Bthat%252Bworks%252Bwith%252BLinux%26tt%3D981442031

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Mon, 5 Feb 2001, David Brownell wrote:

> Serializing the order for event reports is a concern:  don't report
> unplugs before you report the plug-in of that device, keep the device
> identifiers stable.

Er... we can wait for arbitrary lengths of time in execve(). So events 
aren't serialised anyway, and cannot be if you report them by running a 
userspace helper like this. You'd have to have a queue which is read by a 
single userspace process (which could perhaps be spawned when the queue 
becomes non-empty).

> The "boot time events" are all lost unless they can be inferred
> from "usbdevfs" or (for PCI) "procfs".

Should be entirely feasible for a PCMCIA script to determine the devices 
present during boot too, rather than queuing the actual events, then.

> > If you wish to wait, why not wait for activation by sysctl ?
> 
> That is, sysctl to set the kernel "hotplug" string?  Would that
> then invoke "/sbin/hotplug start", or would something else
> need to make sure all the relevant subsystems are well enough
> initialized?

I assumed this meant the threads would be spawned and wait, as I 
suggested, but instead of waiting till the rootfs is mounted, they'd wait 
for an explicit trigger from userspace, whether that's setting the 
'hotplug' string or a new 'hotplug_trigger' sysctl. But that means we have 
kernel threads collecting waiting for userspace to trigger them, and I'm 
not sure that's a good idea.

-- 
dwmw2




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Mon, Feb 05, 2001 at 11:43:06PM +0000, David Woodhouse wrote:
> 
> Now the listserver has finally seen fit to spit my ramblings back at me,
> I'm not really sure whether the bus->read/write functions are a good idea.  

I never got around to fully implementing it, because there are really
quite few situations where it is needed.  There is a PCMCIA card
reader that connects to a parallel port, where every card access has
to be virtualized.  But it is overkill for bridges with different
sorts of memory windowing.  There are already Linux socket drivers for
Motorola mpc8xx, Hitachi SuperH, and StrongARM processors that look
nothing like an i82365.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Sun, Feb 04, 2001 at 11:37:07AM +0000, David Woodhouse wrote:

> Not everything nowadays is an i82365, the bridge chip the PCMCIA spec 
> appears to have been written for.

The spec is actually quite general; the virtualized IO and memory
access scheme is pretty much straight out of the spec.

> I spent a long time trying to avoid this abstraction in the MTD code,
> before someone eventually convinced me that unconditional branches really
> aren't that difficult for modern CPUs to predict, and the increased
> simplicity of the 'map' abstraction was better.

Be sure that you need it.  I originally liked the idea (otherwise I
would not have implemented it), but it has not worked out to be useful
so far.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Sun, Feb 04, 2001 at 10:02:36AM -0800, Miles Lane wrote:
> 
> > 1. 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.
> 
> Huh?  You mean that the driver can't handle _some_ Cardbus adapter
> cards, right?  Mine work fine.

What ones do you have?  Are you using 16-bit cards or only CardBus
cards?

> As for the issue of many drivers
> requiring overrides and special settings, could you please give us
> a few examples? 

The PCMCIA-HOWTO has a list.  Some adapters do not power up in the
correct interrupt delivery mode and the yenta driver doesn't have a
way to tell it that a bridge must be put in PCI interrupt mode.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > > If you wish to wait, why not wait for activation by sysctl ?
> >
> > That is, sysctl to set the kernel "hotplug" string?  Would that
> > then invoke "/sbin/hotplug start", or would something else
> > need to make sure all the relevant subsystems are well enough
> > initialized?
>
> I assumed this meant the threads would be spawned and wait, as I
> suggested, but instead of waiting till the rootfs is mounted, they'd wait
> for an explicit trigger from userspace, whether that's setting the
> 'hotplug' string or a new 'hotplug_trigger' sysctl. But that means we have
> kernel threads collecting waiting for userspace to trigger them, and I'm
> not sure that's a good idea.

There's no need to wait until after spawning the threads.
Check for activation before you spawn. If that check fails, write
the request to a buffer. If the trigger is recieved, replay the buffer.

	HTH
		Oliver


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Woodhouse wrote:
> 
> Er... we can wait for arbitrary lengths of time in execve(). So events
> aren't serialised anyway, and cannot be if you report them by running a
> userspace helper like this. You'd have to have a queue which is read by a
> single userspace process (which could perhaps be spawned when the queue
> becomes non-empty).

I don't really understand why the /sbin/hotplug callout exists
at all.  If instead the kernel were to spit the event strings
out of some FIFO device (character special or whatever) then
hotplugd can perform all its actions nice and serially.

Plus we can buffer all the "insertion events" which occur
from boot-time scanning so they're available when hotplugd
starts up.

Confused.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Jeff Garzik]

Andrew Morton wrote:
> 
> David Woodhouse wrote:
> >
> > Er... we can wait for arbitrary lengths of time in execve(). So events
> > aren't serialised anyway, and cannot be if you report them by running a
> > userspace helper like this. You'd have to have a queue which is read by a
> > single userspace process (which could perhaps be spawned when the queue
> > becomes non-empty).
> 
> I don't really understand why the /sbin/hotplug callout exists
> at all.  If instead the kernel were to spit the event strings
> out of some FIFO device (character special or whatever) then
> hotplugd can perform all its actions nice and serially.
> 
> Plus we can buffer all the "insertion events" which occur
> from boot-time scanning so they're available when hotplugd
> starts up.

I had been thinking the same thing.  I think Linus originally said "do
it with /sbin/hotplug" and that's the way it went.

My suggestion would be a ring buffer that includes a jiffy (or other)
timestamp before each event.  That way it would be trivial for a
hotplugd to replay whatever events it missed...

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

jgarzik@mandrakesoft.com said:
>  My suggestion would be a ring buffer that includes a jiffy (or other)
> timestamp before each event.  That way it would be trivial for a
> hotplugd to replay whatever events it missed... 

Could we use netlink? Or does that not have the desired behaviour when the 
listener isn't yet present? We want it to queue the packets, not just drop 
them.

--
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > That is, sysctl to set the kernel "hotplug" string?  Would that
> > then invoke "/sbin/hotplug start", or would something else
> > need to make sure all the relevant subsystems are well enough
> > initialized?
>
> I assumed this meant the threads would be spawned and wait, as I
> suggested, but instead of waiting till the rootfs is mounted, they'd wait
> for an explicit trigger from userspace, whether that's setting the
> 'hotplug' string or a new 'hotplug_trigger' sysctl. But that means we have
> kernel threads collecting waiting for userspace to trigger them, and I'm
> not sure that's a good idea.

I have thought more about it.
You cannot simply wait. In fact you need to cancel those requests to user 
space. If you simply replay the sequence of events you have scripts acting on
device nodes that have already been reused. Simple waiting is even worse. 
You'd loose the defined order of events. The result wouldn't even be 
deterministic.

On the activation of user space hotplugging support plugging events must be 
faked and must reflect current hardware. Probably user space should be 
notified of the fact that these devices may already be in use.

	Regards
		Oliver


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

Oliver.Neukum@lrz.uni-muenchen.de said:
> You'd loose the defined order of events. The result wouldn't even be
> deterministic. 

There is no defined order of events in the current scheme. Do not make the 
mistake of thinking that there is, just because it happens to look that way 
most of the time.

--
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Dienstag,  6. Februar 2001 16:35, David Woodhouse wrote:
> Oliver.Neukum@lrz.uni-muenchen.de said:
> > You'd loose the defined order of events. The result wouldn't even be
> > deterministic.
>
> There is no defined order of events in the current scheme. Do not make the
> mistake of thinking that there is, just because it happens to look that way
> most of the time.

That is unfortunately true. And it _is_ a bug.
The original design had definite order. That was not a nice addition, it was 
a necessity. You cannot get stable behaviour unless you guarantee that the 
scripts don't race with each other.
The approach with a user space demon solves a part of this problem, but not 
all parts.
User space needs to acknowledge that it is finished dealing with one event
_before_ the next event is pumped to user space _and_ before the device
the event refers to is accessable from user space. That's the only way to
get security if device nodes can be reused.

	Regards
		Oliver


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Jeff Garzik]

David Woodhouse wrote:
> 
> jgarzik@mandrakesoft.com said:
> >  My suggestion would be a ring buffer that includes a jiffy (or other)
> > timestamp before each event.  That way it would be trivial for a
> > hotplugd to replay whatever events it missed...
> 
> Could we use netlink? Or does that not have the desired behaviour when the
> listener isn't yet present? We want it to queue the packets, not just drop
> them.

Not sure, don't know netlink that well.  Interesting idea though...
Queue skbs containing hotplug data onto a virtual network device.

	Jeff



-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

From Oliver:

> I have thought more about it.
> You cannot simply wait. In fact you need to cancel those requests to user
> space. If you simply replay the sequence of events you have scripts acting on
> device nodes that have already been reused. Simple waiting is even worse.
> You'd loose the defined order of events. The result wouldn't even be
> deterministic.

When I thought about this last year, my conclusion was that it SHOULD
be OK to have multiple event orderings so long as all were correctly
serialized with respect to essential criteria.  Just as if they were database
transactions that didn't interfere with each other.  The configuration of a
GNU/Linux operating environment is a transactable problem, and users
have no business caring which hotplug action is handled first ... so long
as each one is handled correctly.


> On the activation of user space hotplugging support plugging events must be
> faked and must reflect current hardware. Probably user space should be
> notified of the fact that these devices may already be in use.

I suspect there are solutions that don't involve faking, but there'd be a
price in extra complexity.  Userspace SHOULD be able to see if the
device has a driver bound to it ... I'm not quite so sure about "in use",
which I usually think of as meaning "opened".

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> Andrew Morton wrote:
> > David Woodhouse wrote:
> > >
> > > Er... we can wait for arbitrary lengths of time in execve(). So events
> > > aren't serialised anyway, and cannot be if you report them by running a
> > > userspace helper like this. You'd have to have a queue which is read by a
> > > single userspace process (which could perhaps be spawned when the queue
> > > becomes non-empty).
> >
> > I don't really understand why the /sbin/hotplug callout exists
> > at all.  If instead the kernel were to spit the event strings
> > out of some FIFO device (character special or whatever) then
> > hotplugd can perform all its actions nice and serially.

One reason was to get rid of the added system costs of creating
such a FIFO, creating a "hotplugd", then operating both of them
(tying down system resources).  After all, the kernel already has
parsed event data in hand, and it's always going to be cheaper to
allocate the hotplug agent resources for short periods than to
keep them allocated at all times (order of 100 KBytes).

The first implementation was a way to get _away_ from yet
another user mode daemon, and its costs.  The tradeoff was
some simple kernel code (less than 512 bytes) against some
complex kernel code to create/manage such a FIFO, and
even more code to decode the FIFO data and call the same
user mode agent the kernel could call directly.


> > Plus we can buffer all the "insertion events" which occur
> > from boot-time scanning so they're available when hotplugd
> > starts up.
>
> I had been thinking the same thing.  I think Linus originally said "do
> it with /sbin/hotplug" and that's the way it went.

I don't recall Linus doing more than acknowledging that such
boot-time solutions were proven ("kudzu" on RedHat) and could
easily just call the same /sbin/hotplug "subroutine" used when
hotplugging.

He did come up with the name "/sbin/hotplug" as a generic
name that all kernel subsystems (not just USB :-) could use
to deliver hotplug notifications ... with specific reference to
2.4 supporting USB, PCI, and network hotplugging.


> My suggestion would be a ring buffer that includes a jiffy (or other)
> timestamp before each event.  That way it would be trivial for a
> hotplugd to replay whatever events it missed...

Didn't "devfsd" rely on such a thing?   But it only knows about
device files, not /proc/bus/* or network interfaces.  Not relying
on "devfs" was another requirement for the original hotplug work,
but maybe that can be rethought for the 2.5 series.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "David Woodhouse" <dwmw2@infradead.org>
> Sent: Monday, February 05, 2001 11:11 PM
>
> On Mon, 5 Feb 2001, David Brownell wrote:
> 
> > Serializing the order for event reports is a concern:  don't report
> > unplugs before you report the plug-in of that device, keep the device
> > identifiers stable.
> 
> Er... we can wait for arbitrary lengths of time in execve(). So events 
> aren't serialised anyway, and cannot be if you report them by running a 
> userspace helper like this. 

Originally they _were_ serialized, because the usermode helpers were
called synchronously by threads that only reported the events in
the appropriate sequence.  That is, serialization between subsystems
wasn't provided (shouldn't be, IMO), only within the subsystem
(say USB or PCI, which provided the thread).

My short version of "why did that change" was that the addition of
network hotplugging turned up some races (the network driver API
wasn't designed for hotplugging, unlike USB or PCI, and some locks
were held so usermode "ifconfig" could deadlock) and changing all
that was the expedient way out.  Andrew Morton can elaborate;
from test5 through test11, hotplugging was synchronous, without
any reported problems when used with USB.


>    You'd have to have a queue which is read by a 
> single userspace process (which could perhaps be spawned when the queue 
> becomes non-empty).

By itself, a queue won't solve the problems.  Entry #1:  new device
/proc/bus/usb/001/004 ... Entry #N: removes it ... Entry #M, new
device reusing the /proc/bus/usb/001/004 name.  Synchronization
of some kind is needed.  ("devfsd" dealt with some of these issues,
not that I use it; there may be ideas woth stealing from it.)

This subproblem might get simpler if the hotplug notifications can't
do more than identify a device type, and they can't access devices
(for stuff like serial numbers, alternative configurations, and other
such "extended type info") ... but that surely rules out some kinds of
necessary response to hotplug notifications.


> > The "boot time events" are all lost unless they can be inferred
> > from "usbdevfs" or (for PCI) "procfs".
> 
> Should be entirely feasible for a PCMCIA script to determine the devices 
> present during boot too, rather than queuing the actual events, then.

Modulo races between usermode code accessing devices using those
names, and the kernel invalidating and reusing them, yes.  "usbdevfs"
lets those issues be solved by keeping device nodes in that namespace
until the last open FD is gone, but there's a role for non-kernel code
to play too (talk to the FS safely, which can't quite be done with the
hotplug agent getting called asynchronously).

Not to overstate things:  typical usage scenarios today (only a few
devices, usage patterns still evolving) probably won't suffer too
much from these problems.  Yet.

- Dave




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Adam J. Richter]

	I don't understand the need to queue hot plug events that
occur before user level facilities are ready to handle them.  For all
devices that I am aware of, it is simple enough to scan the bus after
initializing the hot plugging support and deal with the devices that
are already plugged in at that point.

	Perhaps someone could provide an example.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Woodhouse wrote:
> 
> jgarzik@mandrakesoft.com said:
> >  My suggestion would be a ring buffer that includes a jiffy (or other)
> > timestamp before each event.  That way it would be trivial for a
> > hotplugd to replay whatever events it missed...
> 
> Could we use netlink? Or does that not have the desired behaviour when the
> listener isn't yet present? We want it to queue the packets, not just drop
> them.

Well, I'm glad I wasn't missing something :)

Yes, timestamps would probably be helpful.

Using netlink would tie hotplug to the presence of CONFIG_NET,
which isn't really bad, but isn't really good, either.

Heck, you could just use printk:

	tail -f /var/log/messages | hotplugd &

(joke).

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Dienstag,  6. Februar 2001 23:09, Adam J. Richter wrote:
> I don't understand the need to queue hot plug events that
> occur before user level facilities are ready to handle them.  For all
> devices that I am aware of, it is simple enough to scan the bus after
> initializing the hot plugging support and deal with the devices that
> are already plugged in at that point.
>
> 	Perhaps someone could provide an example.

Well, you need to have your devices working earlier to eg boot from PCMCIA.
Thus you need a way to safely switch from operation without user space 
support to operation with user space support.
You need to lock the bus so that you don't configure devices that have been 
replaced and after that unlock the bus.
You need at least a few sysctls to do that.

	HTH
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Brownell wrote:
> 
> My short version of "why did that change" was that the addition of
> network hotplugging turned up some races (the network driver API
> wasn't designed for hotplugging, unlike USB or PCI, and some locks
> were held so usermode "ifconfig" could deadlock) and changing all
> that was the expedient way out.  Andrew Morton can elaborate;
> from test5 through test11, hotplugging was synchronous, without
> any reported problems when used with USB.

It was a deadlock, not a race.  We were calling `/sbin/hotplug net'
from within register_netdevice, with rtnl_lock held.  /sbin/hotplug
then called `ifconfig up', which wanted to claim rtnl_lock.

My third (and as yet unapplied) call_usermodehelper patch rearranges
the calls to '/sbin/hotplug net' so they happen outside the rtnl_lock,
so I think we could use synchronous-exec mode there.  (We don't have
synchronous exec mode at present - that was the other part of the
patch).

Look.  If we really think we need call_usermodehelper to be synchronous
then let's make a swift and solid decision, present a good case to the boss.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Brownell wrote:
> 
> When I thought about this last year, my conclusion was that it SHOULD
> be OK to have multiple event orderings so long as all were correctly
> serialized with respect to essential criteria.  Just as if they were database
> transactions that didn't interfere with each other.  The configuration of a
> GNU/Linux operating environment is a transactable problem, and users
> have no business caring which hotplug action is handled first ... so long
> as each one is handled correctly.

Device naming worries me.

Suppose we were able to make an entire "hotplug" transaction
synchronous and correctly serialised.  So when I "insert" my
3c501, the driver load and the open all happen safely and
serially.

Well, I still want to provide a consistent and predictable
ordering of this wrt the "hotplug" of my Acenic card.

Why?  Because I don't want them to be randomly assigned
"eth0" or "eth1" depending on which way the wind is
blowing.

This means, I think, that we want *global* serialisation
of all hotplug activity.  *never* do more than one thing
at a time.  So all driver loads and opens will happen
strictly, synchronously in scan order.

Nice, simple, and can't be done.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

"Adam J. Richter" wrote:
> 
>         I don't understand the need to queue hot plug events that
> occur before user level facilities are ready to handle them.  For all
> devices that I am aware of, it is simple enough to scan the bus after
> initializing the hot plugging support and deal with the devices that
> are already plugged in at that point.
> 
>         Perhaps someone could provide an example.

You're right, it _can_ be done by synthesizing hotpluf
events from the initscripts.  In fact, that's how it
must be done.

It simply seems nicer to have just one way of doing things, IMO.

But you still will need to special-case things which are
required to get a successful boot.  I confess I haven't
thought about this too hard.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

On Tue, 6 Feb 2001, Andrew Morton wrote:

> Well, I still want to provide a consistent and predictable
> ordering of this wrt the "hotplug" of my Acenic card.
> 
> Why?  Because I don't want them to be randomly assigned
> "eth0" or "eth1" depending on which way the wind is
> blowing.

Stop. Step back and think.

Why don't you want the name to change?

Surely what you actually mean to say is that you don't want stuff to 
break because the name has changed. Be that because the name didn't 
actually change, or be that just because stuff didn't break - we just want 
it not to break.

Identifying devices by something more constant than the name which the
kernel happens to have assigned to them today is not difficult.

-- 
dwmw2




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> My third (and as yet unapplied) call_usermodehelper patch rearranges
> the calls to '/sbin/hotplug net' so they happen outside the rtnl_lock,
> so I think we could use synchronous-exec mode there.  (We don't have
> synchronous exec mode at present - that was the other part of the
> patch).
>
> Look.  If we really think we need call_usermodehelper to be synchronous
> then let's make a swift and solid decision, present a good case to the
> boss.

No undue haste please. Let's do it right the first time.

We do agree that device addition must be processed fully, before
device removal is processed, don't we ?

Then we have the problem of device node reuse. It means that
a user space script for addition of a new device must not be run before all
removal handlers are completed.
At least I see no alternative.

But I am not sure that synchronous operation is free of deadlocks.
What happens if a CardBus USB Controller with devices attached is plugged in ?

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> You're right, it _can_ be done by synthesizing hotpluf
> events from the initscripts.  In fact, that's how it
> must be done.

I am afraid it cannot be simply done from the init scripts.
Simply parsing proc has an unavoidable race condition.
You need to lock it.

	HTH
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Woodhouse wrote:
> 
> On Tue, 6 Feb 2001, Andrew Morton wrote:
> 
> > Well, I still want to provide a consistent and predictable
> > ordering of this wrt the "hotplug" of my Acenic card.
> >
> > Why?  Because I don't want them to be randomly assigned
> > "eth0" or "eth1" depending on which way the wind is
> > blowing.
> 
> Stop. Step back and think.
> 
> Why don't you want the name to change?
> 
> Surely what you actually mean to say is that you don't want stuff to
> break because the name has changed. Be that because the name didn't
> actually change, or be that just because stuff didn't break - we just want
> it not to break.
> 
> Identifying devices by something more constant than the name which the
> kernel happens to have assigned to them today is not difficult.

Oh that's very true.  The current scheme of assigning
names by scan order sucks seriously - if you swap
your NICs around, *everything* breaks.

Andi has a little app which renames interfaces based on
their MAC address, using SIOCSIFNAME, which is a perfectly
sensible thing to do, IMO.

But:

- We don't want to have anything which is *worse* than what
  we currently have and

- I'm only talking about netdevices.  What happens with other
  types of device if the discovery order is randomised?  I
  dunno.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "Andrew Morton" <morton@nortelnetworks.com>
> 
> Device naming worries me.

Usually a smart thing to do when designing anything, even
if you're not in marketing!  :-)


> Suppose we were able to make an entire "hotplug" transaction
> synchronous and correctly serialised.  So when I "insert" my
> 3c501, the driver load and the open all happen safely and
> serially.
> 
> Well, I still want to provide a consistent and predictable
> ordering of this wrt the "hotplug" of my Acenic card.
> 
> Why?  Because I don't want them to be randomly assigned
> "eth0" or "eth1" depending on which way the wind is
> blowing.

The word I use for that characteristic is a "stable" name.
As in, "Device names visible outside the kernel should
be stable, so you can label devices and use those names
in shell scripts and sysadmin forms."

Names based on physical connectivity (PCI slot, port
on USB hub, etc) are stable almost by definition; they
change only when you connect things differently.  Some
names are more stable than that ... unique serial numbers
(like Ethernet addresses) can help.

Names like "eth0" aren't stable, nor are /proc/bus/usb
names, but /proc/bus/pci names are.  If "acenic" used
"pdev->slot_name" not "eth%d" for its interface names,
that driver would have stable naming right now.

I read recently that "stable" names were a goal of "devfs",
so I wonder if that "stable" is my "stable". 


> This means, I think, that we want *global* serialisation
> of all hotplug activity.  ....

No -- using "stable" names would solve that!  Serialization
between subsystems would be a bug in need of fixing.
Serialization within individual subsystems is likely though.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Andrew Morton wrote:

[...]


> - I'm only talking about netdevices.  What happens with other
>   types of device if the discovery order is randomised?  I
>   dunno.

It appears that we currently only have representation of
USB, PCI, PCMCIA and Network driver/bus developers in this
discussion.  Is that as it should be?  It seems to me that
the topic of device detection and configuration is quite
important to get right for all hotpluggable busses.
Should we be extending invitations to others?

It's clear that there are major usability problems that 
arise from the lack of a MAC address equivalent for all 
hardware devices.  

As David Brownell mentioned, the typical usage pattern
(at least for USB) seems to be that just a few devices
are connected and usually not more than one device of
a given type.  The confusion sets in when there are
multiple USB mice, keyboards, videocams, etc.  If XFree86
ever gets support for multi-headed consoles with support
for dedicated mice and keyboards per console, getting the
mapping from physical device to logical device (for example,
/dev/input/mouse[1-4]) to stay consistent would be really
helpful.  I believe that this feature is actively being
developed for XFree86, BTW.

Probably the most that can be hoped for is that we develop 
a method of locking down the mapping between logical 
device interfaces for those devices that have unique 
identifiers.
	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Adam J. Richter]

>>  = Andrew Morton <morton@nortelnetworks.com>
>   = Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>

>> You're right, it _can_ be done by synthesizing hotpluf
>> events from the initscripts.  In fact, that's how it
>> must be done.
>
>I am afraid it cannot be simply done from the init scripts.
>Simply parsing proc has an unavoidable race condition.
>You need to lock it.
>
>        HTH
>                Oliver

	I said, "scan the bus *after* initializing the hot plugging
support and deal with devices that are already plugged in [...]"
You may process a device twice this way, but user level software
can detect this and synchronize when this is really necessary.  In
most cases, you just want to modprobe a module, which can safely be
done multiple times, so it is not necessary to bother checking.

	Also, since the races are done once the init script completes
(before any user logs in), you can safely do things like load the
saved device settings without worrying about clobbering any work done
before.

	In cases where you really need to avoid doing something twice
(such as spawning a dhcp client on an ethernet port), you can do your
synchronization at user level, by something like:

	# "insert" script
	netif=$1   # For example "eth0"
	# /var/run was previous cleared earlier in the boot process, so
	# we know that if this directory exists, we have been called
	# twice.
	if mkdir /var/run/$netif ; then
		dhclient -pf /var/run/$netif/pid $netif &
	fi

	# "remove" script
	netif=$1   # For example "eth0"
	kill $(cat /var/run/netif/$netif/pid)
	rm -rf /var/run/$netif


Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> 	I said, "scan the bus *after* initializing the hot plugging
> support and deal with devices that are already plugged in [...]"
> You may process a device twice this way, but user level software
> can detect this and synchronize when this is really necessary.  In
> most cases, you just want to modprobe a module, which can safely be
> done multiple times, so it is not necessary to bother checking.

The problem is that may try to configure a device that's no longer there,
or worse a device that is being replaced this way. You need to tell the 
kernel that it must cease processing events on a bus that you are scanning.

> 	In cases where you really need to avoid doing something twice
> (such as spawning a dhcp client on an ethernet port), you can do your
> synchronization at user level, by something like:
>
> 	# "insert" script
> 	netif=$1   # For example "eth0"
> 	# /var/run was previous cleared earlier in the boot process, so
> 	# we know that if this directory exists, we have been called
> 	# twice.
> 	if mkdir /var/run/$netif ; then
> 		dhclient -pf /var/run/$netif/pid $netif &
> 	fi
>
> 	# "remove" script
> 	netif=$1   # For example "eth0"
> 	kill $(cat /var/run/netif/$netif/pid)
> 	rm -rf /var/run/$netif

That's the problem. You compute $1 and then you configure it without a 
guarantee that $1 is still the interface you thought it to be.
It is a very small window, but I feel that we shouldn't design something 
which works only in most cases.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Tue, Feb 06, 2001 at 11:36:32PM +0000, Andrew Morton wrote:

> > Identifying devices by something more constant than the name which the
> > kernel happens to have assigned to them today is not difficult.
> 
> Oh that's very true.  The current scheme of assigning
> names by scan order sucks seriously - if you swap
> your NICs around, *everything* breaks.
> 
> Andi has a little app which renames interfaces based on
> their MAC address, using SIOCSIFNAME, which is a perfectly
> sensible thing to do, IMO.

I think it'd be sensible to let the hotplug daemon not rename, but
_assign a name/number_ to not only netdevices but every device it's
notified about being created.

The daemon can do the decision - it has all the necessary information. 

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

Oliver.Neukum@lrz.uni-muenchen.de said:
>  The problem is that may try to configure a device that's no longer
> there, or worse a device that is being replaced this way. 

That can always happen; synchronous or not. User waits till the hotplug 
script/daemon is just about to configure the device and viciously removes 
it.

Oliver.Neukum@lrz.uni-muenchen.de said:
> You need to tell the  kernel that it must cease processing events on a
> bus that you are scanning. 

You mean ignoring the 'device removed' interrupt and allowing the user to
configure the absent device just because we told them it was there? I'm not 
utterly convinced by that. 

How about assigning a unique ID to each _instance_ of each device (i.e. 
each time it's inserted it gets a new ID. We create a device with a name 
like eth-hotplug-3452 and then tell the usermodehelper about it. The 
usermodehelper can do whatever it needs to do to find out which socket it's 
plugged into, what its MAC address is, or whatever else it needs to decide 
whether it should be eth0 or eth1, and then renames it.

And if the device goes away in the meantime, that's trivially handled.


--
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Mittwoch,  7. Februar 2001 06:17, you wrote:
> Hi,
>
> > > When I thought about this last year, my conclusion was that it SHOULD
> > > be OK to have multiple event orderings so long as all were correctly
> > > serialized with respect to essential criteria.  Just as if they were
> >
> > Essentially I believe you right. But which criteria ?
>
> "add" finishes before "remove" starts; the names of
> devices are stable while those agents execute.
> Minimal.

These are not enough. You must ensure that "remove" has finished before you
start anything that reuses the device node.

Eg.: Printer 1 added -> printcap edited
      Printer 1 removed -> printcap edited
      Printer 2 added -> printcap edited

You see, changing the order of events 2 and 3 is wrong.
You'd have the wrong interfaces in printcap.  

> > > database transactions that didn't interfere with each other.  The
> > > configuration of a GNU/Linux operating environment is a transactable
> > > problem, and users have no business caring which hotplug action is
> > > handled first ... so long as each one is handled correctly.
> >
> > That means that transactions that might interfer are serialised.
> > However is see no way you could tell which transactions might interfer.
> > Thus you have to serialise them all.
>
> The way you resolve this is saying that transactions in different
> subsystems may not interfere (else they're bugs) and that individual
> subsystems get to define their own rules ... but the default expectation
> should be that two devices hotplugging must NOT interfere with each other.

At some level the function of devices enters the game.
The hotplugging events must be generated on the physical busses
to allow module autoloading, yet they come into contact by the device nodes.

Both a disk on FC-AL in the next building and a PCMCIA SCSI controller share
the same device node space.

The amount of locking needed to be provided by shell scripts worries me.

> That means fixing some subsystem behaviors (using stable names for
> network interfaces, as one example).  Architecturally, there is no sense
> to letting two subsystems interfere with each other.

Then you'd need to have a stable name provided to the hotplug script.
This is difficult, for several reasons.
a) You need devfs (which is not PC)
b) You know that name only after the driver is loaded. (You don't even know 
the number of names, multifunction devices and bridges)
c) You'd need to call after drivers have bound to interfaces.
d) There might be devices which have difficulties providing a stable name.

These are conflicting requirements. In fact you'd need _two_ scripts. One to 
load the driver, a second to configure the device the driver has bound to.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Tue, Feb 06, 2001 at 06:11:07PM -0800, Miles Lane wrote:
> Andrew Morton wrote:
> 
> [...]
> 
> 
> > - I'm only talking about netdevices.  What happens with other
> >   types of device if the discovery order is randomised?  I
> >   dunno.
> 
> It appears that we currently only have representation of
> USB, PCI, PCMCIA and Network driver/bus developers in this
> discussion.  Is that as it should be?  It seems to me that
> the topic of device detection and configuration is quite
> important to get right for all hotpluggable busses.
> Should we be extending invitations to others?

Well, in my opinion we should also consider non-hotpluggable busses,
because even there it would make sense to use the same module loading
mechanism. It's more flexible than the current modules.conf way.

> It's clear that there are major usability problems that 
> arise from the lack of a MAC address equivalent for all 
> hardware devices.  

Many devices do have serial numbers, that's OK. Other devices do at
least have bus topology placement, ie. slot number on PCI, hub port on
USB, etc.

If the devices can't be identified by a unique number, then bus topology
is the only way how to describe which device is which, and thus is the
right one.

> As David Brownell mentioned, the typical usage pattern
> (at least for USB) seems to be that just a few devices
> are connected and usually not more than one device of
> a given type.  The confusion sets in when there are
> multiple USB mice, keyboards, videocams, etc.  If XFree86
> ever gets support for multi-headed consoles with support
> for dedicated mice and keyboards per console, getting the
> mapping from physical device to logical device (for example,
> /dev/input/mouse[1-4]) to stay consistent would be really
> helpful. I believe that this feature is actively being
> developed for XFree86, BTW.

Yes, it is. And yes, we need this. And bus topology (head #1 uses port
#1 on the USB card, head #2 uses port #2, etc.) is the way how to find
out which mouse is which.

I imagine it this way:

0) PCI layer finds a new device, registers it, calls the hotplug daemon
   passing the PCI IDs/class/prog-if and topology (/pci00.07.4)
1) Hotplug daemon checks the class/prog-if and loads usb-ohci module. 
2) usb-ohci module senses a new device, registers it w/ USB layer.
3) USB layer calls hotplug daemon, telling it the USB IDs/descriptors
   and bus topology position (/pci00.07.4/usb0).
4) Hoptlug module sees it's a hub and thus it's handled by a built-in
   USB hub driver.
5) The hub driver enables the ports on the hub, usb-ohci sees a new
   device, registers it w/ USB layer.
6) USB layer calls hotplug daemon, telling it the USB IDs/descriptors
   and bus topology position (/pci00.07.4/usb0/usb3).
7) Hotplug daemon checks the descriptors and decides it's a HID device
   and loads hid module.
8) The hid module registers a new device on the Input virtual bus.
9) Input layer calls hotplug daemon, telling it the Input IDs/bitmaps
   and bus topology position (/pci00.07.4/usb0.3/input0).
10) Hotplug daemon checks the bitmaps and decides it's a mouse and loads
   mousedev.o and evdev.o.
11) Mousedev.o registers a new chardevice minor, so does evdev.o.

I'm not completely sure where to fit the device naming in, I'm thinking
about two variants:

A) After step 11, Hotplug daemon is called by the
   char/block/scsi/net-device layer and the hotplug daemon decides
   about the minor number/name (based on IDs and topology path -
   /pci00.07.4/usb0.3/input0/mousedev0).

B) At every time the hotplug daemon is loading a module, it
   passes a name/number it wishes the new device that caused the load
   to be registered under. Example: Loading hid.o, register as 'input4'.

I think A is simpler and easier to do. It also will be fairly easy to
configure.

B gives complete control of device numbering, even for devices on
virtual busses. In the B case, only the last part of the topology would
need to be passed.  What do you think?

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Mittwoch,  7. Februar 2001 10:10, David Woodhouse wrote:
> Oliver.Neukum@lrz.uni-muenchen.de said:
> >  The problem is that may try to configure a device that's no longer
> > there, or worse a device that is being replaced this way.
>
> That can always happen; synchronous or not. User waits till the hotplug
> script/daemon is just about to configure the device and viciously removes
> it.

Removal can happen, replacement cannot happen in the synchronous mode.
Removal can be dealt with by returning EIO.

> Oliver.Neukum@lrz.uni-muenchen.de said:
> > You need to tell the  kernel that it must cease processing events on a
> > bus that you are scanning.
>
> You mean ignoring the 'device removed' interrupt and allowing the user to
> configure the absent device just because we told them it was there? I'm not
> utterly convinced by that.

Again removal is not the problem, replacement is.
And yes, while a configuration script is running the kernel should queue
device addition events.
And to be absolutely correct you need to check the queue for obsolete events
before you play it to user space.

> How about assigning a unique ID to each _instance_ of each device (i.e.
> each time it's inserted it gets a new ID. We create a device with a name
> like eth-hotplug-3452 and then tell the usermodehelper about it. The

Workable approach for net devices, but why bother with a name at all ?
Let's add an ioctl to name by MAC. OK a temporary name might be a good idea.

> usermodehelper can do whatever it needs to do to find out which socket it's
> plugged into, what its MAC address is, or whatever else it needs to decide
> whether it should be eth0 or eth1, and then renames it.

That works for net devices, but what about everything else ?

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 10:57:52AM +0100, Oliver Neukum wrote:

> Again removal is not the problem, replacement is.
> And yes, while a configuration script is running the kernel should queue
> device addition events.
> And to be absolutely correct you need to check the queue for obsolete events
> before you play it to user space.

IMO it needs not to be a true queue, but rather than a list of present
devices which is then checked against a list that the daemon knows about
already and the events would be then made to synchronize them.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

vojtech@suse.cz said:
>  IMO it needs not to be a true queue, but rather than a list of
> present devices which is then checked against a list that the daemon
> knows about already and the events would be then made to synchronize
> them. 

Eeek! Keeping a 'this is what we think userland thinks' state scares me. It 
can and will get out of sync. 

This is where the interface between PCMCIA socket drivers and the core code 
got it right, IMO. You make the current state available, and occasionally 
give hints like 'This bit may have changed. You might want to take a look."

Thinks.... a list of hotplug devices in a /proc file, listing some unique 
per-instance ID against the type, topological information and current name 
of the device. You don't send explicit add/remove events to userspace, just 
an "Oi. Look again".

?



--
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Mittwoch,  7. Februar 2001 11:11, Vojtech Pavlik wrote:
> On Wed, Feb 07, 2001 at 10:57:52AM +0100, Oliver Neukum wrote:
> > Again removal is not the problem, replacement is.
> > And yes, while a configuration script is running the kernel should queue
> > device addition events.
> > And to be absolutely correct you need to check the queue for obsolete
> > events before you play it to user space.
>
> IMO it needs not to be a true queue, but rather than a list of present
> devices which is then checked against a list that the daemon knows about
> already and the events would be then made to synchronize them.

I am afraid that order is important unless the scripts are given a stable 
name.

printer 1 addition -> edit printcap
printer 2 addition -> edit printcap
printer 1 removal -> edit printcap

will leave you with lp1 as your printer name
If you reverse steps 2 and 3 you get lp0 as printer name.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse]

Oliver.Neukum@lrz.uni-muenchen.de said:
>  will leave you with lp1 as your printer name If you reverse steps 2
> and 3 you get lp0 as printer name. 

That doesn't have to be a problem. If your script is editing printcap and 
inserting the device name it's given in the entry for the new printer, with 
whatever queue name(s) are configured elsewhere, why does it matter?

--
dwmw2



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Mittwoch,  7. Februar 2001 11:30, David Woodhouse wrote:
> Oliver.Neukum@lrz.uni-muenchen.de said:
> >  will leave you with lp1 as your printer name If you reverse steps 2
> > and 3 you get lp0 as printer name.
>
> That doesn't have to be a problem. If your script is editing printcap and
> inserting the device name it's given in the entry for the new printer, with
> whatever queue name(s) are configured elsewhere, why does it matter?

If you were given that name. For USB at least you get an usbdevfs name at 
best.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Adam J. Richter]

>> 	I said, "scan the bus *after* initializing the hot plugging
>> support and deal with devices that are already plugged in [...]"
>> You may process a device twice this way, but user level software
>> can detect this and synchronize when this is really necessary.  In
>> most cases, you just want to modprobe a module, which can safely be
>> done multiple times, so it is not necessary to bother checking.

>The problem is that may try to configure a device that's no longer there,
>or worse a device that is being replaced this way. You need to tell the 
>kernel that it must cease processing events on a bus that you are scanning.

	Firstly, that would also happen if you queue the hot plugging
events.  Secondly, this situation is detectable by the user level
initialization script failing (in the dhcp example, dhclient would get
an error).  It is easy enough to have the initialization script
release the locking resource when that happens (in my example, by
doing an "rm -rf /var/run/$netif").

	Even for the more elaborate case, where, say, a user quickly
inserts an ethernet card, removes it and then inserts a wireless
ethernet card which might need a different initialization, my scheme
would get it right because it does not look for existing devices until
it has already initialized the hot plug event handling, since the only
way that the first card could be detected is if the hot plugging
facilties were in place in time to see its later removal and the
insertion of the new card.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> 	Even for the more elaborate case, where, say, a user quickly
> inserts an ethernet card, removes it and then inserts a wireless
> ethernet card which might need a different initialization, my scheme
> would get it right because it does not look for existing devices until
> it has already initialized the hot plug event handling, since the only
> way that the first card could be detected is if the hot plugging
> facilties were in place in time to see its later removal and the
> insertion of the new card.

Exactly that's the problem. What do you wish to do when the replacement has 
happened after you have decided to do something to the interface, but before 
you've started your action.

Let me make a diagramm

enable hotplugging
start scanning bus
decide to assign IP to eth0
				eth0 goes away (eg leaving 802.11 zone)
				a PCMCIA ethernet card is plugged in
assign IP to eth0

The window is very small and in this case of little consequence, but for
a design it is still unacceptable.

You need to prevent any changes to the bus while you do the scanning.
Running hotplug support is not enough. You need further kernel support
to do racefree scanning. It gets worse if you take into account interference
with non hotpluggable busses (SCSI).
Therefore I suggest scanning in kernel space.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

See comments at end of message.

Oliver Neukum wrote:
> 
> On Mittwoch,  7. Februar 2001 06:17, you wrote:
> > Hi,
> >
> > > > When I thought about this last year, my conclusion was that it SHOULD
> > > > be OK to have multiple event orderings so long as all were correctly
> > > > serialized with respect to essential criteria.  Just as if they were
> > >
> > > Essentially I believe you right. But which criteria ?
> >
> > "add" finishes before "remove" starts; the names of
> > devices are stable while those agents execute.
> > Minimal.
> 
> These are not enough. You must ensure that "remove" has finished before you
> start anything that reuses the device node.
> 
> Eg.: Printer 1 added -> printcap edited
>       Printer 1 removed -> printcap edited
>       Printer 2 added -> printcap edited
> 
> You see, changing the order of events 2 and 3 is wrong.
> You'd have the wrong interfaces in printcap.
> 
> > > > database transactions that didn't interfere with each other.  The
> > > > configuration of a GNU/Linux operating environment is a transactable
> > > > problem, and users have no business caring which hotplug action is
> > > > handled first ... so long as each one is handled correctly.
> > >
> > > That means that transactions that might interfer are serialised.
> > > However is see no way you could tell which transactions might interfer.
> > > Thus you have to serialise them all.
> >
> > The way you resolve this is saying that transactions in different
> > subsystems may not interfere (else they're bugs) and that individual
> > subsystems get to define their own rules ... but the default expectation
> > should be that two devices hotplugging must NOT interfere with each other.
> 
> At some level the function of devices enters the game.
> The hotplugging events must be generated on the physical busses
> to allow module autoloading, yet they come into contact by the device nodes.
> 
> Both a disk on FC-AL in the next building and a PCMCIA SCSI controller share
> the same device node space.
> 
> The amount of locking needed to be provided by shell scripts worries me.
> 
> > That means fixing some subsystem behaviors (using stable names for
> > network interfaces, as one example).  Architecturally, there is no sense
> > to letting two subsystems interfere with each other.
> 
> Then you'd need to have a stable name provided to the hotplug script.
> This is difficult, for several reasons.
> a) You need devfs (which is not PC)
> b) You know that name only after the driver is loaded. (You don't even know
> the number of names, multifunction devices and bridges)
> c) You'd need to call after drivers have bound to interfaces.
> d) There might be devices which have difficulties providing a stable name.
> 
> These are conflicting requirements. In fact you'd need _two_ scripts. One to
> load the driver, a second to configure the device the driver has bound to.

Hi,

I am leaving this message intact, because I think it's a good snapshot
of
several important issues.

So, the process looks something like this:

	Device detection
	Module loads
	Device nodes enabled
	Usermode scripts (or daemon) run to 
	do things like launch programs to
	upload data to a device via one of 
	its device nodes.

Now, we need to figure out a robust way to recover from devices
being unplugged and new devices being inserted that reuse
device nodes.  Obviously, any usermode configuration scripts that
fired off for the previous device will still be running and we'd 
then have two instances of that configuration script running
and trying to access devices on the same device nodes.  Not good.

So, it seems that we need a way of telling all usermode scripts
(or daemons) to back out any work done that depends on a given
device node when we discover that the associated device has been
unplugged.  We then need a method of having any new usermode scripts
that will be accessing the same device nodes to wait until the previous
script (or daemon) has completed the back out process.

Then there's the question of what to do when a user application has 
already been launched which will be expecting access to the first
device.  For example, I plug in a videocam and then unplug it, but
my video viewing program has already been launched.  Perhaps this 
isn't a huge problem.  If I then connect a different videocam, it
would reuse the video0 device node.  Hmm.

Yes, this seems like a really messy situation.

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 11:29:42AM +0100, Oliver Neukum wrote:

> > > Again removal is not the problem, replacement is.
> > > And yes, while a configuration script is running the kernel should queue
> > > device addition events.
> > > And to be absolutely correct you need to check the queue for obsolete
> > > events before you play it to user space.
> >
> > IMO it needs not to be a true queue, but rather than a list of present
> > devices which is then checked against a list that the daemon knows about
> > already and the events would be then made to synchronize them.
> 
> I am afraid that order is important unless the scripts are given a stable 
> name.

Yes. Relying on detection order for device naming in a hotplugging
system is a nightmare, anyway.

> printer 1 addition -> edit printcap
> printer 2 addition -> edit printcap
> printer 1 removal -> edit printcap
> 
> will leave you with lp1 as your printer name
> If you reverse steps 2 and 3 you get lp0 as printer name.

So you have to give them some other names, not based on addition/removal
order. Userspace (printcap in this case) will never be happy with names
changing no matter how much we serialize.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> > > > When I thought about this last year, my conclusion was that it SHOULD
> > > > be OK to have multiple event orderings so long as all were correctly
> > > > serialized with respect to essential criteria.  Just as if they were
> > >
> > > Essentially I believe you right. But which criteria ?
> >
> > "add" finishes before "remove" starts; the names of
> > devices are stable while those agents execute.
> > Minimal.
> 
> These are not enough. You must ensure that "remove" has finished before you
> start anything that reuses the device node.

I was assuming something that I suspect we should be considering
as a goal (an "architectural" one?): names passed by hotplug agents
must be stable.

Right now, PCI meets that requirement (PCI_SLOT).
USB does not, networking does not.

Before 2.4.0 went "final", USB changed its address assignment
so its names (busnum/devnum) were less unstable:  devnum is
assigned round-robin.  There's a patch I put together a while back
to give USB devices stable names, but it's not integrated.

I'll have to think more about Vojtech's comments.  I think I will
likely want the kernel to guarantee some stable name (is that a
place where devfs could really help?) and let all the mappings
to "virtual" names (like "eth0") be managed separately.


> You see, changing the order of events 2 and 3 is wrong.
> You'd have the wrong interfaces in printcap.  

Couldn't matter if the agent were passing the right stable names
though, right? 


> The amount of locking needed to be provided by shell scripts worries me.

Compiled code (C, Java, etc) accessing kernel configuration APIs can
kick in at any time it's really needed, don't worry about that one!


> > That means fixing some subsystem behaviors (using stable names for
> > network interfaces, as one example).  Architecturally, there is no sense
> > to letting two subsystems interfere with each other.
> 
> Then you'd need to have a stable name provided to the hotplug script.

Yes ...


> This is difficult, for several reasons.
> a) You need devfs (which is not PC)

"devfsd" is not PC for me, but I'm less clear why a "/devfs" wouldn't be fine.
Anyone care to start a separate thread on such topics?


> b) You know that name only after the driver is loaded. (You don't even know 
> the number of names, multifunction devices and bridges)

Device drivers can be viewed as adapters between namespaces:
loading a device driver may cause entries in other namespaces.

USB device "/proc/bus/usb/002/031" may be network interface "usb0".
The lower level name (USB) is known before "usbnet" is loaded,
but "usb0" isn't known till afterwards ... but then, USB hotplugging
sees the USB name, and network hotplugging is what sees "usb0".


> c) You'd need to call after drivers have bound to interfaces.

USB hotplug is called after the kernel gives drivers a chance to
bind to interfaces.

For network devices, hotplug is called after the driver created
and registered/named a new interface.


> d) There might be devices which have difficulties providing a stable name.

Then let them deal with it.  If the busses provide stable names, then we
can federate them in some namespace that can be used by layers above
the  busses.  "pci-02:7.3" can be a PCI device, and any driver that has
a hard time turning one stable name into another likely has other problems!


> These are conflicting requirements. In fact you'd need _two_ scripts. One to 
> load the driver, a second to configure the device the driver has bound to.

You mean like the difference between /etc/hotplug/*.agent (load driver FOO)
and /etc/hotplug/*/FOO (configure each new device)?  :-)

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "David Woodhouse" <dwmw2@infradead.org>
> 
> How about assigning a unique ID to each _instance_ of each device (i.e. 
> each time it's inserted it gets a new ID. We create a device with a name 
> like eth-hotplug-3452 and then tell the usermodehelper about it. 

Interesting notion, but I think there's still a need for a stable namespace,
which no user mode program can invalidate by renaming.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

Right now there's no printer hotplugging support ... nothing
calls out to userland "/dev/usb/lp0 was just born, have a cigar!".

In fact I'm unclear how much the different sorts of printer
(USB, parallel, network, ...) all get autoconfigured.  Is there
anyone working on putting together all those answers?

- Dave


----- Original Message -----
From: "Oliver Neukum" <Oliver.Neukum@lrz.uni-muenchen.de>
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: "Vojtech Pavlik" <vojtech@suse.cz>; "Adam J. Richter" <adam@yggdrasil.com>;
<linux-hotplug-devel@lists.sourceforge.net>
Sent: Wednesday, February 07, 2001 6:45 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.


> On Mittwoch,  7. Februar 2001 11:30, David Woodhouse wrote:
> > Oliver.Neukum@lrz.uni-muenchen.de said:
> > >  will leave you with lp1 as your printer name If you reverse steps 2
> > > and 3 you get lp0 as printer name.
> >
> > That doesn't have to be a problem. If your script is editing printcap and
> > inserting the device name it's given in the entry for the new printer, with
> > whatever queue name(s) are configured elsewhere, why does it matter?
>
> If you were given that name. For USB at least you get an usbdevfs name at
> best.
>
> Regards
> Oliver
>
> _______________________________________________
> 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


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> Yes. Relying on detection order for device naming in a hotplugging
> system is a nightmare, anyway.

It's hardcoded into many subsystems.

> > printer 1 addition -> edit printcap
> > printer 2 addition -> edit printcap
> > printer 1 removal -> edit printcap
> >
> > will leave you with lp1 as your printer name
> > If you reverse steps 2 and 3 you get lp0 as printer name.
>
> So you have to give them some other names, not based on addition/removal
> order. Userspace (printcap in this case) will never be happy with names
> changing no matter how much we serialize.

There's the little issue of a very limited device node space.
That doesn't mean that I don't agree with the diagnosis.
I just don't see a way to implement the remedy cleanly.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

Oliver,

> You need to prevent any changes to the bus while you do the scanning.
> Running hotplug support is not enough. You need further kernel support
> to do racefree scanning. It gets worse if you take into account interference
> with non hotpluggable busses (SCSI).

Since I think the device naming needs work (PCI/USB/... bus level,
then levels above like "eth0", /dev/lp0, and so on) I'll just say that the
interference issues should be globally removed by providing and using
stable names (in the right ways :-).


> Therefore I suggest scanning in kernel space.

That gets interesting.  How would a usermode program request that,
say, the PCI or USB devices now present all get "hotplug" events?
I agree that it's likely easier to solve the locking issues "well" there,
but wonder how those dots would get connected.

- Dave




_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 07:47:45PM +0100, Oliver Neukum wrote:
> > Yes. Relying on detection order for device naming in a hotplugging
> > system is a nightmare, anyway.
> 
> It's hardcoded into many subsystems.
> 
> > > printer 1 addition -> edit printcap
> > > printer 2 addition -> edit printcap
> > > printer 1 removal -> edit printcap
> > >
> > > will leave you with lp1 as your printer name
> > > If you reverse steps 2 and 3 you get lp0 as printer name.
> >
> > So you have to give them some other names, not based on addition/removal
> > order. Userspace (printcap in this case) will never be happy with names
> > changing no matter how much we serialize.
> 
> There's the little issue of a very limited device node space.

You don't necessarily have to expand it, you just need to use it with
care.

> That doesn't mean that I don't agree with the diagnosis.
> I just don't see a way to implement the remedy cleanly.

Well, I think letting the hotplug program decide what the device will
appear as (the name or possibly also major/minor numbers) could work?

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Here are a couple of resources where we might be able to
find people to connect up with regarding how to get printing
working well in a hotplug environment:

http://sourceforge.net/foundry/printing
http://www.linuxprinting.org/summit.html

David Brownell wrote:
> 
> Right now there's no printer hotplugging support ... nothing
> calls out to userland "/dev/usb/lp0 was just born, have a cigar!".
> 
> In fact I'm unclear how much the different sorts of printer
> (USB, parallel, network, ...) all get autoconfigured.  Is there
> anyone working on putting together all those answers?
> 
> - Dave
> 
> ----- Original Message -----
> From: "Oliver Neukum" <Oliver.Neukum@lrz.uni-muenchen.de>
> To: "David Woodhouse" <dwmw2@infradead.org>
> Cc: "Vojtech Pavlik" <vojtech@suse.cz>; "Adam J. Richter" <adam@yggdrasil.com>;
> <linux-hotplug-devel@lists.sourceforge.net>
> Sent: Wednesday, February 07, 2001 6:45 AM
> Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.
> 
> > On Mittwoch,  7. Februar 2001 11:30, David Woodhouse wrote:
> > > Oliver.Neukum@lrz.uni-muenchen.de said:
> > > >  will leave you with lp1 as your printer name If you reverse steps 2
> > > > and 3 you get lp0 as printer name.
> > >
> > > That doesn't have to be a problem. If your script is editing printcap and
> > > inserting the device name it's given in the entry for the new printer, with
> > > whatever queue name(s) are configured elsewhere, why does it matter?
> >
> > If you were given that name. For USB at least you get an usbdevfs name at
> > best.
> >
> > Regards
> > Oliver
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > These are not enough. You must ensure that "remove" has finished before
> > you start anything that reuses the device node.
>
> I was assuming something that I suspect we should be considering
> as a goal (an "architectural" one?): names passed by hotplug agents
> must be stable.

Good idea.

> I'll have to think more about Vojtech's comments.  I think I will
> likely want the kernel to guarantee some stable name (is that a
> place where devfs could really help?) and let all the mappings
> to "virtual" names (like "eth0") be managed separately.

For SCSI devfs does that. About other subsystems I don't know enough.

But stable names don't save you from a need to serialise due to reuse.
In fact a stable name implies reuse, as it depends on bus location.
Either you get unique or you get stable names.

> > You see, changing the order of events 2 and 3 is wrong.
> > You'd have the wrong interfaces in printcap.
>
> Couldn't matter if the agent were passing the right stable names
> though, right?

Right, except for true reuse. See above.

> > Then you'd need to have a stable name provided to the hotplug script.
>
> Yes ...
>
> > This is difficult, for several reasons.
> > a) You need devfs (which is not PC)
>
> "devfsd" is not PC for me, but I'm less clear why a "/devfs" wouldn't be
> fine. Anyone care to start a separate thread on such topics?
>
> > b) You know that name only after the driver is loaded. (You don't even
> > know the number of names, multifunction devices and bridges)
>
> Device drivers can be viewed as adapters between namespaces:
> loading a device driver may cause entries in other namespaces.

This is the most theoretical way I have ever heard device drivers described 
:-)

> USB device "/proc/bus/usb/002/031" may be network interface "usb0".
> The lower level name (USB) is known before "usbnet" is loaded,
> but "usb0" isn't known till afterwards ... but then, USB hotplugging
> sees the USB name, and network hotplugging is what sees "usb0".

True, but there's no equivalent for network hotplugging for other subsystems.

> > c) You'd need to call after drivers have bound to interfaces.
>
> USB hotplug is called after the kernel gives drivers a chance to
> bind to interfaces.

That's not enough.
The mapping between devices and nodes isn't 1:1 but 1:0-n
You need an agent run for every node and an agent for the device (to load the 
driver)

> > These are conflicting requirements. In fact you'd need _two_ scripts. One
> > to load the driver, a second to configure the device the driver has bound
> > to.
>
> You mean like the difference between /etc/hotplug/*.agent (load driver FOO)
> and /etc/hotplug/*/FOO (configure each new device)?  :-)

I am not sure. I think you need to call them independently.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> But stable names don't save you from a need to serialise due to reuse.
> In fact a stable name implies reuse, as it depends on bus location.
> Either you get unique or you get stable names.

I also said (different word, true) that the names don't invalidate
(hence don't get reused!) while the agents operate.  There were
two constraints I put in that "minimal" set; you' ve focussed on
the first one!


> > USB device "/proc/bus/usb/002/031" may be network interface "usb0".
> > The lower level name (USB) is known before "usbnet" is loaded,
> > but "usb0" isn't known till afterwards ... but then, USB hotplugging
> > sees the USB name, and network hotplugging is what sees "usb0".
> 
> True, but there's no equivalent for network hotplugging for other subsystems.

Yet.  The stack we're looking at today has two layers:  bus (USB, PCI),
and "next" (network).  Printers and disks will be layered above busses;
PCMCIA is another bus.


> > > c) You'd need to call after drivers have bound to interfaces.
> >
> > USB hotplug is called after the kernel gives drivers a chance to
> > bind to interfaces.
> 
> That's not enough.
> The mapping between devices and nodes isn't 1:1 but 1:0-n
> You need an agent run for every node and an agent for the device (to load the 
> driver)

I think I allowed for that already in that comment of mine you had
described as "theoretical"!   (I was trying to describe the practice
of things in a general way ... surely that's one kind of theory.  :-)

By "node" presumably you mean "filesystem node"?  Because I can't
see the sense of a device that doesn't show up in _any_ namespace
(filesystem, netdev, etc).  No software could access it, right?


> > > These are conflicting requirements. In fact you'd need _two_ scripts. One
> > > to load the driver, a second to configure the device the driver has bound
> > > to.
> >
> > You mean like the difference between /etc/hotplug/*.agent (load driver FOO)
> > and /etc/hotplug/*/FOO (configure each new device)?  :-)
> 
> I am not sure. I think you need to call them independently.

Have a look at how the USB hotplug agent works; they're called
independently, in that the per-device setup can get called even
if the driver hasn't been loaded.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Mittwoch,  7. Februar 2001 22:14, David Brownell wrote:
> > But stable names don't save you from a need to serialise due to reuse.
> > In fact a stable name implies reuse, as it depends on bus location.
> > Either you get unique or you get stable names.
>
> I also said (different word, true) that the names don't invalidate
> (hence don't get reused!) while the agents operate.  There were
> two constraints I put in that "minimal" set; you' ve focussed on
> the first one!

OK. I had overlooked that.

> > > USB device "/proc/bus/usb/002/031" may be network interface "usb0".
> > > The lower level name (USB) is known before "usbnet" is loaded,
> > > but "usb0" isn't known till afterwards ... but then, USB hotplugging
> > > sees the USB name, and network hotplugging is what sees "usb0".
> >
> > True, but there's no equivalent for network hotplugging for other
> > subsystems.
>
> Yet.  The stack we're looking at today has two layers:  bus (USB, PCI),
> and "next" (network).  Printers and disks will be layered above busses;
> PCMCIA is another bus.

I see. However as soon as you take PCI into the picture, that's all
devices. It begins to look like recreating devfs.

> > > > c) You'd need to call after drivers have bound to interfaces.
> > >
> > > USB hotplug is called after the kernel gives drivers a chance to
> > > bind to interfaces.
> >
> > That's not enough.
> > The mapping between devices and nodes isn't 1:1 but 1:0-n
> > You need an agent run for every node and an agent for the device (to load
> > the driver)
>
> I think I allowed for that already in that comment of mine you had
> described as "theoretical"!   (I was trying to describe the practice
> of things in a general way ... surely that's one kind of theory.  :-)
>
> By "node" presumably you mean "filesystem node"?  Because I can't
> see the sense of a device that doesn't show up in _any_ namespace
> (filesystem, netdev, etc).  No software could access it, right?

Yes, I was refering to those things living in /dev ;-)
A device invisible to user space isn't useless.
A SCSI controller without devices attached is exactly that,
yet it has its uses later.

> > I am not sure. I think you need to call them independently.
>
> Have a look at how the USB hotplug agent works; they're called
> independently, in that the per-device setup can get called even
> if the driver hasn't been loaded.

I may be dense today. All I can see is usb.c::usb_new_device()

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

David Hinds wrote:

> On Sun, Feb 04, 2001 at 10:02:36AM -0800, Miles Lane wrote:
> 
>>> 1. 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.
>> 
>> Huh?  You mean that the driver can't handle _some_ Cardbus adapter
>> cards, right?  Mine work fine.
> 
> 
> What ones do you have?  Are you using 16-bit cards or only CardBus
> cards?

I have a "3Com PCI 3CCFE575BT Cyclone CardBus" (lspci lists
this device as a "3Com Corporation 3c575 [Megahertz] 10/100 
LAN CardBus [rev 01]") and a "Belkin BusPort Mobile" (lspci
gives "OPTi Inc. 82C861 [rev 10] [prog-if 10 [OHCI]]" for 
this device).

The full lspci output for them is:

01:00.0 Ethernet controller: 3Com Corporation 3c575 
[Megahertz] 10/100 LAN CardBus (rev 01)
        Subsystem: 3Com Corporation: Unknown device 5b57
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- 
	VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- 
	DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- 
	<PERR-
        Latency: 10 min, 5 max, 64 set
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at 1000 [size\x128]
        Region 1: Memory at 10800000 (32-bit, non-prefetchable) 
		[size\x128]
        Region 2: Memory at 10800080 (32-bit, non-prefetchable) 
		[size\x128]
        Expansion ROM at 10400000 [size\x128K]
        Capabilities: [50] Power Management version 1
                Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b7 10 57 51 07 00 10 02 01 00 00 02 00 40 00 00
10: 01 10 00 00 00 00 80 10 80 00 80 10 00 00 00 00
20: 00 00 00 00 00 00 00 00 90 00 00 00 b7 10 57 5b
30: 01 00 40 10 50 00 00 00 00 00 00 00 0b 01 0a 05
40: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
50: 01 00 01 76 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 7c 4b 9d 9d 57 51 c9 c4 36 00 4e 56 50 6d
70: 00 30 09 00 10 00 7c 4b 9d 9d 10 20 00 00 06 00
80: a6 32 70 15 00 00 60 00 07 00 00 00 00 00 81 00
90: 13 03 43 49 53 20 04 01 01 57 51 04 06 03 01 00
a0: 00 00 00 05 0c 41 9a 01 b5 1e 01 55 02 30 ff ff
b0: 01 07 06 11 00 40 00 00 00 15 34 05 00 33 43 6f
c0: 6d 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 33 43
d0: 43 46 45 35 37 35 42 54 00 4c 41 4e 20 43 61 72
e0: 64 62 75 73 20 43 61 72 64 00 30 30 31 00 ff 21
f0: 02 06 01 05 06 00 80 80 80 80 19 ff ff ff ff ff

and

05:00.0 USB Controller: OPTi Inc. 82C861 (rev 10) 
	(prog-if 10 [OHCI])
        Subsystem: OPTi Inc.: Unknown device c861
        Control: I/O- Mem+ BusMaster- SpecCycle- 
	MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- 
	DEVSEL=medium >TAbort- <TAbort- <MAbort- 
	>SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 11000000 (32-bit, non-prefetchable) 
		[size=4K]
00: 45 10 61 c8 02 00 80 02 10 10 03 0c 00 00 00 00
10: 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 45 10 61 c8
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 01 26 00 30 33 33 33 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Now, I do have a couple of bugs I am currently 
documenting.  One where, if I insert a card into
a slot that was empty at boot time, an OOPS occurs
and the PCMCIA/Cardbus slots become unusable.
The other has to do with using these two cardbus
cards simultaneously.  Linus thinks this is related
to my latency_timer settings, but I haven't been
able to confirm this, yet.

I should note that for at least the 3c575, I have
been using this card for about half a year with 
the yenta driver and it's worked great.  The problems
I mention only started showing up in the later 
kernels from the 2.4.0-test series.

Anyhow, I have used both of these cards without
other trouble.  If I have one of these cards
inserted at boot time, I can load either 3c59x
or usb-ohci and use the corresponding card.  

>> As for the issue of many drivers
>> requiring overrides and special settings, could you please give us
>> a few examples? 
> 
> 
> The PCMCIA-HOWTO has a list.  Some adapters do not power up in the
> correct interrupt delivery mode and the yenta driver doesn't have a
> way to tell it that a bridge must be put in PCI interrupt mode.

Thanks.  We'll refer to it.

	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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Adam J. Richter]

>> 	Even for the more elaborate case, where, say, a user quickly
>> inserts an ethernet card, removes it and then inserts a wireless
>> ethernet card which might need a different initialization, my scheme
>> would get it right because it does not look for existing devices until
>> it has already initialized the hot plug event handling, since the only
>> way that the first card could be detected is if the hot plugging
>> facilties were in place in time to see its later removal and the
>> insertion of the new card.

>Exactly that's the problem. What do you wish to do when the replacement has 
>happened after you have decided to do something to the interface, but before 
>you've started your action.

>Let me make a diagramm

>enable hotplugging
>start scanning bus
>decide to assign IP to eth0
>				eth0 goes away (eg leaving 802.11 zone)
>				a PCMCIA ethernet card is plugged in
>assign IP to eth0
[...]

>You need to prevent any changes to the bus while you do the scanning.
>Running hotplug support is not enough. You need further kernel support
>to do racefree scanning.

	You cannot lock physical reality.

	In any case, the doubt that I originally expressed was about
the need to queue hotplug events _before_ the hot plug system was
initialized.  In your example, the events occur after the hot plug
system is initialized.

	However, now that you mention it, let's talk about handling
events that occur after initialization.  I think we can avoid the
need to queue those events too.

	First of all, we should recognize that for most hardware,
the events caused by unplugging are handled directly by the kernel,
not by the user level hot plugging code.  For example, with a DHCP
configured ethernet, removal of the ethernet interface card should
cause the socket that dhcp has open on the ethernet interface to
return an IO exception condition, and dhclient should get -EIO 
and abort when it tries to execute the ioctl to check the status.

	Secondly, there is a way to get this processing right
where necessary without the need to queue events (which can overflow,
and involve maintiaining arbitrary large dynamic data strucutres).
All you need is a "new" flag that the kernel would set when on a device when
it is inserted.  The hot plug code would be called by the kernel
with an argument indicating what device to check, without necessarily
even indicating whether it was a hot plug or a remove event.

	userland_hotplug_handler(dev)
	{
		// was_plugged_in[dev] is persistent data, perhaps
		// stored in a file.

		acquire_lock(dev);   // Flock some file; could just have
				     // one global lock.  Whatever.
		if (was_plugged_in[dev]
		    && (new[dev] || !is_plugged_in[dev])) {
			was_plugged_in[dev] = 0;
			handle_remove_event(dev);
		}
		if (new[dev]) {
			new[dev] = 0;
			if (is_plugged_in[dev]) {
				was_plugged_in[dev] = 1;
				handle_insert_event(device);
			}
		}
		old_status[dev] = new_status;
		release_lock(dev);
	}

	Under this scheme, if multiple events occur on a particular
device slot, they will basically end up being coallesced together,
and the first call to /sbin/hotplug for this device will update
the situation to reflect the present status of the device
(generating possibly both an remove event and then an insert event),
and the subsequent calls to /sbin/hotplug that were queued for
that device will take no action.

	This scheme is inspired by the way similar status changes are
accumulated by USB hubs, but it should be able to work for all of the
hot plugging facilities if necessary.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> >You need to prevent any changes to the bus while you do the scanning.
> >Running hotplug support is not enough. You need further kernel support
> >to do racefree scanning.
>
> 	You cannot lock physical reality.

To a certain extent you can. You cannot hide removal, but you can hide 
addition. That's enough.

> 	In any case, the doubt that I originally expressed was about
> the need to queue hotplug events _before_ the hot plug system was
> initialized.  In your example, the events occur after the hot plug
> system is initialized.

No, it occurs while you are initialising the hotplug system.
You cannot scan a bus without locking it.
While you lock the bus what do you do with the events ?

You could indeed do without queueing initial events, if you did
scan the bus under lock.
Provided that you give stable names (David's definition) to the agents
in order to be able to loose information about ordering of events.

> 	However, now that you mention it, let's talk about handling
> events that occur after initialization.  I think we can avoid the
> need to queue those events too.
>
> 	First of all, we should recognize that for most hardware,
> the events caused by unplugging are handled directly by the kernel,
> not by the user level hot plugging code.  For example, with a DHCP
> configured ethernet, removal of the ethernet interface card should
> cause the socket that dhcp has open on the ethernet interface to
> return an IO exception condition, and dhclient should get -EIO
> and abort when it tries to execute the ioctl to check the status.

I am afraid I have to disagree. Most hardware is associated with device nodes
in /dev which retain their permission bits. You have to reset them on removal.

> 	Secondly, there is a way to get this processing right
> where necessary without the need to queue events (which can overflow,
> and involve maintiaining arbitrary large dynamic data strucutres).
> All you need is a "new" flag that the kernel would set when on a device
> when it is inserted.  The hot plug code would be called by the kernel
> with an argument indicating what device to check, without necessarily
> even indicating whether it was a hot plug or a remove event.
>
> 	userland_hotplug_handler(dev)
> 	{
> 		// was_plugged_in[dev] is persistent data, perhaps
> 		// stored in a file.
>
> 		acquire_lock(dev);   // Flock some file; could just have
> 				     // one global lock.  Whatever.
> 		if (was_plugged_in[dev]
> 		    && (new[dev] || !is_plugged_in[dev])) {
				^ race condition, the condition you check for might change
> 			was_plugged_in[dev] = 0;
> 			handle_remove_event(dev);
> 		}

and you may forget a removal event this way, which is bad

> 		if (new[dev]) {
> 			new[dev] = 0;
> 			if (is_plugged_in[dev]) {
> 				was_plugged_in[dev] = 1;
> 				handle_insert_event(device);
> 			}
> 		}
> 		old_status[dev] = new_status;
> 		release_lock(dev);
> 	}

The problem is is_plugged_in[]. It has to come from the kernel in last 
consequence. To avoid the race condition in the code above, acquire_lock has 
to lock is_plugged_in[], too. That means it has a need for kernel support.
Then what is the kernel supposed to do about events arriving while the lock 
is held ? Dropping them causes a race which can lead to events being lost.
You have to queue them (or at least set a flag, if you use stable names). 

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

Miles Lane wrote:
> 
> Now, I do have a couple of bugs I am currently
> documenting.  One where, if I insert a card into
> a slot that was empty at boot time, an OOPS occurs
> and the PCMCIA/Cardbus slots become unusable.

Do you have a ksymoops trace for that?

> The other has to do with using these two cardbus
> cards simultaneously.  Linus thinks this is related
> to my latency_timer settings, but I haven't been
> able to confirm this, yet.

Well, we played with that and it didn't help.

You're getting a PCI target abort (or was it
a master abort?).  The Cardbus bridge is unhappy.
I think we decided the NIC was generating the
abort, and we don't know why.  It's a messy one.

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > There's the little issue of a very limited device node space.
>
> You don't necessarily have to expand it, you just need to use it with
> care.

If you want stable names based on bus position then you absolutely
need to expand it. For USB at least you have no other way to get a stable 
name.

> > That doesn't mean that I don't agree with the diagnosis.
> > I just don't see a way to implement the remedy cleanly.
>
> Well, I think letting the hotplug program decide what the device will
> appear as (the name or possibly also major/minor numbers) could work?

I believe it could work, but at the same time I think it is a very bad idea.

a) How do you operate during system start ?
b) How do you do the transition ?
c) How do you handle locking ? You need total mutual exclusion.
d) How do you handle an error in the hotplug agent ?
e) What other algorithmus that couldn't be trivially implemented in kernel do 
you want to use ?

Either you use stable names, or you let the kernel decide the name and
give it to the  hotplug agent.
The first approach isn't all that good because it ruins things like 
/dev/videoX or /dev/audioX.
The second requires hotplug notification on device registration.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Andrew Morton]

David Woodhouse wrote:
> 
> Thinks.... a list of hotplug devices in a /proc file, listing some unique
> per-instance ID against the type, topological information and current name
> of the device. You don't send explicit add/remove events to userspace, just
> an "Oi. Look again".

Seems sensible to me.  It's a bit racy, but the read could be made
atomic if desired. (Thinks: devfs).

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

On Donnerstag,  8. Februar 2001 14:49, Andrew Morton wrote:
> David Woodhouse wrote:
> > Thinks.... a list of hotplug devices in a /proc file, listing some unique
> > per-instance ID against the type, topological information and current
> > name of the device. You don't send explicit add/remove events to
> > userspace, just an "Oi. Look again".
>
> Seems sensible to me.  It's a bit racy, but the read could be made
> atomic if desired. (Thinks: devfs).

You throw away information the kernel has for free.
You need to build a map of devices in user space, which is a single point of 
failure. You are required to serialise the agents. You are unable to handle 
errors.

	Regards
		Oliver


_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 11:28:14AM -0800, David Brownell wrote:

> > Yes, it is. And yes, we need this. And bus topology (head #1 uses port
> > #1 on the USB card, head #2 uses port #2, etc.) is the way how to find
> > out which mouse is which.
> >
> > I imagine it this way:
> 
> Your steps 0..11 seemed plausible, though I'm not keen on those
> particular device names.  Reason:  I think that there needs to be a
> strong distinction between the USB "topology" names (which we
> don't have today except as a non-integrated kernel patch or in
> the Java USB library) and the names of the "logical devices" that
> drivers create using those USB devices.  And I think you weren't
> maintaining the distinction between those names.
> 
> 
> > I'm not completely sure where to fit the device naming in, I'm thinking
> > about two variants:
> > 
> > A) After step 11, Hotplug daemon is called by the
> >    char/block/scsi/net-device layer and the hotplug daemon decides
> >    about the minor number/name (based on IDs and topology path -
> >    /pci00.07.4/usb0.3/input0/mousedev0).
> 
> I can see the hotplug agent (called by kernel or daemon) making
> intelligent policy decisions about the logical names to assign, but
> only if it's given good enough input.  Which will include "stable"
> names of various types, from lower levels (bus topology) or even
> from higher levels (network drivers may be able to determine
> stable MAC addresses).

I'm glad you like the scheme I described. I don't care about the naming
much, as long as it works.

> But in the name above, I think I see physical names admixed
> with logical ones ... so that's not a particular naming policy
> that I'd choose!

Depends on what you define as logical and physical. Yes, the "input bus"
is a purely virtual bus which has no physical representation. Still it
may behave like any other hotplugging bus, with input devices appearing
and disappearing, as lower-level modules register/unregister them.

The topology paths I've given above are just an example, and just one I
made up on the fly. However, I think they'd work:

/		is the host virtual bus
pci00.07.4 	is subdevice 4 of device 7 on PCI bus 0.
usb0.3 		is device in the fourth port (#3) on a hub attached
			to the first port on the USB card
input0		is the first input device on the input bus

And I probably made a mistake calling the last 'mousedev0', it should
have been

char13.32	which would be the mousedev device - a chardevice on
			major 13, minor 32.

> > B) At every time the hotplug daemon is loading a module, it
> >    passes a name/number it wishes the new device that caused the load
> >    to be registered under. Example: Loading hid.o, register as 'input4'.
> 
> I don't like "B" because it assumes predictive power in the hotplug
> daemon ... it has to predict/know how any driver will need names.
> That will lead quickly to chaos as the usermode code gets out
> of sync with the real behavior of that kernel driver.

In 'B' we wouldn't need to pass the whole 'topology path', instead
passing just the last part of the path would be enough.

> Also, keep in mind that statically linked modules need to fit into
> this scheme too.  Assigning "logical" names is in the "device init"
> phase of hotplugging, not the earlier "bind driver" (modprobe will
> not always help in binding).

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 10:02:02PM +0100, Oliver Neukum wrote:

> > Device drivers can be viewed as adapters between namespaces:
> > loading a device driver may cause entries in other namespaces.
> 
> This is the most theoretical way I have ever heard device drivers described 
> :-)

But also a very exact one. Current namespaces (buses) include
usb pci isapnp input serio gameport char block scsi net and others ...

There are many types of these 'adapters', for example a PCI gameport
driver for the Live! soundcard is pci->gameport, the mousedev module is
input->char, then there is for example the ohci driver which is
pci->usb, or the a3d is gameport->input+gameport.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 11:43:24PM +0100, Oliver Neukum wrote:

> > Yet.  The stack we're looking at today has two layers:  bus (USB, PCI),
> > and "next" (network).  Printers and disks will be layered above busses;
> > PCMCIA is another bus.
> 
> I see. However as soon as you take PCI into the picture, that's all
> devices. It begins to look like recreating devfs.

Actually I think that we need more than just devfs. Devfs stopped too
early and focuses only on the userland interface (/dev/*). If we manage
to get us stable names, we'll need more than devfs and I think that
we'll also make devfs obsolete.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Thu, Feb 08, 2001 at 02:22:46PM +0100, Oliver Neukum wrote:
> > > There's the little issue of a very limited device node space.
> >
> > You don't necessarily have to expand it, you just need to use it with
> > care.
> 
> If you want stable names based on bus position then you absolutely
> need to expand it. For USB at least you have no other way to get a stable 
> name.

True, if you don't want what's described below. But anyway, something
like that is needed for user friendliness, noone will want to type the
whole topology path each time he wants to access a device.

> > > That doesn't mean that I don't agree with the diagnosis.
> > > I just don't see a way to implement the remedy cleanly.
> >
> > Well, I think letting the hotplug program decide what the device will
> > appear as (the name or possibly also major/minor numbers) could work?
> 
> I believe it could work, but at the same time I think it is a very bad idea.
> 
> a) How do you operate during system start ?

Either assign the numbers by detection order or not at all and assume
the hotplug agent is started early from the root partition - then when
it starts, it'll see the unhandled (new) devices.. Can't do much else
anyway.

> b) How do you do the transition ?

See above. There will be undetected devices, those will be handled by
the hotplug agent. For those already assigned at kernel boot, either
leave them as they are or rename them via some system call.

> c) How do you handle locking ? You need total mutual exclusion.

Uh, mutual exclusion of what? I can't handle a device in the bus path
that's and one below/above it simultaneously. I can handle devices on
different branches simultaneously. It's possible that the hotplug agent
will want the same minor number for two different devices, one of these
calls will fail and will have to be retried with a different number by
the hotplug agent.

Any other problems?

> d) How do you handle an error in the hotplug agent ?

By falling back to assign-first-available default behavior.

> e) What other algorithmus that couldn't be trivially implemented in kernel do 
> you want to use ?

I want a config file, where the user can specify that:

a) The ethercard with MAC 00:06:08:fa:9c:dd is to be registered always
   as eth0

b) Any USB mouse that's connected to a hub connected to the first port
   of the USB card in first PCI slot is to be /dev/input/mouse2

c) Any IDE drive with serial number 8937298A is to be /dev/hdf

d) et similar.

You can't do this sanely in the kernel.

> Either you use stable names, or you let the kernel decide the name and
> give it to the hotplug agent.
> The first approach isn't all that good because it ruins things like 
> /dev/videoX or /dev/audioX.
> The second requires hotplug notification on device registration.

I think the hotplug agent should decide about the name.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > a) How do you operate during system start ?
>
> Either assign the numbers by detection order or not at all and assume
> the hotplug agent is started early from the root partition - then when
> it starts, it'll see the unhandled (new) devices.. Can't do much else
> anyway.

By detection order, else good bye to booting from PCMCIA, firewire, FC-AL, ...

> > c) How do you handle locking ? You need total mutual exclusion.
>
> Uh, mutual exclusion of what? I can't handle a device in the bus path
> that's and one below/above it simultaneously. I can handle devices on
> different branches simultaneously. It's possible that the hotplug agent
> will want the same minor number for two different devices, one of these
> calls will fail and will have to be retried with a different number by
> the hotplug agent.

You can retry, you are right. I failed to see that.
But you seem to suffer from the name reuse race.

reality			task A			task B
plug in dev A
			bind dev A to name 0
unplug dev A
						unbind name 0
plug in dev B
						bind dev B to name 0
			do something arbitrary
			to the dev associated
			with name 0

If the kernel would select name 0, it could lock on name 0.
With your scheme this is hard to do. 

> > e) What other algorithmus that couldn't be trivially implemented in
> > kernel do you want to use ?
>
> I want a config file, where the user can specify that:
>
> a) The ethercard with MAC 00:06:08:fa:9c:dd is to be registered always
>    as eth0
>
> b) Any USB mouse that's connected to a hub connected to the first port
>    of the USB card in first PCI slot is to be /dev/input/mouse2
>
> c) Any IDE drive with serial number 8937298A is to be /dev/hdf
>
> d) et similar.
>
> You can't do this sanely in the kernel.

Nor do you absolutely need to.
You can already rename network devices by ioctl.
For everything else a humble symlink should do the job, shouldn't it ?

Else you introduce complexity without much gain.
And you need renaming in any case, as device names may have been assigned
during boot.

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Fri, Feb 09, 2001 at 12:48:59PM +0100, Oliver Neukum wrote:

> > Either assign the numbers by detection order or not at all and assume
> > the hotplug agent is started early from the root partition - then when
> > it starts, it'll see the unhandled (new) devices.. Can't do much else
> > anyway.
> 
> By detection order, else good bye to booting from PCMCIA, firewire, FC-AL, ...

Ok.

> > > c) How do you handle locking ? You need total mutual exclusion.
> >
> > Uh, mutual exclusion of what? I can't handle a device in the bus path
> > that's and one below/above it simultaneously. I can handle devices on
> > different branches simultaneously. It's possible that the hotplug agent
> > will want the same minor number for two different devices, one of these
> > calls will fail and will have to be retried with a different number by
> > the hotplug agent.
> 
> You can retry, you are right. I failed to see that.
> But you seem to suffer from the name reuse race.
> 
> reality			task A			task B
> plug in dev A
> 			bind dev A to name 0
> unplug dev A
> 						unbind name 0
> plug in dev B
> 						bind dev B to name 0
> 			do something arbitrary
> 			to the dev associated
> 			with name 0
> 
> If the kernel would select name 0, it could lock on name 0.
> With your scheme this is hard to do. 

Unbind on name 0 should block until task A finishes the arbitrary stuff.
Is there any problem with that? We could even have a 'setup finished'
ioctl for this, though I think I'd prefer just having one task per action.

> > > e) What other algorithmus that couldn't be trivially implemented in
> > > kernel do you want to use ?
> >
> > I want a config file, where the user can specify that:
> >
> > a) The ethercard with MAC 00:06:08:fa:9c:dd is to be registered always
> >    as eth0
> >
> > b) Any USB mouse that's connected to a hub connected to the first port
> >    of the USB card in first PCI slot is to be /dev/input/mouse2
> >
> > c) Any IDE drive with serial number 8937298A is to be /dev/hdf
> >
> > d) et similar.
> >
> > You can't do this sanely in the kernel.
> 
> Nor do you absolutely need to.
> You can already rename network devices by ioctl.
> For everything else a humble symlink should do the job, shouldn't it ?

Yes, but with humble symlinks you will run out of minor/major numbers soon.

> Else you introduce complexity without much gain.
> And you need renaming in any case, as device names may have been assigned
> during boot.

Yes. Symlinks would help here, however, you'd probably need devfs in
that case.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Oliver Neukum]

> > You can retry, you are right. I failed to see that.
> > But you seem to suffer from the name reuse race.
> >
> > reality			task A			task B
> > plug in dev A
> > 			bind dev A to name 0
> > unplug dev A
> > 						unbind name 0
> > plug in dev B
> > 						bind dev B to name 0
> > 			do something arbitrary
> > 			to the dev associated
> > 			with name 0
> >
> > If the kernel would select name 0, it could lock on name 0.
> > With your scheme this is hard to do.
>
> Unbind on name 0 should block until task A finishes the arbitrary stuff.
> Is there any problem with that? We could even have a 'setup finished'
> ioctl for this, though I think I'd prefer just having one task per action.

This would work provided that the lock is taken atomically with binding to 
the name.

> > Nor do you absolutely need to.
> > You can already rename network devices by ioctl.
> > For everything else a humble symlink should do the job, shouldn't it ?
>
> Yes, but with humble symlinks you will run out of minor/major numbers soon.

Why is that ? Even if you assign numbers by the agent you would take them out 
of a pool of numbers the kernel could also use.
In both cases it would seem that devices use the same amount of numbers.

> > Else you introduce complexity without much gain.
> > And you need renaming in any case, as device names may have been assigned
> > during boot.
>
> Yes. Symlinks would help here, however, you'd probably need devfs in
> that case.

I can see devfs helping tremendously with providing stable names, but why is 
it necessary ?

	Regards
		Oliver

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

Could you elaborate on "more than devfs"?

I know some criticisms of devfs:  it didn't get drivers out of the business
of preallocating major/minor device numbers.  (Why should there be
so few /dev/input device nodes available?)  And the "let a million
symlinks bloom" role of devfsd isn't necessarily desired.  "devfs"
doesn't know about /proc/bus/... physical names (maybe shouldn't);
it doesn't know about network interface names (maybe shouldn't).

One thing I think I see missing is a way to relate the "logical" names
(like /dev/input/* or /dev/audio*) to physical ones (based on topology,
like /proc/bus/*).  That's something "cardmgr" does inside itself
("eth0" is pcmia slot 1) as I recall.  It should be possible to set up
a topology-based naming policy so that we never see "mouse999"
style names, but only ".../kiosk42/mouse" style ones ... at least
after the system has fully booted.

But I don't yet see all that adding up to something I could wrap my
head around and use or implement ... needs more discussion! :-)

- Dave


----- Original Message ----- 
From: "Vojtech Pavlik" <vojtech@suse.cz>
To: "Oliver Neukum" <Oliver.Neukum@lrz.uni-muenchen.de>
Cc: "David Brownell" <david-b@pacbell.net>; <linux-hotplug-devel@lists.sourceforge.net>
Sent: Thursday, February 08, 2001 7:13 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.


> On Wed, Feb 07, 2001 at 11:43:24PM +0100, Oliver Neukum wrote:
> 
> > > Yet.  The stack we're looking at today has two layers:  bus (USB, PCI),
> > > and "next" (network).  Printers and disks will be layered above busses;
> > > PCMCIA is another bus.
> > 
> > I see. However as soon as you take PCI into the picture, that's all
> > devices. It begins to look like recreating devfs.
> 
> Actually I think that we need more than just devfs. Devfs stopped too
> early and focuses only on the userland interface (/dev/*). If we manage
> to get us stable names, we'll need more than devfs and I think that
> we'll also make devfs obsolete.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Vojtech Pavlik]

On Fri, Feb 09, 2001 at 02:09:39PM +0100, Oliver Neukum wrote:
> > > You can retry, you are right. I failed to see that.
> > > But you seem to suffer from the name reuse race.
> > >
> > > reality			task A			task B
> > > plug in dev A
> > > 			bind dev A to name 0
> > > unplug dev A
> > > 						unbind name 0
> > > plug in dev B
> > > 						bind dev B to name 0
> > > 			do something arbitrary
> > > 			to the dev associated
> > > 			with name 0
> > >
> > > If the kernel would select name 0, it could lock on name 0.
> > > With your scheme this is hard to do.
> >
> > Unbind on name 0 should block until task A finishes the arbitrary stuff.
> > Is there any problem with that? We could even have a 'setup finished'
> > ioctl for this, though I think I'd prefer just having one task per action.
> 
> This would work provided that the lock is taken atomically with binding to 
> the name.

Yep, that's what I intended.

> > > Nor do you absolutely need to.
> > > You can already rename network devices by ioctl.
> > > For everything else a humble symlink should do the job, shouldn't it ?
> >
> > Yes, but with humble symlinks you will run out of minor/major numbers soon.
> 
> Why is that ? Even if you assign numbers by the agent you would take them out 
> of a pool of numbers the kernel could also use.
> In both cases it would seem that devices use the same amount of numbers.

Actually, you're right. For some reason I was assuming the symlinks
would have to point to stable names - unique at least for each topology path.
This is not completely necessary, though.

> > > Else you introduce complexity without much gain.
> > > And you need renaming in any case, as device names may have been assigned
> > > during boot.
> >
> > Yes. Symlinks would help here, however, you'd probably need devfs in
> > that case.
> 
> I can see devfs helping tremendously with providing stable names, but why is 
> it necessary ?

It isn't needed - I was assuming the symlinks would have to point to
stable names.

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "Miles Lane" <miles@megapathdsl.net>
> Sent: Sunday, February 04, 2001 10:02 AM
>
> Here's an overview of where we are now.

[ based on David Hinds' list ]

> > 2. There is no mechanism to request a card eject in the new framework.
> >    This is required for clean shutdown of SCSI and IDE adapters.
> 
> (Rusty Russell and other kernel developers are looking into 
> related improvements.  Also, discussion has started on 
> linux-hotplug-devel)

Exactly what is meant by "eject" though?  "eject pcmcia-slot-1"
can't exactly eject the drive, as it would for a CD or ZIP disc.
And I think it might be good to avoid requiring each type of
hotplug bus to have its own "eject" tool.

I think what's meant is "disconnect the drivers and do electrical
shutdown".  USB needs corresponding functionality.  I did a patch
a while back, which I'll submit soonish; it turns out to be helpful
for a variety of user-mode tools.  It's an ioctl on the /proc/bus/usb
device files ... perhaps that approach should be incorporated into
the /proc/bus/pci device file support.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed

[Chris Brand]

For Compact PCI, what you describe below ("disconnect the drivers and do
electrical shutdown") is called "quiescing" the device. It's essentially the
same thing as opening the ejection handle on a board. The blue "safe to
remove" LED on the board should be lit so the operator can see which board
it is that can now be removed.

Overall, this seems to me like a reasonable interpretation of "eject" in
cPCI-land.

Chris

-----Original Message-----
Date: Mon, 26 Feb 2001 09:47:49 -0800
From: David Brownell <david-b@pacbell.net>
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.
To: Miles Lane <miles@megapathdsl.net>,
 Linux Hotplug <linux-hotplug-devel@lists.sourceforge.net>

> From: "Miles Lane" <miles@megapathdsl.net>
> Sent: Sunday, February 04, 2001 10:02 AM
>
> Here's an overview of where we are now.

[ based on David Hinds' list ]

> > 2. There is no mechanism to request a card eject in the new framework.
> >    This is required for clean shutdown of SCSI and IDE adapters.
> 
> (Rusty Russell and other kernel developers are looking into 
> related improvements.  Also, discussion has started on 
> linux-hotplug-devel)

Exactly what is meant by "eject" though?  "eject pcmcia-slot-1"
can't exactly eject the drive, as it would for a CD or ZIP disc.
And I think it might be good to avoid requiring each type of
hotplug bus to have its own "eject" tool.

I think what's meant is "disconnect the drivers and do electrical
shutdown".  USB needs corresponding functionality.  I did a patch
a while back, which I'll submit soonish; it turns out to be helpful
for a variety of user-mode tools.  It's an ioctl on the /proc/bus/usb
device files ... perhaps that approach should be incorporated into
the /proc/bus/pci device file support.

- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Mon, Feb 26, 2001 at 09:47:49AM -0800, David Brownell wrote:

> Exactly what is meant by "eject" though?  "eject pcmcia-slot-1"
> can't exactly eject the drive, as it would for a CD or ZIP disc.

Actually some PCMCIA sockets do have eject mechanisms.  Powerbooks for
example.

> I think what's meant is "disconnect the drivers and do electrical
> shutdown".

This was mostly what I had in mind.

-- Dave

_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell]

> From: "David Hinds" <dhinds@sonic.net>
> Sent: Monday, February 26, 2001 11:56 PM
>
> On Mon, Feb 26, 2001 at 09:47:49AM -0800, David Brownell wrote:
> 
> > Exactly what is meant by "eject" though?  "eject pcmcia-slot-1"
> > can't exactly eject the drive, as it would for a CD or ZIP disc.
> 
> Actually some PCMCIA sockets do have eject mechanisms.  Powerbooks for
> example.

Does "cardctl eject 1" physically eject on those platforms?


> > I think what's meant is "disconnect the drivers and do electrical
> > shutdown".
> 
> This was mostly what I had in mind.

Good.  Seems like for PCI, we'll need to pay attention to the user
feedback mechanisms, since this is important for the high availability
hotplugging mechanisms (cPCI, Compaq "Hotplug PCI") that use
indicator LEDs to help protect that mission-critical data, while we
recently learned that some folk really like beeps on PC-Card form
factor devices.

Without having looked at this, I'd like to think that the "quiesce
the driver and hardware" functionality should be one code path,
and the "give the right domain-specific feedback" paths might
need to be different ... though I'd hope not.  I think some of the
patches Compaq put up on their hotplug site related to this stuff.

- Dave



_______________________________________________
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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Hinds]

On Wed, Feb 28, 2001 at 08:56:25AM -0800, David Brownell wrote:

> Does "cardctl eject 1" physically eject on those platforms?

There is a patch to do it but I haven't included it in the regular
driver distribution yet.

-- Dave

_______________________________________________
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