Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 05 Jul 1998 07:49:56 -0700
From:      David Greenman <dg@root.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        drosih@rpi.edu, hackers@FreeBSD.ORG
Subject:   Re: Variant Link implementation, continued 
Message-ID:  <199807051449.HAA11925@implode.root.com>
In-Reply-To: Your message of "Sat, 04 Jul 1998 20:36:29 -0000." <199807042036.NAA01481@usr02.primenet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> >I agree that the possible keys (ie, variable names) for symbolic
>> >links should not be something that's fixed at system build time.
>> 
>>    I sure don't agree with that. I also think Jordan's desire to have symlinks
>> translated with the user environment is either not attainable or undesirable
>> or both. I personally would rather that the info be kept in a seperate name
>> table (like what Terry suggested). I also prefer to have a hierarchical
>> structure (also like Terry suggested, except that I'd have the system table
>> as a seperate autonomous thing and not attached to the init process).
>
>Hmmm.
>
>I think "#kern.osrelease" or "#hw.machine" might be a sufficient
>escape mechanism.

   Thanks, Terry for quoting this text...I just noticed that I read what I
was replying to backwards. I *do* agree that the "possible keys should _not_
be something that is fixed at system build time". For some reason, I read
just the opposite, but I'm awake this morning. :-)

>The point was really the the init PID (or 0) be used to reference
>an inherited system space.  It's not as important that it actually
>be hung off a proc structure, it just makes it more orthoganal to
>have one type of object backing the logical name table.

   It seems more orthagonal to me for pid 0/1 to have their own, local name
table and the system one to be entirely seperate. The same struct type would
be used in all cases, of course, but the system table should be completely
seperate, IMO...

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project

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?199807051449.HAA11925>