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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Oct 2008 00:42:33 +0100
From:	Phillip Lougher <phillip@...gher.demon.co.uk>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
CC:	akpm@...ux-foundation.org, linux-embedded@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	tim.bird@...sony.com
Subject: Re: Subject: [PATCH 00/16] Squashfs: compressed	read-only	filesystem

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 between a
> device and a socket?
> 

No, devices and fifo/sockets get their own unique inode numbers:

root@...ckware:/mnt# mount -t squashfs test.sqsh /mnt2 -o loop
root@...ckware:/mnt# ls -li /mnt2
total 0
2 crw-r--r-- 1 root root 1, 1 2008-10-22 00:31 device
4 prw-r--r-- 1 root root    0 2008-10-22 00:31 fifo
3 srwxr-xr-x 1 root root    0 2008-10-17 16:25 socket

struct squashfs_ipc_inode {
         __le16                  inode_type;
         __le16                  mode;
         __le16                  uid;
         __le16                  guid;
         __le32                  mtime;
         __le32                  inode_number;
         __le32                  nlink;
};

struct squashfs_dev_inode {
         __le16                  inode_type;
         __le16                  mode;
         __le16                  uid;
         __le16                  guid;
         __le32                  mtime;
         __le32                  inode_number;
         __le32                  nlink;
         __le32                  rdev;
};


> I use to work on Unionfs and we used CVS initially for our SCM. When we
> started working on mainlining Unionfs we moved over to a GIT based
> system and we found it worked a lot better. You might want to consider
> moving your patches to a GIT tree that you make publically available so
> people can just clone, compile, and test them. I don't see anything that
> stops Squashfs from being compiled and loaded as a module so it might
> not be necessary but it makes it easier for people who want to test the
> code or even contribute patches.


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.

Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/