History log of /linux-master/fs/freevxfs/vxfs.h
Revision Date Author Comments
# 0b1e987c 16-May-2022 Christoph Hellwig <hch@lst.de>

freevxfs: relicense to GPLv2 only

When I wrote the freevxfs driver I had some odd choice of licensing
statements, the options are either GPL (without version) or an odd
BSD-ish licensense with advertising clause.

The GPL vs always meant to be the same as the kernel, that is version
2 only, and the odd BSD-ish license doesn't make much sense. Add
a GPL2.0-only SPDX tag to make the GPL intentions clear and drop the
bogus BSD license.

Acked-by: Krzysztof Błaszkowski <kb@sysmikro.com.pl>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 1cce1701 01-Jun-2016 Krzysztof Błaszkowski <kb@sysmikro.com.pl>

freevxfs: update documentation and cresdits for HP-UX support

Signed-off-by: Krzysztof Błaszkowski <kb@sysmikro.com.pl>
[hch: cosmetic updates]
Signed-off-by: Christoph Hellwig <hch@lst.de>


# 2f137e31 01-Jun-2016 Christoph Hellwig <hch@lst.de>

freevxfs: implement ->alloc_inode and ->destroy_inode

This driver predates those methods and was trying to be clever allocating
it's own private data. Switch to the generic scheme used by other file
systems.

Based on an earlier patch from Krzysztof Błaszkowski <kb@sysmikro.com.pl>.

Signed-off-by: Christoph Hellwig <hch@lst.de>


# 0d83f7fc 31-May-2016 Krzysztof Błaszkowski <kb@sysmikro.com.pl>

freevxfs: handle big endian HP-UX file systems

To support VxFS filesystems from HP-UX on x86 systems we need to
implement byte swapping, and to keep support for Unixware filesystems
it needs to be the complicated dual-endian kind ala sysvfs.

To do this properly we have to split the on disk and in-core inode
so that we can keep the in-core one in native endianness. All other
structures are byteswapped on demand.

Signed-off-by: Krzysztof Błaszkowski <kb@sysmikro.com.pl>
[hch: make spare happy]
Signed-off-by: Christoph Hellwig <hch@lst.de>


# 8e18e294 27-Sep-2006 Theodore Ts'o <tytso@mit.edu>

[PATCH] inode_diet: Replace inode.u.generic_ip with inode.i_private

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" <tytso@mit.edu>
Signed-off-by: Judith Lebzelter <judith@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>


# 552c0348 25-Jun-2006 Cliff Wickman <cpw@sgi.com>

[PATCH] fs/freevxfs: cleanup of spelling errors

Fix of some spelling errors in fs/freevxfs error messages and comments

Signed-off-by: Cliff Wickman <cpw@sgi.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>


# 1d2cc3b8 30-Jun-2005 Pekka Enberg <penberg@cs.helsinki.fi>

[PATCH] freevxfs: remove 2.4 compatability

This patch removes 2.4 compatability header from freevxfs.

Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>


# 1da177e4 16-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

Linux-2.6.12-rc2

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!