Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
The two sides of reflink()
Posted May 12, 2009 1:22 UTC (Tue) by giraffedata (subscriber, #1954)
If they weren't in the kernel, they'd need to be in some
userspace library (ew).
They work better in user space -- there's more flexibility there and the basic concept of a directory has nothing to do with resource allocation between users, which is what the kernel is for. Many OSes do them outside the kernel. The only reason they have to be in the kernel in Unix is that the kernel deletes files implicitly based on directory references. And as I've been saying, we'd be better off without that.
Posted May 12, 2009 19:59 UTC (Tue) by nix (subscriber, #2304)
Also it's a grotesque security hole: now you can't keep stuff secret by
hiding it in unreadable directories anymore.
Periodically there are proposals to introduce an open()-by-inode-number
syscall. They are always shot down. I don't know what sort of system
you're thinking of, but it isn't Unix.
(And if you're going to go that route, make the inums 1024 bits long and
bingo, you've got a capability-based system.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds