<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/include/linux/seq_file.h, branch linux-2.6.25.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.25.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.25.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2008-02-15T05:17:08Z</updated>
<entry>
<title>d_path: Make seq_path() use a struct path argument</title>
<updated>2008-02-15T05:17:08Z</updated>
<author>
<name>Jan Blunck</name>
</author>
<published>2008-02-15T03:38:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c32c2f63a9d6c953aaf168c0b2551da9734f76d2'/>
<id>urn:sha1:c32c2f63a9d6c953aaf168c0b2551da9734f76d2</id>
<content type='text'>
seq_path() is always called with a dentry and a vfsmount from a struct path.
Make seq_path() take it directly as an argument.

Signed-off-by: Jan Blunck &lt;jblunck@suse.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: "J. Bruce Fields" &lt;bfields@fieldses.org&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[NET]: Consolidate net namespace related proc files creation.</title>
<updated>2008-01-28T22:54:28Z</updated>
<author>
<name>Denis V. Lunev</name>
</author>
<published>2007-11-20T06:31:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e372c41401993b45c721c4d92730e7e0a79f7c1b'/>
<id>urn:sha1:e372c41401993b45c721c4d92730e7e0a79f7c1b</id>
<content type='text'>
Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Pavel Emelyanov &lt;xemul@openvz.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Fix f_version type: should be u64 instead of unsigned long</title>
<updated>2007-10-17T15:42:53Z</updated>
<author>
<name>Mathieu Desnoyers</name>
</author>
<published>2007-10-17T06:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2b47c3611de05c585e2d81204f6c7e3e255a3461'/>
<id>urn:sha1:2b47c3611de05c585e2d81204f6c7e3e255a3461</id>
<content type='text'>
Fix f_version type: should be u64 instead of long

There is a type inconsistency between struct inode i_version and struct file
f_version.

fs.h:

struct inode
  u64                     i_version;

and

struct file
  unsigned long           f_version;

Users do:

fs/ext3/dir.c:

if (filp-&gt;f_version != inode-&gt;i_version) {

So why isn't f_version a u64 ? It becomes a problem if versions gets
higher than 2^32 and we are on an architecture where longs are 32 bits.

This patch changes the f_version type to u64, and updates the users accordingly.

It applies to 2.6.23-rc2-mm2.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@polymtl.ca&gt;
Cc: Martin Bligh &lt;mbligh@google.com&gt;
Cc: "Randy.Dunlap" &lt;rdunlap@xenotime.net&gt;
Cc: Al Viro &lt;viro@ftp.linux.org.uk&gt;
Cc: &lt;linux-ext4@vger.kernel.org&gt;
Cc: Mark Fasheh &lt;mark.fasheh@oracle.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: "J. Bruce Fields" &lt;bfields@fieldses.org&gt;
Cc: Trond Myklebust &lt;trond.myklebust@fys.uio.no&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[FS] seq_file: Introduce the seq_open_private()</title>
<updated>2007-10-10T23:55:33Z</updated>
<author>
<name>Pavel Emelyanov</name>
</author>
<published>2007-10-10T09:28:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39699037a5c94d7cd1363dfe48a50c78c643fd9a'/>
<id>urn:sha1:39699037a5c94d7cd1363dfe48a50c78c643fd9a</id>
<content type='text'>
This function allocates the zeroed chunk of memory and
call seq_open(). The __seq_open_private() helper returns
the allocated memory to make it possible for the caller
to initialize it.

Signed-off-by: Pavel Emelyanov &lt;xemul@openvz.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Make common helpers for seq_files that work with list_heads</title>
<updated>2007-07-11T00:51:13Z</updated>
<author>
<name>Pavel Emelianov</name>
</author>
<published>2007-07-11T00:22:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bcf67e16251c42302499499b1c50f7d35622f564'/>
<id>urn:sha1:bcf67e16251c42302499499b1c50f7d35622f564</id>
<content type='text'>
Many places in kernel use seq_file API to iterate over a regular list_head.
The code for such iteration is identical in all the places, so it's worth
introducing a common helpers.

This makes code about 300 lines smaller:

The first version of this patch made the helper functions static inline
in the seq_file.h header. This patch moves them to the fs/seq_file.c as
Andrew proposed. The vmlinux .text section sizes are as follows:

2.6.22-rc1-mm1:              0x001794d5
with the previous version:   0x00179505
with this patch:             0x00179135

The config file used was make allnoconfig with the "y" inclusion of all
the possible options to make the files modified by the patch compile plus
drivers I have on the test node.

This patch:

Many places in kernel use seq_file API to iterate over a regular list_head.
The code for such iteration is identical in all the places, so it's worth
introducing a common helpers.

Signed-off-by: Pavel Emelianov &lt;xemul@openvz.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] struct seq_operations and struct file_operations constification</title>
<updated>2006-12-07T16:39:46Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2006-12-07T04:40:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=15ad7cdcfd76450d4beebc789ec646664238184d'/>
<id>urn:sha1:15ad7cdcfd76450d4beebc789ec646664238184d</id>
<content type='text'>
 - move some file_operations structs into the .rodata section

 - move static strings from policy_types[] array into the .rodata section

 - fix generic seq_operations usages, so that those structs may be defined
   as "const" as well

[akpm@osdl.org: couple of fixes]
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] sem2mutex: fs/seq_file.c</title>
<updated>2006-03-23T15:38:12Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2006-03-23T11:00:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0ac1759abc69fb62438c30a7e422f628a1120d67'/>
<id>urn:sha1:0ac1759abc69fb62438c30a7e422f628a1120d67</id>
<content type='text'>
Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2005-04-16T22:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
