From owner-freebsd-hackers Fri Jul 3 08:43:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA13804 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 08:43:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA13799 for ; Fri, 3 Jul 1998 08:43:35 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id RAA28708; Fri, 3 Jul 1998 17:43:35 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id RAA05469; Fri, 3 Jul 1998 17:43:34 +0200 (MET DST) Date: Fri, 3 Jul 1998 17:43:34 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807031543.RAA05469@surf.IAE.nl> To: drosih@rpi.edu Subject: Re: Variant Link implementation, continued X-Newsgroups: list.freebsd.hackers In-Reply-To: References: <5406.899427726@time.cdrom.com> Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: [ deleted things about why user would faulup the naming scheme ] >> In any case, this argument is also somewhat moot since neither of >> us is actually doing the work of IMPLEMENTING this baby and it's >> the implementor who is always going to have the final say as to >> how it works anyway. :-) Thank you, I hope I'll get that far. If I ever get my RAID's to work prperly, since that is real work. :-) >Sure, go and get all practical on me. Go ahead and ruin all my >fun babbling... :-) No, the reason I threw this into this forum is to get peoples reaction. I could go in the attic, dig out my old Apollo manuals and just implement that. (With or without the problems that come along) But that's not what I want, I'd like it to be usefull in the FreeBSD way of using this system. Best way to frustrate that is to ignore the culture (and code), and "just do something(tm)" >Actually, though, I think that what I'm proposing is really just >an alternative to environment variables (not just "environment >variables for symbolic links", but "an alternative to environment >variables for holding configuration settings"). Perhaps that >wouldn't be too hard to do a simple cut of? Like Jordan said, I'm not up to inventing ALL the variables people might ever want to use. So we need some slack there. And a name-space is just another namespace: Use ENV's with V_ to start??? The point is relatively moot as long as you let the user "mess" with it. But then that is the charme of the whole deal. >To get the kernel to correctly *use* environment variables for >symbolic links is going to take some work (even if everyone agrees >it's the best of all ideas), and perhaps an alternative would be >less work to do. If so, I can get away with all this babbling >without irritating any person who is actually doing the useful >work on it... :-) Talk don't hurt. I'm a one step at the time person. So my next objective is to just get it to work with a set of sysctl variables, and then everybody can have their go at things they'd like to have. Then I'll be thinking about haveing 2 rules of resolution: @{....} and ${....} The first one only uses the 'system name space' and thus can not be modified by the user. (sort of like the /usr/include files) The second one Will follow a 'hierachical' namespace where the user can change the name contents. BTW, Terry, I see this system namespace as what you the INIT-env. As far as I can see, it is rather hard (even for root) to change init's env once it starts running. So that's perhaps a little to rigid. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message