Date: Fri, 3 Jul 1998 17:43:34 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: drosih@rpi.edu Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807031543.RAA05469@surf.IAE.nl> In-Reply-To: <v04011721b1c20a7a03ab@[128.113.24.47]> References: <5406.899427726@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <v04011721b1c20a7a03ab@[128.113.24.47]> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807031543.RAA05469>