Date: Fri, 30 Mar 2001 13:10:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rjesup@wgate.com Cc: tlambert@primenet.com (Terry Lambert), jar@integratus.com (Jack Rusher), freebsd-arch@FreeBSD.ORG (freebsd-arch@FreeBSD.ORG) Subject: Re: configuration files Message-ID: <200103301310.GAA06817@usr05.primenet.com> In-Reply-To: <ybupuf0ihyc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> from "Randell Jesup" at Mar 29, 2001 12:49:15 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Full globbing in the _kernel_ isn't necessary (though I like it, > for a bunch of reasons I'll throw in as a postscript). > > It does require that the default version of readdir() return > only the most recent, and a load of other changes (of course). Much of > this can be in user-space in libraries, though. This can't be done on NFS mounted volumes. The "load of other changes" would include wrapping all path-using system calls, with incidental (complex) changes required to the threading libraries, since they would require orivate versions of these calls in both the libc_r and the third-paty-wraps-open-syscall cases. It is much better to simply turn files into directories, and then build a stacking layer that represents a view on them as "data file with highest version number is returned as if it were the file itself, on references to the directories path component name". Access to the directory contents (versions, in this case, but ACLs, extended attributes, etc.) would require a namespace escape be used. This is the "namespace folding" approach I alluded to earlier; it has the characteristic that it provides 100% application backward compatability to applications not using the escape, and file rewrites can result in versioning (but two stage commits, which is where you wanted it in the first place, all have to be taught about the change). > The suggestion above seemed to be a slight variation on the normal > VMS idea, in that it was only mentioned for use with configuration files. > I.e. no (or few) userland changes, but weird FS semantics (open(), write(), > close() on an existing file causes the old file(s) to be renamed - foo.cfg > becomes foo.cfg.1, .1 becomes .2, etc). This wouldn't be used to replace > UFS/etc, just for config files. (We did something a little similar on the > Amiga at one point; we implemented file-change-notification on the RAMdisk > only, and at boot copied all config files to the ramdisk (actually ENV:) > from permanent storage (ENVARC:). You could reassign ENV: to be on a disk > which didn't support notification; you just lost the benefits of > live notification.) Metadata incursion is preferrable to the file name component incursion (VMS actually used a semicolon seperator, not a period, and restricted the user to not using semicolons, and only using one period in file names, both of which are unacceptable for I18N/L10N reasons). > p.s. Kernel globbing: > 1) it reduces A LOT the traffic required across a network (or > across the kernel/user interface). > 2) it's universal - all programs get the same globbing and it > doesn't depend on the shell > 3) it makes "mv *.c *.c.old" possible I miss this the most. You can achieve the same effect by making "mv" a shell built-in, however, but that doesn't fix rename(2). > 4) it makes syntaxes to commands that need regexps or regexp > characters in arguments simpler, especially for non-hacker > users. (I've written shells, and I still end up playing the > "Ok, lets add quotes and \'s at semi-random until I get the > result I want" game way too often.) > 5) it works well as part of a unified command-line-parsing > package that all program should use (kinda like getopt > and the gnu parsing stuff), which is something that's still > very iffy in Unix mostly due to history. CLDs had their uses; among other things, it was easy to generate "almost complete" documentation programmatically. > Yes, I know there are downsides too, and that it'll never happen in Unix > because it's assumed to be the work of the shell by all commands, but I > can dream, can't I? ... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103301310.GAA06817>