Re: интерфейс seq_file в ядре Linux
Documentation/filesystems/seq_file.txt
#ls Documentation/filesystems/s*
Documentation/filesystems/smbfs.txt Documentation/filesystems/sysfs-pci.txt Documentation/filesystems/sysv-fs.txt
Documentation/filesystems/spufs.txt Documentation/filesystems/sysfs.txt
2.6.25
Киньте, пожалуйста, описание интерфейса seq_file из инетанет инета
запости, пожалуйста, seq_file.txt здесь
зачем напрягать других, когда сам можешь скачать ядро поновее из локалки
в каких ты ебенях что сырцов ядра свежих нет под рукой?
там интерфейс тупой — по реализации или использованию сразу всё ясно.
там интерфейс тупой — по реализации или использованию сразу всё ясно.
нету тут
у грина разве нету?
я на green (172.16.254.11) не могу зайти, даже не пингуется
Ладно, тема уже ушла от первоначального направления.
Я не хочу никого напрягать, просто, если у кого есть возможность выложить seq_file.txt, выложите пожалуйста, если нет - то не напрягайтесь
Я не хочу никого напрягать, просто, если у кого есть возможность выложить seq_file.txt, выложите пожалуйста, если нет - то не напрягайтесь
The seq_file interface
Copyright 2003 Jonathan Corbet <lwn.net>
This file is originally from the LWN.net Driver Porting series at
http://lwn.net/Articles/driver-porting/
There are numerous ways for a device driver (or other kernel component) to
provide information to the user or system administrator. One useful
technique is the creation of virtual files, in debugfs, /proc or elsewhere.
Virtual files can provide human-readable output that is easy to get at
without any special utility programs; they can also make life easier for
script writers. It is not surprising that the use of virtual files has
grown over the years.
Creating those files correctly has always been a bit of a challenge,
however. It is not that hard to make a virtual file which returns a
string. But life gets trickier if the output is long - anything greater
than an application is likely to read in a single operation. Handling
multiple reads (and seeks) requires careful attention to the reader's
position within the virtual file - that position is, likely as not, in the
middle of a line of output. The kernel has traditionally had a number of
implementations that got this wrong.
The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
which are designed to make it easy for virtual file creators to get it
right.
The seq_file interface is available via <linux/seq_file.h>. There are
three aspects to seq_file:
* 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 at
http://lwn.net/Articles/22359/%29.
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 which 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
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 = 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 free 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. The example module's show function is:
static int ct_seq_show(struct seq_file *s, void *v)
{
loff_t *spos = v;
seq_printf(s, "%lld\n", (long long)*spos);
return 0;
}
If all is well, the show function should return zero. A negative error
code in the usual manner indicates that something went wrong; it will be
passed back to user space. This function can also return SEQ_SKIP, which
causes the current item to be skipped; if the show function has already
generated output before returning SEQ_SKIP, that output will be dropped.
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 const 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 iterator 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 (
Copyright 2003 Jonathan Corbet <lwn.net>
This file is originally from the LWN.net Driver Porting series at
http://lwn.net/Articles/driver-porting/
There are numerous ways for a device driver (or other kernel component) to
provide information to the user or system administrator. One useful
technique is the creation of virtual files, in debugfs, /proc or elsewhere.
Virtual files can provide human-readable output that is easy to get at
without any special utility programs; they can also make life easier for
script writers. It is not surprising that the use of virtual files has
grown over the years.
Creating those files correctly has always been a bit of a challenge,
however. It is not that hard to make a virtual file which returns a
string. But life gets trickier if the output is long - anything greater
than an application is likely to read in a single operation. Handling
multiple reads (and seeks) requires careful attention to the reader's
position within the virtual file - that position is, likely as not, in the
middle of a line of output. The kernel has traditionally had a number of
implementations that got this wrong.
The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
which are designed to make it easy for virtual file creators to get it
right.
The seq_file interface is available via <linux/seq_file.h>. There are
three aspects to seq_file:
* 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 at
http://lwn.net/Articles/22359/%29.
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 which 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
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 = 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 free 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. The example module's show function is:
static int ct_seq_show(struct seq_file *s, void *v)
{
loff_t *spos = v;
seq_printf(s, "%lld\n", (long long)*spos);
return 0;
}
If all is well, the show function should return zero. A negative error
code in the usual manner indicates that something went wrong; it will be
passed back to user space. This function can also return SEQ_SKIP, which
causes the current item to be skipped; if the show function has already
generated output before returning SEQ_SKIP, that output will be dropped.
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 const 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 iterator 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 (
Спасибо большое
маршрутизация правильно настроена?
Я бы скорее предположил, что у него гостевой IP.
я на green (172.16.254.11) не могу зайти, даже не пингуетсяу меня есть, и ты от меня пингуешься
а у тебя ip гостевой, насколько я понимаю
Спасибо за информацию,
видно заявки по СМС не действуют.
видно заявки по СМС не действуют.
Оставить комментарий
Nika2303
Киньте, пожалуйста, описание интерфейса seq_file из инета или так расскажите.