Linux 2.6驱动移植指南

需积分: 10 198 浏览量更新于2024-07-25 收藏 1.27MB PDF 举报

"Porting device drivers to the 2.6 kernel" 这篇资源并不是一本传统的书籍，而是一系列关于Linux 2.6内核驱动移植的文章集合，由晏渭川整理并提供。这些文章最初在LWN（Linux Weekly News）网站上发布，并且详细介绍了驱动开发者在将设备驱动程序迁移到2.6内核时所需面对的改动和挑战。在Linux 2.6内核中，有许多对设备驱动编写者至关重要的变更。作者，即LWN Kernel Page的作者，通过一系列文章详细阐述了移植过程中必须进行的修改。这些文章最初在LWN网站上逐篇发布，并且这个文档汇集了所有的内容，有望成为那些需要将驱动迁移到新内核的开发者的实用参考资料。请注意，这些文章的创建是由于LWN.net订阅者的支持。如果你发现这些资料对你有所帮助，作者鼓励你考虑订阅LWN，以支持更多此类内容的创作。尽管没有明确指出，但以下列出的所有文章均由LWN编辑Jonathan Corbet撰写。每篇文章后面的日期和内核版本表示该文章最后一次更新的时间。虽然这里只提供了文章的前两页内容，但可以推断出完整的文档将涵盖以下主题： 1. 内核API的改变：2.6内核可能引入了新的接口或废弃了旧的接口，驱动开发者需要了解这些变化以便更新代码。 2. 中断处理的调整：内核2.6可能对中断处理机制进行了优化，驱动需要相应地调整中断注册和处理函数。 3. 内存管理改进：2.6内核可能采用了更先进的内存管理策略，这可能影响到驱动程序如何分配和释放内存。 4. 性能优化：2.6内核可能包含了一些针对性能提升的改动，驱动开发者需要确保驱动程序能够利用这些改进。 5. 完成和中断模型：可能涉及到中断完成机制的更新，以及如何正确处理中断完成通知。 6. 硬件状态的保存与恢复：在内核版本升级后，驱动可能需要更新以正确地保存和恢复硬件状态。 7. 错误处理和调试：新的内核可能会提供更好的错误报告机制，驱动需要适应这些变化以提高调试效率。此外，原文中提到在LWN.net上可以找到每篇文章对应的Comment & Reply，这部分内容在文档中并未收录，但提供了查阅原始讨论的途径，对于深入理解和解决问题可能是非常有价值的补充资源。这篇文档对于那些需要将设备驱动程序从早期的Linux内核移植到2.6内核的专业人士来说，是一个宝贵的指南，它详尽地解释了移植过程中的技术细节和注意事项。

Porting device drivers to the 2.6 kernel

• An iterator interface which lets a virtual file implementation step through the objects it is

presenting.

• Some utility functions for formatting objects for output without needing to worry about

things like output buffers.

• A set of canned file_operations which implement most operations on the virtual file.

We'll look at the seq_file interface via an extremely simple example: a loadable module which

creates a file called

/proc/sequence. The file, when read, simply produces a set of increasing

integer values, one per line. The sequence will continue until the user loses patience and finds

something better to do. The file is seekable, in that one can do something like the following:

dd if=/proc/sequence of=out1 count=1

dd if=/proc/sequence skip=1 out=out2 count=1

Then concatenate the output files

out1 and out2 and get the right result. Yes, it is a thoroughly

useless module, but the point is to show how the mechanism works without getting lost in other

details. (Those wanting to see the full source for this module can find it

here).

The iterator interface

Modules implementing a virtual file with seq_file must implement a simple iterator object that

allows stepping through the data of interest. Iterators must be able to move to a specific position -

like the file they implement - but the interpretation of that position is up to the iterator itself. A

seq_file implementation that is formatting firewall rules, for example, could interpret position N as

the Nth rule in the chain. Positioning can thus be done in whatever way makes the most sense for

the generator of the data, which need not be aware of how a position translates to an offset in the

virtual file. The one obvious exception is that a position of zero should indicate the beginning of

the file.

The

/proc/sequence iterator just uses the count of the next number it will output as its position.

Four functions must be implemented to make the iterator work. The first, called

start() takes a

position as an argument and returns an iterator which will start reading at that position. For our

simple sequence example, the

start() function looks like:

static void *ct_seq_start(struct seq_file *s, loff_t *pos)

{

loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);

if (! spos)

return NULL;

*spos = *pos;

return spos;

}

The entire data structure for this iterator is a single

loff_t value holding the current position. There

is no upper bound for the sequence iterator, but that will not be the case for most other seq_file

implementations; in most cases the

start() function should check for a "past end of file" condition

and return

NULL if need be.

For more complicated applications, the

private field of the seq_file structure can be used. There

is also a special value whch can be returned by the

start() function called SEQ_START_TOKEN; it

can be used if you wish to instruct your

show() function (described below) to print a header at the

Porting device drivers to the 2.6 kernel

top of the output. SEQ_START_TOKEN should only be used if the offset is zero, however.

The next function to implement is called, amazingly,

next(); its job is to move the iterator forward

to the next position in the sequence. The example module can simply increment the position by

one; more useful modules will do what is needed to step through some data structure. The

next()

function returns a new iterator, or

NULL if the sequence is complete. Here's the example version:

static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)

{

loff_t *spos = (loff_t *) v;

*pos = ++(*spos);

return spos;

}

The

stop() function is called when iteration is complete; its job, of course, is to clean up. If

dynamic memory is allocated for the iterator,

stop() is the place to return it.

static void ct_seq_stop(struct seq_file *s, void *v)

{

kfree (v);

}

Finally, the

show() function should format the object currently pointed to by the iterator for

output. It should return zero, or an error code if something goes wrong. The example module's

show() function is:

static int ct_seq_show(struct seq_file *s, void *v)

{

loff_t *spos = (loff_t *) v;

seq_printf(s, "%Ld\n", *spos);

return 0;

}

We will look at

seq_printf() in a moment. But first, the definition of the seq_file iterator is

finished by creating a

seq_operations structure with the four functions we have just defined:

static struct seq_operations ct_seq_ops = {

.start = ct_seq_start,

.next = ct_seq_next,

.stop = ct_seq_stop,

.show = ct_seq_show

};

This structure will be needed to tie our iterator to the

/proc file in a little bit.

It's worth noting that the interator value returned by

start() and manipulated by the other functions

is considered to be completely opaque by the seq_file code. It can thus be anything that is useful

in stepping through the data to be output. Counters can be useful, but it could also be a direct

pointer into an array or linked list. Anything goes, as long as the programmer is aware that things

can happen between calls to the iterator function. However, the seq_file code (by design) will not

sleep between the calls to

start() and stop(), so holding a lock during that time is a reasonable

thing to do. The seq_file code will also avoid taking any other locks while the iterator is active.

Formatted output

Porting device drivers to the 2.6 kernel

The seq_file code manages positioning within the output created by the iterator and getting it into

the user's buffer. But, for that to work, that output must be passed to the seq_file code. Some

utility functions have been defined which make this task easy.

Most code will simply use

seq_printf(), which works pretty much like printk(), but which

requires the

seq_file pointer as an argument. It is common to ignore the return value from

seq_printf(), but a function producing complicated output may want to check that value and quit

if something non-zero is returned; an error return means that the seq_file buffer has been filled and

further output will be discarded.

For straight character output, the following functions may be used:

int seq_putc(struct seq_file *m, char c);

int seq_puts(struct seq_file *m, const char *s);

int seq_escape(struct seq_file *m, const char *s, const char *esc);

The first two output a single character and a string, just like one would expect.

seq_escape() is

seq_puts(), except that any character in s which is in the string esc will be represented in

octal form in the output.

There is also a function for printing filenames:

int seq_path(struct seq_file *m, struct vfsmount *mnt,

struct dentry *dentry, char *esc);

Here,

mnt and dentry indicate the file of interest, and esc is a set of characters which should be

escaped in the output. This function is more suited to filesystem code than device drivers,

however.

Making it all work

So far, we have a nice set of functions which can produce output within the seq_file system, but

we have not yet turned them into a file that a user can see. Creating a file within the kernel

requires, of course, the creation of a set of

file_operations which implement the operations on

that file. The seq_file interface provides a set of canned operations which do most of the work.

The virtual file author still must implement the

open() method, however, to hook everything up.

The open function is often a single line, as in the example module:

static int ct_open(struct inode *inode, struct file *file)

{

return seq_open(file, &ct_seq_ops);

};

Here, the call to

seq_open() takes the seq_operations structure we created before, and gets set

up to iterate through the virtual file.

On a successful open,

seq_open() stores the struct seq_file pointer in file->private_data. If

you have an application where the same iterator can be used for more than one file, you can store

an arbitrary pointer in the

private field of the seq_file structure; that value can then be retrieved

by the iterator functions.

The other operations of interest -

read(), llseek(), and release() - are all implemented by the

seq_file code itself. So a virtual file's

file_operations structure will look like:

static struct file_operations ct_file_ops = {

.owner = THIS_MODULE,

.open = ct_open,

Porting device drivers to the 2.6 kernel

The old <linux/malloc.h> include file is gone; it is now necessary to include <linux/slab.h>

instead.

The

GFP_BUFFER allocation flag is gone (it was actually removed in 2.4.6). That will bother few

people, since almost nobody used it. There are two new flags which have replaced it:

GFP_NOIO

and

GFP_NOFS. The GFP_NOIO flag allows sleeping, but no I/O operations will be started to

help satisfy the request.

GFP_NOFS is a bit less restrictive; some I/O operations can be started

(writing to a swap area, for example), but no filesystem operations will be performed.

For reference, here is the full set of allocation flags, from the most restrictive to the least::

GFP_ATOMIC: a high-priority allocation which will not sleep; this is the flag to use in interrupt

handlers and other non-blocking situations.

GFP_NOIO: blocking is possible, but no I/O will be performed.

GFP_NOFS: no filesystem operations will be performed.

GFP_KERNEL: a regular, blocking allocation.

GFP_USER: a blocking allocation for user-space pages.

GFP_HIGHUSER: for allocating user-space pages where high memory may be used.

The

__GFP_DMA and __GFP_HIGHMEM flags still exist and may be added to the above to direct

an allocation to a particular memory zone. In addition, 2.5.69 added some new modifiers:

__GFP_REPEAT This flag tells the page allocater to "try harder," repeating failed allocation

attempts if need be. Allocations can still fail, but failure should be less likely.

__GFP_NOFAIL Try even harder; allocations with this flag must not fail. Needless to say, such an

allocation could take a long time to satisfy.

__GFP_NORETRY Failed allocations should not be retried; instead, a failure status will be

returned to the caller immediately.

The

__GFP_NOFAIL flag is sure to be tempting to programmers who would rather not code failure

paths, but that temptation should be resisted most of the time. Only allocations which truly cannot

be allowed to fail should use this flag.

Page-level allocation

For page-level allocations, the alloc_pages() and get_free_page() functions (and variants)

exist as always. They are now defined in

<linux/gfp.h>, however, and there are a few new ones

as well. On NUMA systems, the allocator will do its best to allocate pages on the same node as the

caller. To explicitly allocate pages on a different NUMA node, use:

struct page *alloc_pages_node(int node_id,

unsigned int gfp_mask,

unsigned int order);

The memory allocator now distinguishes between "hot" and "cold" pages. A hot page is one that is

likely to be represented in the processor's cache; cold pages, instead, must be fetched from RAM.

In general, it is preferable to use hot pages whenever possible, since they are already cached. Even

if the page is to be overwritten immediately (usually the case with memory allocations, after all),

hot pages are better - overwriting them will not push some other, perhaps useful, data from the

cache. So

alloc_pages() and friends will return hot pages when they are available.

On occasion, however, a cold page is preferable. In particular, pages which will be overwritten via

a DMA read from a device might as well be cold, since their cache data will be invalidated

anyway. In this sort of situation, the

__GFP_COLD flag should be passed into the allocation.

剩余97页未读，继续阅读

gyj0754

粉丝: 9
资源: 11

Linux 2.6驱动移植指南

Porting device drivers to the 2.6 kernel

Linux Device Drivers (2.6 Kernels)

How to Port a Driver from 2.4 to 2.6 Kernels

Rebuild the library with Windows, GTK+ 2.x or Cocoa support

porting layer时间什么

ERROR: Could not find a version that satisfies the requirement PyXML (from versions: none) ERROR: No matching distribution found for PyXML

void sl_notify_gap_evt_to_porting_layer(sl_bt_msg_t *evt)

freertos sqlite3

蓝牙协议栈到mcu的移植 最新文献?

最新资源

蓝牙协议栈到mcu的移植最新文献?