Hey there.
The changelogs are below, but this is the executive summary.
This beefs up the support for system devices. It introduces the following
structures:
struct sys_root {
u32 id;
struct device dev;
struct device sysdev;
};
struct sys_device {
char * name;
u32 id;
struct sys_root * root;
struct device dev;
};
The former is intended for multi-board systems (e.g. NUMA-like) so they
can accurately represent their topology. The latter is for basic
description of system-level devices, like CPUs, PICs, etc.
The idea is that the enumerators for multi-board systems will register
each board (aka 'node') on boot. They should also know what board each
system device is on, and set that in the sys_device structure.
Without ->root set, system devices will be added as a child of a pseudo
bus: 'sys'. They appear in driverfs in the root/sys/ directory. Each
alternative root gets a directory under root/, and each gets a 'sys'
subdirectory. System devices appear as children of the root's 'sysdev'.
struct sys_root::dev can be used to parent other devices and buses
discovered on that board; e.g. PCI buses on that board.
I've taken the liberty to also implement a CPU device class, and a generic
cpu structure. The device class is registered on boot, which exports all
CPUs in a common place in driverfs in class/cpu/.
For ia32, I've created a simple CPU device driver and a static array of
cpu devices of size NR_CPUS, which are manually registered on boot. The
cpus get directories under root/sys/ in driverfs, like this:
`-- root
`-- sys
|-- cpu0
|-- cpu1
...
And get symlinks in the class directory like this:
|-- class
| |-- cpu
| | |-- devices
| | | |-- 0 -> ../../../root/sys/cpu0
| | | |-- 1 -> ../../../root/sys/cpu1
...
When the CPUs are registered, driverfs files may now be created for them.
I recommend creating device interfaces for various CPU features and
registering them with the device class. When the device is registered with
the class, it will also be registered with all of the interfaces of the
class. More documentation about this is available in the
Documentation/driver-model/ directory (which is now updated!)
Pending approval/comments of the CPU device code, I will be working on
converting some of the interfaces over to use it.
Please apply,
-pat
p.s. the patch is attached for non-BK users.
Please pull from
bk://ldm.bkbits.net/linux-2.5
This will update the following files:
arch/i386/kernel/cpu/common.c | 34 +++++++++
arch/i386/kernel/i8259.c | 16 ++--
arch/i386/kernel/time.c | 15 ++--
drivers/acpi/bus.c | 120 -----------------------------------
drivers/base/Makefile | 5 -
drivers/base/core.c | 36 ++++++++--
drivers/base/cpu.c | 28 ++++++++
drivers/base/driver.c | 11 +++
drivers/base/sys.c | 144 +++++++++++++++++++++++++++++++++++++-----
include/linux/cpu.h | 28 ++++++++
include/linux/device.h | 31 ++++++---
11 files changed, 303 insertions(+), 165 deletions(-)
through these ChangeSets:
<mochel@osdl.org> (02/09/18 1.553)
driver model: add CPU device support
Declare a CPU device class, which gives CPUs a directory in driverfs under class/cpu/.
Define a generic 'struct cpu' for basic defintion of CPU devices. Declare a static array
of size NR_CPUS for ia32 and manually register each one on boot.
Declare an archtecture specific (ia32 only for now) cpu device driver for handling generic
device operations.
<mochel@osdl.org> (02/09/18 1.551)
driver model: strengthen system device support.
Introduce struct sys_root (to describe alternative system roots in multi-
board (NUMA-like) systems; and struct sys_device to better describe system
level devices.
Implement registration functions for alternative system roots (for multi-
board systems; e.g. NUMA-like systems)
Beef-up system device registration functions so it registers the device in
the root it belongs to and so it sets the bus type. It also sets the device's
bus_id based on the fields in struct sys_device.
Add a system_bus_type, so we have place to group the devices and drivers..
<mochel@osdl.org> (02/09/18 1.550)
driver model: Handle devices that have ->driver set on registration.
If a device is registered, and its driver is set, we call found_match() immediately
(and don't walk through the list of drivers of the bus).
We also handle the case where the driver hasn't been registered yet, so if we a NULL
driver from get_driver() in device_attach(), we assume the driver is awaiting a
driver_register().
<mochel@osdl.org> (02/09/18 1.549)
ACPI: get rid of the silly acpi_bus_driver, since it didn't do anything,
and won't ever do anything.
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:24 EST