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
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
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
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
> "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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
