Just an idea about 'file systems'

[Thomas M. Farrelly]

dufrp@oricom.ca wrote:
> 
> 
> Errors-To: listman8@ens.fr
> X-Sequence: 1175
> 
> Well, I am thinking since some hours now and I feel the need to put my
> thoughts on "paper" and exchange this ideas with others. I have the
> feeling of rediscovering the wheel however. I suppose that this only
> some form of persistent, distrubted system.

Yes, I suppose it could be called persistent. But the keep/discard -
mechanism is dependent upon location. That is, to keep something, you'll
have to pass it on to a special "memory"-location. Persistent should, I
think, be an attribute to the objects to be kept, not to the object
which keeps them.


>   Well I was first thinking about how not enough easy it is to use
> existing code to do better. Of how DLL help to do this. And was asking
> myself why allocating memory from RAM is so different of allocating
> memory from a floppy disk.
>   Why not have every bytes in the system (RAM or on Floppy or Hard Disk)
> have an address.
>   I have thought that
>     -1k is 2**10 bytes
>     -1Meg is 1k * 1k = 2**10 * 2**10 = 2**20
>     -1Gig is 1Meg * 1k = 2**20 * 2**10 = 2**30
>     So with 32bits I can address 2**2 * 2**30 = 4 Gigabytes
>  It would be Ok for most systems today, at least enough to hold a hard
>  disk and the RAM. But before year 2000 12Gb CD-ROM is expected to get out.
>  So why not give a 64bits address. This give 4 Gig * 4 Gig = 16 "what?" bytes.
>  I don't know how this is called but it looks enough to hold every bytes on
>  this planet. (Not so sure.) I don't like the idea of letting the CPU taking
>  care of this virtual memory. First it would not accept more than 32 bits.
>  But also because it would not keep tracks of what is allocated and what is
>  not. This seems to be a software task in my opinion.
>

Using ram efficiently and using an external device like a harddrive is
very different.
When accessing/communicating with  something, you need a "reader" and a
"writer", methods to send and resieve information. To access ram you
"call" methods hard-coded into the prosessor. This is possible because
the CPU is so closely etached to its ram. The CPU knows so much
beforehand about the object ram. This is not so for external devices.

Also, devices can be accessed in different ways. Sometimes you need to
write bytes and sometimes words. And there are different ways to
reference the information you want to communicate, for example by
name/path or kinds of numerical references, addresses, sectors and so
on.

So the complexity of the hard-drive access is greater than that of the
ram access. To unify them, you'll have to push ram-access to the same
abstraction level as the hd xs. Thus, for example having to send an
empty parameter-list. This leap in abstraction level is in scale,
emourmous.

But unificating these consepts, things that can be communicated with, is
a good idea.

It's possible to solve the problem by instead of making external devices
accessible in the same way as ram, do it the other way around. So I want
ram to be accessible (at some abstraction-layer) the same way as an
external device. This is simple, as it only require software. Define an
interface to a general object to access devices, or they could be called
"Containers":

	Container
		send(id,object)
		object resieve(id)

(It could be generalized further with iterators)

Accessing ram this way has a lot of advantages. And it does not mess up
ll-ram xs.




--
 ____________[ Thomas M. Farrelly ]_____________
 http://ii.uib.no/~s720/   mailto:s720@ii.uib.no