Messages in this thread | | | Date | Thu, 30 Oct 2003 10:23:38 -0700 (MST) | From | Alex Belits <> | Subject | Re: Things that Longhorn seems to be doing right |
| |
On Thu, 30 Oct 2003, Ihar 'Philips' Filipau wrote:
> >>Keep in mind that just because Windows does thing a certain way > >>doesn't mean we have to provide the same functionality in exactly the > >>same way. > >>Also keep in mind that Microsoft very deliberately blurs what they do > >>in their "kernel" versus what they provide via system libraries (i.e., > >>API's provided via their DLL's, or shared libraries). > > > > Indeed, although certain things could be half-kernel, half-user > > (OK, 0.01% kernel, 99.99% user, e.g. userspace daemon that > > intercepts certain writes). Of course, at that point, you might > > make a special library to interact with the daemon directly, although > > it's then not at all like just calling write(). > > > > I beleive this is 100% user space issue. > > And I think if one really want to do something like this - Gnome's > VFS is a good candidate for this. They already have all abstractions in > place.
Why not just provide a general-purpose interface for:
1. Userspace-visible transactions. A userspace process can mark a set of fd, inodes, files, or "whatever this set of processes did since now", and tell the filesystem to keep a log of changes to that. Journaling will then mark relevant changes (and possibly create an additional log depending on the design, or pass the log-related information to another userspace program), and treat them as a transaction, with the possibility of rollback on kernel-originated error, userspace request, or, possibly, a transaction manager daemon, that may have its own reason to fail the transaction.
2. Update notifications. A set of files or directories, or whatever a certain set of processes accesses, is being monitored, and the list of changes (pages, byte ranges, lists of created/deleted directory entries) is somehow maintained and being passed to a set of processes. Processes can have passive monitoring (they will know what has been changed -- good for indexers and other kinds of application-specific daemons) or intrusive pass-through monitoring (the change is not applied until the process confirms it, and transaction interface applies to this if enabled -- this will be a performance hit, and can be done for, say, a distributed transaction manager).
3. Pluggable directory generator -- a userspace process can tell the system to make an object that looks exactly like a directory, except that its contents are provided by the process, that is being queried when the directory is accessed.
Obviously, the need for performance/asyncronous access and security requirements should be addressed in the implementations of those things, however relatively small scope of the interfaces can allow to do that in a more or less sane manner. Then userspace can have all kinds of indexing monstrosities, transaction-using databases, transaction managers, etc.
-- Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |