On Mon, Dec 12, 2005 at 01:48:45AM +0100, Marcus Brinkmann wrote: > This means that reference counting is now not done at the "map copy" > level of individual files, but at the "package-version" level of > process filesystem namespaces. Because process filesystem namespaces > are potentially dynamic and more or less an abstract concept anyway, I > think we have now moved far into the area where what actually should > happen is defined by policies and contracts rather than technical > features.
I think I must be missing something because this just seems to have compounded the problem. Originally the problem was when to reclaim the space occupied by the (relativly) small set of files that the activly running processes have open, now it's been expanded to whole packages. That being said, I think the idea is great and is the right way to go. It tidies up a lot of the package management mess that we have at the moment e.g. you could install a package, perform any tests you want to and if it isn't right you can remove the package without anything else being affected. With the current system upgrading something like libc has the potential to break lots of stuff in ways that are very difficult to recover from. Your previous mail seemed to suggest that each package would be installed in some big filesystem somewhere and (I'm guessing here) the login process would be responsible for creating the initial unionfs and passing that as the root filesystem that's going to be used by all processes inside that login. Not sure if that's described verbosely enough. The problem the package management has is then is that it needs to track live references to open packages. But the system already knows which files are open and which filesystems are mounted, why not use this existing code to do the package management's work? A package file could be a little filesystem, and the the login process would just mount the required packages, union them together and give them to the first process. The package management program would be free to delete any package file and it would only really get deleted when the last process that used it was killed. I'm not sure if that's helpful, it just feels cleaner to me if packages stay as little self contained blobs, rather than being extracted out into a parent file system. I'm not sure how much of a visible difference it would make to users of the system, but I think that it would simplify the package management code significantly if it could rely on the garbage collection being done, cleanly and completly, by the parent filesystem. Sam _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
