From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,dea2d62ab1462538 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!f5g2000yqh.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Writing an Operating System in Ada Date: Tue, 12 Jan 2010 15:26:06 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <8e9bc311-7540-40a1-b19e-49e93648c25c@s31g2000yqs.googlegroups.com> <9oyblld05omh$.1dzhmyoseeb7x$.dlg@40tude.net> <414945fd-8ed5-4f42-a237-0685602332b3@f5g2000yqh.googlegroups.com> NNTP-Posting-Host: 75.161.5.100 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1263338766 6499 127.0.0.1 (12 Jan 2010 23:26:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jan 2010 23:26:06 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f5g2000yqh.googlegroups.com; posting-host=75.161.5.100; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 4.0.20506),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:8717 Date: 2010-01-12T15:26:06-08:00 List-Id: On Jan 12, 2:52=A0pm, Maciej Sobczak wrote: > On 12 Sty, 20:56, "Dmitry A. Kazakov" > wrote: > > > There should be no file system at all. If you have objects, I mean if y= ou > > do have them consistently all the way, then you do not need files. Make > > objects persistent in the corresponding device, that gives you all > > functionality of any file. No I/O is ever needed. Map the object into t= he > > memory, call its operations, what else any program would have to do? > > Interact with other systems? You know, you might want to sometimes > move your "persistent objects" to another machine. > > Did I mention that you might want to move you whole hard drive to > another machine as well? :-) True, systems may be fairly static: like my old desktop. Or they may be fairly dynamic, being updated/improved regularly. It would be pretty dumb to force someone's data to be bound to a certain system, like certain DRM-pilious companies. While we can be fairly certain that many things will be the same, such as the CPU's family, to completely disregard such exceptional (or regular in the case of some distributed systems) circumstances is valid only in academia or some project where you are GUARANTEED to have only a single configuration [- set] to deal with. Gaming platforms come to mind there, as well as Macs where the company controls hardware. > There is a reason why none of the pure-OO-OS-let's-do-it-correctly > ever really took off. I think you're getting a valid point there. It makes more sense to me to have file-objects derived from some stream-type and then having that stream directed [and possibly transformed, as need be] by the filesystem-object to the drive. {A FS may be of the opposite endianess than the system which is accessing the data, this is a non-issue if it is ALWAYS read & written the same way BUT if you were to port the drive to a system with the same endianness the reading and writing would be mixed-up.} IE - in the high-level world Write(Integer) and Read(Integer) are completely safe... but if another system were to read/write the data in the opposite endianess bad things happen. > > The problem is that we followed the wrong path for too long. > > There is nothing wrong with that path, as it happens to be very > pragmatic. The main problem is, I think, the API-standard of keying, to borrow from databases, on the (Location, Name) Tuple. If we consider the name of a file as a mutable attribute then we must use some other criteria for identifying files. (ie it makes little sense to have a file become invalid because you used the standard 'rename' command.) For a local system we could use the GUID of a 64-bit word, however this system would not work well for distributed/remote/networked systems because, in the absence of proper communication some other Index may be added by two different systems trying to ID a certain file. I would suggest using a vector of hashes to key [UUID] File-ID across a network, say: (MD5, SHA1, XOR-32). This would have the drawback of generating a new ID every time the file is updated... though that could be overcome by allowing the OS to track such changes with versioning or redirects or somesuch. GUID : Globally Unique IDentifier. (Longitude, Latitude) is a GUID. UUID : Universally Unique IDentifier. (Longitude, Latitude) is NOT a UUID because different planets have the same (Long., Lat.) tuple, in order to be a UUID we would have to indicate which planet we are talking about, like this: (Name, Long., Lat.).