Searched hist:4 (Results 201 - 225 of 14306) sorted by relevance

1234567891011>>

/freebsd-9.3-release/sbin/mdconfig/
H A DMakefilediff 157160 Sun Mar 26 21:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be
a problem with listing large number of md(4) devices. Either 'list' or
'query' mode uses XML.

Additionally, new functionality was introduced. It's possible to pass
multiple devices to -u:

# ./mdconfig -l -u md0,md1

Approved by: cognet (mentor)
diff 157160 Sun Mar 26 21:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be
a problem with listing large number of md(4) devices. Either 'list' or
'query' mode uses XML.

Additionally, new functionality was introduced. It's possible to pass
multiple devices to -u:

# ./mdconfig -l -u md0,md1

Approved by: cognet (mentor)
diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean.
After this change it should be possible to use very big md(4) devices.
- Clean up and simplify the code a bit.
- Use humanize_number(3) to print size of md(4) devices.
- Add 't' suffix which stands for terabyte.
- Make '-S' to really work with all types of devices.
- Other minor changes.
diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean.
After this change it should be possible to use very big md(4) devices.
- Clean up and simplify the code a bit.
- Use humanize_number(3) to print size of md(4) devices.
- Add 't' suffix which stands for terabyte.
- Make '-S' to really work with all types of devices.
- Other minor changes.
diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean.
After this change it should be possible to use very big md(4) devices.
- Clean up and simplify the code a bit.
- Use humanize_number(3) to print size of md(4) devices.
- Add 't' suffix which stands for terabyte.
- Make '-S' to really work with all types of devices.
- Other minor changes.
diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8)
entirely as previously advertised.

md(4) adopted all assets of vn(4) some time back and has proper devfs
support and cloning abilities to boot.
diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8)
entirely as previously advertised.

md(4) adopted all assets of vn(4) some time back and has proper devfs
support and cloning abilities to boot.
diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8)
entirely as previously advertised.

md(4) adopted all assets of vn(4) some time back and has proper devfs
support and cloning abilities to boot.
diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8)
entirely as previously advertised.

md(4) adopted all assets of vn(4) some time back and has proper devfs
support and cloning abilities to boot.
70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
/freebsd-9.3-release/sys/dev/nvme/
H A Dnvme_ns_cmd.cdiff 253630 Wed Jul 24 20:50:51 MDT 2013 jimharris MFC r253474:

Fix nvme(4) and nvd(4) to support non 512-byte sector sizes.

Recent testing with QEMU that has variable sector size support for
NVMe uncovered some of these issues. Chatham prototype boards supported
only 512 byte sectors.

Approved by: re (kib)
Sponsored by: Intel
diff 253630 Wed Jul 24 20:50:51 MDT 2013 jimharris MFC r253474:

Fix nvme(4) and nvd(4) to support non 512-byte sector sizes.

Recent testing with QEMU that has variable sector size support for
NVMe uncovered some of these issues. Chatham prototype boards supported
only 512 byte sectors.

Approved by: re (kib)
Sponsored by: Intel
diff 252221 Tue Jun 25 21:32:37 MDT 2013 jimharris MFC r240616, r240619, r240620:

Merge initial NVM Express (NVMe) commits to stable/9.

This only pulls the nvme(4), nvd(4) and nvmecontrol(8) code into stable/9.
A follow-up commit will link it into the build and merge all of the
additional commits made for NVMe over the last few months.

Sponsored by: Intel
diff 252221 Tue Jun 25 21:32:37 MDT 2013 jimharris MFC r240616, r240619, r240620:

Merge initial NVM Express (NVMe) commits to stable/9.

This only pulls the nvme(4), nvd(4) and nvmecontrol(8) code into stable/9.
A follow-up commit will link it into the build and merge all of the
additional commits made for NVMe over the last few months.

Sponsored by: Intel
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
240616 Mon Sep 17 17:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe)
support to FreeBSD. A full description of the overall functionality
being added is below. nvmexpress.org defines NVM Express as "an optimized
register interface, command set and feature set fo PCI Express (PCIe)-based
Solid-State Drives (SSDs)."

This commit adds nvme(4) and nvd(4) driver source code and Makefiles
to the tree.

Full NVMe functionality description:
Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe)
device support.

There will continue to be ongoing work on NVM Express support, but there
is more than enough to allow for evaluation of pre-production NVM Express
devices as well as soliciting feedback. Questions and feedback are welcome.

nvme(4) implements NVMe hardware abstraction and is a provider of NVMe
namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN.
nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks.
nvmecontrol(8) is used for NVMe configuration and management.

The following are currently supported:
nvme(4)
- full mandatory NVM command set support
- per-CPU IO queues (enabled by default but configurable)
- per-queue sysctls for statistics and full command/completion queue
dumps for debugging
- registration API for NVMe namespace consumers
- I/O error handling (except for timeoutsee below)
- compilation switches for support back to stable-7

nvd(4)
- BIO_DELETE and BIO_FLUSH (if supported by controller)
- proper BIO_ORDERED handling

nvmecontrol(8)
- devlist: list NVMe controllers and their namespaces
- identify: display controller or namespace identify data in
human-readable or hex format
- perftest: quick and dirty performance test to measure raw
performance of NVMe device without userspace/physio/GEOM
overhead

The following are still work in progress and will be completed over the
next 3-6 months in rough priority order:
- complete man pages
- firmware download and activation
- asynchronous error requests
- command timeout error handling
- controller resets
- nvmecontrol(8) log page retrieval

This has been primarily tested on amd64, with light testing on i386. I
would be happy to provide assistance to anyone interested in porting
this to other architectures, but am not currently planning to do this
work myself. Big-endian and dmamap sync for command/completion queues
are the main areas that would need to be addressed.

The nvme(4) driver currently has references to Chatham, which is an
Intel-developed prototype board which is not fully spec compliant.
These references will all be removed over time.

Sponsored by: Intel
Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com>
/freebsd-9.3-release/share/man/man4/
H A Dbce.4diff 236722 Thu Jun 07 17:26:21 MDT 2012 sbruno MFC r236412,236418,236420,236591,236624

Doc updates for bce(4) tuneables

Note that for 7/8/9 the strict_rx_mtu variable is named
loose_rx_mtu.
diff 197835 Wed Oct 07 11:46:10 MDT 2009 simon - Document that 'Dell PowerEdge R710' has bce(4) supported NIC.
- Bump document date.

MFC after: 3 days
diff 190832 Tue Apr 07 20:32:15 MDT 2009 delphij Add the following media types as supported by bce(4):

- 1000BaseSX
- 2500BaseSX

While I'm there, correct 1000BaseTX as more standard 1000BaseT.

MFC after: 3 days
diff 187318 Thu Jan 15 20:54:46 MST 2009 delphij Reflect newly added PCI IDs to bce(4).

MFC after: 2 months
diff 185574 Tue Dec 02 23:49:18 MST 2008 delphij Update bce(4)'s hardware list to reflect the recent update to driver.

MFC after: 3 days
diff 183648 Mon Oct 06 16:21:35 MDT 2008 simon Document that the bce(4) driver works with Dell PowerEdge 1950/2950
NIC's.

MFC after: 3 days
diff 166474 Sat Feb 03 17:29:31 MST 2007 brueffer Xref altq(4).
diff 164819 Sat Dec 02 07:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now.
diff 164819 Sat Dec 02 07:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now.
H A Dhme.4diff 204605 Tue Mar 02 20:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from
their software.

Obtained from: NetBSD
diff 194193 Sun Jun 14 12:46:25 MDT 2009 marius Improve the description a bit and add a reference to vlan(4).
diff 187316 Thu Jan 15 20:08:17 MST 2009 marius Don't cross-reference gem(4) and hme(4); maybe this made some sense
back when these two were the only two NIC drivers working on sparc64
but it no longer does nowadays.

MFC after: 3 days
diff 187316 Thu Jan 15 20:08:17 MST 2009 marius Don't cross-reference gem(4) and hme(4); maybe this made some sense
back when these two were the only two NIC drivers working on sparc64
but it no longer does nowadays.

MFC after: 3 days
diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4).
diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4).
diff 148145 Mon Jul 18 22:26:30 MDT 2005 trhodes Add a "Load module on start up" comment, similar to mac_*.4 pages[1].
Quote .Cd and .Nd text.
Bump doc date.

Requested by: some user through ru
Supported by: ru, dwmalone, brueffer
diff 133729 Sat Aug 14 19:44:35 MDT 2004 marius - Capitalize Ethernet and Fast Ethernet.
- Add a NOTES section with information regarding the "local-mac-address?"
system configuration variable on sparc64 and add a reference to eeprom(8)
for using it. Dump document date for this.
- In dc.4, add the on-board DM9102A on Sun Netra X1 and Sun Fire V100 to
the list of known working devices.
116166 Tue Jun 10 16:53:15 MDT 2003 tmm - Add manpages for the gem and hme ethernet drivers. These were obtained
from NetBSD, and changed slightly to account for FreeBSD specifics.
- Hook them up to the build.
- Add them to the list of miibus-using drivers in miibus(4).
H A Damdpm.4diff 153942 Sat Dec 31 14:32:27 MST 2005 brueffer Update for new devices, including the AMD 8111. Also mention
amdsmb(4) for SMBus 2.0 functionality of the AMD 8111.
83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4),
amdpm(4) and smb(4).

This device can be used with userland programs such as sysutils/lmmon
to retrieve sensor information from the motherboard.

PR: kern/23989
Obtained from: Matthew C. Forman <mcf@dmu.ac.uk>
Based on: alpm(4)
83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4),
amdpm(4) and smb(4).

This device can be used with userland programs such as sysutils/lmmon
to retrieve sensor information from the motherboard.

PR: kern/23989
Obtained from: Matthew C. Forman <mcf@dmu.ac.uk>
Based on: alpm(4)
83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4),
amdpm(4) and smb(4).

This device can be used with userland programs such as sysutils/lmmon
to retrieve sensor information from the motherboard.

PR: kern/23989
Obtained from: Matthew C. Forman <mcf@dmu.ac.uk>
Based on: alpm(4)
83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4),
amdpm(4) and smb(4).

This device can be used with userland programs such as sysutils/lmmon
to retrieve sensor information from the motherboard.

PR: kern/23989
Obtained from: Matthew C. Forman <mcf@dmu.ac.uk>
Based on: alpm(4)
H A Dsge.4diff 217468 Sun Jan 16 02:17:13 MST 2011 marius Reference rgephy.4 in man pages of additional MAC drivers also known to
come in combination with these PHYs.

Submitted by: yongari
MFC after: 3 days
diff 207853 Mon May 10 15:48:50 MDT 2010 yongari Now sge(4) supports TCP segmentation offload (TSO).
diff 207381 Thu Apr 29 16:27:37 MDT 2010 yongari Now sge(4) supports hardware VLAN tag insertion/stripping.
206631 Wed Apr 14 19:38:23 MDT 2010 yongari Add sge(4) man page and hook up sge(4) to the build.
Also add Xr to appropriate man pages.
206631 Wed Apr 14 19:38:23 MDT 2010 yongari Add sge(4) man page and hook up sge(4) to the build.
Also add Xr to appropriate man pages.
H A Dstge.4diff 204605 Tue Mar 02 20:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from
their software.

Obtained from: NetBSD
diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4).
diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4).
diff 160800 Fri Jul 28 18:14:43 MDT 2006 simon Add missing .El to close list.

This confused the manual page -> hardware notes perl script somewhat and
resulted in part of the output for the stge(4) entry not to be present
in the hardware notes.

Noticed by: brueffer
160643 Mon Jul 24 22:51:38 MDT 2006 yongari Add a man page for stge(4).
H A Durtw.4diff 198195 Sat Oct 17 22:55:12 MDT 2009 weongyo adds devices supportted by urtw(4) and bumps date.
diff 197724 Sat Oct 03 00:39:23 MDT 2009 weongyo TRENDnet TEW-424UB has multiple revisions so clarify zyd(4) man page and
adds a device to urtw(4). The revision informations are as follows:

rev A ZD1211
V2 SiS163U
V2.1R SiS163U
V3.xR RTL8187B

and bump date.

Obtained from: OpenBSD
Reported by: Albert Shih <Albert.Shih at obspm.fr>
diff 197724 Sat Oct 03 00:39:23 MDT 2009 weongyo TRENDnet TEW-424UB has multiple revisions so clarify zyd(4) man page and
adds a device to urtw(4). The revision informations are as follows:

rev A ZD1211
V2 SiS163U
V2.1R SiS163U
V3.xR RTL8187B

and bump date.

Obtained from: OpenBSD
Reported by: Albert Shih <Albert.Shih at obspm.fr>
diff 195915 Mon Jul 27 16:19:01 MDT 2009 weongyo urtw(4) supports RTL8187B chipset now.

Approved by: re (kib)
187610 Fri Jan 23 03:19:57 MST 2009 weongyo Add a new USB wireless driver, urtw(4) for supporting Realtek's 8187L
chipset.
/freebsd-9.3-release/sys/dev/fdt/
H A Dfdtbus.cdiff 209127 Sun Jun 13 11:02:11 MDT 2010 raj Provide identify method for the fdtbus(4).

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure.

o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This
is a direct replacement for the many incompatible bus drivers grouping
integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.)

o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which
is an umbrella device for most of the integrated peripherals on a typical
system-on-chip device.

o Other components (common routines library, PCI node processing helper
functions)

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure.

o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This
is a direct replacement for the many incompatible bus drivers grouping
integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.)

o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which
is an umbrella device for most of the integrated peripherals on a typical
system-on-chip device.

o Other components (common routines library, PCI node processing helper
functions)

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure.

o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This
is a direct replacement for the many incompatible bus drivers grouping
integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.)

o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which
is an umbrella device for most of the integrated peripherals on a typical
system-on-chip device.

o Other components (common routines library, PCI node processing helper
functions)

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure.

o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This
is a direct replacement for the many incompatible bus drivers grouping
integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.)

o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which
is an umbrella device for most of the integrated peripherals on a typical
system-on-chip device.

o Other components (common routines library, PCI node processing helper
functions)

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
/freebsd-9.3-release/sys/dev/glxsb/
H A Dglxsb.cdiff 185021 Mon Nov 17 05:18:22 MST 2008 philip Fix two possible (but unlikely) NULL-pointer dereferences in glxsb(4).

Spotted by: Coverity
MFC after: 1 week
181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as
found in Soekris hardware, for instance). The hardware supports acceleration
of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4).

TODO:

o Implement rndtest(4) support
o Performance enhancements

Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org>
Reviewed by: jhb, sam
MFC after: 1 week
181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as
found in Soekris hardware, for instance). The hardware supports acceleration
of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4).

TODO:

o Implement rndtest(4) support
o Performance enhancements

Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org>
Reviewed by: jhb, sam
MFC after: 1 week
181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as
found in Soekris hardware, for instance). The hardware supports acceleration
of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4).

TODO:

o Implement rndtest(4) support
o Performance enhancements

Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org>
Reviewed by: jhb, sam
MFC after: 1 week
181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as
found in Soekris hardware, for instance). The hardware supports acceleration
of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4).

TODO:

o Implement rndtest(4) support
o Performance enhancements

Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org>
Reviewed by: jhb, sam
MFC after: 1 week
/freebsd-9.3-release/sys/dev/scc/
H A Dscc_if.m157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
/freebsd-9.3-release/sys/modules/cpuctl/
H A DMakefile181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
/freebsd-9.3-release/usr.sbin/cpucontrol/
H A Damd.h181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
H A Dcpucontrol.h181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
H A Dintel.h181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
/freebsd-9.3-release/etc/etc.sparc64/
H A Dttysdiff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5).

When we had utmp(5), we had to list all the psuedo-terminals in ttys(5)
to make ttyslot(3) function properly. Now that pututxline(3) deals with
slot allocation internally (not based on TTY names), we don't need to
list all the TTYs on the system in ttys(5) to make user accounting work
properly.

This patch removes all the entries from the /etc/ttys files, but also
the pts(4) entries that were appended implicitly, which was added in
r154838.
diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms.

Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:

- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
regions.
- A very hard transition path to support for modern character sets like
UTF-8.

Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.

I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.

IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):

- Run the application inside script(1), try to reduce the problem and
send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
TERM=cons25' so you can run applications the same way you did before.
You can also build your kernel with `options TEKEN_CONS25' to make all
virtual terminals use the cons25 emulator by default.

Discussed on: current@
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
/freebsd-9.3-release/sys/dev/stge/
H A Dif_stge.cdiff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
/freebsd-9.3-release/sys/dev/iicbus/
H A Diicsmb.cdiff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers:
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
/freebsd-9.3-release/sys/dev/vge/
H A Dif_vgereg.hdiff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.

Work around the issue by generating link state change interrupt
with DEVICE_POLLING.

PR: kern/160442
Approved by: re (kib)
diff 200638 Thu Dec 17 16:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx
controllers. TX/RX interrupt mitigation is controlled by
VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress
generation of interrupts until the programmed frames counter equals
to the registers. VT61xx also supports interrupt hold off timer
register. If this interrupt hold off timer is active all interrupts
would be disabled until the timer reaches to 0. The timer value is
reloaded whenever VGE_ISR register written. The timer resolution is
about 20us.

Previously vge(4) used single shot timer to reduce Tx completion
interrupts. This required VGE_CRS1 register access in Tx
start/completion handler to rearm new timeout value and it did not
show satisfactory result(more than 50k interrupts under load). Rx
interrupts was not moderated at all such that vge(4) used to
generate too many interrupts which in turn made polling(4) better
approach under high network load.

This change activates all interrupt moderation mechanism and
initial values were tuned to generate interrupt less than 8k per
second. That number of interrupts wouldn't add additional packet
latencies compared to polling(4). These interrupt parameters could
be changed with sysctl.
dev.vge.%d.int_holdoff
dev.vge.%d.rx_coal_pkt
dev.vge.%d.tx_coal_pkt
Interface has be brought down and up again before change take
effect.

With interrupt moderation there is no more need to loop in
interrupt handler. This loop always added one more register access.
While I'm here remove dead code which tried to implement subset of
interrupt moderation.
diff 200638 Thu Dec 17 16:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx
controllers. TX/RX interrupt mitigation is controlled by
VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress
generation of interrupts until the programmed frames counter equals
to the registers. VT61xx also supports interrupt hold off timer
register. If this interrupt hold off timer is active all interrupts
would be disabled until the timer reaches to 0. The timer value is
reloaded whenever VGE_ISR register written. The timer resolution is
about 20us.

Previously vge(4) used single shot timer to reduce Tx completion
interrupts. This required VGE_CRS1 register access in Tx
start/completion handler to rearm new timeout value and it did not
show satisfactory result(more than 50k interrupts under load). Rx
interrupts was not moderated at all such that vge(4) used to
generate too many interrupts which in turn made polling(4) better
approach under high network load.

This change activates all interrupt moderation mechanism and
initial values were tuned to generate interrupt less than 8k per
second. That number of interrupts wouldn't add additional packet
latencies compared to polling(4). These interrupt parameters could
be changed with sysctl.
dev.vge.%d.int_holdoff
dev.vge.%d.rx_coal_pkt
dev.vge.%d.tx_coal_pkt
Interface has be brought down and up again before change take
effect.

With interrupt moderation there is no more need to loop in
interrupt handler. This loop always added one more register access.
While I'm here remove dead code which tried to implement subset of
interrupt moderation.
diff 200638 Thu Dec 17 16:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx
controllers. TX/RX interrupt mitigation is controlled by
VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress
generation of interrupts until the programmed frames counter equals
to the registers. VT61xx also supports interrupt hold off timer
register. If this interrupt hold off timer is active all interrupts
would be disabled until the timer reaches to 0. The timer value is
reloaded whenever VGE_ISR register written. The timer resolution is
about 20us.

Previously vge(4) used single shot timer to reduce Tx completion
interrupts. This required VGE_CRS1 register access in Tx
start/completion handler to rearm new timeout value and it did not
show satisfactory result(more than 50k interrupts under load). Rx
interrupts was not moderated at all such that vge(4) used to
generate too many interrupts which in turn made polling(4) better
approach under high network load.

This change activates all interrupt moderation mechanism and
initial values were tuned to generate interrupt less than 8k per
second. That number of interrupts wouldn't add additional packet
latencies compared to polling(4). These interrupt parameters could
be changed with sysctl.
dev.vge.%d.int_holdoff
dev.vge.%d.rx_coal_pkt
dev.vge.%d.tx_coal_pkt
Interface has be brought down and up again before change take
effect.

With interrupt moderation there is no more need to loop in
interrupt handler. This loop always added one more register access.
While I'm here remove dead code which tried to implement subset of
interrupt moderation.
diff 200638 Thu Dec 17 16:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx
controllers. TX/RX interrupt mitigation is controlled by
VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress
generation of interrupts until the programmed frames counter equals
to the registers. VT61xx also supports interrupt hold off timer
register. If this interrupt hold off timer is active all interrupts
would be disabled until the timer reaches to 0. The timer value is
reloaded whenever VGE_ISR register written. The timer resolution is
about 20us.

Previously vge(4) used single shot timer to reduce Tx completion
interrupts. This required VGE_CRS1 register access in Tx
start/completion handler to rearm new timeout value and it did not
show satisfactory result(more than 50k interrupts under load). Rx
interrupts was not moderated at all such that vge(4) used to
generate too many interrupts which in turn made polling(4) better
approach under high network load.

This change activates all interrupt moderation mechanism and
initial values were tuned to generate interrupt less than 8k per
second. That number of interrupts wouldn't add additional packet
latencies compared to polling(4). These interrupt parameters could
be changed with sysctl.
dev.vge.%d.int_holdoff
dev.vge.%d.rx_coal_pkt
dev.vge.%d.tx_coal_pkt
Interface has be brought down and up again before change take
effect.

With interrupt moderation there is no more need to loop in
interrupt handler. This loop always added one more register access.
While I'm here remove dead code which tried to implement subset of
interrupt moderation.
/freebsd-9.3-release/etc/etc.ia64/
H A Dttysdiff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5).

When we had utmp(5), we had to list all the psuedo-terminals in ttys(5)
to make ttyslot(3) function properly. Now that pututxline(3) deals with
slot allocation internally (not based on TTY names), we don't need to
list all the TTYs on the system in ttys(5) to make user accounting work
properly.

This patch removes all the entries from the /etc/ttys files, but also
the pts(4) entries that were appended implicitly, which was added in
r154838.
diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms.

Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:

- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
regions.
- A very hard transition path to support for modern character sets like
UTF-8.

Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.

I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.

IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):

- Run the application inside script(1), try to reduce the problem and
send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
TERM=cons25' so you can run applications the same way you did before.
You can also build your kernel with `options TEKEN_CONS25' to make all
virtual terminals use the cons25 emulator by default.

Discussed on: current@
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
/freebsd-9.3-release/etc/etc.powerpc/
H A Dttysdiff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5).

When we had utmp(5), we had to list all the psuedo-terminals in ttys(5)
to make ttyslot(3) function properly. Now that pututxline(3) deals with
slot allocation internally (not based on TTY names), we don't need to
list all the TTYs on the system in ttys(5) to make user accounting work
properly.

This patch removes all the entries from the /etc/ttys files, but also
the pts(4) entries that were appended implicitly, which was added in
r154838.
diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms.

Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:

- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
regions.
- A very hard transition path to support for modern character sets like
UTF-8.

Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.

I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.

IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):

- Run the application inside script(1), try to reduce the problem and
send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
TERM=cons25' so you can run applications the same way you did before.
You can also build your kernel with `options TEKEN_CONS25' to make all
virtual terminals use the cons25 emulator by default.

Discussed on: current@
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys.

Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.

I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.

This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries.

As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.

This means we've now just toggled the amount of entries for pts(4) and
pty(4).

Requested by: rwatson
/freebsd-9.3-release/sys/dev/pcf/
H A Denvctrl.cdiff 181332 Tue Aug 05 15:48:04 MDT 2008 jhb - Consolidate module version for the pcf module into just pcf.c instead
of having duplicate versions in each bus attachment.
- Add a DRIVER_MODULE() instance so that the iicbus(4) driver will
actually attach to pcf(4) driver instances.
- Fix compile of envctrl.c.

Pointy hat: jhb (3)
diff 181332 Tue Aug 05 15:48:04 MDT 2008 jhb - Consolidate module version for the pcf module into just pcf.c instead
of having duplicate versions in each bus attachment.
- Add a DRIVER_MODULE() instance so that the iicbus(4) driver will
actually attach to pcf(4) driver instances.
- Fix compile of envctrl.c.

Pointy hat: jhb (3)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 181303 Mon Aug 04 19:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers:
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.

Tested by: sam (arm/ixp425)
diff 146966 Sat Jun 04 18:29:28 MDT 2005 marius Account for ebus(4) defaulting to SYS_RES_MEMORY for memory resources
since ebus.c rev. 1.22.
/freebsd-9.3-release/sys/dev/smc/
H A Dif_smc.cdiff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042

- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
/freebsd-9.3-release/lib/libz/contrib/
H A DREADME.contribdiff 205471 Mon Mar 22 19:22:48 MDT 2010 delphij Update to zlib 1.2.4 and add versioned symbols to the
library.

Sponsored by: iXsystems, Inc.
diff 205305 Thu Mar 18 22:37:30 MDT 2010 delphij Merge changes from zlib 1.2.4. Bump shared library version number.
205194 Mon Mar 15 18:14:07 MDT 2010 delphij Vendor import of zlib 1.2.4 (trimmed).
/freebsd-9.3-release/lib/libz/contrib/asm686/
H A DREADME.686diff 205471 Mon Mar 22 19:22:48 MDT 2010 delphij Update to zlib 1.2.4 and add versioned symbols to the
library.

Sponsored by: iXsystems, Inc.
diff 205305 Thu Mar 18 22:37:30 MDT 2010 delphij Merge changes from zlib 1.2.4. Bump shared library version number.
205194 Mon Mar 15 18:14:07 MDT 2010 delphij Vendor import of zlib 1.2.4 (trimmed).

Completed in 524 milliseconds

1234567891011>>