commit | 60c2f41705b8816a451a595fb16677dc9e5da1f1 | [log] [tgz] |
---|---|---|
author | Victor Hsieh <victorhsieh@google.com> | Wed Nov 03 13:02:19 2021 -0700 |
committer | Victor Hsieh <victorhsieh@google.com> | Fri Nov 05 08:28:00 2021 -0700 |
tree | 7776d1cbe70242d72bfe77ccbdc4113b61de2717 | |
parent | 26cea2f6ab7867afc25833bfc208fc163b4b2e86 [diff] |
Assign inode values properly in AuthFS Previously, inode_table provides inode -> entry mapping, and the inode value is derived from the entry name, which is supposed to be the remote FD value. That is, remote FD was equal to the filesystem entry name as string and the actual inode value inside the filesystem. This change makes inode an internal notion in the filesystem, which is really the correct way. When a client provides the path -> entry mapping (root_entries), AuthFS now breaks it into two mappings (see below) and assigns the inode for its own internal purpose. To look up an entry in to root directory, we use the path -> inode table (root_entries) to find the inode, then look for the actual entry with the inode -> entry table (inode_table). This gives us the freedom to add more inodes without risking breaking existing entries. It also makes it possible to create inodes not backing by a remote FD. For example, later we could open file by path like "framework/framework.jar" relative to a path FD of /system on the host side. That is, we wouldn't necessarily need to open "/system/framework" and create an inode, then use that inode to open "framework.jar". Bug: 203251769 Test: atest AuthFsHostTest Change-Id: I49b222b91002da12a25fbf03b0c6285f0223f16b
This repository contains userspace services related to running virtual machines on Android, especially protected virtual machines. See the getting started documentation and Microdroid README for more information.