Merge master.kernel.org:/home/davem/BK/net-2.5

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Documentation/kobject.txt

+kobjects - Simple, Generic Kernel Objects
+
+Patrick Mochel <mochel@osdl.org>
+
+30 October 2002
+
+
+kobjects
+
+struct kobject introduces a simple, intregral datatype and a simple
+set of semantics for operating on the device. kobjects are intended to
+be embedded in larger data structures and replace fields it
+duplicates. A set of library functions has been developed to assist in
+the manipulation of kobjects.
+
+struct kobject looks like this:
+
+
+struct kobject {
+	char			name[16];
+	atomic_t		refcount;
+	struct list_head	entry;
+	struct kobject		* parent;
+	struct subsystem	* subsys;
+	struct dentry		* dentry;
+};
+
+void kobject_init(struct kobject *);
+int kobject_register(struct kobject *);
+void kobject_unregister(struct kobject *);
+struct kobject * kobject_get(struct kobject *);
+void kobject_put(struct kobject *);
+
+
+
+subsystems
+
+struct subsystem is introduced to describe a collection of objects of
+a certain type. subsystems are kobjects themselves, though they
+contain lists of kobjects that belong to that subsystem. Objects of a
+subsystem (the embedder objects in which kobjects live) are all of the
+same type. The interface looks like:
+
+
+struct subsystem {
+	struct kobject		kobj;
+	struct list_head	list;
+	struct rw_semaphore	rwsem;
+	struct subsystem	* parent;
+	void (*release)(struct kobject *);
+	struct sysfs_ops	* sysfs_ops;
+	struct attribute	** default_attrs;
+};
+
+void subsystem_init(struct subsystem *);
+int subsystem_register(struct subsystem *);
+void subsystem_unregister(struct subsystem *);
+
+struct subsystem * subsys_get(struct subsystem * s);
+void subsys_put(struct subsystem * s);
+
+
+
+Familial Relations
+
+kobjects and subsystems intersect and intertwine in several ways. Each
+is well-defined (though maybe they could be made simpler). Each kobject
+belongs to a subsystem. Since subsystems are kobjects themselves, they
+also belong to a controlling subsystem. This implies that subsystems
+are hierarchial. 
+
+Many kobjects are hierarchial in nature, which is represented by
+including a pointer to its parent kobject in struct kobject. Many
+different types of kobject-embedding objects may all point to the same
+parent. 
+
+The ancestral hierarchy of kobjects should not be confused with
+membership in a subsystem, or the ancestral relationship of
+subsystems. A set of kobjects may all belong to a subsystem, but all
+have different parents. 
+
+kobjects may be orphans and have no explicit parent. In that case, the
+subsystem to which the object belongs becomes its parent. 
+
+
+Sysfs
+
+These rules force a complete kobject hierarchy, which Suprise! maps
+very well onto a filesystem.
+
+driverfs was recently cloned, and there now exists sysfs. All driverfs
+operations operate on a separate data type: struct driver_dir_entry,
+which all objects that are represented in driverfs must have. driverfs
+also allowed rogue directory creation that had no explicit objects
+associated with them.
+
+struct kobject is intended to be the common data type which sysfs
+operates on. This gives the filesystem the ability to directly access
+more fields of the object, including the reference count. This also
+forces each directory in the filesystem to be tied directly to a
+kobject. 
+
+
+Directory Placement
+
+Parental relationships are determined in the kobject/subsystem layer,
+and the kobject is then passed off to the sysfs layer. kobjects with
+no parent have directories created for them in the sysfs root
+directory. Per the rules above, the only kobjects that remain orphans
+are subsystems without parent subsystems (since leaf objects either
+have an explicit parent, or are assigned their controlling subsystem
+as their foster parent). 
+
+
+File Callbacks
+
+Previously, each driverfs directory contained a pointer to a list of file
+operations for reading and writing driverfs files. These callbacks
+received a struct driver_dir_entry, when they performed a
+container_of() transform on to receive the specific object type for
+which the call was meant. 
+
+These callbacks have been converted to accept a struct kobject instead
+of struct driver_dir_entry. Since all kobjects belong to a subsystem
+that contains kobjects all of the same type, the sysfs operations
+have been moved to reside in the subsystem, since they are common for
+all kobjects.
+
+
+Default Attributes
+
+Most subsystems have a set of default attributes associated with an
+object that registers with them. A subsystem definition may contain a
+NULL-terminated array of attributes that will be exported when an
+object is registered with the subsystem. 
+
+
+Reference Counting
+
+All objects contain reference counts. All functions accessing objects
+should increment the reference count until they are finished, and
+decrement the reference count. When an object is initialized, it
+receives a reference count of 1. When a device is unregistered, the
+reference is decremented. When the reference counts reaches 0, the
+subsystem's ->release() callback for that object type (remember
+subsystems control only one type of device each) is called; and the
+reference counts of the kobject's subsystem and parent are
+decremented. 
+
+The ->release() callback is the opportunity for the subsystem to free
+memory allocated for the object. It is the notification that
+absolutely no one is using the structure any more (and can't acquire a
+reference to it), so it is safe to free it.
+

Documentation/parisc/IODC.txt

-Some notes on IODC, its general brokenness, and how to work around it.
-
-Short Version
-
-IODC is HP's pre-PCI standard for device identification (a la PCI vendor,
-device IDs), detection, configuration, initialization and so on.
-
-It also can provide firmware function to do the actual IO, which are slow,
-not really defined for runtime usage and generally not desirable.  (There
-are other firmware standards, such as STI, to do real IO).
-
-Usually, there are two parts to IODC.  The actual ROMs, which are laid out,
-detected aso in a bus-specific manner (IO_DC_ADDRESS / IO_DC_DATA on
-GSC/Runway, PCI spec - compliant ROMs for PCI, God-only-knows how on EISA),
-and the slightly cooked data read by PDC_IODC.
-
-The ROM layout is generally icky (only one byte out of every 4-byte-word
-might be valid, and many devices don't implement required options), so
-using PDC_IODC is highly recommended.  (In fact, you should use the device
-lists set up by the kernel proper instead of calling PDC_IODC yourself).
-
-Now, let's have a look at what the cooked ROM looks like (see iodc.pdf for
-the details, this is the simplified version).
-
-Basically, the first 8 bytes of IODC contain two 32-bit ids called HVERSION
-and SVERSION.  Those are further split up into bit fields, and
-unfortunately just ignoring this split up isn't an option.
-
-SVERSION consists of a 4-bit revision field, a 20-bit model field and a
-8-bit opt field.  Now, forget the revision and opt fields exist.  Basically,
-the model field is equivalent to a PCI device id (there is no vendor id.
-this is proprietary hardware we're talking about).  That is, all your
-driver cares for, in 90 % of the cases, is to find all devices that match
-the model field.
-
-The rev field is - you guessed it - roughly equivalent to the revision
-byte for PCI, with the exception that higher revisions should be strict
-supersets of lower revisions.
-
-The last byte of HVERSION, "type", and the last byte of SVERSION, "opt",
-belong together;  type gives a very rough indication of what the device
-is supposed to do, and opt contains some type-specific information. (For
-example, the "bus converter" (ie bus bridge) type encodes the kind of
-bus behind the bridge in the opt field.
-
-The rest of HVERSION contains, in most cases, a number identifying the
-machine the chip was used in, or a revision indicator that just fixed
-bugs and didn't add any features (or was done in a shrinked process or
-whatever).
-
-So, here's the interface you actually should use to find your devices:
-
-
-/* Find a device, matching the model field of sversion only (from=NULL
- * for the first call */
-struct iodc_dev *iodc_find_device(u32 sversion, struct iodc_dev *from);
-
-
-Here's a function you should use if you have special requirements, such
-as finding devices by type rather than by model.  Generally, if you're
-using this, you should be me).
-
-/* Find a device, masking out bits as specified */
-struct iodc_dev *iodc_find_device_mask(u32 hversion, u32 sversion,
-	u32 hversion_mask, u32 sversion_mask, struct iodc_dev *from);
-
-
-	Philipp Rumpf <prumpf@tux.org>

Makefile

@@ -46,7 +46,9 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
 TOPDIR	:= $(CURDIR)
 
 HOSTCC  	= gcc
+HOSTCXX  	= g++
 HOSTCFLAGS	= -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCXXFLAGS	= -O2
 
 CROSS_COMPILE 	=
 
@@ -171,7 +173,8 @@ AFLAGS		:= -D__ASSEMBLY__ $(CPPFLAGS)
 
 export	VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
 	CONFIG_SHELL TOPDIR HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
-	CPP AR NM STRIP OBJCOPY OBJDUMP MAKE GENKSYMS PERL UTS_MACHINE
+	CPP AR NM STRIP OBJCOPY OBJDUMP MAKE GENKSYMS PERL UTS_MACHINE \
+	HOSTCXX HOSTCXXFLAGS
 
 export CPPFLAGS NOSTDINC_FLAGS OBJCOPYFLAGS LDFLAGS
 export CFLAGS CFLAGS_KERNEL CFLAGS_MODULE 
@@ -211,7 +214,7 @@ SUBDIRS		:=
 
 ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
 
-include-config := 1
+export include-config := 1
 
 -include .config
 
@@ -247,21 +250,7 @@ ifdef include-config
 
 #	In this section, we need .config
 
-#	If .config doesn't exist - tough luck
-
-.config: arch/$(ARCH)/config.in # FIXME $(shell find . -name Config.in)
-	@echo '***'
-	@if [ -f $@ ]; then \
-	  echo '*** The tree was updated, so your .config may be'; \
-	  echo '*** out of date!'; \
-	else \
-	  echo '*** You have not yet configured your kernel!'; \
-	fi
-	@echo '***'
-	@echo '*** Please run some configurator (e.g. "make oldconfig" or'
-	@echo '*** "make menuconfig" or "make xconfig").'
-	@echo '***'
-	@exit 1
+-include ..config.cmd
 
 ifdef CONFIG_MODULES
 export EXPORT_FLAGS := -DEXPORT_SYMTAB
@@ -429,11 +418,8 @@ include/config/MARKER: scripts/split-include include/linux/autoconf.h
 # 	with it and forgot to run make oldconfig
 
 include/linux/autoconf.h: .config
-	@echo '***'
-	@echo '*** You changed .config w/o running make *config?'
-	@echo '*** Please run "make oldconfig"'
-	@echo '***'
-	@exit 1
+	+@$(call descend,scripts/kconfig,scripts/kconfig/conf)
+	./scripts/kconfig/conf -s arch/$(ARCH)/Kconfig
 
 # Generate some files
 # ---------------------------------------------------------------------------
@@ -649,34 +635,36 @@ ifeq ($(filter-out $(noconfig_targets),$(MAKECMDGOALS)),)
 .PHONY: oldconfig xconfig menuconfig config \
 	make_with_config
 
-xconfig:
-	$(Q)$(MAKE) -f scripts/Makefile.build obj=scripts scripts/kconfig.tk
-	wish -f scripts/kconfig.tk
+scripts/kconfig/conf scripts/kconfig/mconf scripts/kconfig/qconf: scripts/fixdep FORCE
+	+@$(call descend,scripts/kconfig,$@)
+
+xconfig: scripts/kconfig/qconf
+	./scripts/kconfig/qconf arch/$(ARCH)/Kconfig
 
-menuconfig:
+menuconfig: scripts/kconfig/mconf
 	$(Q)$(MAKE) -f scripts/Makefile.build obj=scripts lxdialog
-	$(CONFIG_SHELL) $(src)/scripts/Menuconfig arch/$(ARCH)/config.in
+	./scripts/kconfig/mconf arch/$(ARCH)/Kconfig
 
-config:
-	$(CONFIG_SHELL) $(src)/scripts/Configure arch/$(ARCH)/config.in
+config: scripts/kconfig/conf
+	./scripts/kconfig/conf arch/$(ARCH)/Kconfig
 
-oldconfig:
-	$(CONFIG_SHELL) $(src)/scripts/Configure -d arch/$(ARCH)/config.in
+oldconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -o arch/$(ARCH)/Kconfig
 
-randconfig:
-	$(CONFIG_SHELL) $(src)/scripts/Configure -r arch/$(ARCH)/config.in
+randconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -r arch/$(ARCH)/Kconfig
 
-allyesconfig:
-	$(CONFIG_SHELL) $(src)/scripts/Configure -y arch/$(ARCH)/config.in
+allyesconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -y arch/$(ARCH)/Kconfig
 
-allnoconfig:
-	$(CONFIG_SHELL) $(src)/scripts/Configure -n arch/$(ARCH)/config.in
+allnoconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -n arch/$(ARCH)/Kconfig
 
-allmodconfig:
-	$(CONFIG_SHELL) $(src)/scripts/Configure -m arch/$(ARCH)/config.in
+allmodconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -m arch/$(ARCH)/Kconfig
 
-defconfig:
-	yes '' | $(CONFIG_SHELL) $(src)/scripts/Configure -d arch/$(ARCH)/config.in
+defconfig: scripts/kconfig/conf
+	./scripts/kconfig/conf -d arch/$(ARCH)/Kconfig
 
 ###
 # Cleaning is done on three levels.

arch/arm/mach-arc/Config.help

-CONFIG_ARCH_ARCA5K
-  This selects what ARM system you wish to build the kernel for. It
-  also selects to some extent the CPU type. If you are unsure what
-  to set this option to, please consult any information supplied with
-  your system.
-
-CONFIG_ARCH_A5K
-  Say Y here to to support the Acorn A5000.  Linux can support the
-  internal IDE disk and CD-ROM interface, serial and parallel port,
-  and the floppy drive.  Note that on some A5000s the floppy is
-  plugged into the wrong socket on the motherboard.
-
-CONFIG_ARCH_ARC
-  The Acorn Archimedes was an personal computer based on an 8K ARM2
-  processor, released in 1987.  It supported 512K of RAM and 2 800K
-  floppy disks.  Picture and more detailed specifications at
-  <http://www.computingmuseum.com/museum/archi.htm>.
-
-CONFIG_PAGESIZE_16
-  Say Y here if your Archimedes or A5000 system has only 2MB of
-  memory, otherwise say N.  The resulting kernel will not run on a
-  machine with 4MB of memory.
-
-

arch/arm/mach-arc/Config.in

-mainmenu_option next_comment
-comment 'Archimedes/A5000 Implementations'
-# These architectures will be combined.  However, until this
-# is complete...  Note that the ARC will take precedence over
-# A5K
-comment 'Archimedes/A5000 Implementations (select only ONE)'
-dep_bool '  Archimedes' CONFIG_ARCH_ARC $CONFIG_ARCH_ARCA5K
-dep_bool '  A5000' CONFIG_ARCH_A5K $CONFIG_ARCH_ARCA5K
-
-if [ "$CONFIG_ARCH_ARCA5K" = "y" ]; then
-   bool '2MB physical memory' CONFIG_PAGESIZE_16
-fi
-
-endmenu
-

arch/arm/mach-arc/Kconfig

+
+menu "Archimedes/A5000 Implementations"
+
+# These architectures will be combined.  However, until this
+# is complete...  Note that the ARC will take precedence over
+# A5K
+comment "Archimedes/A5000 Implementations (select only ONE)"
+
+config ARCH_ARC
+	bool "Archimedes"
+	depends on ARCH_ARCA5K
+	help
+	  The Acorn Archimedes was an personal computer based on an 8K ARM2
+	  processor, released in 1987.  It supported 512K of RAM and 2 800K
+	  floppy disks.  Picture and more detailed specifications at
+	  <http://www.computingmuseum.com/museum/archi.htm>.
+
+config ARCH_A5K
+	bool "A5000"
+	depends on ARCH_ARCA5K
+	help
+	  Say Y here to to support the Acorn A5000.  Linux can support the
+	  internal IDE disk and CD-ROM interface, serial and parallel port,
+	  and the floppy drive.  Note that on some A5000s the floppy is
+	  plugged into the wrong socket on the motherboard.
+
+config PAGESIZE_16
+	bool "2MB physical memory"
+	depends on ARCH_ARCA5K
+	help
+	  Say Y here if your Archimedes or A5000 system has only 2MB of
+	  memory, otherwise say N.  The resulting kernel will not run on a
+	  machine with 4MB of memory.
+
+endmenu
+

arch/arm/mach-epxa10db/Config.help

-CONFIG_PLD_HOTSWAP
-  This enables support for the dynamic loading and configuration of
-  compatible drivers when the contents of the PLD are changed. This
-  is still experimental and requires configuration tools which are
-  not yet generally available. Say N here. You must enable the kernel
-  module loader for this feature to work.
-
-