diff -Nru a/CREDITS b/CREDITS --- a/CREDITS Fri Oct 18 21:03:07 2002 +++ b/CREDITS Fri Oct 18 21:03:07 2002 @@ -1750,6 +1750,11 @@ S: 370 01 Ceske Budejovice S: Czech Republic +N: Adam Belay +E: ambx1@neo.rr.com +D: Linux Plug and Play Support +S: USA + N: Bas Laarhoven E: sjml@xs4all.nl D: Loadable modules and ftape driver diff -Nru a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile --- a/Documentation/DocBook/Makefile Fri Oct 18 21:03:04 2002 +++ b/Documentation/DocBook/Makefile Fri Oct 18 21:03:04 2002 @@ -13,14 +13,6 @@ writing_usb_driver.sgml scsidrivers.sgml sis900.sgml \ kernel-api.sgml journal-api.sgml lsm.sgml -JBDSOURCES := $(TOPDIR)/include/linux/jbd.h \ - $(TOPDIR)/fs/jbd/journal.c \ - $(TOPDIR)/fs/jbd/recovery.c \ - $(TOPDIR)/fs/jbd/transaction.c - -journal-api.sgml: journal-api.tmpl $(JBDSOURCES) - $(TOPDIR)/scripts/docgen $(JBDSOURCES) \ - journal-api.sgml ### # The build process is as follows (targets): # (sgmldocs) @@ -32,7 +24,7 @@ # The targets that may be used. .PHONY: sgmldocs psdocs pdfdocs htmldocs clean mrproper -BOOKS := $(addprefix Documentation/DocBook/,$(DOCBOOKS)) +BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) sgmldocs: $(BOOKS) PS := $(patsubst %.sgml, %.ps, $(BOOKS)) @@ -86,19 +78,19 @@ ### # procfs guide uses a .c file as example code. # This requires an explicit dependency -C-procfs-example = Documentation/DocBook/procfs_example.sgml -Documentation/DocBook/procfs-guide.sgml: $(C-procfs-example) +C-procfs-example = procfs_example.sgml +C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) +$(obj)/procfs-guide.sgml: $(C-procfs-example2) ### # The parportbook includes a few images. # Force them to be build before the books IMG-parportbook := parport-share.fig parport-multi.fig parport-structure.fig -IMG-parportbook2 := $(addprefix Documentation/DocBook/,$(IMG-parportbook)) +IMG-parportbook2 := $(addprefix $(obj)/,$(IMG-parportbook)) EPS-parportbook := $(patsubst %.fig,%.eps, $(IMG-parportbook2)) PNG-parportbook := $(patsubst %.fig,%.png, $(IMG-parportbook2)) -Documentation/DocBook/parportbook.html: $(PNG-parportbook) -Documentation/DocBook/parportbook.ps Documentation/DocBook/parportbook.pdf:\ - $(EPS-parportbook) +$(obj)/parportbook.html: $(PNG-parportbook) +$(obj)/parportbook.ps $(obj)/parportbook.pdf: $(EPS-parportbook) ### # Rules to generate postscript, PDF and HTML @@ -155,21 +147,21 @@ ### # clean and mrproper as used by the top-level makefile # Temporary files left by various tools -DVI := $(patsubst %.sgml, %.dvi, $(BOOKS)) -AUX := $(patsubst %.sgml, %.aux, $(BOOKS)) -TEX := $(patsubst %.sgml, %.tex, $(BOOKS)) -LOG := $(patsubst %.sgml, %.log, $(BOOKS)) -OUT := $(patsubst %.sgml, %.out, $(BOOKS)) - -clean: - @rm -f $(BOOKS) - @rm -f $(DVI) $(AUX) $(TEX) $(LOG) $(OUT) - @rm -f $(PNG-parportbook) $(EPS-parportbook) - @rm -f $(C-procfs-example) - -mrproper: - @rm -f $(PS) $(PDF) - @rm -f -r $(HTML) $(patsubst %.html,%,$(HTML)) +clean-files := $(DOCBOOKS) \ + $(patsubst %.sgml, %.dvi, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.aux, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.tex, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.log, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.out, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.ps, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.pdf, $(DOCBOOKS)) \ + $(patsubst %.sgml, %.html, $(DOCBOOKS)) \ + $(patsubst %.fig,%.eps, $(IMG-parportbook)) \ + $(patsubst %.fig,%.png, $(IMG-parportbook)) \ + $(C-procfs-example) -include $(TOPDIR)/Rules.make +ifneq ($(wildcard $(BOOKS)),) +clean-rule := rm -rf $(wildcard $(BOOKS)) +endif +include $(TOPDIR)/Rules.make diff -Nru a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/Documentation/filesystems/sysfs.txt Fri Oct 18 21:03:08 2002 @@ -0,0 +1,342 @@ + +sysfs - _The_ filesystem for exporting kernel objects. + +Patrick Mochel + +17 October 2002 + + +Note (17 Oct 2002): the name has just been changed from driverfs to +sysfs. Updates to the documentation will come soon; after the +conversion to use it is completely finished. + + + +What it is: +~~~~~~~~~~~ +driverfs is a ram-based filesystem. It was created by copying +ramfs/inode.c to driverfs/inode.c and doing a little search-and-replace. + +driverfs is a means to export kernel data structures, their +attributes, and the linkages between them to userspace. + +driverfs provides a unified interface for exporting attributes to +userspace. Currently, this interface is available only to device and +bus drivers. + + +Using driverfs +~~~~~~~~~~~~~~ +driverfs is always compiled in. You can access it by doing something like: + + mount -t driverfs driverfs /devices + + +Top Level Directory Layout +~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driverfs directory arrangement exposes the relationship of kernel +data structures. + +The top level driverfs diretory looks like: + +bus/ +root/ + +root/ contains a filesystem representation of the device tree. It maps +directly to the internal kernel device tree, which is a hierarchy of +struct device. + +bus/ contains flat directory layout of the various bus types in the +kernel. Each bus's directory contains two subdirectories: + + devices/ + drivers/ + +devices/ contains symlinks for each device discovered in the system +that point to the device's directory under root/. + +drivers/ contains a directory for each device driver that is loaded +for devices on that particular bus (this assmumes that drivers do not +span multiple bus types). + + +More information can device-model specific features can be found in +Documentation/device-model/. + + +Directory Contents +~~~~~~~~~~~~~~~~~~ +Each object that is represented in driverfs gets a directory, rather +than a file, to make it simple to export attributes of that object. +Attributes are exported via ASCII text files. The programming +interface is discussed below. + +Instead of having monolithic files that are difficult to parse, all +files are intended to export one attribute. The name of the attribute +is the name of the file. The value of the attribute are the contents +of the file. + +There should be few, if any, exceptions to this rule. You should not +violate it, for fear of public humilation. + + +The Two-Tier Model +~~~~~~~~~~~~~~~~~~ + +driverfs is a very simple, low-level interface. In order for kernel +objects to use it, there must be an intermediate layer in place for +each object type. + +All calls in driverfs are intended to be as type-safe as possible. +In order to extend driverfs to support multiple data types, a layer of +abstraction was required. This intermediate layer converts between the +generic calls and data structures of the driverfs core to the +subsystem-specific objects and calls. + + +The Subsystem Interface +~~~~~~~~~~~~~~~~~~~~~~~ + +The subsystems bear the responsibility of implementing driverfs +extensions for the objects they control. Fortunately, it's intended to +be really easy to do so. + +It's divided into three sections: directories, files, and operations. + + +Directories +~~~~~~~~~~~ + +struct driver_dir_entry { + char * name; + struct dentry * dentry; + mode_t mode; + struct driverfs_ops * ops; +}; + + +int +driverfs_create_dir(struct driver_dir_entry *, struct driver_dir_entry *); + +void +driverfs_remove_dir(struct driver_dir_entry * entry); + +The directory structure should be statically allocated, and reside in +a subsystem-specific data structure: + +struct device { + ... + struct driver_dir_entry dir; +}; + +The subsystem is responsible for initializing the name, mode, and ops +fields of the directory entry. (More on struct driverfs_ops later) + + +Files +~~~~~ + +struct attribute { + char * name; + mode_t mode; +}; + + +int +driverfs_create_file(struct attribute * attr, struct driver_dir_entry * parent); + +void +driverfs_remove_file(struct driver_dir_entry *, const char * name); + + +The attribute structure is a simple, common token that the driverfs +core handles. It has little use on its own outside of the +core. Objects cannot use a plain struct attribute to export +attributes, since there are no callbacks for reading and writing data. + +Therefore, the subsystem is required to define a data structure that +encapsulates the attribute structure, and provides type-safe callbacks +for reading and writing data. + +An example looks like this: + +struct device_attribute { + struct attribute attr; + ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); + ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); +}; + + +Note that there is a struct attribute embedded in the structure. In +order to relieve pain in declaring attributes, the subsystem should +also define a macro, like: + +#define DEVICE_ATTR(_name,_mode,_show,_store) \ +struct device_attribute dev_attr_##_name = { \ + .attr = {.name = __stringify(_name) , .mode = _mode }, \ + .show = _show, \ + .store = _store, \ +}; + +This hides the initialization of the embedded struct, and in general, +the internals of each structure. It yields a structure by the name of +dev_attr_. + +In order for objects to create files, the subsystem should create +wrapper functions, like this: + +int device_create_file(struct device *device, struct device_attribute * entry); +void device_remove_file(struct device * dev, struct device_attribute * attr); + +..and forward the call on to the driverfs functions. + +Note that there is no unique information in the attribute structures, +so the same structure can be used to describe files of several +different object instances. + + +Operations +~~~~~~~~~~ + +struct driverfs_ops { + int (*open)(struct driver_dir_entry *); + int (*close)(struct driver_dir_entry *); + ssize_t (*show)(struct driver_dir_entry *, struct attribute *,char *, size_t, loff_t); + ssize_t (*store)(struct driver_dir_entry *,struct attribute *,const char *, size_t, loff_t); +}; + + +Subsystems are required to implement this set of callbacks. Their +purpose is to translate the generic data structures into the specific +objects, and operate on them. This can be done by defining macros like +this: + +#define to_dev_attr(_attr) container_of(_attr,struct device_attribute,attr) + +#define to_device(d) container_of(d, struct device, dir) + + +Since the directories are statically allocated in the object, you can +derive the pointer to the object that owns the file. Ditto for the +attribute structures. + +Current Interfaces +~~~~~~~~~~~~~~~~~~ + +The following interface layers currently exist in driverfs: + + +- devices (include/linux/device.h) +---------------------------------- +Structure: + +struct device_attribute { + struct attribute attr; + ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); + ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); +}; + +Declaring: + +DEVICE_ATTR(_name,_str,_mode,_show,_store); + +Creation/Removal: + +int device_create_file(struct device *device, struct device_attribute * entry); +void device_remove_file(struct device * dev, struct device_attribute * attr); + + +- bus drivers (include/linux/device.h) +-------------------------------------- +Structure: + +struct bus_attribute { + struct attribute attr; + ssize_t (*show)(struct bus_type *, char * buf, size_t count, loff_t off); + ssize_t (*store)(struct bus_type *, const char * buf, size_t count, loff_t off); +}; + +Declaring: + +BUS_ATTR(_name,_mode,_show,_store) + +Creation/Removal: + +int bus_create_file(struct bus_type *, struct bus_attribute *); +void bus_remove_file(struct bus_type *, struct bus_attribute *); + + +- device drivers (include/linux/device.h) +----------------------------------------- + +Structure: + +struct driver_attribute { + struct attribute attr; + ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off); + ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off); +}; + +Declaring: + +DRIVER_ATTR(_name,_mode,_show,_store) + +Creation/Removal: + +int driver_create_file(struct device_driver *, struct driver_attribute *); +void driver_remove_file(struct device_driver *, struct driver_attribute *); + + +Reading/Writing Data +~~~~~~~~~~~~~~~~~~~~ +The callback functionality is similar to the way procfs works. When a +user performs a read(2) or write(2) on the file, it first calls a +driverfs function. This calls to the subsystem, which then calls to +the object's show() or store() function. + +The buffer pointer, offset, and length should be passed to each +function. The downstream callback should fill the buffer and return +the number of bytes read/written. + + +What driverfs is not: +~~~~~~~~~~~~~~~~~~~~~ +It is not a replacement for either devfs or procfs. + +It does not handle device nodes, like devfs is intended to do. I think +this functionality is possible, but indeed think that integration of +the device nodes and control files should be done. Whether driverfs or +devfs, or something else, is the place to do it, I don't know. + +It is not intended to be a replacement for all of the procfs +functionality. I think that many of the driver files should be moved +out of /proc (and maybe a few other things as well ;). + + + +Limitations: +~~~~~~~~~~~~ +The driverfs functions assume that at most a page is being either read +or written each time. + +There is a race condition that is really, really hard to fix; if not +impossible. There exists a race between a driverfs file being opened +and the object that owns the file going away. During the driverfs +open() callback, the reference count for the owning object needs to be +incremented. + +For drivers, we can put a struct module * owner in struct driver_dir_entry +and do try_inc_mod_count() when we open a file. However, this won't +work for devices, that aren't tied to a module. And, it is still not +guaranteed to solve the race. + +I'm looking into fixing this, but it may not be doable without making +a separate filesystem instance for each object. It's fun stuff. Please +mail me with creative ideas that you know will work. + + +Possible bugs: +~~~~~~~~~~~~~~ +It may not deal with offsets and/or seeks very well, especially if +they cross a page boundary. + diff -Nru a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt --- a/Documentation/i386/zero-page.txt Fri Oct 18 21:03:04 2002 +++ b/Documentation/i386/zero-page.txt Fri Oct 18 21:03:04 2002 @@ -31,6 +31,7 @@ 0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb 0x1e8 char number of entries in E820MAP (below) +0x1e9 unsigned char number of entries in EDDBUF (below) 0x1f1 char size of setup.S, number of sectors 0x1f2 unsigned short MOUNT_ROOT_RDONLY (if !=0) 0x1f4 unsigned short size of compressed kernel-part in the @@ -66,6 +67,7 @@ 0x220 4 bytes (setup.S) 0x224 unsigned short setup.S heap end pointer 0x2d0 - 0x600 E820MAP +0x600 - 0x7D4 EDDBUF (setup.S) 0x800 string, 2K max COMMAND_LINE, the kernel commandline as copied using CL_OFFSET. diff -Nru a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt --- a/Documentation/networking/e100.txt Fri Oct 18 21:03:08 2002 +++ b/Documentation/networking/e100.txt Fri Oct 18 21:03:08 2002 @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters ============================================================== -April 9, 2002 +September 16, 2002 Contents @@ -19,26 +19,9 @@ =============== This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of -Adapters, version 2.0.x. This driver includes support for Itanium(TM)-based +Adapters, version 2.1.x. This driver includes support for Itanium(TM)-based systems. -New for this release: - - - Additional ethtool functionality, including link status test and EEPROM - read/write. A third-party application can use the ethtool interface to - get and set driver parameters. - - - Support for Zero copy on 82550-based adapters. This feature provides - faster data throughput and significant CPU usage improvement in systems - that use the relevant system call (sendfile(2)). - - - Support for large MTU-enabling interface (1504 bytes) with kernel's - VLAN module - - - Support for polling on RX - - - Support for Wake On LAN* on 82550 and 82559-based adapters - Supported Adapters ================== @@ -96,8 +79,7 @@ To verify that your adapter is supported, find the board ID number on the adapter. Look for a label that has a barcode and a number in the format -123456-001 (six digits hyphen three digits). Match this to the list of -numbers above. +A12345-001. Match this to the list of numbers above. For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: @@ -106,15 +88,20 @@ For the latest Intel PRO/100 network driver for Linux, see: - http://appsr.intel.com/scripts-df/support_intel.asp + http://downloadfinder.intel.com/scripts-df/support_intel.asp Command Line Parameters ======================= -The following parameters are used by entering them on the command line with -the modprobe or insmod command. For example, with two Intel PRO/100 PCI -adapters, entering: +The following optional parameters are used by entering them on the command +line with the modprobe or insmod command using this syntax: + + modprobe e100 [