Messages in this thread | | | From | Peter Swain <> | Subject | Re: Thread implementations... poll() on regular files | Date | Tue, 23 Jun 1998 20:06:16 +1000 (EST) |
| |
Richard Gooch wrote: > Dean Gaudet writes: > > On Tue, 23 Jun 1998, Richard Gooch wrote: > > > ext2? You mean regular files? > > Yeah. > You currently can't poll for when a regular file delivers the block of > data you asked for. I'm not aware of any UNIX that supports this. > This is a whole new can of worms than the implementation of completion > ports/whatever.
interesting can of worms, but. worth playing with.
<sermon> it gives a userland interface to all sorts of things which currently do happen, but are hidden in kernel (supporting buffer-cache, knfs, dcache, ...)
consider what happens if poll() gets extended to all vfs objects... and readdir() returns add/delete/change events, optionally on subdirs, too.
"tail -f" loses it's sleep(1), and reduces to poll()
"find ..... -poll" keeps files/dirs open, awaits any inode change, and utters the name (and -printf"..." details) of altered inodes
"make --persist" accumulates a bag of fds for everything it ever stat()'d, and checks for up-to-date-ness on each twitch. No, too many fds! But consider what happens if you just keep the dirs open -- much lower o'head.
daemons which scan a spool dir need only opendir("...", ONONBLOCK), readdir() the static entries to eof, then poll() for changes.
All of the above suggest kernel bloat & extra overhead, but when such concepts are needed by an application, they're currently accomplished much less efficient userland versions -- the challenge is finding space-efficient kernel representation which wastes no time when not utilised, and much less than the userland alternative when they are used. Ideally piggybacking on existing kernel concepts (which most of it does).
readdir() and find would have to grow to embrace a different object type, the recently-expunged entity. But that's supported in many places already -- ext2's dtime, negative dcache entries, stat's ENOENT.
An all-embracing poll() allows user-level access to waitq and notify concepts. I had a low-impact mudmap of the concept somewhere, time to dig it out again. Requires a sort of preemptible resource locking, where (one/all of) a list of interested parties are notified when a lock is released. Difference is that said parties don't ever acquire the lock, they just sniff around it whenever it rattles (equivalently, they do (collectively) acquire the lock in a multi-snooper-multi-reader-one-writer sense, where snoopers are readers w/o the right to *lock* it, but just get notified with a callback when the lock gets grabbed from under them). Since i last played with this, linux has grown a notify concept, which could? be stretched to fit, i think.
i suspect the main reason it's never been attempted in the past is the great simplification of security hacks, where one can do fds[0].fd = opendir("/tmp", ONONBLOCK);
for (;;) { poll(fds, 1, -1);
// see if we've caught any interesting // switch+grab possibilities while (readdir(fds[0].fd, dirent...) >= 0) { if (!strncmp(dirent.name, "mail-temp-prefix", 16)) { //gotcha // try an insecure-mail-handler exploit } else ..... } }
these usually spin on readdir() or stat("/tmp"), thus their priority goes down enuff that the window-of-opportunity slams shut on their fingers. With a publicly-scrutinised gnu/linux toolset, the number of such holes goes down rapidly, especially since the same principle can be employed in satan-for-filesystems type security monitors.
does this enthuse anyone? It's not new.
It seemed to be implied twixt the lines of the original 4bsd manifesto's everything-is-a-descriptor concepts. i certainly saw it there, back in the days when symlinks were young, and had '@' in their names.
[see also plan9, recent Lucent stuff, ....]
But such grand-unified-theory-of-namespaces dreams got quiely buried by the USG's market-driven KISS, which kept all complexity hived off into separate corners, to avoid startling the horses. Witness sysv-shmem, which refused to have vfs access (/proc/shm/*) on the (not insubstantial) grounds that VMS-pundits would mutter "psst, that unix shit puts shared-memory on *disk*". POSIX shared-mem has at last done a mount() of shm, msg, ...! I'd like to do the reverse, and extend kernel's event system out thru vfs.
Linux is getting to the point where these concepts can be bridged, with almost no cost to internal complexity, as the scaffolding already bridges most gaps for other reasons. One day i'll string a rope across & pull them together.
People have been selling big, heavy custom bridges across this space for years. They're called DBMSs, and they've traditionally sucked every concept they touched inside themselves because they couldn't be built around simple portable event-aware interfaces, as a sufficient set didn't exist.
</sermon>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |