Commit Graph

5 Commits

Author SHA1 Message Date
Christoph Hellwig
0b1e987c56 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>
2022-05-18 15:30:17 +02:00
Krzysztof Błaszkowski
1cce170179 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>
2016-06-01 09:27:33 +02:00
Christoph Hellwig
2f137e31e0 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>
2016-06-01 09:23:24 +02:00
Krzysztof Błaszkowski
0d83f7fc83 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>
2016-06-01 09:01:28 +02:00
Linus Torvalds
1da177e4c3 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!
2005-04-16 15:20:36 -07:00