2007年2月14日星期三

Linux 網路資源

（一）Linux Kernel相關網站：由於大陸研究LINUX風氣比台灣盛行，因此找到的網站大多為大陸地區。
　　　 (1) lxr.linux.no/source/
　　　 　可看到每一版本Linux Kernel的原始碼及版本之間的比較、容易找到函數或變數定義之處。

　　　 (2) Linux原始碼目錄樹結構 (大陸網站)

　　　 (3) joyfire linux筆記（網址為 http://www.joyfire.net/ 或 http://joyfire.net/ ）
　　　 　將大陸方面有關Linux Kernel V2.4 研究的資訊做有系統的整理，但有些部份太過簡略。

　　　 (4)Welcome to OldLinux（網址為 http://www.oldlinux.org/ 或 http://www2.oldlinux.org/ ）
　　　　資料提供者為上海同濟大學【趙炯博士】，針對LINUX 0.11版做完整的解說。
　　　　讀者可能認為LINUX 0.11版有研究的價值嗎？趙炯博士認為「早期Linux Kernel程式碼
　　　　就是目前所使用最新Kernel的一個精簡版本，有人拿此當做嵌入式系統的核心」。
　　　　繁體版　"Linux Kernel完全剖析"書籍已上市

　　　 (5)中國LINUX論壇 (大陸網站)
　　　 　有許多 Linux Kernel 部份的討論資料，簡體、繁體字皆通用。
　　　 　在『技術論壇』中藏有許多高手，可以幫忙解決問題，像站長曾經提問過，不到兩天就解決了。

　　　 (6)永遠的UNIX (大陸網站)
　　　 　有各種作業系統、程式語言、資料庫、網路等電腦資訊。

　　　 (7) http://hira.main.jp/wiki/
　　　 　日本網站，針對 Linux Kernel V2.6.10 及 V2.4.18 程式做解說，可以利用線上翻譯
　　　　　http://www.excite.co.jp/world/chinese/web/ 翻成中文、英文、韓文。

　　　 (8)Developing Your Own OS on IBM PC (大陸網站)
　　　 　作者將這本書【Developing Your Own OS on IBM PC】部份內容釋出。

　　　 (9)Linux Study Notes
　　　 　將Linux Kernel API分門別類，但不知使用那一版的Linux Kernel。

　　　 (A)LinuxMM - linux-mm.org Wiki
　　　 　Linux Memory Management介紹。

　　　 (B)內核之旅 (大陸網站)
　　　 　Linux Kernel介紹（有些不錯的電子書）。

　　　 (C)KernelNewbies
　　　 　Linux Kernel 相關文件。

（二）文件：下載時需小心電腦病毒、著作權、合法性等問題
　　　 (1)Operating System Design - Linux
　　　 　 Linux Kernel 開機流程完整介紹。

　　　 (2) Linux i386 Boot Code HOWTO
　　　 　電子書，針對原始碼提供虛擬碼或代碼的解說。對於make檔、Kernel Build、SMP Boot、LILO、
　　　 　GRUB過程有詳細說明。

　　　 (3)Linux內核情景分析
　　　 　電子書分成上下兩冊，針對Linux Kernel 2.4版做解說 。

　　　 (4) Linux Kernel 中文版(失鏈中)　　　 Linux Kernel 中文版

　　　 (5) Linux Kernel 2.4 Internals (PDF檔)

　　　 (6) IA-32 IntelR Architecture Software Developer's Manual Volume 3: System Programming Guide 簡體字版 (PDF檔)
　　　 　目前翻譯完成第1、2、3、4、5、7、11、12章，需花點時間找尋。

　　　 (7) Linux HOWTO 中文索引 (簡體版)

　　　 (8) Memory Management in Linux
　　　 　 針對 Linux Kernel 有關記憶體部份，從頭開始做程式碼解說。

　　　 (9) Linux運行時內核分析第三、四版（PDF檔）--- 大陸網站(失鏈中)

　　　 (A) Netfilter hacking howto 簡體版(失鏈中)

　　　 (B)Understanding the Linux Kernel 3rd Edition
　　　 　電子書，內容包括 Linux Kernel V2.6 。

　　　 (C)Understanding Linux Network Internals中文翻譯計劃 (大陸網站)
　　　 　電子書，計劃將英文版翻成中文。

　　　 (D)Linux Device Drivers, Third Edition
　　　 　Linux Device Drivers 第三版，第一、二版的簡體版可在 KernelTech(Linux內核技術)找到。

　　　 　Linux Device Drivers 第三版(簡體中文版)(失鏈中) 　 　簡體中文版、RAR檔

　　　 (E)Linux IP Networking(失鏈中)
　　　 　介紹 Linux IP Networking For 2.2.14 版。

　　　 (F)Unreliable Guide To Locking 　　中文翻譯（簡體字、pdf檔）
　　　 　介紹 The Locking systems in the Linux Kernel V2.6。

　　　 (G) The Linux@ Networking Architecture: Design and Implementation of Network Protocols in the Linux Kernel
　　　 　介紹 Linux 網路架構(包括設計、做實作)。

　　　 (H) Hardware Data and Specifications
　　　 　介紹各種電腦硬體規格 。

　　　 (I) VGA Function Specification GXm/MXi Processors (PDF檔)
　　　 　介紹ＶＧＡ規格 。

　　　 (J)Online Books
　　　 　有許多與 Linux 相關的線上書籍。

　　　 (K)Man手冊中心 (大陸網站)
　　　 　有Linux、BSD、Unix等各類手冊、文件。

　　　 (L)Input/Output Base Address
　　　 　I/O Port功能簡介。

（三）DIY Linux 系統：
　　　 (1)Linux From Scratch 中文用戶組 (大陸網站)
　　　 　Linux From Scratch V6.1.1 簡體版。

　　　 (2)BabyLinux (大陸網站)
　　　 　一個很小的Linux系統。

　　　 (3)Jollen 網路學院
　　　 　Embedded Linux專區。

　　　 (4)Linux設備驅動開發工具光碟第一版 (大陸網站)
　　　 　Linux設備驅動開發工具光碟介紹。　下載光碟

（四）Linux網站：
　　　 (1)OSRC: The Operating System Resource Center
　　　 　The Operating System 電腦各項軟硬體資源介紹。

　　　 (2)肥肥世家
　　　 　介紹開源技術的網站，有大量的Linux、Python、Zope 等教學資料。

　　　 (3)Huihoo.com-GNU/Linux (大陸網站)
　　　 　Linux系統、常見軟體、教學等。

　　　 (4)EOS Lab
　　　 　Linux Kernel部份介紹。

　　　 (5)KernelStudy
　　　 　Linux Kernel介紹。

　　　 (6)developerWorks Linux (大陸網站)
　　　 　IBM有關developerWorks Linux專欄。

　　　 (7)阿卡主頁 (大陸網站)
　　　 　不少 Linux 教學資料。

（五）Linux 入門（新增在2006/03/25）：下載時需小心電腦病毒、著作權、合法性等問題
　　　 (1)Linux新手管理員指南 (簡體字版、PDF檔)
　　　 　Linux Newbie Administrator Guide 的中文譯本

　　　 (2)Fedora 中文用戶 (大陸網站)
　　　 　Fedora教學等相關資料

　　　 (3)VMware虛擬安裝 Fedora Core 4.0 手冊 (大陸網站)
　　　 　在Windows系統下，使用VMware安裝Fedora Core 4.0

　　　 (4)Fedora Core2 安裝線上教學
　　　 　Fedora Core2安裝教學動畫

　　　 (5)圖解 Fedora Core 5安裝 (大陸網站)
　　　 　Fedora Core5 安裝教學

　　　 (6)紅帽企業 Linux 4 (大陸網站)
　　　 　RedHat Linux 安裝教學(x86、Itanium、AMD64、IntelR EM64T)

（六）MIPS處理器（新增在2006/09/29）：下載時需小心電腦病毒、著作權、合法性等問題
　　　 (1)See MIPS Run (簡體字版、大陸網站)
　　　 　See MIPS Run 中文譯本，此書對MIPS處理器有詳細介紹。

（七）模擬器（新增在 2006/10/01）
　　　 (1)盒子裡的世界 (大陸網站) ：各類平台模擬器介紹。

　　　 (2)SkyEye ：介紹 、安裝與使用

　　　 (3)ARMware ：ARM 模擬器。
（八）Linux Kernel 書籍（新增在 2006/10/07）
　　　 (1)Linux Kernel完全剖析 ：針對 Linux Kernel 0.11版做完整介紹。

　　　 (2)Linux Core Kernel 程式碼解說 ：針對 Linux Kernel 2.2.5 版做介紹。

　　　 (3)Linux內核情景分析 (簡體版) ：針對 Linux Kernel 2.4.0 版做介紹。

　　　 (4)Linux核心程式設計 ：針對 Linux Kernel 2.4 版做介紹。

　　　 (5)The Linux Kernel Primer中文版 ：在 X86與 PowerPC 兩種平台下，對 Linux Kernel 2.6 版做介紹。

　　　 (6)Linux 核心詳解 (Understanding the Linux Kernel) 第三版 ：對 Linux Kernel 2.6 版做介紹。
　　　　 第一版：針對 Linux Kernel 2.2 版做介紹。
　　　　 第二版：針對 Linux Kernel 2.4 版做介紹。　　　　簡體版(tar.gz檔 )

(九) 其他 http://www.topology.org/soft/lkernel.html
linux kernel source and news

linkscomments
www.kernel.org The Linux kernel archives. This is where you get the linux kernels. Of course, it's best to use the kernel.org mirrors for full kernel download. Remember to check the crypto dignature. (Here's the Australian mirror for linux kernel source [actually a multiply-defined DNS entry for more than one actual website].)
LinuxHQ The LinuxHQ web site tries to organize and catalog many of the Linux related kernel patches in one central location. Also, this site maintains an active archive of the linux-kernel mailing list, as well as some other useful Linux information. Has useful HOWTOs and other documentation. Includes kernel module programming.
kernel traffic Linux kernel news. Used to be at kt.linuxcare.com. This is a weekly newsletter covering some activities of linux-kernel. Linux-kernel is the kernel development mailing list, where Linus Torvalds, Alan Cox and a lot of other amazing programmers from around the world share patches, argue about implementation details, discuss the news of the day, and generally make history. (Even earlier, this used to be at www.kt.opensrc.org.)
kerneltrap.org Slashdot-similar (but much better-looking) news site about linux kernel issues. Includes HowTo Upgrade To The 2.6 Kernel.
OSDL Open Source Development Labs. A commercially funded group of linux developers and promoters including Linus Torvalds (from December 2003). Here's a nice 2004-2-9 article about OSDL at NewsForge.
LANANA The Linux Assigned Names And Numbers Authority. Similar to IANA, but maintains a global register of shared name and number spaces for things like block and character device names and numbers. See also Linux Standard Base.
wwol26 The Wonderful World of Linux 2.6. A preview by Joseph Pranevich of forthcoming linux 2.6 features. This is very useful and clearly written. See also Dave Jones' document on linux 2.6.
2.6 improvements 2004-2-19: Improvements in kernel development from 2.4 to 2.6. By Paul Larson at www-106.ibm.com.

linux kernel documentation and tutorials

linkscomments
Linux Kernel HOWTO New in March 2003. This is a very useful-looking user-level manual, not a developer's manual, but the user-level stuff is a prequisite for developers anyway. See also the Boot prompt HOWTO, the LILO crash rescue HOWTO, the linux crash HOWTO, the Bootdisk HOWTO, diskless linux node HOWTO, and all the other linux HOWTO documents.
Kernel analysis HOWTO Useful info on linux kernel internals. See also the Linux 2.4.x Initialization for IA-32 HOWTO, the linux loadable kernel module HOWTO, the CPU design HOWTO, and the linux assembly language HOWTO.
Rusty's Remarkably
Unreliable Guides 		Includes his linux kernel hacking guide and kernel locking guide.
tux.org Tux.Org is an umbrella organization supporting the efforts of users groups and developers. I can't see what the real focus of this site is. Includes linux kernel mailing list FAQ, which includes how to prepare a kernel patch and an explanation of the `tainted' message in lsmod.
(The main problem with the tainted kernel strategy is that once you've loaded up just one kernel module which is not marked explicitly as GPL, there's no way to reverse the taint. So there's no motivation to stop loading up more and more tainting modules. Therefore this strategy is unlikely to achieve its objectives of dictating everyone's software licences. The other big problem is the fact that people are attracted to linux because of the desire for freedom. So taking away that freedom takes away the main advantage of linux. In other words, the linux kernel developers are scoring a goal for the opposition! It is offensive to developers of other faiths to require them to worship the Holy Anointed Software Licence as revealed to Saint Richard the Stubborn in the wilderness. There is more than one True Faith!)
kernelnewbies.org Introduction to the linux kernel. Sets a bad example for web design by using large graphics files, too many cookies and other annoyances. Includes the very useful-looking linux kernel API document. Also has Rusty's kernel hacking guide, Bus-Independent Device Accesses, and Rusty's kernel locking guide.
linux kernel internals Online manual by Tigran Aivazian (tigran@veritas.com) on the linux 2.4 kernel. See also this thedukeofurl.org review of linux 2.4.
migrating to kernel 2.6 2004-2-8: Article (part 1) at linuxdevices.com by William von Hagen on migration of drivers etc. to the 2.6 linux kernel. 2004-2-16: Here's part 2 on device driver porting. Apparently the hello-world program is much more complex than for linux 2.4. And here's part 3: Converting an existing development system to the 2.6 kernel.
2.4-2.6 changes An O'Reilly article on things which will disappear from the linux kernel between linux 2.4 and 2.6. See also this LWN article on workqueues, which will replace task queues.
tldp.org The Linux Documentation Project. Includes the very useful LDP guides. See especially Ori Pomerantz's linux kernel module programming guide.
wikipedia article 2004-6-5: A nice single-page article introducing the linux kernel for a general audience. (Unfortunately it perpetuates the annoying fallacy that the linux is just part of the gnu software development environment.)
linux VM Documentation of the linux 2.4 virtual memory system.
David Rusling's book An online book on the linux kernel 2.0.33 at linuxdoc.org.
Michael Johnson's book An online book on the 1.x.y linux kernels?
device driver tutorial Linux Planet tutorial: `Linux Device Drivers Demystified.'
porting to 2.2 Richard Gooch's info on porting 2.0 kernel modules to 2.2. See also his notes on porting to 2.3. See also linux kernel newsflashes.
Alan Cox article Alan Cox article at O'Reilly Books on porting 2.0 kernel modules to 2.2. There is also a second article in the series.
LKM_HACKING Info on linux modules for kernel 2.2.x.
kernel book O'Reilly book on linux kernels 2.2 and 2.4 by Daniel P. Bovet and Marco Cesati.
linux.org LKM info Module HOWTO. How To Insert And Remove LKMs.
LDD Some sort of brief summary of linux kernel development.
linux boot 2005-2-12: IBM article: Migrating from x86 to PowerPC, Part 2: Anatomy of the Linux boot process. Has diagrams of the linux boot process.

firewall and packet filtering software

linkscomments
netfilter.org Includes the Linux 2.4 Packet Filtering HOWTO which explains iptables. (This website used to be at netfilter.samba.org.)
Tigran Aivazian article About new security features in linux 2.4. See also this article.

tools for developing portable device drivers

linkscomments
Uniform Driver Interface Portable device driver interface for OSs including linux, UnixWare 7, HP-UX, and Compaq Tru64 UNIX.
jungo.com Software to develop portable device drivers. [...] enables developers to quickly create custom device drivers that can run on a multitude of operating systems without modification. ... source compatible to Solaris, Windows 2000/NT, 98/95, Windows CE, NT Embedded, OS/2 and VxWorks. WinDriver for Linux automates and simplifies the development of user mode Linux device drivers for PCI/CardBus/ISA/PMC/PCI-X/PCI-104 and CompactPCI. No OS internals knowledge or kernel level programming required. Made in Israel.

embedded, microcontroller and real-time linux variants

linkscomments
embedded linux requirements A 4-part article at linuxdevices.com about Identifying the top requirements for Embedded Linux systems, by Nicholas McGuire, March 9, 2002.
Xbox linux Xbox Linux makes use of all Xbox hardware and is based on common Linux distros with small modifications.
familiar.handhelds.org The Familiar Project is composed of a group of loosely knit developers all contributing to creating the next generation of PDA OS. Currently, most of our development time is being put towards producing a stable, and full featured Linux distribution for the Compaq iPAQ series of handheld computers, as well as apps to run on top of the distribution.
netsilicon.com Embedded software. 2004-4-11: They used to have some sort of linux-on-a-chip product with the label netlx. But it's disappeared.
the LART pages The LART is a small yet powerful embedded computer capable of running Linux. Its performance is around 250 MIPS while consuming less than 1 Watt of power. In a standard configuration it holds 32MB DRAM and 4MB Flash ROM, which is sufficient for a Linux kernel and a sizeable ramdisk image.
DSPLinux Commercial cross-compilation tools for linux on TI chips. DSPLinux from RidgeRun is the industry's first embedded Linux distribution targeted exclusively toward wireless, broadband and multimedia appliances built on DSPs, such as the new dual-core processors from Texas Instruments.
HA Linux This was apparently (according to slashdot) some sort of high availability linux distribution for embedded systems, developed by Motorola. I got this info in October 2000: Most of the developers of this at Motorola defected to form the Phoenix office of Monta Vista earlier this year. Motorola contracted Caldera or Lineo to produce CD-ROMs for them, and apparently Caldera/Lineo never really managed to deliver anything.
Monta Vista The Embedded Linux Experts. What they say is The immediately available preemptable kernel improves real-time application response from hundreds of milliseconds (worst case) to about twelve milliseconds.
RTLinuxFree
real-time linux Includes on-line manual
www.uclinux.org Linux/microcontroller project.
embedded linux devices The Embedded Linux "Cool Devices" Quick Reference Guide. At linuxdevices.com.
Lineo An embedded linux software company. Created by Caldera.

linux device drivers and device software

linkscomments
CESDIS linux NASA site with linux network drivers.
www.LinuxHardware.net Device drivers.
Lm_sensors `This is the home page for the effort of building and providing some essential tools for monitoring the hardware health of Linux systems.'
Soundblaster Soundblaster developers' page for linux.
linux-pp External Parallel Port devices and Linux.
scanner software Metalab.
kscan Scanner front end for KDE.
SANE back-ends If you unwisely bought a dexxa scanner like me, see the SANE dexxa query result. Also see Artec scanner backends, the ppscanimage_19990420.c and ppscan990326.c programs for linux/BSD dexxa scanning, Artec AS6E backend info, and Artec USA.

related links

linkscomments
C++ in kernel 2004-10-28: Reykjavík University: We have implemented a complete kernel level run-time support for C++ in the Linux kernel. In particular our run-time support enables the full use of C++ exceptions in the Linux kernel, but notably also includes support for global constructors and destructors, and dynamic type checking.
gnu coreutils 2005-6-18: Includes fileutils, shellutils, and textutils. See also coreutils manual. See also FSF coreutils download page.
Xen 2004-11-6: The Xen virtual machine monitor. Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Xen is Open Source software, released under the terms of the GNU General Public License. We have a fully functional ports of Linux 2.4 and 2.6 running over Xen, and regularly use it for running demanding applications like MySQL, Apache and PostgreSQL. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS.
LTSP 2005-1-27: Linux Terminal Server Project.
coLinux 2004-4-13: Some el-wierdo software which allows the linux kernel to run natively on an MS-Windows box. Cooperative Linux allows one to freely run Linux on Windows 2000/XP, without using a commercial PC virtualization software such as VMware, in a way which is much more optimal than using any general purpose PC virtualization software. See also this linuxworld.com article about coLinux.
Sebek An article about some software which is run inside the kernel on a honeypot machine to break session encryption. Includes an article (PDF).
IRQ priorities Part of a document by Eugene Blanchard stating that the order of IRQ priorities is 0, 1, 2, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7. So 7 has the lowest priority?
irqtune A Linux IRQ Priority Optimizer. This also explains why PPP/serial sometimes loses bytes because of overruns.
IP alias 2005-1-11: Mini How-to on Setting Up IP Aliasing On A Linux Machine by Harish Pillay.
Go to general linux links.
Go to linux file systems, benchmarks and devfs.
Go to linux bugs and vulnerabilities.
Go to CPU information.
Go to SCSI information and hardware.
Go to my notes on SuSE firewall.
Go to compilers for linux.
Go to linux in not gnu/linux.
Go to other software links.
Go to Alan Kennington's home page.
发帖者 时间： 没有评论:
标签：

API changes in the 2.6 kernel series

The 2.6 kernel development series differs from its predecessors in that much larger and potentially destabilizing changes are being incorporated into each release. Among these changes are modifications to the internal programming interfaces for the kernel, with the result that kernel developers must work harder to stay on top of a continually-shifting API. There has never been a guarantee of internal API stability within the kernel - even in a stable development series - but the rate of change is higher now.

This article will be updated to keep track of the internal changes for each 2.6 kernel release. Its permanent location is:

http://lwn.net/Articles/2.6-kernel-api/

This page will, doubtless, remain incomplete for a while. If you see an omission, please let us know by sending a note to kernel@lwn.net rather than by posting comments here. The chances of a prompt update are higher, the article will not become cluttered with redundant comments, and we'll be more than happy to credit you here.

If you are a Linux Device Drivers, Third Edition reader looking for information on changes since the book was published: LDD3 covers version 2.6.10 of the kernel, so only the changes starting with 2.6.11 are relevant.
发帖者 时间： 没有评论:
标签： ,

基于USB2.0的MPEG视频卡的设计与实现

通用串行总线(Universal Serial Bus，即USB)以其方便的即插即用和热插拔特性，以及较高的传输速率，成为PC领域广为应用的外设连接规范。目前，国内外普遍采用的是USB1.1规范，它支持两种传输速率：1.5Mbps和12Mbps，主要应用在低速传输要求的场合。2000年发布的USB2.0规范提供了480Mbs的传输速率，以满足更快的数据传输要求。

为了使MPEG视频卡快速地向PC机传送大量的数据，我们在设计MPEG视频卡与PC机的接口时采用USB2.0技术。对USB的设计与开发，我们是基于CYPRESS公司的EZ-USB FX2系列的CY7C68013芯片及其FX2开发包。

1、硬件设计

传统的采用PCI接口的MPEG视频卡, 不但占用了有限的PCI插槽，安装不方便，而且不支持热插拔和即插即用。所以，在本设计中，我们选用USB2.0接口芯片对传统的MPEG视频卡进行了改进。

改进后的USB2.0接口的方案如图1所示。

该USB2.0接口的MPEG视频卡的工作原理为：音视频信号经AK4550音频处理芯片及AA7113视频处理芯片进行A/D转换，将模拟信号转换成8bit的PCM格式的数字信号，传入SZ1510音视频压缩采集芯片进行处理，将编码调制PCM格式的数据转化为符合格式MPEG-1的混合影视文件，最后MPEG-1数据经USB接口芯片送给PC机作进一步的处理，如存储、显示等。

设计中，我们选用的USB接口芯片是EZ-USB FX2 系列的CY7C68013芯片。该芯片是针对USB2.0的，而且和USB1.1兼容，它支持两种传输速率：全速（Full_speed）12Mbps和高速（High_speed）480Mbps，它不支持低速(Low_speed)1.5Mbps。该芯片的内部结构如图2所示。

CY7C68013-128AC内部集成了一个增强的8051内核，它既与标准的8051兼容，又有诸多的改进：最高工作频率48MHZ，一个指令周期只需4个时钟周期，比标准的8051平均提高了2.5倍；2个UARTS端口；3个定时/记数器；扩展的中断系统及其更多I/O口等。CY7C68013内部集成的USB2.0的SIE能完成大部分USB2.0协议的处理工作，减少了用户对繁杂的USB协议的处理。另外，用户在开发时，可以利用GPIF和FIFO方式实现与高速外围设备之间的逻辑连接，并进行高速数据的传输。在该改进方案中，我们选用的是GPIF方式，实现和Z1510之间的通信。

2、软件设计

USB 软件设计包括三方面的工作：固件（Fireware）设计，驱动程序设计和主机端应用程序的设计。

（1）固件设计

设计中，我们考虑到MPEG视频卡要求快速地持续地传送大量数据，并对数据的完整性要求不太高，我们采用ISO传输方式。另外，我们让CY7C68013工作在GPIF模式下的FIFO Read方式，最多可以传输4G byte（WORDWIDE=0）或word（WORDWIDE=1）。外设的数据由于不需8051的处理，我们采用自动打包的方式（AUTOIN=1），直接从FIFO到SIE，这样有利于提高传输速率。其主要实现代码如下：

void TD_Init( )
{
CPUCS = 0X01; 　　　file://CLKSPD[1:0]=10; for 48MHz operation.
GpifInit( );
……
SYNCDELAY;
EP6CFG = 0XDA; 　　　file://端点配置： 同步IN方式、缓冲大小1024字节
SYNCDELAY;
FIFORESET = 0X80; 　　// activate NAK_ALL to avoid race conditions
SYNCDELAY;
FIFORESET = 0X06; 　 file://reset, FIFO 6
SYNCDELAY;
FIFORESET = 0X00; 　 file://deactivate NAK_ALL

SYNCDELAY;
EP6FIFOCFG = 0X0D; file://wordwide=1
SYNCDELAY;
……
}

（2）驱动程序设计

在WINDOWS平台下，USB 驱动程序由三部分组成：USB设备驱动程序，USB总线驱动程序和USB主控制器驱动程序，它们必须遵循WIN32驱动程序模型（WDM）。其中，WINDOWS操作系统已经提供了处于驱动程序栈底的USB总线驱动程序和USB主控制器驱动程序。而USB设备驱动程序由设备开发者编写，它通过向USB总线驱动程序发送包含URB（USB? Request Block）的IRP(I/O Request Packet)，来实现USB外设之间的信息交换。当主机应用程序要对USB设备进行I/O操作时，它调用Windows API函数对Win32子系统进行Win32调用，由I/O管理器将此请求构造成一个合适的IRP，并把它传递给USB设备驱动程序。USB设备驱动程序接受到这个IRP后，根据IRP中包含的具体操作代码，构造响应的URB并把它放到一个新IRP中，然后把此IRP传递到USB总线驱动程序，USB总线驱动程序根据IRP中所包含的URB执行响应的操作，并把操作结果通过IRP返还给USB设备驱动程序。USB设备驱动程序接受到此IRP后，将操作结果通过IRP返还I/O管理器。最后，I/O管理器将此IRP中操作结果返还给应用程序，至此应用程序对USB设备的一次I/O操作完成。

开发USB设备驱动程序，可采用Numega公司的开发包Driver Works和 Microsoft公司的2000DDK，并以VC++6.0作为辅助开发环境。Driver Works提供的驱动向导,，可根据用户的需要，自动生成代码框架。减少了开发的难度，缩短了开发的周期。

在CYPRESS公司的EZ-USB FX2开发包中，有一个通用的驱动程序，该程序可不加修改经DDK编译后直接使用。在本设计中，由于时间关系，我们采用的就是这个通用驱动程序（GPD）。

（3）应用程序设计

USB主机应用程序是计算机中完成特定功能的程序，其关键是实现从USB 外设读取或发送特定数量的数据，USB标准设备请求和特定的命令等。另外，可以对数据做进一步的处理，如：存储、显示、快速傅立叶变换等。在WINDOWS 2000下，我们所使用的应用程序开发工具是VC++6.0。

3、结束语

该卡是对传统的PCI接口的MPEG视频卡的改进，它支持热插拔和即插即用。由于采用USB2.0接口，其传输速率也高于后者，满足了数据高速传输的要求，解决了USB1.1存在的传输瓶颈。相信随着各大电脑主板商对USB2.0的支持，USB2.0必将在PC机应用的各个领域得到广泛的应用。

发帖者 时间： 没有评论:
标签：

数字视频压缩的大容量记录系统设计

作者：空军工程大学 陈国庆 张登福 寇明延

摘要 介绍用ARM7微控制器LPC2214和MPEG-1压缩芯片SZ1510实现数字视频压缩记录的嵌入式系统。SZ1510在LPC2214的控制下，完 成音频和视频数据的实时压缩和码流合成，LPC2214同时完成码流的传输和存储控制。利用LPC2214的I/O端口实现IDE接口的扩展，可直接驱动 大容量硬盘和CF存储卡。

关键词 ARM MPEG-1嵌入式系统 数字视频

引言

　　随着计算机技术、多媒体和数据通信技术的迅速发展，数字视频的应用越来越广，如视频监控、视频会议和移动电视等。数字视频数据量巨大，不利于传 输和存储，使其应用受到很大限制。为解决视频数据的存储和传输问题，唯一的途径就是对视频数据进行压缩。常见的视频压缩方法有MPEG系列和H.26x系 列。考虑到压缩技术的成熟度、成本和主要用途，采用MPEG-1作为压缩标准，设计出基于ARM处理器的嵌入式数字视频记录系统。该系统适用于视频监控、 视频会议等多种应用场合，同时还可安装在飞行器上，用于实时记录飞行器的飞行及训练过程中的各种信息。

　　目前，市场上有大量的基于PCI总线的MPEG-1视频压缩卡和PC机构架的网络视频服务器。与之相比，我们设计的视频记录系统具有成本低、体积小和功耗低等优势。

1 系统工作原理

　　视频压缩记录系统的设计着眼于控制器的嵌入化和整体的便携性。本系统主要由3部分组成，即压缩部分、控制部分和存储部分。视频记录系统的结构组 成如图1所示。其中压缩部分由MPEG1音视频压缩电路组成，主要功能是实现对输入的音视频信号解码、数字化和压缩编码，产生MPEG1程序流和传输流； 控制部分由ARM最小系统组成，用于实现对整个系统的控制、数据流管理和IDE接口控制；存储部分由大容量硬盘或CF存储卡组成，实现对压缩数据的实时长 时间记录。

　　系统启动时，ARM处理器对整个压缩系统进行初始化，首先通过HOST接口对SZ1510内部寄存器进行配置，并使用SZ1510的串行接口模 拟I2C总线对视频解码器SAA7113H进行初始化。当设置好MPEG-1的压缩格式及数据速率后，系统开始正常工作，音视频信号经AK4550音频处 理芯片和SAA7113视频处理芯片进行A/D转换，输出8位的PCM格式数字音频信号和4∶2∶0的YCbCr数字视频信号，传入SZ1510音视频压 缩采集芯片进行处理，将数字音视频数据转化为符合MPEG-1格式的混合影视文件，最后MPEG1数据流在ARM处理器的控制下通过IDE接口写入硬盘或 CF卡。在工作时，ARM还将不断监视相关信号，并在图像中加入相应的标志，直到接收到关机信号，系统自动结束压缩工作。

2 硬件电路设计

　　由于MPEG-1压缩算法需要很大的运算量，用软件实时完成比较困难，所以在本系统中主要依靠专用芯片实现对视频信号的高效压缩。目前，常用的 MPEG-1压缩芯片有VW2010、W99200F、WIS 7007SB等。本设计采用的是Zapex公司的SZ1510 MPEG-1 A/V编码芯片，自身完成音视频的同步编码，16位HOST接口易于与多种微处理器连接。另外，该芯片还可以直接控制视频解码芯片SAA7113H、音频 解码芯片AK4550VT和SDRAM（KM416S1020CT-G10）。CPU采用Philips公司的ARM7TDMIS内核微控制器 LPC2214，通过其I/O端口控制IDE接口硬盘或CF卡的数据读取和存储。


图1 数字视频记录系统结构框图

2.1 MPEG-1压缩电路设计

　　SZ1510是一个 MPEG-1和运动JPEG图像编码器。其内置的视频压缩核经过优化，适合高效、实时的MPEG1数字图像压缩，具有功能多、功耗低、温度范围宽等特点； 同时整合了TI公司的TMS320C54X高性能DSP内核，可依据MPEG-1标准对音视频同步编码。

（1） 时钟同步电路设置
　　SZ1510是一个复杂的视频压缩小系统，要完成音视频的同步，MPEG-1视频的压缩以及系统内部数据流 的复合、调度；时钟关系较为复杂，是系统设计的一个难点。时钟配置可分为主时钟、音视频时钟、视频压缩核时钟、DSP核时钟以及扩展的I2S接口时钟几部 分。其功能和关系为：
　　◆ 主时钟。SZ1510的主时钟为稳定的27 MHz(CLK)。该时钟在芯片内部被PLL1倍频为81 MHz，驱动SZ1510的视频压缩核及SDRAM。PLL2连到DSP内核，通过软件配置使其工作在94.5 MHz，用于音频压缩和系统数据流复合。
　　◆ 音视频时钟。视频时钟来自视频解码器，典型值为27 MHz。音频时钟由视频时钟分频产生。
　　◆ I2S接口时钟。本系统中在音视频同步设计中使用I2S接口的从模式，由SZ1510产生串行时钟和帧同步信号。

（2） 主机（HOST）端口设置
　　SZ1510作为从设备，受主机控制，其HOST接口是SZ1510的控制和数据交换接口。 SZ1510可以选择复用或不复用的Intel和Motorola总线类型；不复用总线，又可以分为8位和16位。具体的主机端口由HCONFIG [1∶0]引脚和SysConfig[3]寄存器配置。在本系统设计中，通过跳线把HCONFIG0拉低，HCONFIG1拉高，使其工作在Intel 8051类型的非复用的16位数据总线模式下。

2.2 LPC2214微处理器电路设计

　　LPC2214是一款基于32位ARM7TDMI-S，支持实时仿真和跟踪的CPU；带有16 KB片内SRAM、256 KB嵌入的高速Flash存储器、128位宽度的存储器接口和独特的加速结构，使32位代码能够在最大时钟速率60 MHz下运行。芯片内部集成了多种串行接口。LPC2214与SZ1510的接口和控制关系如图2所示。在设计中，需要注意的是保持SZ1510读写时序 与内部时钟的同步。通过CS3选通SZ1510实现控制字和数据的交换。


图2 LPC2214与SZ1510的接口关系

2.3 IDE接口设计

　　由于LPC2214芯片不具备IDE接口，因此在本系统中使用通用I/O 口，模拟产生ATA 设备的读写时序，实现对IDE硬盘的可靠读写操作。图3为LPC2214与IDE硬盘连接图。其中，P2.16～P2.31作为数据线， P1.16～P1.20作为地址和选通信号，P0.17和P0.20为设备的复位和状态请求信号，用P0.21和P0.19实现读写控制。


图3 LPC2214与IDE硬盘连接图

3 系统软件设计

　　系统软件由主程序和若干个子程序组成，工作流程如图4所示。主要的子模块有：SZ1510 的设置与控制、IDE接口驱动和文件系统的管理。


图4 系统工作流程

3.1 SZ1510的设置与控制

　　SZ1510共有128个寄存器，每个寄存器都有一个索引号。当SZ1510工作在非复用总线模式下时，外界对寄存器的访问都是通过IOAR和IODR来完成的。访问时首先将这个寄存器的索引号写入IOAR，然后将要写的数据写入IODR。

　　SZ1510设置与控制过程如下：
　　① 向中断使能寄存器写入0x40，以使能Ready中断；
　　② 等待SZ1510的Ready中断；
　　③ 等到Ready中断后，向SZ1510的0x1E寄存器写入0x0A，设置它内部的DSP时钟为94.5 MHz；
　　④ 向0x013寄存器写入0x55，对SZ1510进行软复位；
　　⑤ 向中断使能寄存器0x0C写入0x40，以使能Ready中断；
　　⑥ 等候RDY中断；
　　⑦ 待Ready中断后对SAA7113进行初始化；
　　⑧ 对SZ1510进行软复位，即向0x0B寄存器写入0x55，同时向0x0C寄存器写入0x40；
　　⑨ 等待Ready中断，等到后向SZ1510的内部DSP装载二进制代码；
　　⑩ 进行SZ1510内部视频压缩核的二进制代码装载，具体装载步骤如下：

　　◆ 向0x08寄存器写0x04，发送开始命令；
　　◆ 等待Ready中断，清除Ready中断；
　　◆ 向Data in寄存器0x01写256个字节；
　　◆ 等待End of Data中断，然后清除中断；
　　◆ 查程序空间的代码是否装载完毕，如没有，则继续装载。

3.2 IDE接口驱动

　　本系统采用LPC2214的通用可编程I/O口模拟ATA设备的读写时序，实现对硬盘的读写。这里给出模拟写ATA 设备寄存器的步骤（读ATA设备寄存器的步骤类似）：

　　① 关系统中断，预防在写寄存器操作中产生中断；
　　② 设置GPIO 模拟ATA 接口数据的引脚为输出状态，准备输出数据到设备数据线；
　　③ 设置ATA 设备寄存器的相应地址；
　　④ 设置GPIO 模拟ATA 接口数据的引脚电平为要写到设备的值；
　　⑤ 使写ATA 设备寄存器信号为低电平；
　　⑥ 使写ATA 设备寄存器信号为高电平；
　　⑦ 取消ATA 设备寄存器地址的选择；
　　⑧ 设置GPIO 模拟ATA 接口的数据总线引脚为输入状态，释放总线；
　　⑨ 开系统中断。

3.3 文件系统管理

　　本设计中采用的是面向嵌入式系统的小型文件系统ZLG/FS [1]，主要用于将数据存储为标准的文件格式和对整个文件系统的管理。同时，为了便于音视频的检索和查询，以及防止非法断电造成大量未保存数据的丢失，在 系统中设置了每间隔一定的时间（30 min）将压缩数据存储在以系统时间命名的新文件里。

4 结论

　　经测试，系统可实时长时间记录外部的音视频信号，记录的压缩数据流符合MPEG-1图像压缩国际标准。在设计中，采用的压缩视频流速率为1.5 Mbps，1小时的视频数据量为(1.5 Mbps/8)×3 600=675 MB，对于一个40 GB的硬盘，系统连续记录时间接近60小时。系统体积小、功耗低，便于移动环境下对音视频数据的实时长时间压缩记录。


发帖者 时间： 没有评论:
标签：

2007年2月11日星期日

Linux Kernel Document 

http://old.kernelnewbies.org/documents/kdoc/
http://www.aoc.nrao.edu/~tjuerges/ALMA/Kernel/

[TXT] deviceiobook.html       21-Aug-2006 15:56   60
[DIR] deviceiobook/           21-Aug-2006 15:56    -
[TXT] gadget.html             21-Aug-2006 16:03   48
[DIR] gadget/                 21-Aug-2006 16:03    -
[TXT] journal-api.html        21-Aug-2006 16:03   58
[DIR] journal-api/            21-Aug-2006 16:03    -
[TXT] kernel-api.html         21-Aug-2006 16:03   56
[DIR] kernel-api/             21-Aug-2006 16:03    -
[TXT] kernel-hacking.html     21-Aug-2006 15:56   64
[DIR] kernel-hacking/         21-Aug-2006 15:56    -
[TXT] kernel-locking.html     21-Aug-2006 15:56   64
[DIR] kernel-locking/         21-Aug-2006 15:56    -
[TXT] libata.html             21-Aug-2006 16:03   48
[DIR] libata/                 21-Aug-2006 16:03    -
[TXT] librs.html              21-Aug-2006 16:03   46
[DIR] librs/                  21-Aug-2006 16:03    -
[TXT] lsm.html                21-Aug-2006 16:03   42
[DIR] lsm/                    21-Aug-2006 16:03    -
[TXT] mcabook.html            21-Aug-2006 15:56   50
[DIR] mcabook/                21-Aug-2006 15:56    -
[TXT] mtdnand.html            21-Aug-2006 16:03   50
[DIR] mtdnand/                21-Aug-2006 16:03    -
[TXT] procfs-guide.html       21-Aug-2006 15:56   60
[DIR] procfs-guide/           21-Aug-2006 15:56    -
[TXT] rapidio.html            21-Aug-2006 16:04   50
[DIR] rapidio/                21-Aug-2006 16:04    -
[TXT] sis900.html             21-Aug-2006 15:56   48
[DIR] sis900/                 21-Aug-2006 15:56    -
[TXT] usb.html                21-Aug-2006 16:03   42
[DIR] usb/                    21-Aug-2006 16:03    -
[TXT] videobook.html          21-Aug-2006 15:56   54
[DIR] videobook/              21-Aug-2006 15:56    -
[TXT] wanbook.html            21-Aug-2006 15:56   50
[DIR] wanbook/                21-Aug-2006 15:56    -
[TXT] writing_usb_driver.html 21-Aug-2006 15:56   72
[DIR] writing_usb_driver/     21-Aug-2006 15:56    -
[TXT] z8530book.html          21-Aug-2006 15:56   54
[DIR] z8530book/

发帖者 时间： 没有评论:
标签：

2007年2月5日星期一

The Linux USB Input Subsystem

PART I
http://www.linuxjournal.com/article/6396

By Brad Hards on Sat, 2003-02-01 02:00. Software As the USB input subsystem spreads further with each kernel release, it's time to understand what it's doing for your devices.

The Linux USB input subsystem is a single, harmonized way to manage all input devices. This is a relatively new approach for Linux, with the system being partly incorporated in kernel version 2.4 and fully integrated in the 2.5 development series.

This article covers four basic areas: a description of what the input subsystem does, a short historical perspective on development, a description of how the input subsystem is implemented in the kernel and an overview of the user-space API for the input subsystem and how you can use it in your programs. The first three areas are discussed in this article. The user-space API, the final topic, will be discussed in Part II of this article.

What Is the Input Subsystem?

The input subsystem is the part of the Linux kernel that manages the various input devices (such as keyboards, mice, joysticks, tablets and a wide range of other devices) that a user uses to interact with the kernel, command line and graphical user interface. This subsystem is included in the kernel because these devices usually are accessed through special hardware interfaces (such as serial ports, PS/2 ports, Apple Desktop Bus and the Universal Serial Bus), which are protected and managed by the kernel. The kernel then exposes the user input in a consistent, device-independent way to user space through a range of defined APIs.

How We Got Here

The Linux input subsystem is primarily the work of Vojtech Pavlik, who saw the need for a flexible input system from his early work on joystick support for Linux and his later work on supporting USB. The first integration for the input subsystem replaced existing joystick and USB drivers in the 2.3 development kernel series. This support carried over to version 2.4, and input support in the 2.4 series is basically limited to joysticks and USB input devices.

The 2.5 development kernel series fully integrates the input subsystem. This tutorial is based on the full integration, which will be the input API for the 2.6 stable kernel. Although some differences exist in the user-space APIs between 2.4 and 2.5 kernels at the time of this writing, there is ongoing work to harmonize them--mainly by updating the 2.4 kernel.

Under the Hood--Understanding the Kernel Internals

The three elements of the input subsystem are the input core, drivers and event handlers. The relationship between them is shown in Figure 1. Note that while the normal path is from low-level hardware to drivers, drivers to input core, input core to handler and handler to user space, there usually is a return path as well. This return path allows for such things as setting the LEDs on a keyboard and providing motion commands to force feedback joysticks. Both directions use the same event definition, with different type identifiers.

Figure 1. The Relationship between the Elements of the Input Subsystem

The interaction between various elements is through events, which are implemented as structures (see Listing 1). The first field (time) is a simple timestamp, while the other fields are more interesting. The type field shows the generic type of event being reported, for example, a key press or button press, relative motion (like moving a mouse) or absolute motion (like moving a joystick). The code field tells which of the various buttons or axes are being manipulated, while the value field tells you what the state or motion is. For example, if the type is a key or button, code tells you which key or button it is, and value tells you if the button has been pressed or released. Similarly, if type is a relative axis, then code tells you which axis, and value tells you how much motion you have and the direction of that motion on that axis. If you move a mouse in a diagonal direction, while simultaneously moving the scroll wheel, you will get three relative events per update: one for motion in the vertical direction (Y-axis), one for motion in the horizontal direction (X-axis) and one for motion of the wheel.

Listing 1. event-dev-struct.txt

Event handlers provide the interface to user space, converting the standard event format into the format required by a particular API. Handlers usually take care of the device nodes (/dev entries) too. The most common handler is the keyboard handler, which is the ``standard input'' that most programmers (especially C programmers) are familiar with.

Drivers usually interface with low-level hardware, such as USB, PCI memory or I/O regions, or serial port I/O regions. They convert the low-level hardware version of the user input into the standard event format before sending it to the input core. The input core uses a standard kernel plugin design, with input_register_device() used to add each device and input_unregister_device() used to remove it. The argument to these calls is the input_dev structure, which is shown in Listing 1. Although this structure looks quite large, most of the entries are provided to allow a driver to specify the capabilities of the device, such as which event types and codes may be sent or received by the device.

In addition to managing drivers and handlers, the input core also exports a useful /proc filesystem interface, which can be used to see what devices and handlers are currently active. Here is a typical example from /proc/bus/input/devices showing a USB mouse:

I: Bus=0003 Vendor=046d Product=c002 Version=0120
N: Name="Logitech USB-PS/2 Mouse M-BA47"
P: Phys=usb-00:01.2-2.2/input0
H: Handlers=mouse0 event2
B: EV=7
B: KEY=f0000 0 0 0 0 0 0 0 0
B: REL=103

The I: line is the identity information--showing bus type 3 (which is USB) and the vendor, product and version information from the USB descriptors in the mouse. The N: line shows the name, which in this case is a string provided by the USB descriptors. The P: line shows the physical device information; here, it's structure information comprised of the PCI address for the USB controller, the USB tree and the input interface. The input0 part indicates this is the first logical input device for the physical device. Some devices, such as multimedia keyboards, can map part of the physical device to one logical input device and map another part to a second logical input device. The H: line shows the handler drivers associated with this device; we'll discuss this in more detail later in the article. The various B: lines show the bitfields that identify the devices' capabilities, in this case some keys for the buttons and relative axes for the ball and the scroll wheel.

Listing 2. register.c

This /proc interface is a useful way to test some simple drivers. Let's consider the example of a driver that registers on init and unregisters on removal, as shown in Listing 2. This does some preliminary initialization using init_input_dev(). It sets up the name, physical and identification descriptors, and then sets up the bit arrays to indicate that the device is capable of providing one type of event (EV_KEY indicating buttons and keys) with two possible codes (KEY_A and KEY_B, indicating the key labels). The initialization routine then registers the device with the input core. If you add this code to the kernel (using modprobe), you can see the new device has been added to /proc/bus/input/devices, as shown below:

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="Example 1 device"
P: Phys=A/Fake/Path
H: Handlers=kbd event3
B: EV=3
B: KEY=10000 40000000

If we actually want to send events from our device driver to the input core, we need to call input_event or one of the convenience wrappers, such as input_report_key or input_report_abs, provided in . An example of code that does this is shown in Listing 3. This example is basically the same setup as the previous one, except that we add a timer that calls ex2_timeout(). This new routine sends four presses of KEY_A and four presses of KEY_B. Note that 16 key press events are created in total, because a separate event is created for each press and each release. These events are passed to the input core and, in turn, to the keyboard handler, which will cause the pattern ``aaaabbbb'' or ``AAAABBBB'', depending on the Shift key selection, to be transmitted to the console or command line. The timer is then set up to run four seconds later, looping infinitely. The four-second delay is intended to give you enough time to remove the module when you have seen enough of the pattern. If you reduce the delay, make sure you have another way of accessing the system, such as an SSH connection. Also note the call to the input_sync function. This function is used to inform the event handler (in this case, the keyboard handler) that the device has transmitted an internally consistent set of data. The handler may choose to buffer events until input_sync is called.

Listing 3. aaaabbbb.c

Let's look at one final example of a driver, this time showing how relative information is provided, shown in Listing 4. This example is a driver that emulates a mouse. The initial setup configures the device to have two relative axes (REL_X and REL_Y) and one key (BTN_LEFT). As in the previous example, we use a timer to run ex3_timeout. This timer then calls input_report_rel to provide small relative motion (five unit steps--the relative movement is the third argument to the function) consisting of 30 steps right, 30 steps down, 30 steps left and 30 steps up, so the cursor is moved in a square pattern. To provide the illusion of movement, the timeout is only 20 milliseconds. Again, note the call to input_sync, which is used to ensure that input handlers only process events that make up a consistent set. This specification wasn't strictly necessary in our previous example. But, it is definitely required to convey information like relative movement to the input core, because more than one axis may be required to represent movement. If you were moving diagonally, you would do something like:

...
input_report_rel(..., REL_X, ...);
input_report_rel(..., REL_Y, ...);
input_sync(...);
...

which ensures that the mouse will move diagonally and not across, then up.

Listing 4. squares.c

Handlers--Getting to User Space

In the previous section, we saw that the device drivers basically sat between the hardware and the input core, translating hardware events, usually interrupts, into input events. To make use of those input events, we use handlers, which provide a user-space interface.

The input subsystem includes most of the handlers you'll likely need: a keyboard handler to provide a console, a mouse handler for applications like the X Window System, a joystick handler for games and also a touchscreen handler. There is also a general-purpose handler called the event handler, which basically provides input events to user space. This means you almost never need to write a handler in the kernel, because you can do the same thing with the event handler and equivalent code in user space. This API discussion is covered in the second part of this article.

Acknowledgements

I'd like to thank Greg Kroah-Hartman and Vojtech Pavlik for their assistance with this article.



PART II

http://www.linuxjournal.com/article/6429


No matter how many buttons an input device has or how many kinds of events it can generate, you can now work with it from user space.

In last month's article, we saw how the Linux input subsystem worked inside the kernel, ending with a quick mention of the event handlers. Each handler essentially provides a different user-space API, converting input events into the particular format that makes up that API.

One of the key aspects of the input subsystem integration into Linux is the availability of the event interface. This basically exposes the raw events to userspace through a collection of character device nodes--one character device node per logical input device. The event interface is a really powerful technique, because it allows the manipulation of the events in userspace without information loss. For example, legacy mouse interfaces support only two relative axes and up to five buttons. These are normally mapped to the two real axes and three real buttons, with the fourth and fifth buttons logically being mapped to the scroll wheel up and scroll wheel down events.

However, this mapping becomes a problem when trying to use a mouse with a scroll wheel and more than three buttons, because any additional buttons can be mapped only to an existing button. The legacy APIs also impede use of advanced input devices, such as space balls and other devices' with many axes. By contrast, the event API provides full access to the devices capabilities, and it even includes a per-device description of those capabilities and other device characteristics.

This month's article focuses on the various ioctl capabilities of the event interface, in addition to the normal read and write calls.

Finding the Version of the Event Interface

The event interface supports determining the version of the event device code, using the EVIOCGVERSION ioctl function. The argument is an int (32 bits) and is meant to be interpreted as a major version (two high bytes), a minor version (third byte) and a patch level (low byte). The same value is returned from each event device on a machine.

An example of the EVIOCGVERSION is shown in Listing 1. The first argument to the ioctl function is an open file descriptor for the event device node (for example, /dev/input/event0). Notice that you have to pass a pointer to the integer variable, not the variable itself, as the third argument to the ioctl call.

Listing 1. Sample EVIOCGVERSION Function

Finding Information about the Device's Identity

The event interface supports retrieving information associated with the underlying device using the EVIOCGID ioctl. The argument is a pointer to an input_id structure; the input_id structure is defined as shown in Listing 2. The __u16 data type is a Linux-specific, unsigned 16-bit integer. You can safely cast it to a standard uint16_t in your code.

Listing 2. iput_id Structure Definitions

The bus type is the only field that contains accurate data. You should probably consider it to be an opaque, enumerated type, and compare it with the various BUS_x type definitions provided in . The vendor, product and version fields are bus type-specific information relating to the identity of the device. Modern devices (typically using PCI or USB) do have information that can be used, but legacy devices (such as serial mice, PS/2 keyboards and game ports on ISA sound cards) do not. These numbers therefore are not meaningful for some values of bus type.

An example of the EVIOCGID ioctl is shown in Listing 3. This example calls the ioctl and then prints out the results. The case logic shows all current bus types. Here is an example of running that code: vendor 045e product 001d version 0111 is on a Universal Serial Bus.

Listing 3. Sample EVIOCGID ioctl

In addition to the type of bus and the vendor, product and version information, some devices can provide strings that make up meaningful names. This can be obtained from the event interface using the EVIOCGNAME ioctl. This ioctl provides a string and returns the length of the string (or a negative error value). If the string is too long to fit into the argument, it will be truncated. An example is provided in Listing 4. If it seems strange that the argument is not &name, remember the name of an array is the same as a pointer to the first element. Therefore, &name would be a pointer to a pointer to the first element, which is not what we want. If you really want to use a dereference, use &(name[0]).

Listing 4. Example Trunctated String

Here is an example of running that event code:

The device on /dev/input/event0 says its name
   is Logitech USB-PS/2 Optical Mouse

Not all devices contain meaningful names, however, so kernel input drivers try to provide something meaningful. For example, USB devices without manufacturer or product strings concatenate the vendor and product ID information.

Although device identity and name information is often useful, it may not be sufficient information to tell which device you have. For example, if you have two joysticks that are the same, you may need to identify them based on which port they use. This is usually known as topology information, and you can get this from the event interface using the EVIOCGPHYS ioctl. Like EVIOCGNAME, this provides a string and returns the length of the string (or a negative error number). An example is shown in Listing 5; running that example will produce something like:

The device on /dev/input/event0 says its path
   is usb-00:01.2-2.1/input0

Listing 5. Using EVIOCGPHYS for Topology Information

To understand what this string is showing, you need to break it down into parts. The usb part means this is a physical topology from the USB system. The 00:01.2 is the PCI bus information for the USB host controller (in this case, bus 0, slot 1, function 2). The 2.1 shows the path from the root hub to the device. In this case, the upstream hub is plugged in to the second port on the root hub, and that device is plugged in to the first port on the upstream hub. input0 means this is the first event device on the device. Most devices have only one, but multimedia keyboards may present the normal keyboard on one interface and the multimedia function keys on a second interface. This topology example is shown in Figure 1.

Figure 1. Keyboard Topology

This setup doesn't help if you swap the cables on two identical devices. The only thing that can help in this case is if the device has some form of unique identifier, such as a serial number. You can get this information using the EVIOCGUNIQ ioctl. An example is shown in Listing 6. Most devices don't have such an identifier, and you will get an empty string from this ioctl.

Listing 6. Finding a Unique Identifier

Determining the Device Capabilities and Features

For some applications, it might be enough to know the device identity, because this would allow you to handle any special cases depending on what device is being used. However, it doesn't scale well; consider a case where you want to enable scroll wheel handling only if the device has a scroll wheel. You really don't want to have to list the vendor and product information for every mouse with a scroll wheel in your code.

To avoid this problem, the event interface allows you to determine which features and capabilities are available for a particular device. The types of features supported by the event interface are:

  • EV_KEY: absolute binary results, such as keys and buttons.

  • EV_REL: relative results, such as the axes on a mouse.

  • EV_ABS: absolute integer results, such as the axes on a joystick or for a tablet.

  • EV_MSC: miscellaneous uses that didn't fit anywhere else.

  • EV_LED: LEDs and similar indications.

  • EV_SND: sound output, such as buzzers.

  • EV_REP: enables autorepeat of keys in the input core.

  • EV_FF: sends force-feedback effects to a device.

  • EV_FF_STATUS: device reporting of force-feedback effects back to the host.

  • EV_PWR: power management events.

These are only the types of features; a wide range of individual features can be found within each type. For example, the EV_REL feature type distinguishes between X, Y and Z axes and horizontal and vertical wheels. Similarly, the EV_KEY feature type includes literally hundreds of different keys and buttons.

The capabilities or features of each device can be determined through the event interface, using the EVIOCGBIT ioctl. This function allows you to determine the types of features supported by any particular device, for example, whether it has keys, buttons or neither. It further allows you to determine the specific features that are supported, for example, which keys or buttons are present.

The EVIOCGBIT ioctl takes four arguments. If we consider it as ioctl(fd, EVIOCGBIT(ev_type, max_bytes), bitfield), then the fd argument is an open file descriptor; ev_type is the type of features to return (with 0 as a special case, indicating the list of all feature types supported should be returned, rather than the list of particular features for that type); max_bytes shows the upper limit on how many bytes should be returned; and bitfield is a pointer to the memory area where the result should be copied. The return value is the number of bytes actually copied on success or a negative error code on failure.

Let's look at a couple of examples of the EVIOCGBIT ioctl call. The first example, Listing 7, shows how to determine the types of features present. It determines how much memory is required for the bit array using evtype_bitmask, based on the EV_MAX definition in . The ioctl is then submitted, and the event layer fills in the bit array. We then test each bit in the array and show where the bit was set, which indicates the device does have at least one of this type of feature. All devices support the EV_SYN feature type in 2.5; the input core sets this bit.

Listing 7. Determining Features with EVIOCGBIT

When run, with a keyboard as the target, the example in Listing 7 produces:

Supported event types:
 Event type 0x00  (Synchronization Events)
 Event type 0x01  (Keys or Buttons)
 Event type 0x11  (LEDs)
 Event type 0x14  (Repeat)

With a mouse as the target, the example produces:

Supported event types:
 Event type 0x00  (Synchronization Events)
 Event type 0x01  (Keys or Buttons)
 Event type 0x02  (Relative Axes)


Retrieving Input from (and to) the Device

Having determined what capabilities a particular device has, you know what types of events it will produce and what types of events you can send.

Retrieving events from a device requires a standard character device ``read'' function. Each time you read from the event device (e.g., /dev/input/event0), you will get a whole number of events, each consisting of a struct input_event.

Listing 8. Checking for Busy Spots

The example shown in Listing 8 does a busy loop on the open file descriptor, trying to read any events. It filters out any events that don't correspond to keys and then prints out the various fields in the input_event structure. Running this while typing on my keyboard produced:

Event: time 1033621164.003838, type 1, code 37, value 1
Event: time 1033621164.027829, type 1, code 38, value 0
Event: time 1033621164.139813, type 1, code 38, value 1
Event: time 1033621164.147807, type 1, code 37, value 0
Event: time 1033621164.259790, type 1, code 38, value 0
Event: time 1033621164.283772, type 1, code 36, value 1
Event: time 1033621164.419761, type 1, code 36, value 0
Event: time 1033621164.691710, type 1, code 14, value 1
Event: time 1033621164.795691, type 1, code 14, value 0

You get one event per key press and another per key release.

This read interface has all the normal characteristics of a character device, meaning you don't need to use a busy loop. You can simply wait until your program needs some input from the device and then perform the read call. In addition, if you are interested in the input from a number of devices, you can use the poll and select functions to wait on a number of open devices at the same time.

Sending information to the device is a process similar to receiving it, except you use the standard write function instead of read. It is important to remember that the data used in the write call has to be a struct input_event.

A simple example of writing data is shown in Listing 9. This example turns the Caps Lock LED on, waits 200 milliseconds and then turns the Caps Lock LED off. It then turns the Num Lock LED on, waits 200 milliseconds, and then turns the Num Lock LED off. The cycle then repeats (in an infinite busy loop), so you see alternate flashing of the two keyboard LEDs.

Listing 9. Sample Data Write Function

By now it should be fairly clear that you receive events only when something changes--a key is pressed or released, the mouse is moved and so on. For some applications, you need to be able to determine what the global state of the device is. For example, a program that manages keyboards may need to determine which LEDs are currently lit and which keys are currently depressed on the keyboard, even though some of the keys may have been depressed before the application started.

The EVIOCGKEY ioctl is used to determine the global key and button state for a device. An example is shown in Listing 10. This ioctl is similar to the EVIOCGBIT(...,EV_KEY,...) function in some ways; instead of setting a bit in the bit array for each key or button that the device can send, EVIOCGKEY sets a bit in the bit array for each key or button that is depressed.

Listing 10. Determining a Device's Global Key and Button State

The EVIOCGLED and EVIOCGSND functions are analogous to EVIOCGKEY, except that they return which LEDs are currently lit and sounds that are currently turned on, respectively. An example of how you would use EVIOCGLED is shown in Listing 11. Again, each bit is interpreted in the same way as the bits in the bit array are filled in by EVIOCGBIT.

Listing 11. Using EVIOCGLED

You can determine the repeat rate settings for a keyboard using the EVIOCGREP ioctl. An example is shown in Listing 12, with two elements to the array. The first element specifies the delay before the keyboard starts repeating, and the second element specifies the delay between subsequent repeats. So if you hold down a key, you'll get one character straight away, a second character rep[0] milliseconds later, a third character rep[1] milliseconds after the second character and another character every rep[1] milliseconds thereafter, until you release the key.

Listing 12. Checking the Repeat Rate Settings

You also can set the key repeat rate using EVIOCSREP. This uses the same two-element array that you'd use to get the settings, as shown in Listing 13; it sets the initial delay to 2.5 seconds and the repeat rate to 1 per second.

Listing 13. Setting the Repeat Rates

Some input drivers support variable mappings between the keys held down (which are interpreted by the keyboard scan and reported as scancodes) and the events sent to the input layer. You can determine what key is associated with each scancode using the EVIOCGKEYCODE ioctl. An example is shown in Listing 14, which loops over the first 100 scancodes. The value of the scancode (input to the function) is the first element in the integer array, and the resulting input event key number (keycode) is the second element in the array. You can also modify the mapping, using the EVIOCSKEYCODE ioctl. An example is shown in Listing 15; this ioctl maps my M key to always produce a letter N. Be aware that keycode ioctl functions may not work on every keyboard--that USB keyboard is an example of a driver that does not support variable mappings.

Listing 14. Looping over Scancodes

Listing 15. Mapping Keys

The EVIOCGABS function also provides state information. Instead of filling in a bit array that represents the global state of boolean values, however, it provides a struct input_absinfo (see Listing 16) for one absolute axis. If you want the global state for a device, you have to call the function for each axis present on the device. An example is shown in Listing 17. The elements in the array are signed 32-bit quantities, and you can safely treat them as equivalent to int32_t. The first element shows the current value of the axis, the second and third elements show the current limits of the axis, the fourth element shows the size of the ``flat'' section (if any) of the response and the last element shows the size of the error that may be present.

Listing 16. input_absinfo for an Absolute Axis

Listing 17. Checking Globabl State by Axis

Force Feedback

Three additional ioctl functions may be used for controlling force-feedback devices: EVIOCSFF, EVIOCRMFF and EVIOCGEFFECT. These functions currently send a force-feedback effect, remove a force-feedback effect and determine how many simultaneous effects can be used, respectively. Because the force-feedback support is still emerging and substantial work remains to be done, it is a little premature to fully document the API. The web sites listed in the Resources section of this article may have updated information by the time you read this.

发帖者 时间： 没有评论:
标签： ,

Wireless LAN resources for Linux

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/

Foreword

 The Linux Wireless LAN Howto is an Open Source project sponsored by Hewlett Packard (through my contribution) since 1996, and built with the contribution of many Linux users all over the world.

I first got involved in the Wireless LAN world by hacking the Wavelan drivers for Linux. I'm quite curious, so I start gathering information to know how the damn beasty was working.

Then, I realised that there was no central point where you could find all this information, links to the drivers and issues with Linux. So, I start stuffing it on my web pages, and it slowly evolved to what you see now.

I'm no longer active on the Wavelan drivers, but I'm also still following the work of Wireless LAN (called as well WLAN or Radio Ethernet), especially in relation with Linux. So, once every century, I update my Linux Wireless LAN Howto (html and pdf available below) and the collection of URLs (after the howto). I hope that it is usefull to someone...

The Linux Wireless LAN Howto

 I've decided to collect all the information about Wireless LANs and Linux that I was able to find. The goal was also to document my work and to become famous :-) You will find all that information in the Linux Wireless LAN Howto, available in PostScript, PDF and HTML (see below).

The original Linux Wireless LAN Howto is available as 3 postscript or acrobat (PDF) documents, which contains the same material but with the original presentation. So if you wish to enjoy a better reading experience or to print it, use those documents :

PostScript : Acrobat (pdf) :

The translation of the Howto to HTML lack the presentation but is more browser friendly, with cross references, external web links and support of HTML navigation. It is composed of the following documents :


My Howto finishes here, below is a huge collection of links ;-)
If you want to add links there, send me a nice e-mail...

Wireless LAN drivers web pages

 Lot's of people are working to make Linux better in supporting Wireless LANs, you will find down here some link to their web pages. This is only some shortcuts, you will find the complete list of drivers and all the details in the Howto.
  • Release notes for the Linux Wavelan drivers, that support only the very old Wavelan cards (now obsolete).
  • Release notes for the Linux Orinoco driver, that support most Orinoco cards, Symbol HR cards and PrismII cards.
  • John Markus Bjørndalen was the maintainer of the Xircom Netwave Linux driver.
  • Dag Brattli was the maintainer of the Xircom Netwave Linux driver and the Linux IrDA Project.
  • Jay Moorman was the maintainer of the Netwave AirSurfer plus driver (only in Netwave mode).
  • Dave Koberstein was the maintainer of the Proxim RangeLan2 Linux driver, and he had a mailing list about it.
  • David Leonard was working on a public domain Proxim RangeLan2 Pcmcia driver for OpenBSD and needs help.
  • Paul Fox was working on a driver for the IBM Wireless LAN Entry card (a product which is now discontinued).
  • Andreas Neuhaus was the maintainer of the Wavelan IEEE Linux driver.
  • Moustafa Youssef is the maintainer of the mwvlan driver, a modified version of wvlan_cs with scanning support.
  • Benjamin Herrenschmidt has modified the Wavelan IEEE driver to make it work with the Apple Airport card.
  • Lee John Keyser-Allen was the maintainer the Symbol drivers, and he had some discussion forums about it.
  • Cullen Jennings and Elmer Joandi were the maintainers of the Aironet Arlan Linux driver.
  • Thomas Corey has developed a driver for the Raytheon Raylink 802.11 wireless LAN (his old homepage).
  • Reyk Floeter was working on a GPL driver for the various cards based on the ATHEROS 802.11a chipset, and had preliminary source code available (not yet functional).
  • Jörg Albert is maintaining the old driver for the Elsa MC2 and ZCOM WL24 devices originally written by ZCOM and Elsa. He has a mailing list about it.
  • Bas Vermeulen has developed a driver for the No Wires Needed 802.11 wireless LAN.

Wireless Linux software on the Internet

 Linux Wireless support is not limited to Wireless LAN drivers, you can find tools, distributions and support for other wireless technologies.

Wireless Tools and Applications

Wireless LAN Protocol stacks

Wireless Linux Distributions

Most distributions support some Wireless cards out of the box, and have the infrastructure to support other cards when the proper driver is installed. Those distributions have a specific focus on Wireless LAN.
  • IT-University KTH has released Flying Linux, a Linux distribution with native support for wireless LANs (mostly Wavelan IEEE & Mobile IP).
  • The Linux Router Project (LRP) has also some support for some Wireless Lans, for example there is a Aviator2.4 LRP image and some Wavelan LRP images. Also, there is an LRP Aironet Howto.
  • Vladimir Ivaschenko has created parprouted, a daemon for transparent IP (Layer 3) proxy ARP bridging. This allow to do "IP bridging" on any 802.11 card (instead of MAC bridging).
  • Till Straumann has created a Linux distribution for Airport (to run Linux directly on the Airport or RG-1000 Access Point).
  • Instant 802 Networks, Inc have created OpenAP, a Linux distribution which directly on Prism II Access Points (such as the US Robotics, SMC or Addtron Access Points). This is based on the HostAP driver.
  • OpenWRT is a wireless distribution specific to Linksys WRT54G Access Points.
  • WISP-Dist is as embedded Linux distribution for wireless routers based on LEAF Bering and that support Orinoco/Aironet/PrismII cards.
  • Sputnik Gateway is a distribution that turn a regular PC with a wireless card into a Sputnik Gateway.
  • ROSE is a Linux distribution that Radionet use to deploy WiFi HotSpots. Like many others, it is based on the HostAP driver.

BlueTooth support

IrDA support

Other Wireless Technologies

  • Linux can also be used for Wireless WANs, such as Mobitex.

Security software for your Wireless LAN

 The security included in all Wireless LAN is cost effective, so if you want security over your Wireless LAN, you may want to check those packages.

Generic security solutions

Generic security protocols are totally independant of the underlying technology, so will work on any kind of wired or wireless connection. Those solutions are often classical, well defined and proven.
  • FreeS/WAN is the popular IPsec package for Linux. Only available with 3DES encryption.
  • WaveSec is a part of the FreeS/WAN project looking at how it FreeS/WAN applies to Wireless LANs. They provide tools, documentations and sample configurations.
  • Cerberus, an IPsec implementation from NIST. This implementation contain many different encryption cypher (including all the AES finalists), but is subject to US export controls.
  • OpenSSH, an Open Source implementation of the SSH protocol. A favorite for Unix users.
  • PoPTop, a PPTP server for Linux.
  • PPTP-Linux, a PPTP client for Linux.

802.11 specific security solutions

802.11 specific solutions are more complex and depend on hardware support. They come in two parts, the first part runs between the card and the Access Point (802.1x, WPA), the second part runs between the Access Point and an authentication server (Radius).

  • Open1x is an Open Source implementation of the 802.1x protocol (capable of using EAP/TLS to authenticate) for Linux and BSD. Recent version add support for the WPA and WPA2 protocols.
  • Adam Sulmicki has written a FAQ on how to setup 802.1x with Radius under Linux.
  • wpa_supplicant is complete implementation of the WPA protocol, providing enhanced privacy and security.

Public wireless LAN solutions

If you are deploying public wireless LAN access, you often don't want all those complication and can use a simple captive portal.
  • NoCat is a captive portal based on HTTPS authentication and firewall filtering for Linux currently in development.
  • Chillispot is a captive portal that support a Radius authentication server. It also works with WPA instead of the HTTP authentication.

Other Linux Wireless Howtos and help

 There is a lot of good documentation out there ;-)
  • Roberto Arcomano has written a good detailed Wireless Howto covering in depth the setup of some Wireless LANs.
  • Dries Buytaert has written an excellent Linux-wlan FAQ, answering common question mostly related to the linux-wlan-ng Linux driver for Intersil PrismII based cards.
  • Anindya has done a complete installation Howto for the PrismII and Aironet cards.
  • Craig has done some technical installation Howto for the TI, Atmel and ADMtek cards.
  • Personal Telco has a short Wireless FAQ.
  • Marcel Holtmann has a good page on Wireless LAN, in German.
  • The Arlan Wireless Router Howto explain how to use any wireless LAN as a point to point data link between distant houses.
  • Another excellent Wireless link Howto, where they describe in details all the step by step operations (theory, hardware, software...) of using the Symphony (or other Wireless LAN) as a point to point connection between distant houses. And they have a comprehensive list of links...
  • The Low Cost Wireless Network Howto explain how to use the Proxim card to create point to point links.
  • Simon Anderson has a Linux Wireless Access Point HOWTO, which include lot's of good information on various AP topics (HostAP, DHCP, DNS, routing, firewalling, NoCat...).
  • Yang-Hwee TAN has a quick Howto about Building a Secure Wireless Access Point using the HostAP driver and FreeS/WAN.
  • Jason Boxman has a pretty extensive Howto on how to use the HostAP driver, especially to set up an Access Point.
  • Ross Finlayson explain in details how to use Linux as a Wireless router for their wireless ISP (LIVE.COM).
  • Yunus Bookwala explain how to set-up a Wireless HotSpot, using OpenWrt and focusing mostly on the accounting/security back-end.
  • John G. Faughnan has a page on home networking, including Wireless LANs and Linux.
  • Mad Science Research labs explain you how to upgrade the Airport UFO to RC4 128 bits.
  • Harald Roelle has a page on how to set up a Wavelan IEEE under Linux-PPC and how to connect it to the "UFO" (the Apple Airport base station).
  • Elan Digital Systems has a very complete FAQ on how to setup PCI-Pcmcia bridges under Linux.
  • Jun Sun's has a howto on how to flash PrismII firmwares under Linux or Windows.
If after reading all the documentation above you still can't find the info you are looking, here are a couple of source of help to get in touch with other Linux users.
  • The Linux Pcmcia web site has the Pcmcia FAQ and some Pcmcia Wireless forums for all questions regarding drivers included in the Linux Pcmcia package and the Linux kernel.
  • For questions regarding point to point links, the Wavelan users in Autralia have set up a very useful mailing list...
  • Some individual drivers have specific mailing lists associated with them, those are listed in the Howto...

Public Wireless Linux networks

 If you don't want to play alone with your wireless equipement, there are lots of people setting up public wireless networks using Linux. I just picked a few of those with interesting info on their pages.
  • WiFiMaps has some maps of public wireless connectivity, and allow you to locate those public wireless Access Points.
  • Linux users in Australia are using the good old Wavelan or the Wavelan IEEE to create point to point data link between distant houses. They have set up a mailing list, which is not Wavelan specific and very useful.
  • Guerilla Net aim to setup a free network in the area of Boston.
  • Consume the net want to do the same in the area of London. Many mailing lists.
  • Elektrosmog wants fast Internet everywhere, starting in Sweeden.
  • Seattle Wireless wants to build a next-generation community wireless network.
  • Personal Telco want to build alternative communication networks in the area of Portland. Their web site contains a mountain of information, such as this Wireless FAQ.
  • NYCwireless wants Free Public Wireless Internet for New York City. They have some mailing lists.
  • BAWUG, the Bay Area (California) Wireless User group is pretty active and has some mailing lists.
  • Reseau Citoyen is deploying their wireless network in Bruxelles, Belgium, and has an extensive amount of information in french.
  • LIVE.COM want you to enjoy wireless coffee in Mountain View, California.
  • The Shmoo Group has setup a database of public Wireless LAN networks.

Wireless LAN Hardware (surveys and reviews)

 Various people maintain some approximate list of the hardware that is compatible with Linux :
  • Of course, I list a number of vendors in the various sections of the Howto...
  • Absoval has one of the most exaustive list of wireless cards, and list compatibility of PrismII cards with their own linux-wlan driver.
  • Hendrik-Jan Heins is now maintaining an updated version of the exaustive list from Absoval. This is very difficult task, so don't be surprised if you find minor errors.
  • Personal Telco has a short list of PrismII cards (for which many Linux drivers are available).
  • Seattle Wireless has a pretty long list of cards, but the information on this page is not always correct, so double check.
  • Kismet Wireless list card compatible with Kismet, and the corresponding driver.
  • Nicolai Langfeldt has a short list of 802.11g cards comaptible with Linux.
  • Jacek Pliszka has many tips on how to identify the various card, especially USB devices.
  • Jason Hecker maintains a list of all Atmel USB devices.
  • Tarmo Järvalt has long lists of cards containing various chipsets, one page per chipset, including some Google Ads.
Just a few reviews and guides here, not Linux specific.
  • Most manufacturer web sites are listed in the Howto...
  • Tim Higgins has a huge amount of 802.11 information on his web site (FAQ, articles, reviews, links), which is acurate, detailed and up to date.
  • Practically Networked lists and compares the main Wireless LAN products available on the market. Their list is long and they have reviewed in details a lot of products.
  • I've found a really good web page on the different radio products available (now quite outdated).
  • Network Computing has a long and complete article comparing various 802.11 products. Definitely worth a read, even if they don't mention Linux support ;-)
  • PC Magazine/ZDnet has done a short review of 802.11-b products. They have tested the latest products from the big names.
  • Toms Networking has frequent detailed reviews of various wireless hardware.
  • Synack Communications has done some testing of the Power Consumptions of some common Wireless LANs.

Other web sites of interest (Wireless LAN related)

 A random collection of links. I welcome your suggestions...
  • Roger Coudé has developped an impressive package to predict the performance and coverage of a radio system based on the characteristic of the environment.
  • The State University of Ohio has a basic Overview of 802.11.
  • Mark S. Mathews has a nice white paper on 802.11.
  • Intersil (formerly Harris) has a lot of white papers, but they tend to have a very strong bias towards what they are offering.
  • Lot's of links about Wireless (no longer updated).
  • Ben Gross has more links about Wireless (mostly Linux related, and quite up to date).
  • Jacco Tunnissen has lot's of links about Wardriving and Wireless Security.
  • Bernard Adoba has created The Unofficial 802.11 Security Web Page, with many links about security issues in wireless networks and 802.1x.
  • Delbert K. Matlock used to have a very complete page on Linux BlueTooth support, linking to all information available on the net on this subject, but hasn't updated it in since 2001.
  • Foo Chun Choong has a web page that link to various BlueTooth research projects and papers.
  • The NTIA maintain a chart of the frequencies in use in the US. Try to find the unlicensed bands ;-)
  • You may also want to check my paper page, especially if you look for either my publications or SWAP information.

Linux and other links

 Some personal recommendations on the web...
  • The project I'm currently officially working on for HP is called CoolTown.
发帖者 时间： 没有评论:
订阅： 博文 (Atom)