hotplug TTD

hotplug TTD

[Morton, Andrew [WOLL:4009-M:EXCH]]

So. What needs to be done to finish this thing?

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

Re: hotplug TTD

[Miles Lane]

Well, for one thing, my Belkin BusPort Mobile USB Host-controller
(which is a Cardbus PCcard) needs to start getting configured when
it is inserted.  This was working in 2.4.0-test12-pre5 and broken
in all subsequent kernels.

Another thing, we need to add in support for collecting the
device detection events early in the boot process and then
replay those events to /sbin/hotplug, so that those devices
get configured.

Also, currently we still get errors during the boot process
where Request_module fails with an error like this one:

    kernel: request_module[scsi_hostadapter]: Root fs not mounted

Since this message is being generated during a time when it is
impossible to actually load modules, this error message should
not be emitted.

I imagine there are other issues in addition to these.

Cheers,
	Miles

Morton, Andrew [WOLL:4009-M:EXCH] wrote:

> So. What needs to be done to finish this thing?
> 
> _______________________________________________
> Linux-hotplug-devel mailing list
> Linux-hotplug-devel@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel



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

Re: hotplug TTD

[Miles Lane]

Hmm.  I assume that by "finish this thing", you mean the
generic portion of hotplug support.  There are obviously
boatloads of changes needed in all the hotplug bus trees
and for all the hotpluggable devices.

The respective development communities will need to
enumerate the requirements for their areas (this IS
an invitation):

SCSI
Fusion MPT?
I2O?
IrDA
FireWire
PCMCIA/PC-Card
	- Network adapter cards
	- SCSI adapter cards
	- USB host-controller cards
	- Wireless network adapter cards
	- ISDN adapter -- AVM A1 PCMCIA (Fritz)
Wireless Networking
PCI
USB

A somewhat tangential project is porting support for
all the devices covered by the pcmcia-cs package into
the kernel tree.  This project also includes working
out all the usermode utility and configuration support
issues.  Currently, the pcmcia-cs configuration does
not work for the native kernel drivers in 2.4.0
(yenta, 3c59x, etc).

I would prefer to see default configuration files live
in the kernel tree and be installed by the kernel
installation process when PCMCIA/Cardbus support is
selected.  Ideally, the necessary usermode support
utilities would be disseminated in the same way that
ksymoops and modutils are now.

Other thoughts?

	Miles


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

Re: hotplug TTD

[Adam J. Richter]

        Perhaps I'm just being pedantic, but I'd like to just clarify
that many of the Linux-related facilities that people refer to as
"hot plugging" in are not really hot plugging, but rather a set of
facilities used by most of the kernel hot plugging schemes:

                1. a standardized hardware identification scheme
                   for the bus in question (ISAPnP, PCI, USB, other
                   systems covered by Intel Plug'n'Play standards, etc.)

                2. a facility for dynamically loading kernel driver
                   modules for that bus.

                3. A MODULE_DEVICE_ID table for that format in each
                   relevant driver.

                4. Support for that ID table format in depmod
        
                5.  A user level program that reads the appropriate depmod
                    modules.___map and figures out which modules to load.

        For example, I understand that ISAPnP hardware is not
capable of hot plugging, but it uses these same facilities.
Conceivably, other non-hotplug busses that have quasi-standard
schemes for hardware enumeration could use these facilities
as well (NuBus? S-Bus?).

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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: hotplug TTD

[David Brownell]

> So. What needs to be done to finish this thing?

Can one "finish" software, ever?  :-)


A few things on my mind:  move the hotplug scripts to this new
linux-hotplug project. Create better hotplug docs, put them on
the a website.  Maybe the hotplug programs should turn into C
programs not scripts, who knows.  Volunteers?


Technically, there are open issues I think need to be addressed.

First, get hotplugging back to the behavior I saw in about test11,
which is bugfixing and testing.  Call this "kernel 2.4.1 work" for
the most part; basically, hotplugging for USB, PCI/Cardbus, and
NETworking should all work smoothly.

    - Sync up with the 2.4.0-final ABI change for usb_device_id,
      including "usbutils" and various bugs (usb-serial etc) that
      snuck in with that change.  (I think modutils is set.)

    - More testing on the "new" user mode hotplug scripts (which
      use /etc/hotplug exclusively) ... adding a PCI hotplug agent
      (steal from the old one).

    - Find out what's up with those async changes (test12) that
      sometimes seem to wedge things when I modprobe a USB HCD
      for a controller that's got a network adapter pre-connected.
      (Andrew, I've not yet made time to try your sync/async patch
      putting USB back in pure synchronous mode; chasing an oops.)

    - Similarly for the PCI/Cardbus hotplug situation; Miles has
      reported problems there.

    - Are those network API changes a 2.4.1 issue -- replacing
      init_etherdev() with prepare_etherdev()/withdraw_netdev() ?
      It was my understanding they were needed to cleanly do
      network hotplugging.

I think that all USB devices other than some of the funkier HID
devices should be ready to hotplug at this time ... the main win
from that ABI change was simpler handling for usb-storage, but we
got some destabilization too.

Second, there are various types of related functionality to be
developed.  Addressing the "can't hotplug during boot" issue
(something kudzu-like to scan /proc/bus/{usb,pci}/*/* and create
hotplug events).  Some sort of generic analogue to "cardctl eject"
would be good.  And as Miles noted, "pcmcia_cs" is a degenerate
case of (generic) hotplug ...

There's also device/driver specific initialization that we should
understand better.  We know how to ensure that a USB controller
(on any PCI bus) is cleanly initted.  I don't think we know how
to do that for a disk drive (start with SCSI and generalize) or
printer.

- Dave




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

Re: hotplug TTD

[David Brownell]

Hi Adam,

>         Perhaps I'm just being pedantic, but I'd like to just clarify
> that many of the Linux-related facilities that people refer to as
> "hot plugging" in are not really hot plugging, but rather a set of
> facilities used by most of the kernel hot plugging schemes:

I don't think there's been a strict definition of "hotplugging",
but you're _absolutely right_ that what we've got is a collection
of facilities that need to be reasonably well integrated.  Which
is one of the challenges in growing it, moving forward.


>                 1. a standardized hardware identification scheme
>                    for the bus in question (ISAPnP, PCI, USB, other
>                    systems covered by Intel Plug'n'Play standards, etc.)

That's pretty much what the original "PCI Hotplug" config option did.
It's evolved a bit since then ... ;-)

>                 2. a facility for dynamically loading kernel driver
>                    modules for that bus.

That's one of the subtasks "/sbin/hotplug" (CONFIG_HOTPLUG) enables;
but not the only one.

>                 3. A MODULE_DEVICE_ID table for that format in each
>                    relevant driver.
>
>                 4. Support for that ID table format in depmod

Also within each bus framework ... USB, PCI, and ISAPNP use those tables
when binding drivers to devices.

>                 5.  A user level program that reads the appropriate depmod
>                     modules.___map and figures out which modules to load.

And there's more:

-  "Network hotplugging" isn't specific to any given bus, it
   works for all network devices.

-  I suspect that "SCSI" hotplugging (like "input" hotplugging)
   will be more what one might think of as a "logical" bus that
   needn't correspond to any particular type of hardware.  (USB
   storage device, even flash memory, are virtual SCSI devices;
   the input subsystem isn't USB-specific.)

-  It includes device configuration, not just module loading;
   Hotplugging is useful even on fully static kernels.

Basically, "plug the device in and it's immediately usable" is
the goal of hotplugging.  So it's got to cover more than just
device-to-driver binding issues; in some cases it'll need to
know how to notify applications about new devices they should
be managing.


>         For example, I understand that ISAPnP hardware is not
> capable of hot plugging, but it uses these same facilities.
> Conceivably, other non-hotplug busses that have quasi-standard
> schemes for hardware enumeration could use these facilities
> as well (NuBus? S-Bus?).

Yes.  I usually think of hotplug as "autoconfiguring Linux".  The
same kinds of facilities (and "design patterns" if I can mention
that here without getting shot!) can apply in many contexts.

For example, I think there's no virtue to having separate ways
to configure USB or PCI devices depending on whether they were
there at powerup time ("cold plugging") or were plugged in later
("hot" pluggging).

Once I start thinking that way, I think "hotplug" maybe wasn't
the perfect name ... not that I know a better one, of course!

- Dave



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

RE: hotplug TTD

[Grover, Andrew]

ACPI.

-- Andy

> From: Miles Lane [mailto:miles@megapathdsl.net]
> The respective development communities will need to
> enumerate the requirements for their areas (this IS
> an invitation):
> 
> SCSI
> Fusion MPT?
> I2O?
> IrDA
> FireWire
> PCMCIA/PC-Card
> 	- Network adapter cards
> 	- SCSI adapter cards
> 	- USB host-controller cards
> 	- Wireless network adapter cards
> 	- ISDN adapter -- AVM A1 PCMCIA (Fritz)
> Wireless Networking
> PCI
> USB


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

RE: hotplug TTD

[Grover, Andrew]

Is it unreasonable, long-term, to move towards a unified Linux hotplug
architecture?

Under both Windows and BeOS, a given bus driver is responsible for
enumerating the devices on it, and it tells a central "configuration
manager", who then is the one who loads the drivers.

Having one entity who knows about all devices on a system is also great for
power management, and implementing suspend-to-memory and suspend-to-disk.

Thoughts?

Regards -- Andy


> From: Adam J. Richter [mailto:adam@yggdrasil.com]
>         Perhaps I'm just being pedantic, but I'd like to just clarify
> that many of the Linux-related facilities that people refer to as
> "hot plugging" in are not really hot plugging, but rather a set of
> facilities used by most of the kernel hot plugging schemes:
> 
>                 1. a standardized hardware identification scheme
>                    for the bus in question (ISAPnP, PCI, USB, other
>                    systems covered by Intel Plug'n'Play 
> standards, etc.)
> 
>                 2. a facility for dynamically loading kernel driver
>                    modules for that bus.
> 
>                 3. A MODULE_DEVICE_ID table for that format in each
>                    relevant driver.
> 
>                 4. Support for that ID table format in depmod
>         
>                 5.  A user level program that reads the 
> appropriate depmod
>                     modules.___map and figures out which 
> modules to load.
> 
>         For example, I understand that ISAPnP hardware is not
> capable of hot plugging, but it uses these same facilities.
> Conceivably, other non-hotplug busses that have quasi-standard
> schemes for hardware enumeration could use these facilities
> as well (NuBus? S-Bus?).


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

Re: hotplug TTD

[Andrew Morton]

David Brownell wrote:
> 
>     - Are those network API changes a 2.4.1 issue -- replacing
>       init_etherdev() with prepare_etherdev()/withdraw_netdev() ?
>       It was my understanding they were needed to cleanly do
>       network hotplugging.

No, they're not likely to be a problem.  The unpopular dev_probe_lock()
protects us for Cardbus and PCI devices.  A `sleep 1' prior to running
`ifconfig up' will pretty well avoid any problems.  Probably unnecessary
though.

> I think that all USB devices other than some of the funkier HID
> devices should be ready to hotplug at this time ... the main win
> from that ABI change was simpler handling for usb-storage, but we
> got some destabilization too.
> 
> Second, there are various types of related functionality to be
> developed.  Addressing the "can't hotplug during boot" issue
> (something kudzu-like to scan /proc/bus/{usb,pci}/*/* and create
> hotplug events).  Some sort of generic analogue to "cardctl eject"
> would be good.  And as Miles noted, "pcmcia_cs" is a degenerate
> case of (generic) hotplug ...

mm..  For PCI isn't it simply a matter of parsing /proc/bus/pci/*/*
(or lspci output) to determine all the devices, then synthesising
hotplug events for them?

Now, there are a number of bells-n-whistles which could be added
here.  For example, people get irritated when they put their network
cards into different slots and eth0 and eth1 get swapped around. We
could fix this with some constraints, or a manual override before
the automatic hotplug synthesis.

This is just one requirement - there are surely many others.  'fraid
I haven't started to get my head around it yet.

> There's also device/driver specific initialization that we should
> understand better.  We know how to ensure that a USB controller
> (on any PCI bus) is cleanly initted.  I don't think we know how
> to do that for a disk drive (start with SCSI and generalize) or
> printer.

err, yes.   Plus if you run `/sbin/hotplug pci' five times
back-to-back for five devices, you'll cause a great storm
of initialisation activity, concurrent execution of
modprobe and all sorts of things.  Kernels will explode,
I promise :)   This is going to be complex.

We do need to bring the devices up sequentially and
methodically.

-

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

Re: hotplug TTD

[Andrew Morton]

"Grover, Andrew" wrote:
> 
> Is it unreasonable, long-term, to move towards a unified Linux hotplug
> architecture?
> 
> Under both Windows and BeOS, a given bus driver is responsible for
> enumerating the devices on it, and it tells a central "configuration
> manager", who then is the one who loads the drivers.
> 
> Having one entity who knows about all devices on a system is also great for
> power management, and implementing suspend-to-memory and suspend-to-disk.
> 

Not sure I completely understand this one.

Given that all the different bus ("resource"?) types have different
discovery mechanisms, I think you're proposing that, once discovered,
they will be recorded in a database of some form?  In a unified format?

So we have, if you like, an array of objects each of which represents
a device in the system, and they each have state, `eject', `powerdown' methods,
etc?

Heh.  XircomNic is-a CardbusDevice is-a PCIDevice is-a Device is-a blah.

It could get complex with devices behind bridges behind bridges. Is a 
bridge a device?  Do we need to care about bridges?

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

Re: hotplug TTD

[Andrew Morton]

"Grover, Andrew" wrote:
> 
> ACPI.

What are the ACPI requirements??

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

Re: hotplug TTD

[David Brownell]

> From: Grover, Andrew <andrew.grover@intel.com>
> Sent: Tuesday, January 09, 2001 10:34 PM
>
> Is it unreasonable, long-term, to move towards a unified Linux hotplug
> architecture?

I don't see why it would be unreasonable.  Arguably, that's the direction
that has been set already.  But -- what do you mean by "architecture"?
That's a loaded word in many minds.

So far I've been happy to start seeing subsystems share more structure and
start to behave in the same kinds of ways.  I think there's a long way we
can usefuly go down that path.  "Lightweight architecture"?  The design
patterns used by various subsystems need to fit together effectively.


> Under both Windows and BeOS, a given bus driver is responsible for
> enumerating the devices on it, and it tells a central "configuration
> manager", who then is the one who loads the drivers.

Many of us don't know those two systems very well; but perhaps the
"/sbin/hotplug" policy agent is analagous to that mananager.  Except
that it can't just "load drivers", it's got to configure them too.
Maybe you could elaborate a bit?

Using USB and PCI (in Linux 2.4 kernels) as an example, clearly the
bus drivers (USB HCDs, Cardbus or Hotplug PCI bridges) are going to
enumerate devices and handle some of the config change details.  But
the goal is to punt all the hard policy questions (what driver, how
to set it up) to userspace through one mechanism (/sbin/hotplug).


> Having one entity who knows about all devices on a system is also great for
> power management, and implementing suspend-to-memory and suspend-to-disk.

I'm glad you mentioned power management, the "hot" in "hot plug"!

USB has some work to do yet for power management.  For example, I
suspect that USB Host Controller Drivers ("HCDs") should mediate
suspend/resume processing for each of their devices, ensuring devices
get suspended before bridges (and resumed after).  That's simple
enough to do (Cardbus got complicated because of PCMCIA) but it calls
for "struct usb_driver" API updates.

So far I've been thinking of power management as _mostly_ an issue
that subsystems should deal with locally ... following global rules
and policies.  Likely you have clearer ideas about how those should
get reflected down to the subsystems, or back to some global/central
entity when policy questions arise.

- Dave




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

Re: hotplug TTD

[David Brownell]

> From: Andrew Morton <andrewm@uow.edu.au>
> Sent: Wednesday, January 10, 2001 2:58 AM
>
> David Brownell wrote:
> > 
> > Second, there are various types of related functionality to be
> > developed.  Addressing the "can't hotplug during boot" issue
> > (something kudzu-like to scan /proc/bus/{usb,pci}/*/* and create
> > hotplug events).  Some sort of generic analogue to "cardctl eject"
> > would be good.  And as Miles noted, "pcmcia_cs" is a degenerate
> > case of (generic) hotplug ...
> 
> mm..  For PCI isn't it simply a matter of parsing /proc/bus/pci/*/*
> (or lspci output) to determine all the devices, then synthesising
> hotplug events for them?

Yes.

Though when I started to think about how to do that stuff robustly, I
began to wish a kernel "module" didn't stop being a visible component
when it gets statically linked.  There's a rather arbitrary line between
static linking (build tools) and dynamic linking (modutils).  Hotplugging
a device shouldn't need to care so much how the driver module is linked.


> Now, there are a number of bells-n-whistles which could be added
> here.  For example, people get irritated when they put their network
> cards into different slots and eth0 and eth1 get swapped around. We
> could fix this with some constraints, or a manual override before
> the automatic hotplug synthesis.

David Hinds at one point spoke in favor of having more info passed
to the network hotplug events than just the interface name.  That's
critical for statically configured hardware (servers); dynamically
configured ones (pure DHCP clients, say) should not care.

It's a generic problem with the notion of automagically assigning
"user meaningful names" to hardware.  Happens all the time when
USB devices show up ... two card readers, two cameras, etc have
exactly analagous problems.  And it's not a problem "devfs" is
able to handle, near as I can tell.


> This is just one requirement - there are surely many others.  'fraid
> I haven't started to get my head around it yet.

Me either.  Hence my "..." above ... ;-)


> > There's also device/driver specific initialization that we should
> > understand better.  We know how to ensure that a USB controller
> > (on any PCI bus) is cleanly initted.  I don't think we know how
> > to do that for a disk drive (start with SCSI and generalize) or
> > printer.
> 
> err, yes.   Plus if you run `/sbin/hotplug pci' five times
> back-to-back for five devices, you'll cause a great storm
> of initialisation activity, concurrent execution of
> modprobe and all sorts of things.  Kernels will explode,
> I promise :) 

Exploding penguin-shaped TV set-top boxes ... the holy grail
of kernel development?  Clearly a sign that we need Python
developers involved ... ;-)

- Dave




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

Re: hotplug TTD

[David Hinds]

On Thu, Jan 11, 2001 at 08:40:44AM -0800, David Brownell wrote:
> 
> Though when I started to think about how to do that stuff robustly, I
> began to wish a kernel "module" didn't stop being a visible component
> when it gets statically linked.  There's a rather arbitrary line between
> static linking (build tools) and dynamic linking (modutils).  Hotplugging
> a device shouldn't need to care so much how the driver module is linked.

Yes this is useful.  For PCMCIA, I created /proc/bus/pccard/drivers to
list what drivers are present, as static or modules.  But a kernel
wide solution would be better (even if it is /proc/bus/*/drivers).

> David Hinds at one point spoke in favor of having more info passed
> to the network hotplug events than just the interface name.  That's
> critical for statically configured hardware (servers); dynamically
> configured ones (pure DHCP clients, say) should not care.

Yes, I can tell you that if only the interface name is passed, it is
going to frustrate some people who are used to having more information
from PCMCIA.  It isn't entirely bad... at least, you can get the
interface's hardware address, and use that to choose configurations.
But I find it quite useful to know that eth0 is "the 3C575 card in
PCMCIA socket 1", or vice versa.

-- Dave

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

Re: hotplug TTD

[David Brownell]

Hi Dave,

> On Thu, Jan 11, 2001 at 08:40:44AM -0800, David Brownell wrote:
> > 
> > Though when I started to think about how to do that stuff robustly, I
> > began to wish a kernel "module" didn't stop being a visible component
> > when it gets statically linked.  There's a rather arbitrary line between
> > static linking (build tools) and dynamic linking (modutils).  Hotplugging
> > a device shouldn't need to care so much how the driver module is linked.
> 
> Yes this is useful.  For PCMCIA, I created /proc/bus/pccard/drivers to
> list what drivers are present, as static or modules.  But a kernel
> wide solution would be better (even if it is /proc/bus/*/drivers).

It'd not just be "better", I suspect...

The first USB hotplug "/etc/usb/policy" checked /proc/bus/usb/drivers,
but the current one doesn't.

Why?  Because there are driver frameworks that are built on top of
USB (like usb-serial, usb-storage, "input") so that multiple modules
may need to get loaded.  And so, lacking an explicit representation
of the kernel's module structure, knowing the "usbcore" drivers that
were there just wouldn't let me check if the driver actually did what
I expected it to do.  (Load/init OK, and bind to the device.)

In the case of "input", I think the hope is that someone will donate
time to create an "input" hotplug system, that USB HID (and ADB?) will
be able to use; it'll cause "keybdev", "mousedev", "joydev", and so on
to get loaded.

But I don't think we should expect every driver framework to be that
generic.  A better global tool could really help robustness.  It'd
apply to big Linux servers, not just desktops ... the facilities needed
to dynamically reconfigure a big server (downtime is bad!) aren't that
different from those which prevent a desktop from needing to reboot
when you install a new device.  (Except that the desktop really needs
to assume there's normally nobody that understands sysadmin.)


> > David Hinds at one point spoke in favor of having more info passed
> > to the network hotplug events than just the interface name.  That's
> > critical for statically configured hardware (servers); dynamically
> > configured ones (pure DHCP clients, say) should not care.
> 
> Yes, I can tell you that if only the interface name is passed, it is
> going to frustrate some people who are used to having more information
> from PCMCIA.  It isn't entirely bad... at least, you can get the
> interface's hardware address, and use that to choose configurations.
> But I find it quite useful to know that eth0 is "the 3C575 card in
> PCMCIA socket 1", or vice versa.

This sort of issue can get sorted out as pcmcia_cs and hotplugging
start to ... "co-evolve"?  :-)

> -- Dave


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

RE: hotplug TTD

[Grover, Andrew]

Devices on the ACPI bus need to have drivers loaded for them.

(For those that aren't familiar with it, one of ACPI's purposes is to
replace PNPBIOS. So the ACPI driver has a list of hardware IDs that, if a
mechanism existed to do so, it could load the appropriate drivers for.)

On a laptop undock, some of these would go away, and would need to be
unloaded too.

If you would like me to expand further I am willing to. ;-)

Regards -- Andy

> From: Andrew Morton [mailto:andrewm@uow.edu.au]
> > ACPI.
> 
> What are the ACPI requirements??
> 
> _______________________________________________
> Linux-hotplug-devel mailing list
> Linux-hotplug-devel@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
> 


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

RE: hotplug TTD

[Grover, Andrew]

> From: Andrew Morton [mailto:andrewm@uow.edu.au]
> 
> "Grover, Andrew" wrote:
> > Having one entity who knows about all devices on a system 
> is also great for
> > power management, and implementing suspend-to-memory and 
> suspend-to-disk.
> > 
> 
> Not sure I completely understand this one.
> 
> Given that all the different bus ("resource"?) types have different
> discovery mechanisms, I think you're proposing that, once discovered,
> they will be recorded in a database of some form?  In a 
> unified format?

While different buses have different discovery mechanisms, they all will
either result in either device removal or device insertion notifications.
Since we will want to have one hotplug module loader (yes?) it seems
necessary that the various bus enumerators communicate with it in a common
format.

Having the loading entity keep track of what devices/drivers are already
present would then have two advantages:
1) Bus enumeration drivers can, when queried, report all devices found, and
do not have to worry about which ones have come or gone, because the manager
is keeping track.
2) Because we know the entire device attachment tree, when suspending, we
can send power-down requests outermost-first and vice-versa when resuming.

> So we have, if you like, an array of objects each of which represents
> a device in the system, and they each have state, `eject', 
> `powerdown' methods,
> etc?

I think so. But perhaps the appropriate structure is a tree, because devices
depend on each other and we will need to sequence power transitions with
that in mind. (e.g. don't turn off the PCI bus until all PCI devices are
powered down.)

> 
> Heh.  XircomNic is-a CardbusDevice is-a PCIDevice is-a Device 
> is-a blah.
> 
> It could get complex with devices behind bridges behind bridges. Is a 
> bridge a device?  Do we need to care about bridges?

Yes, it can get complex, but I think we do need to account for bridges.

Regards -- Andy


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

RE: hotplug TTD

[Grover, Andrew]

> From: David Brownell [mailto:david-b@pacbell.net]

> > From: Grover, Andrew <andrew.grover@intel.com>
> > Is it unreasonable, long-term, to move towards a unified 
> Linux hotplug
> > architecture?
> 
> I don't see why it would be unreasonable.  Arguably, that's 
> the direction
> that has been set already.  But -- what do you mean by "architecture"?
> That's a loaded word in many minds.

I mean we have individual subsystems doing HP all over the place. While each
has bus-specific stuff, a lot of the stuff is the same across all of these.

> > Under both Windows and BeOS, a given bus driver is responsible for
> > enumerating the devices on it, and it tells a central "configuration
> > manager", who then is the one who loads the drivers.
> 
> Many of us don't know those two systems very well; but perhaps the
> "/sbin/hotplug" policy agent is analagous to that mananager.  Except
> that it can't just "load drivers", it's got to configure them too.
> Maybe you could elaborate a bit?

Well, of course devices need to be configured, but in my mind once we've
loaded the driver that's half the battle. If I insert a USB foo device, the
foo driver is going to be the one who knows how to configure it, yes? And, I
remember reading that the latest modutils had some mechanism to pass config
info, but I haven't looked further..

> Using USB and PCI (in Linux 2.4 kernels) as an example, clearly the
> bus drivers (USB HCDs, Cardbus or Hotplug PCI bridges) are going to
> enumerate devices and handle some of the config change details.  But
> the goal is to punt all the hard policy questions (what driver, how
> to set it up) to userspace through one mechanism (/sbin/hotplug).

True, some setup info is surely needed. But one of the goals of hotplug is
you insert the device and it "just works". Won't that be awesome?? ;-)

> So far I've been thinking of power management as _mostly_ an issue
> that subsystems should deal with locally ... following global rules
> and policies.  Likely you have clearer ideas about how those should
> get reflected down to the subsystems, or back to some global/central
> entity when policy questions arise.

I agree, a given subsystem driver is in a much better position to power
manage itself instead of a global entity. But I also think the system needs
be able to veto a subsystem's PM in light of the system's overall state.

For example, in Windows, a driver can request to be put into a power state.
If the system has no objections, it turns around and tells the driver to
switch states. This has two advantages: 1) it gives the OS the chance to not
fulfill the request (if it knows turning off the device would have bad
consequences) and 2) it lets the OS implement a simple PM strategy, that can
then be overridden by the subsystem if it wishes. This saves each driver
from worrying about PM policy if the OS's default policy is good enough.

Regards -- Andy


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

Re: hotplug TTD

[Andrew Morton]

While I think of it.  Something Linus said a few weeks back:


> 
> 1: yenta driver sees the card insertion.  schedules a call to
>    pci_insert_device

We should actually change this, and do it only for the case where we don't
already have a driver for the device. If we have a driver fior the device,
we should assume that it is the drivers responsibility to notify the
system about higher-level events.






Does this really matter?  We'll get a failed modprobe...

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

Re: hotplug TTD

[David Brownell]

Andrew,

> > 1: yenta driver sees the card insertion.  schedules a call to
> >    pci_insert_device
> 
> We should actually change this, and do it only for the case where we don't
> already have a driver for the device. 

Why?  It's a "here's a new device" notification, being called
when there's a new device!

It might be reasonable to have a _separate_ notification for
the "this device has no driver" case, but those "new device"
notifications will still be needed.


>    If we have a driver fior the device,
> we should assume that it is the drivers responsibility to notify the
> system about higher-level events.

Not all higher level events; just some of them.  Potentially.

The hotplug events in the current system are primarily what one
could call "container" notifications:  bus subsystems (USB, PCI)
reporting add/remove events for their devices, or the network
subsystem reporting register/unregister events at the higher
level that it works with (above busses, below apps).

I don't think we want to encourage every driver to call some
user mode helper directly, though I'm willing to accept that
as a useful tool for rare cases.  (Your async/sync fixes are
helpful there, even enabling such calls in_interrupt.)  The
overall system has to be manageable and simple; encouraging
lots of per-driver variation doesn't lead that direction.

- Dave




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

Re: hotplug TTD

[David Brownell]

Andy,

> Well, of course devices need to be configured, but in my mind once we've
> loaded the driver that's half the battle.

This is true enough to be confusing.  For some simple drivers it's the
WHOLE of the battle!

If they show up as filesystem devices, apps use only filesystem-based
discovery (after device connection), and the device is so simple that
it doesn't need more configuration ... then that's enough.  But that's
not going to work for all devices or drivers.


>     If I insert a USB foo device, the
> foo driver is going to be the one who knows how to configure it, yes?

The UNIX convention (inherited by Linux) is that some sysadmin knows
how to configure it, using driver and application/service/tool docs
(or sometimes UTSL) along with site policy knowledge (security, tool
choice, etc) ... when additional configuration is needed.

So no, the driver is NOT going to be the one to know how to configure.
It never has been, as a rule.  There are lots of reasons why, and many
of them can/will be automated through /sbin/hotplug; but there will be
a few cases where sysadmins still need to help out.


> True, some setup info is surely needed. But one of the goals of hotplug is
> you insert the device and it "just works". Won't that be awesome?? ;-)

It _is_ awesome ... just needs more work and a few 2.4.0 patches!  :-)


>     And, I
> remember reading that the latest modutils had some mechanism to pass config
> info, but I haven't looked further..

That's module configuration data, not device configuration data.

It's provided with the "load new module" code paths, and won't
help much with subsequent "similar new device" processing.  Two
distinct problems, in my book.

- Dave




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

Re: hotplug TTD

[Keith Owens]

On Fri, 12 Jan 2001 09:37:52 -0800, 
David Brownell <david-b@pacbell.net> wrote:
>andrew.grover wrote
>>     And, I
>> remember reading that the latest modutils had some mechanism to pass config
>> info, but I haven't looked further..
>
>That's module configuration data, not device configuration data.

It can be either.  The new mechanism allows for persistent module data,
i.e. data values that are saved and restored across unload and reload,
even across reboot.  Modutils just saves and restores the data, it is
up to the module to decide what to do with it.  The obvious use is for
user settings in media drivers; volume, balance, TV tuner settings etc.

Does persistent data make sense for hotuplugging devices?  It depends
on the device and the driver.  Even if you use persistent data, the
driver has to cope with the case of no data.  There is no data for the
initial load and when the saved data is not available, for whatever
reason.


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

Re: hotplug TTD

[David Brownell]

> >>     And, I
> >> remember reading that the latest modutils had some mechanism to pass config
> >> info, but I haven't looked further..
> >
> >That's module configuration data, not device configuration data.
> 
> It can be either. 

Hmm ... is there some simple example module on the web, doing both?
I probably wouldn't have seen a notice, and haven't had time to do
more than glance at the persistence patch in the modutils FTP area.

Was the output format text, or binary?  Tools could be easier if
they could rely on text.

It'd be nice if Linux had a better solution than distro-specific
config files to hold device configuration data, and I could see
the module persistence stuff evolving into that.  It'd sure help
make hotplug policy software be more portable if it could rely on
all hotpluggable drivers (network, media, ...) using such a scheme.

- Dave




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

Re: hotplug TTD

[Keith Owens]

On Sat, 13 Jan 2001 10:54:04 -0800, 
David Brownell <david-b@pacbell.net> wrote:
>Hmm ... is there some simple example module on the web, doing both?
>I probably wouldn't have seen a notice, and haven't had time to do
>more than glance at the persistence patch in the modutils FTP area.

No module currently uses persistent data.  I tested it with some dummy
module code and released the patch.  It is up to coders to decide how
they use persistent data.

>Was the output format text, or binary?  Tools could be easier if
>they could rely on text.

man insmod, man rmmod, man modules.conf.  All text.  Persistent data
behaves as if you specified the saved values on the insmod command
line.  The order is values from modules.conf, then saved persistent
data, then insmod options.  modules.conf is default values, persistent
data is what you set the values to after loading, insmod is override
for this load.


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

Re: hotplug TTD

[Miles Lane]

Can we continue this discussion?  It seems there are important
questions left unanswered here.

Keith Owens wrote:
> > > >> And, I remember reading that the latest modutils had some 
> > > >> mechanism to pass config info, but I haven't looked further..
> > > >
> > > >That's module configuration data, not device configuration data.
> > > 
> > > It can be either. 
> > 
> > Hmm ... is there some simple example module on the web, doing both?
> > I probably wouldn't have seen a notice, and haven't had time to do
> > more than glance at the persistence patch in the modutils FTP area.
> 
> No module currently uses persistent data.  I tested it with some dummy
> module code and released the patch.  It is up to coders to decide how
> they use persistent data.

So, are we going to attempt to use the persistent module data for any 
Hotplug related development?  Might this be helpful for giving some
more consistent mapping of a device node to a physical device resource
(e.g., /dev/eth0 -> the 3c575 with a particular set of device 
characteristics -- memory ranges, IRQ, DMA, etc)>

> >Was the output format text, or binary?  Tools could be easier if
> >they could rely on text.
> 
> man insmod, man rmmod, man modules.conf.  All text.  Persistent data
> behaves as if you specified the saved values on the insmod command
> line.  The order is values from modules.conf, then saved persistent
> data, then insmod options.  modules.conf is default values, persistent
> data is what you set the values to after loading, insmod is override
> for this load.
> 
> > It'd be nice if Linux had a better solution than distro-specific
> > config files to hold device configuration data, and I could see
> > the module persistence stuff evolving into that.  It'd sure help
> > make hotplug policy software be more portable if it could rely on
> > all hotpluggable drivers (network, media, ...) using such a scheme.

Has anyone begun using this data, yet?

_______________________________________________
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: hotplug TTD

[Keith Owens]

On Sat, 03 Feb 2001 15:37:06 -0800, 
Miles Lane <miles@megapathdsl.net> wrote:
>So, are we going to attempt to use the persistent module data for any 
>Hotplug related development?  Might this be helpful for giving some
>more consistent mapping of a device node to a physical device resource
>(e.g., /dev/eth0 -> the 3c575 with a particular set of device 
>characteristics -- memory ranges, IRQ, DMA, etc)>

I would be very wary of doing anything like that.  Persistent data is a
good fit for user controlled settings like volume and TV tuner values,
where the worst case is a wrong volume or the wrong TV channel at start
up.

If you use it for critical data such as IRQ then the worst case is the
module does not load.  It will confuse users when the data becomes
obsolete and the module fails to load.  It is not at all obvious where
the insmod data is coming from.

One option does make sense to me.  Use persistent data and rmmod -e to
extract the persistent data to a file.  Because rmmod -e does not
remove the module (it only extracts the data), hotplug can use this
mechanism as a way to extract data from the module and save it.  Then
the next hotplug load can decide if it wants to use the existing data
or not, erasing the saved persistent data before issuing modprobe.

Alternatively hotplug can try to load the module twice, once leaving
the persistent data alone, the second time it renames the saved data
file.  If one works, issue rmmod -e.  If neither work, reinstate the
persistent data file.


_______________________________________________
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