summaryrefslogtreecommitdiff
path: root/fs/freevxfs/vxfs_inode.h
AgeCommit message (Collapse)AuthorFilesLines
2022-05-18freevxfs: relicense to GPLv2 onlyChristoph Hellwig1-26/+1
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>
2016-06-01freevxfs: update documentation and cresdits for HP-UX supportKrzysztof Błaszkowski1-0/+1
Signed-off-by: Krzysztof Błaszkowski <kb@sysmikro.com.pl> [hch: cosmetic updates] Signed-off-by: Christoph Hellwig <hch@lst.de>
2016-06-01freevxfs: implement ->alloc_inode and ->destroy_inodeChristoph Hellwig1-0/+7
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>
2016-06-01freevxfs: handle big endian HP-UX file systemsKrzysztof Błaszkowski1-66/+72
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>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+180
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!