数日前，朋友和我说了这样一句话：“现在社会的、经济的问题根本解决之道还在于人的素质的提高”。

不禁问自己：什么是“素质”？如果说“素质”这个词可以涵盖几乎所有方面的话，我非常支持。—— 但是，这样子这句话就成了废话了...

有些困。早些休息啦。

Write a Linux Hardware Device Driver

Learn to write and install a Linux device driver to control a hardware card. We detail what functions need to be written, outline the supporting kernel functions that are available, explain how to initialize the driver and how memory is requested and allocated in an efficient manner, and provide a ``real'' driver example.

By Tom Coffey and Andrew O'Shaughnessy

Introduction to Linux

Linux is a 32-bit multitasking, multimedia operating system with complete source code, developed b y the free software community on the Internet. Linux is a clone of the Unix operating system that runs on Intel 80386/80486/Pentium computers. It supports a wide range of software, from TEX to the X Window System, to the GNU C/C++ compiler, to TCP/IP. The Linux system is mostly compatible at the source level with a number of Unix standards including IEEE POSIX.1, System V, and BSD. Linux also provides a complete Unix programming environment, including standard libraries, programming tools, compilers, and debuggers.

A device driver consists of a set of routines that control a peripheral device attached to a workstation. The operating system normally provides a uniform interface to all peripheral devices. Linux and Unix present peripheral devices at a sufficiently high level of abstraction by observing that a large proportion of I/O devices can be represented as a sequence of bytes. Linux and Unix use the file--which is a well understood data structure for handling byte sequences--to represent I/O devices.

Linux I/O Subsystem

Figure 1 shows the Linux architecture in the most general terms. Here, the kernel is shown wrapped around the hardware to depict that it is the software component that has direct access to--and control over--the system hardware, including the processor, primary memory, and I/O devices.

Figure 2 [Bach86] shows that user-level programs communicate with the kernel using system calls, for instance, open(), read(), write(), ioctl(), close() , and the like.

Linux System Calls

The kernel is not a separate task under Linux. It is as if each process has a copy of the kernel. When a user process executes a system call, it does not transfer control to another process, but changes its execution mode from user to kernel mode. In kernel mode, while executing the system call, the process has access to the kernel address space, and through supporting functions , it has access to the address space of the user executing the call.

Figure 3 depicts the I/O Subsystem. The Linux kernel implements a device-independent I/O system that serves all devices. A device driver provides the I/O system with a standard interface to the hardware, hiding the unique characteristics of the hardware device from the user to the greatest extent possible.

Listing 1 illustrates a user program that employs some basic system calls to read characters from a device into a buffer. When a system call is requested, the kernel transfers control to the appropriate device driver routine that executes on behalf of the calling user process (as shown previously with Figure 3).

All devices look like files on a Linux system. In fact, the user-level interface to a device is called a ýspecial file These special files (often called device nodes) reside in the /dev directory. For ex ample, invoking the command ls -l /dev/lp* can be used to yield the following status information:

crw-rw-rw 1 root root 6, 0 April 23 1994 /dev/lp0

This example indicates that: ýlp0ý is a character type device (the first letter of the file mode field is ýcý), the major number is 6, and minor device number 0 is assigned to the device.

Major device numbers are used by the Linux system to map I/O requests to the driver code, thereby deciding which device driver to execute, when a user reads from or writes to the special file. The minor numbers are entirely under the control of the driver writer, and usually refer to ýsub-devicesý of the device. These sub-devices may be separate units attached to a controller. Thus, a disk device driver may, for example, communicate with a hardware controller (the device) which has several disk drives (sub-devices) attached.

Figure 4 outlines the flow of execution of a system call within th e Linux operating system.

Device Drivers

A device driver is a collection of subroutines and data within the kernel that constitutes the software interface to an I/O device. When the kernel recognizes that a particular action is required from the device, it calls the appropriate driver routine, which passes control from the user process to the driver routine. Control is returned to the user process when the driver routine has completed. A device driver may be shared simultaneously by user applications and must be protected to ensure its own integrity.

Figure 5 shows the relationship between device driver and the Linux system.

A device driver provides the following features:

• A set of routines that communicate with a hardware device and provide a uniform interface to the operating system kernel.
• A self-contained component that can be added to, or removed from, the operating system dynamically.
• Management of data flow and c ontrol between user programs and a peripheral device.
• A user-defined section of the kernel that allows a program or a peripheral device to appear as a `` /dev '' device to the rest of the system's software.

Character and Block Device Drivers

Character and block device drivers are the two main types of peripheral drivers. A disk drive is an example of a block device, whereas, terminals and line printers are examples of character devices.

A block device driver is accessed by user programs through a system buffer that acts as a data cache. Specific allocation and memory management routines are not necessary as the system transfers the data to/from the device. Character device drivers communicate directly with the user program, as there is no buffering performed. Linux transfers control to the appropriate device driver when a user program requests a data transfer between a section of its memory and a device. The device driver is responsible for transferring the d ata. Within Linux, the source for character drivers is kept in the /usr/src/linux/drivers/char directory. This article only addresses the development of character device drivers.

Kernel Programming Environment

A Linux user process executes in a space isolated from critical system data and other user processes. This protected environment provides security to protect the process from mistakes in other processes. By contrast, a device driver executes in kernel mode, which places few limits on its freedom of action. The driver is assumed to be correct and responsible. A driver has to be part of the kernel in order to service interrupts and access device hardware. A driver should process interrupts efficiently to preserve the schedulerýs ability to balance the demands on the system. It should also use system buffers responsibly to avoid degrading system performance.

A device driver contains both interrupt and synchronous sections. The interrupt section deals with re al-time events and is driven by interrupts from devices. The synchronous section, which comprises the remainder of the driver, only executes when the process which it serves is also active. When a device requests some software service, it generates an ``interrupt.'' The interrupt handler must determine the cause of the interrupt and take appropriate action.

A Linux process might have to wait for an event to occur before it can proceed. For example, a process might wait for requested information to be written to a hardware device before continuing. One way that processes can coordinate their actions with events is through sleep() and wakeup() system calls. When a process goes to sleep, it specifies an event that must occur, that is, wakeup, before it can continue its task. For example: interruptible_sleep_on(&dev_wait_queue) causes the process to sleep and adds the process number to the list of processes sleeping on dev_wait_queue . When the devi ce is ready, it posts an interrupt, causing the interrupt service routine in the driver to be activated. The routine services the device and issue a corresponding wakeup call, for example, wake_up_interruptible(&dev_wait_queue) , which wakes up the process sleeping on dev_wait_queue .

Special care must be taken if two or more processes, such as the synchronous and interrupt portions of a device driver, share common data. The shared data area must be treated as a critical section. The critical section is protected by ensuring that processes only have mutually exclusive access to the shared data. Mutually exclusive access to a critical section can be implemented by using the Linux kernel routines cli() and sti() . Interrupts are disabled by cli() while the process is operating in the critical section and re-enabled by sti() upon exit from the critical section, as in:

cli()

Critical Section Operations

sti
()

Virtual File system Switch (VFS)

The principal interface between a device driver and the rest of the Linux kernel comprises a set of standard entry points and driver-specific data structures (see Figure 6 ).

Listing 2 illustrates how the entry points are registered with the Virtual File system Switch using the file_operations structure. This structure, which is defined in /usr/include/linux/fs.h , constitutes a list of the functions written for the driver. The initialization routine, xxx_init() registers the file_operations structure with the VFS and allocates a major number for the device.

Device Driver Development Supporting Functions

The table below contains most of the common supporting functions available for writing device drivers. See also the Kernel Hackers' Guide [John93] for a more detailed ex planation:

add_timer()

Causes a function to be executed when a given amount of time has passed

cli()

Prevents interrupts from being acknowledged

end_request()

Called when a request has been satisfied or aborted

free_irq()

Frees an IRQ previously acquired with request_irq() or irqaction()

get_fs*()

Allows a driver to access data in user space, a memory area distinct from the kernel

inb(), inb_p()

Reads a byte from a port. Here, inb() goes as fast as it can, while inb_p() pauses before returning.

irqaction()

Registers an interrupt like a signal.

IS_*(inode)

Tests if inode is on a file system mounted with the corresponding flag.

kfree*()

Frees memory previously allocated with kmalloc()

kmalloc()

Allocates a chu nk of memory no larger than 4096 bytes.

MAJOR()

Reports the major device number for a device.

MINOR()

Reports the minor device number for a device.

memcpy_*fs()

Copies chunks of memory between user space and kernel space

outb(), outb_p()

Writes a byte to a port. Here, outb() goes as fast as it can, while outb_p() pauses before returning.

printk()

A version of printf() for the kernel.

put_fs*()

Allows a driver to write data in user space.

register_*dev()

Registers a device with the kernel.

request_irq()

Requests an IRQ from the kernel, and, if successful, installs an IRQ interrupt handler.

select_wait()

Adds a process to the proper select_wait queue.

*sleep_on()

Sleeps on an event, puts a wait_queue entry in the list so that the process can be awakened on that event.

sti()

Allows interrupts to be acknowledged.

sys_get*()

System calls used to get information regarding the process, user, or group.

wake_up*()

Wakes up a process that has been put to sleep by the matching *sleep_on() function.

Name space

The name of the driver should be a short string. Throughout this article we have used "xxx" as our device name. For instance, the parallel (printer) device is the ``lp'' device, the floppies are the ``fd'' devices, and the SCSI disks are the ``sd'' devices. To avoid name space confusion, the entry point names are formed by concatenating this unique driver prefix with a generic name that describes the routine. For instance, xxx_open() is the ``open'' routine for the ``xxx'' driver.

Accessing Hardware Memory

A Linux user process can not access physical memory directly. The memory management sc heme--which is a demand paged virtual memory system--means that each process has its own address space (user virtual address space) that begins at virtual location zero. The kernel has its own distinct address space known as the system virtual address space.

The device driver copies data between the kernel'ýs address space and the user program'ýs address space whenever the user makes a read() or write() system call. Several Linux routines--such as, memcpy_*fs() and put_fs*() --enable device drivers to transfer data across the user-system boundary. Data may be transferred in bytes, words, or in buffers of arbitrary sizes. For example, memcpy_fromfs() transfers an arbitrary number of bytes of data from user space to the device, while get_fs_byte() transfers a byte of data from user space. Similarly, memcpy_tofs() and put_fs_byte() write data to user space memory.

The transfer of data betwee n the memory accessible to the kernel and the device itself is machine-dependent. Some machines require that the CPU execute special I/O instructions to move data between a device register and addressable memory--often called direct memory access (DMA). Another scheme, known as memory mapped I/O, implements the device interface as one or more locations in the memory address space. The most common method uses I/O instructions, provided by the system to allow drivers access the data in a general way. Linux provides inb() to read a single byte from an I/O address (port) and outb() to write a single byte to an I/O address. The calling syntax is shown here:

unsigned char inb(int port)
outb(char data, int port)

Writing a Character Device Driver

Listing 3 shows a sample xxx_write() routine where the device driver would, typically, poll the hardware to determine if it is ready to transfer data. The xxx_writ e() routine transfers a character string of count bytes from the user-space memory to the device. Using interrupts, the hardware is able to interrupt when it is ready to transfer data and so there is no waiting. Listing 4 outlines an alternative xxx_write() routine for an interrupt-driven driver.

Here, xxx_table[] is an array of structures, each of which have several members. Some of the members include xxx_wait_queue and bytes_xfered , which are used for both reading and writing. The interrupt-handling code can use either request_irq() or irqaction() in the xxx_open() routine to call xxx_interrupt() .

Listing 5 presents an example of a complete device driver (for the bus mouse). The source listing contains the code for a typical bus mouse driver, such as the Logitec bus mouse or the Microsoft bus mouse.

Device Driver Initialization

In order that the device driver is correctly initialized when the operating system is booted, the xxx_init() routine must be executed. To ensure this happens, add the following line to the end of the chr_drv_init() function in the /usr/src/linux/driver/char/mem.c file:

mem_start = xxx_init(mem_start);

and resave the file back to disk.

Installing the Driver in the Kernel

A character device driver has to be archived into the /usr/src/linux/drivers/char/char.a library. The following steps are required to link the driver to the kernel:

• Put a copy of the source file (say xxx_drv.c ) in the /usr/src/linux/drivers/char directory.
• Edit Makefile in the same directory so it will compile the source for the driver--add xxx_drv.o to the OBJS list, which causes the make utility to automatically compi le xxx_drv.c and add the object code to the char.a library archive.
• The last step step is the recompilation of the kernel.

The following steps are required to recompile the Linux kernel:

1. Log in as root
2. Change to the /root/linux directory
3. Carry out the following series of commands
   
   • make clean ; make config to configures the basic kernel
   • make dep to set-up the dependencies correctly
   • make to create the new kernel
4. Wait for the kernel to compile and go to the /usr/src/linux directory.
5. In order to boot the new kernel, copy the new kernel image ( /usr/src/linux/zImage ) into the place where the regular bootable kernel is found.

Device File Creation

In order to access the device using system calls, a special file is created. The driver files are normally stored in the /dev directory of the system. The following commands create the special device file:

mknod /dev/xxx c 22 0

Creates a special character file named xxx and gives it major number 22 and minor number 0.

chmod 0666 /dev/xxx

Ensures that every user in the system has read/write access to the device.

Conclusions

In this article, we have detailed how to write a hardware character device driver for the Linux operating system. We have outlined how to access hardware memory. We have also presented the kernel programming environment, as well as the supporting functions available to write a device driver. A number of worked examples were also presented to aid the programmer in developing his/her own device driver(s).

Bibliography

[Bach86] Bach, M; The Design of the Unix Operating System ; Englewood Cliffs, NJ: Prentice Hall, 1986.

[John93] Michael K. Johnson; LINUX Kernel Hackers' Guide ; 201 Howell Street, Apt. 1C, Chapel Hill, North Carolina 27514-4818; 1993.

[Swit93] Robert Switzer, University of Gottingen, Germany; Operating Systems, A Practical Approach ; Prentice Hall 1993.

[YCI94] The Linux Bible, The GNU Testament-2nd Edition ; Yggdrasil Computing Incorporated, Version 2.1.1, 10 July 1994.

 

---

Background of Work

This tutorial is a result of an independant study I made with the original intention of porting USB to RTLinux (a real time operating system)

Who should read this?

• If you have no knowledge of any of the aspects of USB whatsoever, and are curious to know as to what the hype surrounding it is about, this would provide a reasonable starting point.
• If you have some ideas of working with USB on the application layer (as using a client library), but would like to learn about the internals this is worth reading
• If you are familiar with the workings of USB, but have not worked with it under Linux, this tutorial would be useful.
• If you are not too interested in USB, but are interested in virtual filesystems under Linux, this may be worthwhile
• If you are accomplished in using the USB stack and using it under Linux, then please read on and give me some feedback on what you think of the page!

All in all, if you'd rather not yet read the numerous other voluminous, exhaustive documentation; if you want to read something about USB which is quick, short and relatively straighforward, just to give a feel for all that there is and hopefully get you going, this would be something for you.

Disclaimer

In spite of the fact that I have made every effort to ensure that the content of the tutorial is correct, I make no guarantees regarding the same.

Overview of the tutorial

In this tutorial I present a series of topics of interest related to USB and its implementation in Linux. The topics are dealt with in varying degrees of detail, due to both their relevance to main issue, and due to varying degrees to which I (had to) understand them myself.

I start by giving an brief introduction about USB from the enduser stand point. Then, I delve into some of the technicalities and specifications of the protocol - all of which is operating system independant. I then talk about what it takes to port USB to a particular operating system. I then talk about how Linux goes about things and to some extent why it does so.

Here goes.....

Its quite likely that you have worked with a USB device before, for maybe linking up your camera to download pictures, or maybe to even hook up your mouse/keyboard. But USB for many of us is a fancy new technology, which seems to do provide lot of features - its fast (you pictures download much faster from your camera on the USB link and compared to say a serial link), does not seem to have those annoying driver problems - with minimal fuss - all that there is, is a small connector which fits snugly into the slot at the back of your machine.

To understand USB better it may be instructive to understand the acronym - which stands for Universal Serial Bus. The words Serial and Bus are crucial.

• Bus reminds you that though we seem to use USB for data transfer between a computer and an external device much like a serial cable, it is infact much more than that. To understand the difference, consider what's required to get a serial connection to work on a computer. All that we need to have is a driver for the serial port installed and that would make our serial port functional. It is not our concern as to what is hooked up at the other end of the serial cable. With the driver installed, the only other utility that maybe required is a serial client application like Hyperterm (if you are using Windows) or Minicom (if you running some flavour of Unix/Linux). The point is that you are only concerned about our end of things. But USB is a bus like say a PCI bus. Since, the bus is part of the computer's datapath, it follows that all devices connected the USB cable, by virtue of being 'on the bus', are part of the computer in some sense. So, apart from being interested in just putting the bits on the wire - as was the case with the serial link - now we are also concerned at some level on what is on the other end wire.
• Serial tells us that data transmission on the wire is serial (as opposed to parallel)- one bit at a time

In spite of the fact that most USB connections seem to run from computer to device (point to point) this hardly needs to be the case. The layout is really a tree rather than a link. Every node in the tree is represents a hub. The 'root hub' is present inside the computer and the two USB sockets present on the computer may infact be two nodes connected to the root hub. Thus a compound USB device which consists of a keyboard and the mouse with one USB link going to the host may be represented as folows.

                         -------------------------------
                         |                 Keyboard     |
                         |                /             |
                         |               /              |
                         |              /               |
        Computer ----------Internal Hub                 |
                         |              \               |
                         |               \              |
                         |                \             |
                         |                Mouse         |
                         --------------------------------

where the boxed region represents the device. The internal hub is invisible to the user
This raises a couple of points. First, obviously the computer needs to be aware and able to address either of the devices. This is done by way of assigning device addresses to each of the devices on the bus. Also, inspite of the fact that the function and the location of the internal hub is different from the devices, as far as the computer is concerned, it treats the hub in the very same way as it treats the other devices.
USB was designed having in mind devices with multiple capabilitites. With this being the case, the host needs to be aware of these multiple capabilities that a particular device may have. This is acheived by describing a device in terms of heirarchical structure. A device may have multiple configurations, each of which may in turn have multiple interfaces, which in turn may have multiple endpoints. The interfaces also have classes (and sub-classes) associated with them. Common classes include those for human interface devices such as keyboard, mice etc. and those for storage devices such as hard disks. See references for links to more detailed descriptions regarding USB heirarchy structures. This allows a device to present multiple interfaces/configurations for different purposes.

All transfers to USB devices fall into one of four classes, namely: control, isochronous, bulk and interrupt, with the names being fairly descriptive of the purpose of each of the transfers. Control and interrupt transfers are used for sending small messages across , such as for setting a configuration of a device or sending small sets of data across. Bulk and isochronous transfers are for sending larger sets of data across. While isochronous (as the name suggests) gives some time guarantees with regard to the transfers, bulk transfers are highly flexible in their transfer mechanisms. Every endpoint that a device may posses has a specific transfer type associated with itself. Hence a device which wants to make transfers of multiple types, must have one corresponding endpoint for each of the types. A more rigorous discussion on the configurations/iterfaces and on the different types of transfers is beyond the scope of this tutorial. Please lookup the references for more information.

The host learns of the various devices on the bus through a process known as enumeration. All communication between the host and a device takes place through pipes. The device is controlled using pipe 0, which is the standard control pipe for any device. The host can ask the device to enuremate itself using the control pipe, on which device sends back a whole lot of information back to the host including - its product and vendor id, information regarding configurations, interfaces and the different endpoints that it has. Apart from enumeration, the host also has other responsibilites. For example, it may be noted that the USB link is a resource that is shared across all the devices. This means that contention can result in terms of more than one device wanting to send data at the same time (as is the case with ethernet). USB resolves this issue by following a master-slave protocol. The host is the master and controls the bus, and all the devices attached to the bus are slaves. Any device can transfer on the bus only at the request of the master

The host-controller is the component inside the host which is responsible for implementing all host-aspects of USB. In some sense it is analogous to an ethernet NIC card, but much more complicated. The host-controller is protocol-aware and identifies different transfer types (control/bulk etc.) Note that all information described thus far is operating system independant. Any operating system will have to provide some means for the client applications to open pipes to particular endpoints of devices, make transfers of desired types etc. Also, typically on booting up, the operating would enumerate all the devices on the bus to get an idea of the layout of the entire bus.
The actual layout of USB on the host is as follows:

          |-------------------------|
                                   
            Client Application
           -------------------------

            USB System software (USB Driver)
           --------------------------

            Host Controller Software 
           --------------------------

               Hardware
          |-------------------------|

As the figure shows, USB has a layered structure on the host side. Right at the bottom is the actual hardware which throws signals on the wire and most importantly consists of the host controller.

Rest of the tutorial deals with USB as related to Linux.
First we will look at what it takes to get a USB device to work under Linux Let us consider a typical scenario of a USB device being used in Linux. Whenever a new device is plugged, the host controller detects the new device and conveys the information to the operating system. As soon as the operating system learns of the new device, the device is enumerated. This enumeration takes place by way of the operating system issuing commands to the host controller, more of which is presented later. Note that all devices on the bus are also enumerated at boot time. Based on the information that the host learns at the time of enumeration, the operating system assigns a driver to the device. Of course, it is possible that none of the known drivers match. A device driver for a USB device implements all the functions implemented in a usual device driver, namely open, read, write, ioctl etc. Among these ioctl() performs a specially important role. It is easy to should be noted that the operation of say writing to a USB device has several attributes associated with it such as the type of transfer. It would be convinient to implement a write inside an ioctl so that the necessary attributes may be passed to the ioctl call as paramaters.
An example ioctl call may be as follows:

  ret = ioctl(dev->fd, IOCTL_USB_BULK, &bulk);

This makes a bulk write by calling ioctl function associated with the file of USB device dev. The second parameter IOCTL_USB_BULK identifies the call as a bulk write, with the structure bulk containing the actual data to be written.
In the previous example, it was mentioned that Linux compares the device description that it gets back at the time of enumeration, to check for any suitable drivers. This means that the operating system needs to keep track of among other things - all attached devices and all registered drivers. LInux accomplishes this by way of using the USB filesystem of USBFS (also known as USB Dev FS). USBFS is a virtual filesystem like the /proc filesystem.

Modern versions of the Linux kernel use one central filesystem, known as the Virtual Filesystem. All 'real' filesystems register themselves with the VFS, where the filesystem registering itself specifies the 'driver' that the VFS can use to talk to itself. This requires the filesystem to implement a particular interface that the VFS can use to communicate with it. Once a particular filesystem has been registered, directories can be mounted of the different filesystem types in various places inside the VFS. For example, ext2 and dos may register themselves and have respective directories mounted at / and /dos.
One of the motivations for using the VFS is to accomodate the inter-operability of different types of filesystems. The other advantage of using the VFS is being able to accomodate virtual filesystem i.e filesystems which have no physical existence. As we saw earlier, the only requirement on part of a filesystem to register itself with the VFS is for it to implement the necessary interface with which the VFS can interact with it. The proc filesystem for example - mounted at /proc - presents a directory structure containing a whole lot of system information concerning memory, system buses, processor etc. None of this information is physically stored in any particular file on disk. When the VFS acesses any of the files in the /proc directory, the /proc filesystem generates all this information realtime. This makes the implementation of the virtual filesystem completely transparent to the end user and indeed even to the VFS. Another example of a virtual filesystem is devfs.
Having seen the idea behind a virtual filesystem, it is straightforward to see the motivation behind using USBFS and making it a virtual filesystem. USBFS tries to make all attached USB devices seem like traditional files (in line with the UNIX philosophy). It dynamically keeps track of devices which are attached to or removed from the bus .Compare this to the old unix philosophy of using nodes inside /dev. This suffered from the fact that there never had to be any correspondance between an entry in /dev and a physical device on the machine. Often huge number of nodes are present in /dev with node entries being created for every conveivable scenario, but rarely ever used. USBFS being dynamically updated, does not have this problem.
Apart from the aspect of providing a cleaner filesystem, USBFS also makes drivers aspect of things much more transparent. all USB devices have the same major number, making the use of them to determine the drivers impractical. Instead, the filesystem decides the association based on the description the device returns on enumeration and the list of registered drivers. Apart from this aspect, USB drivers work in the same way as conventional drivers, with functions being defined for open,read,write ,ioctl etc.

The usb filesystem is mounted traditionally at /proc/bus/usb. Inside this directory there is one entry for each bus. On my machine, the contents of the directory reads as:

/proc/bus/usb$ ls -l
total 0
dr-xr-xr-x    1 root     root            0 Oct 18 16:30 001
dr-xr-xr-x    1 root     root            0 Oct 18 16:30 002
-r--r--r--    1 root     root            0 Oct 29 12:10 devices
-r--r--r--    1 root     root            0 Oct 29 12:10 drivers

showing that there are two busses (designated by 001 and 002). The directories corresponding to the hubs have one file per device connected directly or indirectly to the hub. My first hub has one device connected to it. So its directory contents read:

/proc/bus/usb/001$ ls -l
total 1
-rw-r--r--    1 root     root           18 Oct 29 12:11 001
-rw-r--r--    1 root     root           18 Oct 29 12:11 003

The 001 device is always present and it represents the root hub.

Note that 003 is not characterized as a hardware device file(such as a char or a block) as is the case with say the serial port. But the file is opened, the VFS forwards this request to USBFS. The USBFS then refers to its list of registered drivers and picks the appropriate driver to complete the open operation.

Apart from the usual functions defined in a driver, those for USB need to have another function named probe defined. Once a device is connected to the USB bus, USBFS executes this probe method in each of the drivers, to decide on the driver corresponding to the device. The signature of the probe method is as follows:

static void *probe(struct usb_device *dev, unsigned int i,
                       const struct usb_device_id *id)

Based on the information retreived from the device, the driver determines as to whether it is compatible with the device,and accordingly returns a pointer to a driver-specific value or NULL. For example, a driver for a hub may check to see whether the interface subclass has the value 0, and also whether the device has one single interrupt endpoint. Devices typically use the product id, vendor id and class/sub-class values while probing the device.

Next, we look at how data can be transferred on the bus. To transfer data to or from a device, first a handle needs to be obtained to the device. libusb is a user-level library that may be used to implement client-side functionality for USB on Linux. libusb requires that the function namely usb_init() be called before any other function is called. To get to access the various devices on the bus, two functions may be called in sequence: usb_find_busses(), usb_find_devices() . Calling these functions leads to initialization of a global link list names bus (of type usb_bus). The number of elements in this link link is equal to the number of busses on the system. The structure usb_type has a field named devices , which in itself is a linked list of all devices (of type usb_device)on the bus. A brief description on the internals of the functions follows. A more comprehensive explanation is beyond the scope of the tutorial. As we saw earlier, each device on the bus is represented as a file in the usb filesystem (at /proc/bus/usb/001 directory). This file really contains the device descriptor for the associated device. For example, the following line of code initializes the descriptor for the pointer to structure dev, by reading the data off the file.

    ret = read(fd, (void *)&dev->descriptor, sizeof(dev->descriptor));

where fd is a file descriptor corresponding to the device file inside the usb filesystem. All that the two functions do, is to iterate through the two directories corresponding to the two busses on the system, namely /proc/bus/usb/001 and /proc/bus/usb/002. For each file inside the directory, which is representative of a device on the bus, the file descriptor is read in the manner mentioned above.
After calling the two functions (usb_find_busses() and usb_find_devices()), to get a handle to the required device, all that needs to be done is iteration along the linked list of the devices on the file, to get access to each of the devices. On reaching the desired device, a handle to the device may be obtained by calling the usb_open() method, passing a pointer to the usb_device structure as a parameter.
Once the handle has been obtained, one may use the whole lot of libusb functions on the handle. The range of functions broadly classify into two classes:

• those for configuring the device: usb_set_configuration, usb_claim_interface
• those for doing data transfer: usb_bulk_write,usb_bulk_read,usb_control_msg

For more information on the API provided by libusb, lookup references.
Here is an example using libusb

---

 

Linux Kernel Documentation

The following Books are automatically generated from the Linux Kernel 2.6:

• Bus-Independent Device Accesses
• USB Gadget API for Linux
• The Linux Journalling API
• Linux Kernel API
• Unreliable Guide To Hacking The Linux Kernel
• Unreliable Guide To Locking
• libATA Developer's Guide
• Reed-Solomon Library Programming Interface
• Linux Security Modules: General Security Hooks for Linux
• MCA Driver Programming Interface
• MTD NAND Driver Programming Interface
• Linux Kernel Procfs Guide
• SCSI Subsystem Interfaces
• SiS 900/7016 Fast Ethernet Device Driver
• Tulip Driver User's Guide
• The Linux-USB Host Side API
• Via 686 Audio Driver for Linux
• Video4Linux Programming
• Synchronous PPP and Cisco HDLC Programming Guide
• Writing USB Device Drivers
• Z8530 Programming Guide

Intro

Mozete da izpolzvate Online books stranicata mi za tyrsene po zaglavie i/ili avtor. Turseneto e w biblioteka s pove4e ot 12000 zaglavia!

Knigi, opisani w Linux Kernel Documentation:

Tozi spisuk e HTML versia na kernel-docs.txt file ot Linux Kernel dokumentite. Prosto razdelih vi4ki zapisi za online books w otdelni files i knovertirah URL-ite.

• The Linux Kernel by David A. Rusling.
  Description: On line, 200 pages book describing most aspects of the Linux Kernel. Probably, the first reference for beginners. Lots of illustrations explaining data structures use and relationships in the purest Richard W. Stevens' style. Contents: "1.-Hardware Basics, 2.-Software Basics, 3.-Memory Management, 4.-Processes, 5.-Interprocess Communication Mechanisms, 6.-PCI, 7.-Interrupts and Interrupt Handling, 8.-Device Drivers, 9.-The File system, 10.-Networks, 11.-Kernel Mechanisms, 12.-Modules, 13.-The Linux Kernel Sources, A.-Linux Data Structures, B.-The Alpha AXP Processor, C.-Useful Web and FTP Sites, D.-The GNU General Public License, Glossary". In short: a must have.
  Keywords: everything!, book.

• The Devil's in the Details by Georg v. Zezschwitz and Alessandro Rubini.
  Description: Linux Journal Kernel Korner article. Here is it's abstract: "This article, the third of four on writing character device drivers, introduces concepts of reading, writing, and using ioctl-calls".
  Keywords: read(), write(), select(), ioctl(), blocking/non blocking mode, interrupt handler.

• Dissecting Interrupts and Browsing DMA by Alessandro Rubini and Georg v. Zezschwitz.
  Description: Linux Journal Kernel Korner article. Here is it's abstract: "This is the fourth in a series of articles about writing character device drivers as loadable kernel modules. This month, we further investigate the field of interrupt handling. Though it is conceptually simple, practical limitations and constraints make this an ``interesting'' part of device driver writing, and several different facilities have been provided for different situations. We also investigate the complex topic of DMA".
  Keywords: interrupts, irqs, DMA, bottom halves, task queues.

• Device Drivers Concluded by Georg v. Zezschwitz.
  Description: Finally, the above turned out into a five articles series. This latest one's introduction reads: "This is the last of five articles about character device drivers. In this final section, Georg deals with memory mapping devices, beginning with an overall description of the Linux memory management concepts".
  Keywords: address spaces, pages, pagination, page management, demand loading, swapping, memory protection, memory mapping, mmap, virtual memory areas (VMAs), vremap, PCI.

• Network Buffers And Memory Management by Alan Cox.
  Description: Linux Journal Kernel Korner. Here is the abstract: "Writing a network device driver for Linux is fundamentally simple---most of the complexity (other than talking to the hardware) involves managing network packets in memory".
  Keywords: sk_buffs, network devices, protocol/link layer variables, network devices flags, transmit, receive, configuration, multicast.

• An Introduction to the Linux 1.3.x Networking Code by Vipul Gupta.
  Description: A short description of files under the net/ directory. Each file has a one or two lines paragraph description. sk_buffs explained, too, with some beautiful pictures. A little bit outdated.
  Keywords: files, sk_buffs.

• Linux ioctl() Primer by Vipul Gupta.
  Description: Little description and examples on the use and implementation of the ioctl() system call. A little bit biased towards sockets.
  Keywords: ioctl, socket.

• Writing Linux Device Drivers by Michael K. Johnson.
  Description: Introductory 50-minutes (sic) tutorial on writing device drivers. 12 pages written by the same author of the "Kernel Hackers' Guide" which give a very good overview of the topic.
  Keywords: files, VFS, file operations, kernel interface, character vs block devices, I/O access, hardware interrupts, DMA, access to user memory, memory allocation, timers.

• The Venus kernel interface by Peter J. Braam.
  Description: "This document describes the communication between Venus and kernel level file system code needed for the operation of the Coda filesystem. This version document is meant to describe the current interface (version 1.0) as well as improvements we envisage".
  Keywords: coda, filesystem, venus, cache manager.

• Programming PCI-Devices under Linux by Claus Schroeter.
  Description: 6 pages tutorial on PCI programming under Linux. Gives the basic concepts on the architecture of the PCI subsystem, as long as basic functions and macros to read/write the devices and perform busmastering.
  Keywords: PCI, device, busmastering.

• Writing Character Device Driver for Linux by R. Baruch and C. Schroeter.
  Description: 68 pages paper on writing character drivers. A little bit old (1.993, 1.994) although still useful.
  Keywords: character device drivers, I/O, signals, DMA, accesing ports in user space, kernel environment.

• The Linux Kernel Hackers' Guide by Michael K.Johnson and others.
  Description: No more Postscript book-like version. Only HTML now. Many people have contributed. The interface is similar to web available mailing lists archives. You can find some articles and then some mails asking questions about them and/or complementing previous contributions. A little bit anarchic in this aspect, but with some valuable information in some cases.
  Keywords: everything!

• Design and Implementation of the Second Extended by R閙y Card, Theodore Ts'o, Stephen Tweedie.
  Description: Paper written by three of the top ext2 hackers. Covers Linux filesystems history, ext2 motivation, ext2 features, design, physical structure on disk, performance, benchmarks, e2fsck's passes description... A must read! Notes: This paper was first published in the Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9.
  Keywords: ext2, linux fs history, inode, directory, link, devices, VFS, physical structure, performance, benchmarks, ext2fs library, ext2fs tools, e2fsck.

• The Second Extended Filesystem by Matthew Wilcox.
  Description: Description of ext2's blocks, directories, inodes... Notes: Seems to be DOWN. Anyone knows another link for it?
  Keywords: ext2, filesystem.

• Analysis of the Ext2fs structure by Louis-Dominique Dubeau.
  Description: Description of ext2's blocks, directories, inodes, bitmaps, invariants ...
  Keywords: ext2, filesystem, ext2fs.

• Journaling the Linux ext2fs Filesystem by Stephen C. Tweedie.
  Description: Excellent 8-pages paper explaining the journaling capabilities added to ext2 by the author, showing different problems faced and the alternatives chosen.
  Keywords: ext3, journaling.

• Kernel API changes from 2.0 to 2.2 by Richard Gooch.
  Description: Kernel functions/structures/variables which changed from 2.0.x to 2.2.x.
  Keywords: 2.2, changes.

• Kernel API changes from 2.2 to 2.3 by Richard Gooch.
  Description: Kernel functions/structures/variables which changed from 2.2.x to 2.3.x.
  Keywords: 2.3, changes.

• Linux Kernel Module Programming Guide by Ori Pomerantz.
  Description: Very nice 92 pages GPL book on the topic of modules programming. Lots of examples.
  Keywords: modules, GPL book, /proc, ioctls, system calls, interrupt handlers .

• Device File System (devfs) Overview by Richard Gooch.
  Description: Document describing Richard Gooch's controversial devfs, which allows for dynamic devices, only shows present devices in /dev, gets rid of major/minor numbers allocation problems, and allows for hundreds of identical devices (which some USB systems might demand soon).
  Keywords: filesystem, /dev, devfs, dynamic devices, major/minor allocation, device management.

• I/O Event Handling Under Linux by Richard Gooch.
  Description: From the Introduction: "I/O Event handling is about how your Operating System allows you to manage a large number of open files (file descriptors in UNIX/POSIX, or FDs) in your application. You want the OS to notify you when FDs become active (have data ready to be read or are ready for writing). Ideally you want a mechanism that is scalable. This means a large number of inactive FDs cost very little in memory and CPU time to manage".
  Keywords: IO, I/O, select(2), poll(2), FDs, aio_read(2), readiness event queues.

• The Kernel Hacking HOWTO by Various Talented People, and Rusty.
  Description: From the Introduction: "Please understand that I never wanted to write this document, being grossly underqualified, but I always wanted to read it, and this was the only way. I simply explain some best practices, and give reading entry-points into the kernel sources. I avoid implementation details: that's what the code is for, and I ignore whole tracts of useful routines. This document assumes familiarity with C, and an understanding of what the kernel is, and how it is used. It was originally written for the 2.3 kernels, but nearly all of it applies to 2.2 too; 2.0 is slightly different. ".
  Keywords: HOWTO, kernel contexts, deadlock, locking, modules, symbols, return conventions.

• Conceptual Architecture of the Linux Kernel by Ivan T. Bowman.
  Description: Conceptual software arquitecture of the Linux kernel, automatically extracted from the source code. Very detailed. Good figures. Gives good overall kernel understanding.
  Keywords: conceptual software arquitecture, extracted design, reverse engineering, system structure.

• ALSA 0.5.0 Developer documentation by Stephan 'Jumpy' Bartels .
  Description: Advanced Linux Sound Architecture for developers, both at kernel and user-level sides. Work in progress. ALSA is supposed to be Linux's next generation sound architecture.
  Keywords: ALSA, sound, soundcard, driver, lowlevel, hardware.

• Programming Guide for Linux USB Device Drivers by Detlef Fliegl.
  Description: A must-read. From the Preface: "This document should give detailed information about the current state of the USB subsystem and its API for USB device drivers. The first section will deal with the basics of USB devices. You will learn about different types of devices and their properties. Going into detail you will see how USB devices communicate on the bus. The second section gives an overview of the Linux USB subsystem [2] and the device driver framework. Then the API and its data structures will be explained step by step. The last section of this document contains a reference of all API calls and their return codes". Notes: Beware: the main page states: "This document may not be published, printed or used in excerpts without explicit permission of the author". Fortunately, it may still be read...
  Keywords: USB, universal serial bus.

• Tour Of the Linux Kernel Source by Vijo Cherian.
  Description: A classic of this page! Was lost for a while and is back again. Thanks Vijo! TOLKS: the name says it all. A tour of the sources, describing directories, files, variables, data structures... It covers general stuff, device drivers, filesystems, IPC and Networking Code.
  Keywords: .

• Linux Kernel Mailing List Glossary by John Levon.
  Description: From the introduction: "This glossary is intended as a brief description of some of the acronyms and terms you may hear during discussion of the Linux kernel".
  Keywords: glossary, terms, linux-kernel.

• Linux Kernel Locking HOWTO by Various Talented People, and Rusty.
  Description: The title says it all: document describing the locking system in the Linux Kernel either in uniprocessor or SMP systems. Notes: "It was originally written for the later (>2.3.47) 2.3 kernels, but most of it applies to 2.2 too; 2.0 is slightly different". Freely redistributable under the conditions of the GNU General Public License.
  Keywords: locks, locking, spinlock, semaphore, atomic, race condition, bottom halves, tasklets, softirqs.

• Porting Linux 2.0 Drivers To Linux 2.2 by Alan Cox.
  Description: Article from Linux Magazine on porting from 2.0 to 2.2 kernels.
  Keywords: ports, porting.

• Porting Device Drivers To Linux 2.2 by Alan Cox.
  Description: Second part on porting from 2.0 to 2.2 kernels.
  Keywords: ports, porting.

• How To Make Sure Your Driver Will Work On The Power by Paul Mackerras.
  Description: The title says it all.
  Keywords: Mac, Power Macintosh, porting, drivers, compatibility.

• An Introduction to SCSI Drivers by Alan Cox.
  Description: The title says it all.
  Keywords: SCSI, device, driver.

• Advanced SCSI Drivers And Other Tales by Alan Cox.
  Description: The title says it all.
  Keywords: SCSI, device, driver, advanced.

• Concrete Architecture of the Linux Kernel by Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan.
  Description: Concrete arquitecture of the Linux kernel, automatically extracted from the source code. Very detailed. Good figures. Gives good overall kernel understanding. This papers focus on lower details than its predecessor (files, variables...).
  Keywords: concrete arquitecture, extracted design, reverse engineering, system structure, dependencies.

• Writing Linux Mouse Drivers by Alan Cox.
  Description: The title says it all.
  Keywords: mouse, driver, gpm.

• More on Mouse Drivers by Alan Cox.
  Description: The title still says it all.
  Keywords: mouse, driver, gpm, races, asynchronous I/O.

• Writing Video4linux Radio Driver by Alan Cox.
  Description: The title says it all.
  Keywords: video4linux, driver, radio, radio devices.

• Video4linux Drivers, Part 1 by Alan Cox.
  Description: The title says it all.
  Keywords: video4linux, driver, video capture, capture devices, camera driver.

• Video4linux Drivers, Part 2 by Alan Cox.
  Description: The title says it all.
  Keywords: video4linux, driver, video capture, capture devices, camera driver, control, query capabilities, capability, facility.

• PCI Management in Linux 2.2 by Alan Cox.
  Description: The title says it all.
  Keywords: PCI, bus, bus-mastering.

• Linux 2.4 Kernel Internals by Tigran Aivazian.
  Description: A little book used for a short training course I gave on this subject at VERITAS. Covers building the kernel image, booting (including SMP), process management, VFS and more.
  Keywords: Linux, kernel, VFS, SMP boot

• Linux as a Case Study by Ivan T. Bowman, Richard C. Holt and Neil V. Brewster.
  Description: Paper appeared at ICSE'99, Los Angeles, May 16-22, 1999. A mixture of the previous two documents from the same author.
  Keywords: software architecture, architecture recovery, redocumentation.

• Overview of the Virtual File System by Richard Gooch.
  
  Keywords: VFS, File System, mounting filesystems, opening files, dentries, dcache. Description: Brief introduction to the Linux Virtual File System. What is it, how it works, operations taken when opening a file or mounting a file system and description of important data structures explaining the purpose of each of their entries.

• The Linux RAID-1, 4, 5 Code by Ingo Molnar, Gadi Oxman and Miguel de Icaza.
  Description: Linux Journal Kernel Korner article. Here is it's abstract: "A description of the implementation of the RAID-1, RAID-4 and RAID-5 personalities of the MD device driver in the Linux kernel, providing users with high performance and reliable, secondary-storage capability using software".
  Keywords: RAID, MD driver.

• Dynamic Kernels by Alessandro Rubini.
  Description: Linux Journal Kernel Korner article. Here is it's abstract: "This is the first of a series of four articles co-authored by Alessandro Rubini and Georg Zezchwitz which present a practical approach to writing Linux device drivers as kernel loadable modules. This installment presents an introduction to the topic, preparing the reader to understand next month's installment".
  Keywords: device driver, module, loading/unloading modules, allocating resources.

• Dynamic Kernels by Alessandro Rubini.
  Description: Linux Journal Kernel Korner article. Here is it's abstract: "This article, the second of four, introduces part of the actual code to create custom module implementing a character device driver. It describes the code for module initialization and cleanup, as well as the open() and close() system calls".
  Keywords: character driver, init_module, clean_up module, autodetection, mayor number, minor number, file operations, open(), close().

Polezni prepratki

• Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel -- 4ast ot Linux Kernel sources (Documentation dir)
• Slackware Linux Essentials
• Vyvedenie w GNU/Linux OS - u4ebnik ot LUG-BG
• Linux docs na ruski ezik

第一篇，哈哈……

测试一下看看哦～！

原文发表于 2004-12-30

Ivy的留言：人生就好比是砂，用两手捧起砂，砂会逐渐从细缝中流失。全部流掉的时候，就是低潮的时候。不过，砂是可以再捧起，再捧起一堆就好。人生，就是这样不断地重复。

Ivy 这句话不是回复 "责任" 这个话题的吧，应该是没有地方写，只好回复到那里。我猜对了没？

耳边响起的居然刚好是 陈亦迅 的《十年》，如此伤感的一首歌。sigh...

刚刚看到"用两手捧起砂"的时候，心理不由得紧张了一下，因为曾经听过这样的话：爱情就像一把细砂，你把它轻轻捧在手中，它就圆满；你把它用力握紧，它反而从指缝中流失。握得越紧，失去的越多，到最后所剩无几... 这句话让我难过了很长很长时间。直到现在，听到或者看到这句话，心理仍然有一种莫名的失落。

现在的我，已经接受了这句话。其实，不仅仅是爱情，很多事情都是这个道理。越是关心、越是担心、越是觉得它很重要，反倒会让自己失望，也会"迷失了自己"。[注：想起几天前收到朋友的一条短信中说的话："好好做你自己，不要因他人而强加给自己一些不喜欢的东西，要开心，好吗？"]

Ivy 比我乐观，砂可以再捧起。我却想，再也不能捧起原来的那些砂了，"物是人非事事休，欲语泪先流。" 或许我这人天生就比较喜欢记住一些过去的事情，怎么也忘不掉。

饿了，吃饭去啦。

原文发表于 2004-12-30

说好要写一些关于责任的看法的。今天晚上就偷个懒，随便写几个字吧。----又到年底了，应该做个小结，顺便抽点时间来灌水。 ^_^

去年英语课上学到 Jack London 那篇 "What life means to me" 的时候，老师让我们做一个 speech, topic 就是 "what life means to me". 思量了两三天，我选定在 responsibility 上。在我的眼里，生活，并不是开心就好，更多的，是责任。

生活，不是那么简单。童年时候梦想着自己可以赶快长大，真的长大了，却发现面对的是各种各样的责任。生活远比儿时想象得复杂，尽管再也没有作业。现在要承担的是对父母、亲人的责任，对自己未来家庭的责任，对社会的责任。每做一个重要的决定，最先要考虑的，就是父母 ---- 我没有自己期望得到的，但是不能没有父母，因为这是既成事实。正因如此，对父母的责任，是没有办法逃避的。自己做的很多选择，有时候虽然有违自己的意愿，为了父母，还是要努力去做好。

灵子说，儿孙自有儿孙福。殊不知父母难做啊！小时候不听话，奶奶常对我说"不养儿不知父母恩"。现在回家都觉得有些怕，怕给父母添太多的负担，怕他们为了让我吃点自己喜欢的东西而四处奔波，怕他们为我的将来而忧心忡忡，更怕自己没有什么成就作为回报。又快到回家的日子了，似乎又听到那首《常回家看看》，奶奶告诉我说，每次她听到这首歌都泪流满面。

举一个父母难做的例子吧。作为父母，都期望自己的孩子能够在自己的身边，奶奶也不例外，尤其是看到自己的孙子辈一个个外出读书、工作，她老人家更是挂念着。老爸就劝奶奶说，子女留在身边，天天都能看到，固然很好；可是如果留下来远不如在外地生活得好，是不是还不如就让子女自己出去闯荡呢？ ---- 作为父母，哪个不期望子女在自己的身边以享天伦之乐？可是如果子女真的能够生活得更好，他们却又宁可舍弃一些自己一直期望的东西。

一直认为，如果自己有了孩子，一定要自己带，哪怕自己再辛苦、再累，也一定要自己带。一个是不想让父母再为自己的事情操心，另一个是觉得这是自己的责任。孩子的成长，最重要的是父母。从我自己的成长，深刻地感受到父母对子女教育的重要。老妈曾经总结过，如果一个家庭中没有人对子女的教育比较重视，那么他们的子女很难有"出息"（姑且用这个词吧，老妈的原话，虽然我觉得这个词有些歧视）。老爸也说过这样一句话：对子女的教育是否成功，也是衡量一个人是否成功的标准之一。信然。

罗里罗嗦地写了一大堆，似乎也没怎么表达清楚。

原文发表于 2004-12-24

凌云版上的一个话题，刚好最近和朋友谈到这个话题很多，转一下。

研究生是否该告别纯情时代？

突然发觉，社会、生活已经为自己定位了，很多事情都不能象以前那样的了。不能象以前那样，傻傻的痴痴的爱，毫无顾忌地喜欢；不能象以前那样想干啥就干啥，有些事情必须要做，而且要做的很好；突然发觉路真的要自己去走了，要独立，什么都要自己干，没人可以帮你，只能靠自己，不再是跟哥们搭肩膀同挥汗的时光了，如果自己停下来，就会被抛弃的啦，而且被看不起。
第一次这么强烈的发觉，原来这么多人 在乎面子，在乎声望，在乎钱与名誉。呵呵，似乎真的没这么简单。这就是我孩提时代眼中的大人吗？一定不是。喜欢看爱国者，很为那父亲感动，我也有渴望，渴望成为英雄，就像小时候的梦一样。可生活真的很现实，简单是一种奢望。即使有点落寞、茫然，但路，毕竟要走啊，现实总是要面对。最大的现实就是社会的期望啊，呵呵，这就是生存。
为什么一定要看书、考试、做论文？难道是为了拿文凭。为什么要工作赚钱？为了成家，好生活？这里面是否有比较深沉的东西，我们都没挖掘出来的东西？
曾说，我最在乎的是爱，简单生活，简单的爱。能简单吗？
" 随心所欲 " ，这是我第一个暗恋的女生送给我的祝福，曾让我发愁的祝福。现在，甚至将来，也未必能做到。

====================================
曾经总是思考未来，却没有把握现在；如今当我们开始明白，努力去面对现在时，却失去了曾经的未来。

====================================
楼主的贴说出了许多人的心声，但却不包括现在的我。偶曾经一度也彷徨过，不过后来发现即使你再彷徨，发再多这样的贴，一样无济于事，于是我学会了顺其自然。我很崇拜庄子，崇拜他的那种与世无争。或许楼下有很多人会把你们所谓的"逆来顺受"加在我头上，但只要自己活得开心，再逆又有什么关系呢！楼主，站起来勇敢面对生活，以后得事情以后再说吧！！！

====================================
呵呵
比以前累是绝对的啦
在乎面子,声望和名誉
有的人是这个样子
但是也不全然是
因为 成长意味着责任
对父母的责任 对社会的责任
当然就没有办法想干什么就干什么了
拒绝成长
某种程度上是拒绝责任

ps:
偶实际上也经常觉得很累
也想傻傻的简单的过一辈子

====================================
当我猜到谜底，才发现，一切都已过去
岁月早已换了谜题。

很有这种感觉吧，当你发现你所追求的其实并不是你的需要时

====================================
因为 成长意味着责任
对父母的责任 对社会的责任
当然就没有办法想干什么就干什么了
拒绝成长
某种程度上是拒绝责任

can't agree more.
父母养育我们、培育我们至此。
小学、中学、大学、硕士、博士。
都是他们在付出啊，
我们理应长大，承担责任。
当你周围的长辈年老体弱的时候，
你要撑起一片天空，
就像他们年轻时候所做的那样。

====================================
说到点子上了。
是啊，是时候要自己撑起一片天了。：）

====================================
想简单生活就别读研究生
单纯体力劳动者的生活比较简单

====================================
随心所欲，谁都希望的。只是，社会赋予的角色，自己背负的包袱有点沉重啊。

====================================
我们应该学会承担责任了，父母在渐渐的老去；为他们，我们要做可能我们内心不是喜欢做的事，要去适应这个社会，要去改变自己的性格，活着并痛着，或许这就是现实，当童年的梦想渐渐远去，我们也慢慢变得平庸

原文发表于 2004-12-12

在寝室窝了一天，除了吃饭。可能和前两天看了《对话》出的一本书有关吧，今天还思考了挺多的。

洗澡时候突然想到老祖宗的一句话：君子之交淡如水，小人之交甘如醴。不禁佩服起古人的大智慧。记得有人这样比喻，人与人之间的关系就像是冬天里互相取暖的野猪，不能靠得太近，也不能离得太远：近了会因为身上的刺而互相伤害，远了又难以取暖。是不是自己在与人的交往之中也要注意如何把握这个度的问题呢？

应该好好反思一下来厦门后甚至在杭州时候的人际交往问题。