[Coco] Environment Variables for NitrOS-9

[Jeff Teunissen]

[Sorry about the long reply -- I didn't have the time to make it shorter]

Boisy Pitre wrote:
> On Dec 4, 2006, at 7:36 AM, Jeff Teunissen wrote:
> 
>> Also, has anyone thought of using a per-user data module for mocking
>> up an environment space? Say, an 8K module named ENV<uid> that would be
>> read from a random or sequential file by the Shell (or LOGIN, on multi-
>> user systems) to hold shell variables like the PATH, Multi-Vue
>> information, the user's "home" directory, etc.
> 
> Some years back I made a proposal for environment variables under  
> then-OS-9 (now NitrOS-9) but cannot seem to find that post.  My  
> solution didn't use a data module but instead relied on the memory  
> being allocated in the process' space at F$Fork time and accessible  
> in such a way that it would pose no compatibility problems.
> 
> Now that I think about it, here's an implementation off the top of my  
> head:  reserve two bytes in the process descriptor to be a pointer to  
> a block of system RAM.  Also create a new system call: F$Env.  From  
> this call, a SetEnv or GetEnv could be performed.

something like

entry:
	A	command code -- NV.Init, NV.Get, NV.Put, NV.Delete
	B	[if there's an Init & cmd=NV.Init] size of _data_ blocks
	X	address of environment key
	Y	address of new value [if command is NV.Put]
exit:
	X	address of new key (may have been truncated)
	Y	address of current value (ditto)

error:
	CC, B(187,207,214?,218,235,238?)	set

note: error 218 might be returned if you pass in a key name longer than the
maximum and the truncated key already exists.

> Upon the first call to F$Env for a process, a 256 byte page would be  
> allocated from process' 64K memory space.  Some indexing scheme could  
> be employed to hold the environment variable name and its contents in  
> that page.  When that page is filled, a new one could be allocated.
>
> The real work would be to develop an efficient (both in terms of  
> space and time) way to manage the environment variables in those 256  
> byte pages: SET, GET and DELETE operations would be need to be  
> implemented.

I can see at least one gotcha there -- how would child processes inherit the
parent's environment? That was one reason I thought of using a per-user data
module, so that you could e.g. set variables in the shell for other programs
to read if they know how to. For example, setting LS=-CFk might tell the ls
program to use color output, to classify files with * or /, and to show sizes
in kilobytes.

As far as implementation goes, I'd probably go with fixed-size records, almost
like directory entries, and allocate 3 pages at a time(there is a reason for
this). If a variable has been deleted, write a zero byte to the first
character in its key, thus marking it for future reuse.

The reason I'd allocate 3 pages at a time is that I'd store 96 bytes per
variable -- 16 for the key, 80 for the variable, and with that layout you
could store 8 variables in 3 pages.

Alternately, there's the two separate spaces method; one page for the keys and
 2B+1B ranges (pointer + length), another for values, each growing
independently -- that would tend to save memory, but either suffer from
fragmentation of the environment or result in compaction overhead that would
have the side effect of making the returned pointers unreliable.

There's also a combination of the two schemes, with two separate spaces AND
fixed record sizes, if 80-char envvars aren't long enough. With that scheme,
the index would be 32 bytes per record: 29 for the key, two to hold the
address to the page being used, and one byte to hold the index within that
page. Data pages might hold 128-char variables.

Or, of course, an explicit initialization call might set the sizes of the
keys/variables desired.

> It definitely is doable and can even be written to exist in a KrnP3  
> kernel extension module.  Jeff, do you think this is something you  
> would be interested in tackling?  I would definitely add something  
> like this to the NitrOS-9 Project.

-- 
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek at d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project     http://www.quakeforge.net/
| Specializing in Debian GNU/Linux           http://www.d2dc.net/~deek/