ORG,KER+ far12

[Andreas Arff]

Hello everybody.

> >> > >> > Giving device drivers their own priority -- good.
> >> > Ok, but WHO (what processes) can set up device drivers ?
> >> > if anyone can call its own local driver, there's no more security. See (1)
> >> THis comes back to security -- any comments/suggestions?
> >> THe concept of a superuser is a relatively simple (if rather insecure) way
> >> of doing things.
> >> Of course we'll have to introduce the notion of process ownership ...

Don't like the idea of a superuser, a chain is never stronger than its weakest
link. It's better if we could make the OS replace the superusers most powerful
rights.
As I see it, we have a dictionary with a list of possible device drivers,
as harddisk, soundcard etc. If a program has its own device driver it first
looks into the dictionary, is there any device drivers that can fulfill what
I want to do? If, add myself to the dictionary as a passive device, else
add myself as an active device.
The dictionary must have dictionary entries for a huge set of possible
device drivers. If we want, we can tag our own device drivers as
non-changeable to make the os more secure. Then only a superuser could change
the entries.
Now I see one problem that can/will arise, a device not mentioned in the
dictionary, but then the superuser could add it into the dictionary.
This might look like a cumbersome way of doing things, but that is the way
I'd like it. It is flexible and requires very little human involvment.
The OS could support calls like CheckForDictionaryEntry (xxx),
AddToDictionaryEntry (xxx, yyyy).

> I prefer the more general 'you know its ID, you can use it' phylosophy. Then
> you can have a 'user' object with the list of its known objects being limited
> to some objects, and some aspects only of objects not entirely owned.

See my part over.

> >> Alternatively we can decide that this is a single user system so anyone logged
> >> in from the console is "safe" ...
>
> Well, we should have a superuser console; but the common user shouldn't need
> use it in everyday life if the system is stable (if he has access to it).

See my part over.

> >> > I know - tell me more if you know others). That's why the system should
> >> > offer
> >> > many different capabilities of allocating memory, from raw reservation of
> >> > contiguous physical memory (to device drives) to garbage collecting-aware
>
> >> NO! The kernel should offer a single simple and (hopefully) sufficiently
> >> general method that is used by all.
>
> Hey ! who told you the Kernel should do that ? Of course the Kernel won't
> provide any memory allocation routine; it will only branch you to the memory
> device you need (only a basic device being available on a basic system).

As long as the kernel can give amounts of code to the system, we don't
actually care what happens to that memory amount, does we. I vote for
Fare's(with appostrof over the 'e' :-) way of doing it concerning this issue.

> >> [Stuff about us copying Unix and how bad MS-DOS and MacOS are deleted ...]

Should agree of a name Fare' for MS-DOS, I would prefer to call it
ugglybuggly dos. :-)

> >> (1) There's no need to go around insulting DOS and Mac -- we all know DOS's


> >> > There we come to an important point: error handling. Of course, old OSes
> >> > (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
> >> > neither could they understand anything sensible about HL programming (nor
> >> > LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
> >> > shit). Recent language like ADA, later version of (true) C++ and CAML do
> >> > include exception handling, and many HLL I don't know certainly do. I like
> >> > very much that of CAML (not knowing the others - tell me - 't'should be
> >> > mostly taken from the same language as for C++, but CAML should be better
> >> > because of automatic genericity as opposed to C++'s template hack). The
> >> > Kernel should include exception handling as a standard, so that objects
> >> > can exchange not only usual data, but also exceptional data (notice that
> >> > these language do not allow embedding exception in data itself by declaration
> >> > of exceptional format as should accept the language I vouch for (of course,
> >> > their are ways to obtain equivalent results, but then why not repeat we all
> >> > use Turing Machine equivalent languages ?)

Let's design a critical event device, of the style I've already proposed.
A tree-structured function list (? :-). When a critical event appers it
just calls the function linked, belonging to the app, or just a standard
function, if the app hasn't added one to the device.

> >> Were designing an OS - not a langueg.
True enough, but what is an OS without any accesible functions from the
outside world. An OS and nothing more. A vast screen with no apps :-)

> >> I'll come back to this point again, I think you're trying to throw a lot
> >> of what properly belongs in a language into the kernel -- thereby imposing
> >> a uniform object oriented view on all users of the OS.
> >>
> >> Personally I will disassociate myself from MOOSE if we decide to enforce
> >> OO programming on everything ... I feel that OO is overhyped.
It depends on the way we implement to objects...
> >> Personally I'd much rather use a Very-High-Level-Language like Haskell --
> >> OOPLs are based around imperative languages and are lower level as a result.
No language discussion please, as you said, we are not designing a language,
but an OS.

> >> Objects:
> >> > >> > I like the approach of simply defining a standard format.
> >> > Well, if not, this would no more really be OO'ed, and be another DOS, waiting
> >> > to be (VERY quickly) obsolete !
> >> > OO standardness is compulsory. To be in advance with other existing OS
> >> > projects, we must also include NOW genericity (for the which C++ templates
> >> > are only a hack) and logical programming (the most common use is find how
> >> > to find the "best" path to transform a virtual object into another, knowing
> >> > the elementary virtual transformations available and their physical cost).
> >>
> >> Yet another OO fanatic ... :-)
> >> I repeat -- objects are not magic ...
But they can be very helpful from time to time...

> >> > How complicated !
> >> > Again, let's program it by layer. The lowest (kernel) layer does a Andreas
> >> > says. Then, you can have a filter monopolize the lower-level resource to emit
> >> > events on a queue, then if you want, mix that queue into a general event queue
> >> > for stubborn processes to un-multiplex the global queue, as stupid current
> >> > systems do. YES, you CAN do it ! But once you see there are simpler, easier
> >> > means to handle data, by piping data just where you want, you WON'T use the
> >> > centralizing algorithm. Everything is easier, neater, quicker, better, when
> >> > objects just fit one into the other.
I liked that part "does an Andreas say".

Have to go now. I'll continue in another mail. Have a nice weekend.


Arff

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--