Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-23 Thread Phillip Lougher
Geert Uytterhoeven wrote: Hi Phillip, On Fri, 17 Oct 2008, Phillip Lougher wrote: This is a second attempt at mainlining Squashfs. The first attempt was way This is great news! I ran a quick test of squashfs 4.0 (the CVS version) on UML/ia32 and ppc64, and it seems to work fine! G

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-22 Thread Geert Uytterhoeven
Hi Phillip, On Fri, 17 Oct 2008, Phillip Lougher wrote: > This is a second attempt at mainlining Squashfs. The first attempt was way This is great news! I ran a quick test of squashfs 4.0 (the CVS version) on UML/ia32 and ppc64, and it seems to work fine! Great job! Let's hope we'll s

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-22 Thread Tim Bird
Phillip Lougher wrote: > Yeah, Git is much better than CVS, however, I've got nowhere to host a > public Git repository. If someone were to offer hosting I'd be only too > happy to move over to Git. I can offer you hosting on mirror.celinuxforum.org. If you are interested, let me know and I'll s

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-22 Thread David Woodhouse
On Wed, 2008-10-22 at 00:42 +0100, Phillip Lougher wrote: > Yeah, Git is much better than CVS, however, I've got nowhere to host a > public Git repository. If someone were to offer hosting I'd be only too > happy to move over to Git. Mail me a SSH public key (use a passphrase on it), and I'll g

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-22 Thread Peter Korsgaard
> "Phillip" == Phillip Lougher <[EMAIL PROTECTED]> writes: Hi, Phillip> Yeah, Git is much better than CVS, however, I've got nowhere Phillip> to host a public Git repository. If someone were to offer Phillip> hosting I'd be only too happy to move over to Git. You could apply for a kernel

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread David P. Quigley
On Wed, 2008-10-22 at 00:42 +0100, Phillip Lougher wrote: > David P. Quigley wrote: > > > > > Looking through the code I noticed that you give certain object types > > the same inode number for all instances of it (devices, fifo/sockets). > > How is this done internally? Do these types of objects

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread Phillip Lougher
David P. Quigley wrote: Looking through the code I noticed that you give certain object types the same inode number for all instances of it (devices, fifo/sockets). How is this done internally? Do these types of objects occupy the same position on the inode table? If so how do you differentiate

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread Phillip Lougher
Alex Riesen wrote: 2008/10/17 Phillip Lougher <[EMAIL PROTECTED]>: There are 16 patches in the patch set, and the patches are against the latest linux-next tree (linux 2.6.27-next-20081016). You better don't base anything off linux-next. These are not stable: there can be even something in the

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread Alex Riesen
2008/10/17 Phillip Lougher <[EMAIL PROTECTED]>: > There are 16 patches in the patch set, and the patches are against the > latest linux-next tree (linux 2.6.27-next-20081016). You better don't base anything off linux-next. These are not stable: there can be even something in the tree you mentioned

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread David P. Quigley
On Tue, 2008-10-21 at 02:12 +0100, Phillip Lougher wrote: > David P. Quigley wrote: > > Looking through the code I see two references to xattrs, one is the > > index of the xattr table in the superblock and there seems to be struct > > member in one of the inode structures that is an index into thi

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-21 Thread Stephen Smalley
On Tue, 2008-10-21 at 02:12 +0100, Phillip Lougher wrote: > David P. Quigley wrote: > > Looking through the code I see two references to xattrs, one is the > > index of the xattr table in the superblock and there seems to be struct > > member in one of the inode structures that is an index into thi

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-20 Thread Phillip Lougher
David P. Quigley wrote: In SELinux and other LSMs symlinks and directories are also labeled so they will need xattr entries. BTW you don't mention device, fifo and socket inodes... Do they ever get labelled? It's something I was going to look into closer to an implementation, but it would

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-20 Thread Phillip Lougher
David P. Quigley wrote: Looking through the code I see two references to xattrs, one is the index of the xattr table in the superblock and there seems to be struct member in one of the inode structures that is an index into this table. Looking through the code I don't see either of these used at

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-17 Thread David P. Quigley
Looking through the code I see two references to xattrs, one is the index of the xattr table in the superblock and there seems to be struct member in one of the inode structures that is an index into this table. Looking through the code I don't see either of these used at all. Do you intend to add

Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-17 Thread Jörn Engel
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote: > > Codewise all of the packed bit-fields and the swap macros have been removed in > favour of aligned structures and in-line swapping using leXX_to_cpu(). The > code has also been extensively restructured, reformatted to kernel codin

Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem

2008-10-17 Thread Phillip Lougher
This is a second attempt at mainlining Squashfs. The first attempt was way way back in early 2005 :-) Since then the filesystem layout has undergone two major revisions, and the kernel code has almost been completely rewritten. Both of these were to address the criticisms made at the original at