From owner-p4-projects@FreeBSD.ORG Sun Jan 1 10:39:08 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 911571065672; Sun, 1 Jan 2012 10:39:08 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 535DD1065670 for ; Sun, 1 Jan 2012 10:39:08 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8838FC0C for ; Sun, 1 Jan 2012 10:39:08 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q01Ad8Nk056977 for ; Sun, 1 Jan 2012 10:39:08 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q01Ad83q056974 for perforce@freebsd.org; Sun, 1 Jan 2012 10:39:08 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 1 Jan 2012 10:39:08 GMT Message-Id: <201201011039.q01Ad83q056974@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 203804 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 10:39:08 -0000 http://p4web.freebsd.org/@@203804?ac=10 Change 203804 by rene@rene_acer on 2012/01/01 10:38:40 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#118 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/disks/chapter.sgml#30 integrate .. //depot/projects/docproj_nl/www/en/copyright/freebsd-doc-license.sgml#5 integrate .. //depot/projects/docproj_nl/www/en/copyright/freebsd-license.sgml#5 integrate .. //depot/projects/docproj_nl/www/en/events/Makefile#5 integrate .. //depot/projects/docproj_nl/www/en/internal/machines.sgml#8 integrate .. //depot/projects/docproj_nl/www/en/smp/index.sgml#5 integrate .. //depot/projects/docproj_nl/www/share/sgml/header.ent#10 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#118 (text+ko) ==== @@ -1,4 +1,4 @@ - + + @@ -11,7 +11,7 @@ Site Map | - Legal Notices | © 1995-2011 The FreeBSD Project. + Legal Notices | © 1995-2012 The FreeBSD Project. All rights reserved.'> home   |   contact   |   legal   |   ©right;'> From owner-p4-projects@FreeBSD.ORG Sun Jan 1 10:41:19 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 7FD7D1065670; Sun, 1 Jan 2012 10:41:19 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41F7E106566C for ; Sun, 1 Jan 2012 10:41:19 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3AF8FC0A for ; Sun, 1 Jan 2012 10:41:19 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q01AfJ3X058449 for ; Sun, 1 Jan 2012 10:41:19 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q01AfJgt058446 for perforce@freebsd.org; Sun, 1 Jan 2012 10:41:19 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 1 Jan 2012 10:41:19 GMT Message-Id: <201201011041.q01AfJgt058446@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 203805 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 10:41:19 -0000 http://p4web.freebsd.org/@@203805?ac=10 Change 203805 by rene@rene_acer on 2012/01/01 10:41:05 [www] MFen header.l10n.ent 1.17 -> 1.18 Affected files ... .. //depot/projects/docproj_nl/www/nl/share/sgml/header.l10n.ent#23 edit Differences ... ==== //depot/projects/docproj_nl/www/nl/share/sgml/header.l10n.ent#23 (text+ko) ==== @@ -1,6 +1,6 @@ @@ -14,7 +14,7 @@ Sitemap | - Wettelijke mededelingen | © 1995-2011 Het FreeBSD Project. + Wettelijke mededelingen | © 1995-2012 Het FreeBSD Project. Alle rechten voorbehouden.'> beginpagina   |   contact   |   legaal   |   ©right;'> From owner-p4-projects@FreeBSD.ORG Tue Jan 3 20:44:55 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id ACAC31065675; Tue, 3 Jan 2012 20:44:55 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6A91065670 for ; Tue, 3 Jan 2012 20:44:55 +0000 (UTC) (envelope-from pjd@freebsd.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD928FC08 for ; Tue, 3 Jan 2012 20:44:55 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q03KitDe052860 for ; Tue, 3 Jan 2012 20:44:55 GMT (envelope-from pjd@freebsd.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q03KitsZ052857 for perforce@freebsd.org; Tue, 3 Jan 2012 20:44:55 GMT (envelope-from pjd@freebsd.org) Date: Tue, 3 Jan 2012 20:44:55 GMT Message-Id: <201201032044.q03KitsZ052857@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to pjd@freebsd.org using -f From: Pawel Jakub Dawidek To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 203939 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:44:55 -0000 http://p4web.freebsd.org/@@203939?ac=10 Change 203939 by pjd@pjd_anger on 2012/01/03 20:44:37 Remove impossible condition. If we are here, the error variable must be 0, so no need to check it. Affected files ... .. //depot/projects/trustedbsd/openbsm/libauditd/auditd_lib.c#16 edit Differences ... ==== //depot/projects/trustedbsd/openbsm/libauditd/auditd_lib.c#16 (text+ko) ==== @@ -26,7 +26,7 @@ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. * - * $P4: //depot/projects/trustedbsd/openbsm/libauditd/auditd_lib.c#15 $ + * $P4: //depot/projects/trustedbsd/openbsm/libauditd/auditd_lib.c#16 $ */ #include @@ -852,8 +852,6 @@ /* Success. */ *newfile = fn; close(fd); - if (error) - return (error); if (saverrno) { /* * auditctl() failed but still From owner-p4-projects@FreeBSD.ORG Sat Jan 7 15:25:44 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 0FDE31065673; Sat, 7 Jan 2012 15:25:44 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD39F106564A for ; Sat, 7 Jan 2012 15:25:43 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id A2A998FC15 for ; Sat, 7 Jan 2012 15:25:43 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q07FPhoF040452 for ; Sat, 7 Jan 2012 15:25:43 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q07FPgHx040449 for perforce@freebsd.org; Sat, 7 Jan 2012 15:25:42 GMT (envelope-from rene@FreeBSD.org) Date: Sat, 7 Jan 2012 15:25:42 GMT Message-Id: <201201071525.q07FPgHx040449@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 204189 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 15:25:44 -0000 http://p4web.freebsd.org/@@204189?ac=10 Change 204189 by rene@rene_acer on 2012/01/07 15:25:18 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#46 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#119 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/portbuild/article.sgml#44 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml#2 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.sgml#8 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#121 integrate .. //depot/projects/docproj_nl/share/misc/docbook.css#7 integrate .. //depot/projects/docproj_nl/www/en/releases/9.0R/Makefile#2 integrate .. //depot/projects/docproj_nl/www/en/releases/9.0R/hardware.html#1 branch .. //depot/projects/docproj_nl/www/en/releases/9.0R/readme.html#1 branch .. //depot/projects/docproj_nl/www/nl/share/sgml/header.l10n.ent#24 integrate .. //depot/projects/docproj_nl/www/share/sgml/notices.xml#7 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#46 (text+ko) ==== @@ -9,7 +9,7 @@ The &os; Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.306 2011/11/12 17:57:14 crees Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.308 2012/01/05 06:35:47 manolis Exp $ 1999 @@ -25,6 +25,7 @@ 2009 2010 2011 + 2012 The FreeBSD Documentation Project @@ -2638,31 +2639,31 @@ - Make whatever changes needed to make the port - work again. (If it was deleted due to no more distfiles - being available, you will need to volunteer to become the - "upstream" maintainer yourself and host the distfiles, or - find someone else to do so.) + Perform whatever changes are necessary to make the port + work again. If it was deleted because the distfiles are + no longer available you will need to volunteer to host them + yourself, or find someone else to do so. - Re-add the port via cvs commit. + cvs add the updated files. - Re-add the SUBDIR listing of the port - in the parent directory Makefile. + Restore the SUBDIR listing of the port + in the parent directory Makefile, and + delete the entry from ports/MOVED. - Delete the entry from - ports/MOVED. + If the port had an entry in + ports/LEGAL, restore it. - If the port had an entry in - ports/LEGAL, re-add that. - + cvs commit these changes, preferably in + one step. + ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#119 (text+ko) ==== @@ -1,4 +1,4 @@ - + + + + Create the appropriate files in + /etc/.ssh/. + + + + Add the following to /etc/sysctl.conf: +kern.maxfiles=40000 + + + + + TBA + + + + + + + Configuring the disk + + + + + Create a zfs volume named + a and mount it on + /a. + + + + + Create a zfs volume named + a/portbuild and mount it on + /a/portbuild. + + + + + +# mkdir -p /a/portbuild +# cd /a/portbuild +# +# chmod 775 . + +ln -s ../arch/archive/errorlogs arch-errorlogs + + + + + TBA + + + + + + Configuring <literal>src</literal> - Add the following to etc/sysctl.conf: -kern.maxfiles=40000 - + TBA @@ -2534,6 +2670,19 @@ + + Other + + + + + TBA + + + + + + ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml#2 (text+ko) ==== @@ -1,99 +1,110 @@ - Jeroen - Ruigrok van der Werven (asmodai) -
asmodai@FreeBSD.org
- - Written by + Jeroen + Ruigrok van der Werven (asmodai) + +
asmodai@FreeBSD.org
+ + Written by - Hiten + Hiten Pandya -
hiten@uk.FreeBSD.org
+ +
hiten@uk.FreeBSD.org
 Newbus - Special thanks to Matthew N. Dodd, Warner Losh, Bill Paul, - Doug Rabson, Mike Smith, Peter Wemm and Scott Long. + Special thanks to Matthew N. Dodd, Warner Losh, Bill + Paul, Doug Rabson, Mike Smith, Peter Wemm and Scott + Long. + + This chapter explains the Newbus device framework in + detail. - This chapter explains the Newbus device framework in detail. Device Drivers + Purpose of a Device Driver device driver - device driverintroduction - A device driver is a software component which provides the - interface between the kernel's generic view of a peripheral - (e.g. disk, network adapter) and the actual implementation of the - peripheral. The device driver interface (DDI) is - the defined interface between the kernel and the device driver component. - + + device + driverintroduction + + A device driver is a software component which provides the + interface between the kernel's generic view of a peripheral + (e.g. disk, network adapter) and the actual implementation of + the peripheral. The device driver interface + (DDI) is the defined interface between the kernel + and the device driver component. - + Types of Device Drivers - There used to be days in &unix;, and thus FreeBSD, in which there - were four types of devices defined: - + + There used to be days in &unix;, and thus FreeBSD, in + which there were four types of devices defined: + - block device drivers - character device drivers - network device drivers - pseudo-device drivers + block device drivers + character device drivers + network device drivers + pseudo-device drivers - + block devices - Block devices performed in way that used - fixed size blocks [of data]. This type of driver depended on the - so called buffer cache, which had the purpose - to cache accessed blocks of data in a dedicated part of the memory. - Often this buffer cache was based on write-behind, which meant that when - data was modified in memory it got synced to disk whenever the system - did its periodical disk flushing, thus optimizing writes. + Block devices performed in way that + used fixed size blocks [of data]. This type of driver + depended on the so called buffer cache, + which had the purpose to cache accessed blocks of data in a + dedicated part of the memory. Often this buffer cache was + based on write-behind, which meant that when data was modified + in memory it got synced to disk whenever the system did its + periodical disk flushing, thus optimizing writes. - + Character devices character devices However, in the versions of FreeBSD 4.0 and onward the - distinction between block and character devices became non-existent. - + distinction between block and character devices became + non-existent. - + Overview of Newbus - Newbus + Newbus + + Newbus is the implementation of a new + bus architecture based on abstraction layers which saw its + introduction in FreeBSD 3.0 when the Alpha port was imported + into the source tree. It was not until 4.0 before it became the + default system to use for device drivers. Its goals are to + provide a more object oriented means of interconnecting the + various busses and devices which a host system provides to the + Operating System. - Newbus is the implementation of a new bus - architecture based on abstraction layers which saw its introduction in - FreeBSD 3.0 when the Alpha port was imported into the source tree. It was - not until 4.0 before it became the default system to use for device - drivers. Its goals are to provide a more object oriented means of - interconnecting the various busses and devices which a host system - provides to the Operating System. - Its main features include amongst others: - + dynamic attaching easy modularization of drivers pseudo-busses - - One of the most prominent changes is the migration from the flat and - ad-hoc system to a device tree lay-out. - - At the top level resides the root - device which is the parent to hang all other devices on. For each - architecture, there is typically a single child of root - which has such things as host-to-PCI bridges, etc. - attached to it. For x86, this root device is the - nexus device and for Alpha, various - different different models of Alpha have different top-level devices - corresponding to the different hardware chipsets, including - lca, apecs, - cia and tsunami. - - A device in the Newbus context represents a single hardware entity - in the system. For instance each PCI device is represented by a Newbus - device. Any device in the system can have children; a device which has - children is often called a bus. - Examples of common busses in the system are ISA and PCI which manage lists - of devices attached to ISA and PCI busses respectively. - - Often, a connection between different kinds of bus is represented by - a bridge device which normally has one - child for the attached bus. An example of this is a - PCI-to-PCI bridge which is represented by a device - pcibN on the parent PCI bus - and has a child pciN for the - attached bus. This layout simplifies the implementation of the PCI bus - tree, allowing common code to be used for both top-level and bridged - busses. - - Each device in the Newbus architecture asks its parent to map its - resources. The parent then asks its own parent until the nexus is - reached. So, basically the nexus is the only part of the Newbus system - which knows about all resources. - - An ISA device might want to map its IO port at - 0x230, so it asks its parent, in this case the ISA - bus. The ISA bus hands it over to the PCI-to-ISA bridge which in its turn - asks the PCI bus, which reaches the host-to-PCI bridge and finally the - nexus. The beauty of this transition upwards is that there is room to - translate the requests. For example, the 0x230 IO port - request might become memory-mapped at 0xb0000230 on a - MIPS box by the PCI bridge. - - Resource allocation can be controlled at any place in the device - tree. For instance on many Alpha platforms, ISA interrupts are managed - separately from PCI interrupts and resource allocations for ISA interrupts - are managed by the Alpha's ISA bus device. On IA-32, ISA and PCI - interrupts are both managed by the top-level nexus device. For both - ports, memory and port address space is managed by a single entity - nexus - for IA-32 and the relevant chipset driver on Alpha (e.g. CIA or tsunami). - - - In order to normalize access to memory and port mapped resources, - Newbus integrates the bus_space APIs from NetBSD. - These provide a single API to replace inb/outb and direct memory - reads/writes. The advantage of this is that a single driver can easily - use either memory-mapped registers or port-mapped registers - (some hardware supports both). - - This support is integrated into the resource allocation mechanism. - When a resource is allocated, a driver can retrieve the associated - bus_space_tag_t and - bus_space_handle_t from the resource. - - Newbus also allows for definitions of interface methods in files - dedicated to this purpose. These are the .m files - that are found under the src/sys hierarchy. - - The core of the Newbus system is an extensible - object-based programming model. Each device in the system - has a table of methods which it supports. The system and other devices - uses those methods to control the device and request services. The - different methods supported by a device are defined by a number of - interfaces. An interface is simply a group - of related methods which can be implemented by a device. - - In the Newbus system, the methods for a device are provided by the - various device drivers in the system. When a device is attached to a - driver during auto-configuration, it uses the method - table declared by the driver. A device can later - detach from its driver and - re-attach to a new driver with a new method table. - This allows dynamic replacement of drivers which can be useful for driver - development. - - The interfaces are described by an interface definition language - similar to the language used to define vnode operations for file systems. - The interface would be stored in a methods file (which would normally named - foo_if.m). - + + One of the most prominent changes is the migration from the + flat and ad-hoc system to a device tree lay-out. + + At the top level resides the + root device which is the + parent to hang all other devices on. For each architecture, + there is typically a single child of root which + has such things as host-to-PCI bridges, + etc. attached to it. For x86, this root device + is the nexus device and for + Alpha, various different different models of Alpha have + different top-level devices corresponding to the different + hardware chipsets, including lca, + apecs, cia and + tsunami. + + A device in the Newbus context represents a single hardware + entity in the system. For instance each PCI device is + represented by a Newbus device. Any device in the system can + have children; a device which has children is often called a + bus. Examples of common + busses in the system are ISA and PCI which manage lists of + devices attached to ISA and PCI busses respectively. + + Often, a connection between different kinds of bus is + represented by a bridge + device which normally has one child for the attached bus. An + example of this is a PCI-to-PCI bridge + which is represented by a device + pcibN on the + parent PCI bus and has a child + pciN for the + attached bus. This layout simplifies the implementation of the + PCI bus tree, allowing common code to be used for both top-level + and bridged busses. + + Each device in the Newbus architecture asks its parent to + map its resources. The parent then asks its own parent until + the nexus is reached. So, basically the nexus is the only part + of the Newbus system which knows about all resources. + + An ISA device might want to map its IO port at + 0x230, so it asks its parent, in this case + the ISA bus. The ISA bus hands it over to the PCI-to-ISA bridge + which in its turn asks the PCI bus, which reaches the + host-to-PCI bridge and finally the nexus. The beauty of this + transition upwards is that there is room to translate the + requests. For example, the 0x230 IO port + request might become memory-mapped at + 0xb0000230 on a MIPS box + by the PCI bridge. + + Resource allocation can be controlled at any place in the + device tree. For instance on many Alpha platforms, ISA + interrupts are managed separately from PCI interrupts and + resource allocations for ISA interrupts are managed by the + Alpha's ISA bus device. On IA-32, ISA and PCI interrupts are + both managed by the top-level nexus device. For both ports, + memory and port address space is managed by a single entity - + nexus for IA-32 and the relevant chipset driver on Alpha (e.g. + CIA or tsunami). + + In order to normalize access to memory and port mapped + resources, Newbus integrates the bus_space + APIs from NetBSD. These provide a single API to replace inb/outb + and direct memory reads/writes. The advantage of this is that a + single driver can easily use either memory-mapped registers or + port-mapped registers (some hardware supports both). + + This support is integrated into the resource allocation + mechanism. When a resource is allocated, a driver can retrieve + the associated bus_space_tag_t and + bus_space_handle_t from the + resource. + + Newbus also allows for definitions of interface methods in + files dedicated to this purpose. These are the + .m files that are found under the + src/sys hierarchy. + + The core of the Newbus system is an extensible + object-based programming model. Each device in + the system has a table of methods which it supports. The system + and other devices uses those methods to control the device and + request services. The different methods supported by a device + are defined by a number of interfaces. An + interface is simply a group of related methods + which can be implemented by a device. + + In the Newbus system, the methods for a device are provided + by the various device drivers in the system. When a device is + attached to a driver during + auto-configuration, it uses the method + table declared by the driver. A device can later + detach from its driver and + re-attach to a new driver with a new method + table. This allows dynamic replacement of drivers which can be + useful for driver development. + + The interfaces are described by an interface definition + language similar to the language used to define vnode operations + for file systems. The interface would be stored in a methods + file (which would normally named + foo_if.m). + Newbus Methods + # Foo subsystem/driver (a comment...) @@ -231,114 +257,125 @@ } DEFAULT doit_generic_to_child; - - When this interface is compiled, it generates a header file - foo_if.h which contains function - declarations: - + + When this interface is compiled, it generates a header file + foo_if.h which contains + function declarations: + int FOO_DOIT(device_t dev); int FOO_DOIT_TO_CHILD(device_t dev, device_t child); - - A source file, foo_if.c is - also created to accompany the automatically generated header file; it - contains implementations of those functions which look up the location - of the relevant functions in the object's method table and call that - function. - - The system defines two main interfaces. The first fundamental - interface is called device and - includes methods which are relevant to all devices. Methods in the - device interface include - probe, - attach and - detach to control detection of - hardware and shutdown, - suspend and - resume for critical event - notification. - - The second, more complex interface is - bus. This interface contains - methods suitable for devices which have children, including methods to - access bus specific per-device information - &man.bus.generic.read.ivar.9; and - &man.bus.generic.write.ivar.9;, event notification - (child_detached, - driver_added) and resource - management (alloc_resource, - activate_resource, - deactivate_resource, - release_resource). - - Many methods in the bus interface are performing - services for some child of the bus device. These methods would normally - use the first two arguments to specify the bus providing the service - and the child device which is requesting the service. To simplify - driver code, many of these methods have accessor functions which - lookup the parent and call a method on the parent. For instance the - method - BUS_TEARDOWN_INTR(device_t dev, device_t child, ...) - can be called using the function - bus_teardown_intr(device_t child, ...). - - Some bus types in the system define additional interfaces to - provide access to bus-specific functionality. For instance, the PCI - bus driver defines the pci interface which has two - methods read_config and - write_config for accessing the - configuration registers of a PCI device. + + A source file, foo_if.c + is also created to accompany the automatically generated header + file; it contains implementations of those functions which look + up the location of the relevant functions in the object's method + table and call that function. + + The system defines two main interfaces. The first + fundamental interface is called + device and includes methods + which are relevant to all devices. Methods in the + device interface include + probe, + attach and + detach to control detection + of hardware and shutdown, + suspend and + resume for critical event + notification. + + The second, more complex interface is + bus. This interface + contains methods suitable for devices which have children, + including methods to access bus specific per-device information + &man.bus.generic.read.ivar.9; and + &man.bus.generic.write.ivar.9;, event + notification + (child_detached, + driver_added) and + resource management + (alloc_resource, + activate_resource, + deactivate_resource, + release_resource). + + Many methods in the bus interface are + performing services for some child of the bus device. These + methods would normally use the first two arguments to specify + the bus providing the service and the child device which is + requesting the service. To simplify driver code, many of these + methods have accessor functions which lookup the parent and call + a method on the parent. For instance the method + BUS_TEARDOWN_INTR(device_t dev, device_t child, + ...) can be called using the function + bus_teardown_intr(device_t child, + ...). + + Some bus types in the system define additional interfaces to + provide access to bus-specific functionality. For instance, the + PCI bus driver defines the pci interface which + has two methods + read_config and + write_config for + accessing the configuration registers of a PCI device. - + Newbus API + As the Newbus API is huge, this section makes some effort at - documenting it. More information to come in the next revision of this - document. - + documenting it. More information to come in the next revision + of this document. + Important locations in the source hierarchy - - src/sys/[arch]/[arch] - Kernel code for a - specific machine architecture resides in this directory. For example, - the i386 architecture, or the - SPARC64 architecture. - - src/sys/dev/[bus] - device support for a - specific [bus] resides in this directory. - - src/sys/dev/pci - PCI bus support code - resides in this directory. - - src/sys/[isa|pci] - PCI/ISA device drivers - reside in this directory. The PCI/ISA bus support code used to exist - in this directory in FreeBSD version 4.0. + + src/sys/[arch]/[arch] - Kernel code + for a specific machine architecture resides in this directory. + For example, the i386 architecture, or the + SPARC64 architecture. + + src/sys/dev/[bus] - device support + for a specific [bus] resides in this + directory. + + src/sys/dev/pci - PCI bus support + code resides in this directory. + + src/sys/[isa|pci] - PCI/ISA device + drivers reside in this directory. The PCI/ISA bus support + code used to exist in this directory in FreeBSD version + 4.0. - + Important structures and type definitions - devclass_t - This is a type definition of a - pointer to a struct devclass. - - device_method_t - This is same as - kobj_method_t (see - src/sys/kobj.h). - - device_t - This is a type definition of a - pointer to a struct device. - device_t represents a device in the system. It is - a kernel object. See src/sys/sys/bus_private.h - for implementation details. - - driver_t - This is a type definition which, - references struct driver. The - driver struct is a class of the - device kernel object; it also holds data private - to for the driver. - + + devclass_t - This is a type definition + of a pointer to a struct devclass. + + device_method_t - This is same as + kobj_method_t (see + src/sys/kobj.h). + + device_t - This is a type definition of + a pointer to a struct device. + device_t represents a device in the system. + It is a kernel object. See + src/sys/sys/bus_private.h for + implementation details. + + driver_t - This is a type definition + which, references struct driver. The + driver struct is a class of the + device kernel object; it also holds data + private to for the driver. +
- <emphasis>driver_t</emphasis> implementation + <emphasis>driver_t</emphasis> implementation + struct driver { KOBJ_CLASS_FIELDS; @@ -346,14 +383,16 @@ };
- + A device_state_t type, which is - an enumeration, device_state. It contains - the possible states of a Newbus device before and after the - autoconfiguration process. - + an enumeration, device_state. It contains + the possible states of a Newbus device before and after the >>> TRUNCATED FOR MAIL (1000 lines) <<<