Linux-Development-Sys Digest #813, Volume #6 Thu, 10 Jun 99 19:14:29 EDT
Contents:
Re: the ultimate OS (Vladimir Z. Nuri)
Re: Any Journaling FS development? (David T. Blake)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: the ultimate OS (Lou Grinzo)
Re: gcc: Internal compiler error: program cc1 got fatal signal 11 (Villy Kruse)
Re: Red Hat 6.0 not fscking the root partition! (Villy Kruse)
Re: Terabite Plus Filesystems (root)
Re: 64-bit arithmetic inside kernel (Peter Samuelson)
Re: Writing Linux FileSystems for Dummies :-) (Peter Samuelson)
----------------------------------------------------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: the ultimate OS
Date: Thu, 10 Jun 1999 20:34:23 GMT
DK wrote one of the more in depth analyses of the essay..
my only complaint is that he is expecting me to flesh everything
out myself. nothing new there. well I will elaborate a little.
: This is rather vague. What about Objected Orientation makes
: it appropriate for low-level programming? Even if it were
: possible to write an OS in OOP, it should be done only when
: it provides better implementation. Of course whether the
: above means the system should be written in OOP or merely
: provide OOP interface isn't too clear.
I think a very good compiler could take a very good object model
and make it as efficient as say C code. hence I am implicitly
demanding much more powerful compilers that are fused into
the OS. I think this is more possible when the compiler is
considered part of the optimization functions of the OS, as
inherent to its minute-to-minute operation as disk caching.
I submit that code optimization is a form of optimization very
similar to caching that needs to be handled by the OS on-the-fly.
hence when I say, "everything is based on object" many people
are assuming, "it would be slower than written in C".. but I
don't think the vision is possible without a compiler that makes
the objects as efficient as C when the opportunities arise.
another poster suggested that if I said "component" instead of
"object" I would have drawn less fire.. I doubt it, but perhaps.
I'm willing to switch terminology.
: I don't see what you mean by code, distinguishable from
: interface. What is data? A raw binary stream? Data should not
: be accessible directly at all should it?
the interface is basically the class interface, the procedures
that are the "face" to the outside world of the object. yes I agree
data should generally not be accessable directly.. but a very good
compiler might optimize object configurations such that it can
avoid the procedural call overhead to changing data.. I believe some
compilers are doing this. essentially I am envisioning a very sophisticated
compiler that can handle object configurations and
for which making everything an object incurs no performance
penalty.
: How are interface/links maintained when an object is
: transferred from one computer to another? For example if a
: picture file, an object is transferred, are the methods for
: display and manipulation automatically transferred as well?
this is a key problem that needs to be fleshed out. but basically
there are objects that exist somewhere else, and exist "virtually"
in another location. so I could call an object on my computer
and it may be implemented or running on another computer. the
system supports this. I don't know whta you mean about "methods
for display" which only seems to have relevance to the GUI.
the system allows you to open up objects and pull out objects
inside them & recombine them (the object browser). so everything is the
user's choice. ultimately
: > * Objects "hook up" to other objects and pass data back and forth.
: > These links are all carefully recorded and entire object networks
: > and trees can be traversed.
: What is that supposed to mean and how is it supposed to be
: implemented?
the basic idea is that the OS/system understands the data types
that objects use, all the way down to granularity of ints or bytes,
up to the large types such as images, source code projects, etc..
it allows you to pack or unpack arbitrarily. there is no distinction
at any layer. an object that accepts an image is the same as
an object that accepts two INTs and adds them together.
the system/OS understands that they are all different datatypes.
hence the OS becomes very much like a programming language/compiler,
and the language becomes like an OS.
I can do things like say, "ok system, give me all the objects that
accept JPG inputs" and it will show me. it understands. I can hook
up a huge network of objects and see the dataflow diagrams.
: So what happens if you download a file from a Linux machine?
: How is the type determined? Does it carry "unspecified" tag
: or are there some magical methods that automatically assign
: the correct types to those files?
all objects have a "type". a binary version of an object must
be created. it is possible to have stand alone files that have
no type, that can be put together to create objects. the system
allows you to cut open objects as much as glue them together.
there may be types that are "unspecified" in some ways. "raw
binary file" is one type.
[object browser]
: I think this is very close to what MS is trying to do with
: explorer.exe. It's not really much more than a file manager/
: user interface that can make use of plug-ins.
yes, I believe the MS explorer is gradually converging in the
direction I am writing about. you're sharp for finding it.
: You mean there are ways (filter objects?) through which the
: system can be taught how to convert different object types.
: You can't expect an OS is to have total knowledge of how to
: read and write every single object type in the world.
that's essentially what I am proposing: that the system at
least understands when two objects are different types. it may not
know what to do with certain types because it has no other objects
that accept those types.
: Ouch this is way too close to my idealism :)
ah, a breath of fresh air.. idealism, a guy after my own heart<g>
: This, if I read correctly, forces open source model on
: the developers and may not be welcomed at all by developers.
: I had thought of such idea and felt that there should be a
: way to let the developers package and hide their object
: structures. After all there's got to be an informal way to
: escape this exposure anyways, so why not make it formal
: through "the powerful security model provided by the OS"?
absolutely, some objects cannot be opened up and poked around
in because of security constraints. I'm not saying all code is
open source at all. that would make no sense to me. there must
be a capability to support closed source when it is preferred.
: How about an Operating System upgrade? I was thinking
: of a system that actually puts absolute restrictions on
: every process, where it cannot modify anything beyond
: its scope (sandbox model). To do anything useful with
: such a system however, UI must be given some special
: priviledges, to make it possible for a user to
: temporarily extend its scope (modifying a document not
: within its object structure, for example, would be
: considered out of scope, for any process).
I firmly believe in the concept of "sandboxes within sandboxes"
and hope to better elaborate on this. briefly, hardware is in
a sandbox from software (software cannot damage hardware
or vice versa) and every app runs in its own sandbox to prevent
viruses, etc.
: > In Tao *everything* is *always* "plug-and-play". All hardware, all
: > software, everything. Anything can be connected or disconnected at any
: > time with the system handling it elegantly in every situation.
: These are hardware restrictions that you cannot deal
: with as an OS developer. Unless you consider the message
: "Unable to use the device" as elegant handling, the
: above is impossible.
"unable to use device" is far more elegant than one device sabotaging
another or the system, crashing it. yes I do consider that elegant
and superior to existing crappy systems. if device runs in sandbox,
it cannot break system even if driver is written wrong and has
bugs.
: In other words, Tao is going to be slow than other less
: elegant systems, but Moore's Law and its flexibility will
: more than compensate for it. Nothing wrong with that,
: but let's cut the BS ("cannot be efficiently implemented
: ... I disagree")
no, again I think a better written compiler with different
goals/approaches can make the object
system I am proposing as fast as compiled C for example.
: Before that, think about how TAO breaks all the existing
: standards.
it will attempt to allow existing hardware standards as much as possible.
: I like the system a lot, just as I did my Operating System,
: which seems nearly identical, but I'd wait before I see
: some implementation or even specific design as to how.
fair enough. I appreciate your well thought out post that
focused on what I actually wrote.
: Dan, ever as dreaming.
me too!!
take care
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Any Journaling FS development?
Date: 10 Jun 1999 13:06:14 -0700
[EMAIL PROTECTED] writes:
>Frank Sweetser <[EMAIL PROTECTED]> wrote:
>>addition SGI is working in porting and releasing linux code for the
>>XFS filesystem.
>I wonder why they're waiting until "later this summer" to "begin
>releasing code"
According to SGI, it is so that their lawyers can look into
it and see how 'freely' they will be allowed to license
XFS wrt any existing agreements they might have with copyright
infringements, patents, ... The management says they want to
use GPL if possible, or something as compatible as possible,
but until their lawyers give them the lowdown there will
be no XFS.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 10 Jun 1999 20:40:12 GMT
Alexander Viro ([EMAIL PROTECTED]) wrote:
: Grasshopper, it's not you, it's boredom.
what a coincidence!! you bore me to tears too!! when you want to
talk about something I wrote rather than your delusions of grandeur or
kookdom, plz drop me line!! I'm sorry you miss one of your old
troller pals from 4 yrs ago, Mr. whoever-you-are, but I'm
afraid I can't help you (any more than I have already hehehe)
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Date: Thu, 10 Jun 1999 17:22:56 -0400
My favorite variation of this thought says that there are
two types of people in the world: Pumps and valves. <g>
Lou
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> p.s. there are those who:
>
> a. make things happen
> b. watch things happen
> c. wonder what happened..
>
> and .. perhaps related to b., and particularly apropos to Usenet..
>
> d. interfere/complain/criticise/oppose/flame what is happening..
>
>
> --
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
> "in theory, there's no difference [EMAIL PROTECTED]
> between theory and practice, mad genius research lab
> but in practice there is!" http://www8.pair.com/mnajtiv/
>
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: gcc: Internal compiler error: program cc1 got fatal signal 11
Date: 10 Jun 1999 09:35:53 +0200
In article <7jmbph$5g8$[EMAIL PROTECTED]>,
Jonathan Stott <[EMAIL PROTECTED]> wrote:
>In article <7jm8fa$6h3$[EMAIL PROTECTED]>,
>Villy Kruse <[EMAIL PROTECTED]> wrote:
>>
>>Would you get sig 11 if you run out of both memory and swap space?
>
>You shouldn't, but it certainly is possible with badly written code.
>
>malloc() returns NULL on error, at which point any well written program
>will stop with an "out of memory"-type error. If, however, you incorrectly
>assume that the malloc() always succeeds and try to access memory via the
>NULL pointer, you can easily generate signal 11's (sig 11 = SIGSEGV).
Some widely used unix system (not necessaryli linux) has the feature
that the available physical and swap memory space is not checked at the
time of malloc so tha malloc succeed and only when later the momory page
needs to be allocated on physical memory the system finds there are no
more free memory pages and the swap disk is full, so that particular
system will find and kill som process to free up some memory.
Also, if an extra page is needed because a Copy-On-Write page is about
to be modified, the system has no way of returning an error code to
the program. Copy-On-Write pages are created anytime you fork a process.
Villy
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: Red Hat 6.0 not fscking the root partition!
Date: 10 Jun 1999 09:42:44 +0200
In article <[EMAIL PROTECTED]>,
Ronald Cole <[EMAIL PROTECTED]> wrote:
>I'm a new convert to Red Hat (from Slackware). I've performed a
>"Server" install of "official" Red Hat 6.0 and noticed that the root
>partition check is aborting and therefore the root partition never
>gets checked. I rebooted several dozen times while configuring the
>system. I've tried Red Hat's "on-line support" but it is horribly
>broken and Red Hat's support manager admits as much but doesn't offer
>any useful suggestions to resolve the issue (all email gets promptly
>ignored, but that is another problem)...
Standard redhat install puts the read-only flag in the /etc/lilo.conf
and it is essential that this flag is retained.
Thus with standard redhat lilo setup or standard redhat created boot
floppy the root is mounted read-only just to be able to fsck it.
The other distributions do excatly the same.
Villy
------------------------------
From: root <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.alpha,comp.os.linux.hardware
Subject: Re: Terabite Plus Filesystems
Date: Thu, 10 Jun 1999 18:13:42 -0500
"Christopher B. Browne" wrote:
>
> On 29 May 1999 19:05:07 -0400, "Stefan Monnier
> <[EMAIL PROTECTED]> posted:
> >>>>>> "David" == David T Blake <[EMAIL PROTECTED]> writes:
> >> PCs with *x86 architecture have about 1/3 the computing power
> >> of an alpha at the same clock speed. That is the penalty for
> >> keeping legacy chip architecture around.
> >
> >You lost here all credibility.
>
> Indeed. My Alpha/166 system is absolutely *not* the equal of a 400MHz
> IA-32.
>
> It is instead roughly the equal to a P75/P90, thus suggesting a rather
> different ratio, such as that PC's with IA-32 architectures have
> approximately twice the computing power of an Alpha-based system of the same
> clock speed.
>
> I would not, however, promote *that* position either, as it is not a
> reasonable characterization of either Alpha or IA-32.
>
> A fairer claim would be that for FP-intensive operations, Alpha systems are
> comparatively a *lot* faster than IA-32 systems of similar price.
>
> It is not clear which processor has advantage when working with highly I/O
> intensive operations; that is liable to be dominated by:
> a) The speed of the disk system, and
> b) The rate at which DMA can move data back and forth between memory and the
> devices.
>
> In that circumstance, Alpha won't have a substantial advantage.
>
> In applications involving hefty amounts of integer calculations that can fit
> into 32 bits, IA-32 appears to be a more economical answer.
>
> When 64 bit values start to represent important factors in applications,
> Alpha will doubtless look better in that it can do things in one instruction
> that likely take 4 or more on IA-32.
>
> Those are the sorts of factors that *should* be used to assess which
> architecture will be preferable; the blanket assessment that
> "AXP = IA-32 * 3" just makes the proponent look ignorant.
>
> --
> Those who do not understand Unix are condemned to reinvent it, poorly.
> -- Henry Spencer <http://www.hex.net/~cbbrowne/alpha.html>
> [EMAIL PROTECTED] - "What have you contributed to free software today?..."
I Know nothing about alpha's but I do work with alot of sparc machines,
can't compare any enterprise 5000 with 10 processors to no pc but I do
have an ultra 1 that is 167mhz that out performs my pentium II 300, but
I don't think it out performs my 400....
Just my two sense
------------------------------
From: Peter Samuelson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.questions,comp.os.linux.misc,comp.os.linux.help
Subject: Re: 64-bit arithmetic inside kernel
Date: 10 Jun 1999 17:34:17 -0500
[Bill Woessner]
> > Hi. I'm trying to write a kernel module that uses 64 bit
> > arithmetic and am having some problems with it. When I try to
> > insert the module, I get the following errors:
> >
> > longlong.o: unresolved symbol __udivdi3
> > longlong.o: unresolved symbol __umoddi3
[Juergen Heinzl <[EMAIL PROTECTED]>]
> Since the usual Intel CPU's are not 64 bit long long's are done in
> software, part of libgcc.a. I cannot tell whether you can force gcc
> / egcs to generate inline code here, sorry. If not you're probably
> up to some asm code.
Inline code requires complete implementation in the header files,
which AFAIK isn't there. But ... is there some reason you *couldn't*
use libgcc.a in the kernel? I can't think of a good one, but I know
how much I do not know about kernels, linking, etc. Of course, if
__udivdi3 and __umoddi3 make use of the FPU, you're SOL.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Peter Samuelson <[EMAIL PROTECTED]>
Subject: Re: Writing Linux FileSystems for Dummies :-)
Date: 10 Jun 1999 17:37:43 -0500
[ELSID Software Systems LTD. <[EMAIL PROTECTED]>]
> I am working on a project that requires a very good understanding of
> the interaction between the Linux kernel and its file system modules
Well, there's Richard's piece:
http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
