28 Apr, 2007

1 commit

  • I went to use this the other day, only to find it didn't exist.

    It's a straight copy of the debugfs u32 code, then s/u32/u64/. A quick
    test shows it seems to be working.

    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Michael Ellerman
     

17 Feb, 2007

1 commit

  • debugfs: implement symbolic links

    Implement a new function debugfs_create_symlink() which can be used
    to create symbolic links in debugfs. This function can be useful
    for people moving functionality from /proc to debugfs (e.g. the
    gcov-kernel patch).

    Signed-off-by: Peter Oberparleiter
    Signed-off-by: Greg Kroah-Hartman

    Peter Oberparleiter
     

13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

27 Sep, 2006

1 commit

  • The following patches reduce the size of the VFS inode structure by 28 bytes
    on a UP x86. (It would be more on an x86_64 system). This is a 10% reduction
    in the inode size on a UP kernel that is configured in a production mode
    (i.e., with no spinlock or other debugging functions enabled; if you want to
    save memory taken up by in-core inodes, the first thing you should do is
    disable the debugging options; they are responsible for a huge amount of bloat
    in the VFS inode structure).

    This patch:

    The filesystem or device-specific pointer in the inode is inside a union,
    which is pretty pointless given that all 30+ users of this field have been
    using the void pointer. Get rid of the union and rename it to i_private, with
    a comment to explain who is allowed to use the void pointer. This is just a
    cleanup, but it allows us to reuse the union 'u' for something something where
    the union will actually be used.

    [judith@osdl.org: powerpc build fix]
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Judith Lebzelter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Theodore Ts'o
     

26 Sep, 2006

1 commit


01 Jul, 2006

1 commit


29 Mar, 2006

1 commit

  • This is a conversion to make the various file_operations structs in fs/
    const. Basically a regexp job, with a few manual fixups

    The goal is both to increase correctness (harder to accidentally write to
    shared datastructures) and reducing the false sharing of cachelines with
    things that get dirty in .data (while .rodata is nicely read only and thus
    cache clean)

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

21 Mar, 2006

1 commit


07 Feb, 2006

1 commit


21 Jun, 2005

1 commit

  • Based on the discussion about spufs attributes, this is my suggestion
    for a more generic attribute file support that can be used by both
    debugfs and spufs.

    Simple attribute files behave similarly to sequential files from
    a kernel programmers perspective in that a standard set of file
    operations is provided and only an open operation needs to
    be written that registers file specific get() and set() functions.

    These operations are defined as

    void foo_set(void *data, u64 val); and
    u64 foo_get(void *data);

    where data is the inode->u.generic_ip pointer of the file and the
    operations just need to make send of that pointer. The infrastructure
    makes sure this works correctly with concurrent access and partial
    read calls.

    A macro named DEFINE_SIMPLE_ATTRIBUTE is provided to further simplify
    using the attributes.

    This patch already contains the changes for debugfs to use attributes
    for its internal file operations.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds