Part 30 - Dec 05 2003

[admin]

#895 From: tomleem@...
Date: Wed Dec 17, 2003 4:29 pm
Subject: ThirdEye(?); (was Re: Kernel development) bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


> OS/2 may be on life-support, but it's sure not dead.
> I just got my 18-year-old Linux geek best friend
> to give Warp 4 a try. He loves it and
> is actually considering buying eCS 1.1
> to upgrade. But device support is
> a big issue. I have a Dell with Win98SE
> on my SOHO network just to use a
> USB scanner and 2 very cheap cameras
> for eBay items.
>
OS/2 might not be as 'alive' as Win but it is not dead
either. I totally agree with you on that.

Have you tried ThirdEye for the digital cameras? IIRC -
I think I read that it supports USB cameras(?)

> I'm trying to learn how to write drivers
> right now. Problem is I come from the days of
> BASIC, Cobol and Pascal. C isn't bad I'm hitting a
> block with but C++. I just can't make the jump
> from procedural to OOP.
> --
> Davey Brain
> dsbrain@NOSPAM!neosplice.com or
> dsbrain2001@y...!com
>
BigWarpGuy

PS I think ThirdEye is at http://www.ecomstation.ru

[admin]

#896 From: "Yuri Prokushev" <yuri_prokushev@mail.ru>
Date: Wed Dec 17, 2003 6:20 pm
Subject: Re: Kernel development prokushev
Offline Offline
Send Email Send Email


** Reply to message from Jos� Francisco Garc�a Mart�nez <correo@...>
on Tue, 16 Dec 2003 12:24:36 -0600

> I agree in all points with Cris.
>
> At least we have an important subject in the list.

Please quote messages.

[admin]

#897 From: "Yuri Prokushev" <yuri_prokushev@mail.ru>
Date: Wed Dec 17, 2003 7:26 pm
Subject: Re: Re: Kernel development prokushev
Offline Offline
Send Email Send Email


** Reply to message from tomleem@... on Wed, 17 Dec 2003 13:26:10
-0000

Hi

> A lack of device driver might not have helped OS/2 but it
> did not kill it since OS/2 is not dead (IMHO).
Heh. When I need scanning I use Windows, because OS/2 doesn't support such
scanner. In such sutiation OS/2 is dead. Temporary, but dead. So drivers real
problem.

When I need to write some article then I again using Windows because no
applications wich supports required file formats. Etc, etc, etc. So support of
'mainstram' formats also real problem.

wbr,
Yuri

[admin]

#898 From: "Yuri Prokushev" <yuri_prokushev@mail.ru>
Date: Wed Dec 17, 2003 7:49 pm
Subject: Re: Kernel development prokushev
Offline Offline
Send Email Send Email


** Reply to message from "Yuri Prokushev" <yuri_prokushev@...> on Wed, 17
Dec 2003 21:20:47 +0600

> > I agree in all points with Cris.
> >
> > At least we have an important subject in the list.
>
> Please quote messages.
I mean make small quotes

[admin]

#899 From: Dale Erwin <daleerwin@...>
Date: Thu Dec 18, 2003 1:54 am
Subject: Re: Kernel development dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Davey Brain wrote:
>
> I'm trying to learn how to write drivers right now. Problem is I come
> from the days of BASIC, Cobol and Pascal. C isn't bad I'm hitting a
> block with but C++. I just can't make the jump from procedural to OOP.

You don't really need OOP for device drivers. Plain C will do just
fine. A little assembler wouldn't hurt though.
--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

[admin]

#900 From: Frank Griffin <fgriffin@...>
Date: Thu Dec 18, 2003 5:09 am
Subject: Re: Kernel Development ftg314159
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


I hate to open an old wound, but this discussion has been had before, in
depth. It contributed materially to the split between FreeOS and OSFree.

To give you the short version, it goes something like this....

A: We need a kernel because IBM isn't doing anything with the current
one, or they're not doing enough, or we'd have to pay to get the new
ones (or even the old ones).

B: Why don't we base it on Linux, since Linux is pretty much the only OS
that is coming anywhere close to staying current with device support ?

C1: I don't know anything about kernel programming, but I'm absolutely
against Linux because it isn't OS/2

C2: I don't know anything about kernel programming, but I'm absolutely
against Linux because X (which has nothing to do with the Linux kernel)
isn't like PM

C3: I don't know anything about kernel programming, but I'm absolutely
against Linux because it got my sister pregnant

C4: I don't know anything about kernel programming, but I'm absolutely
against Linux because ...

(C4 through C59 are left as an exercise for the student)

D: Well, why don't we use a microkernel ? Linus Torvalds hates them so
they must be good.

E1: I just found the abc kernel project. Why doesn't someone have a
look at it ?

E2: I just found the def kernel project. Why doesn't someone have a
look at it ?

E3: I just found the ghi kernel project. Why doesn't someone have a
look at it ?

(E4 through E1023 are left as an exercise for the student)

......................................................


The bottom line is that any well-programmed kernel brings several things
to the table:

a) basic device support (keyboards, VGA, mice)
b) process control personaility
c) memory management (including address space management)
d) device drivers for more complex devices (sound, ih-res video, USB)

Basic device support almost never changes; the specs for the devices are
pretty much old as dirt. The problem is that a lot of the hardware
implementations are like HTML "in the wild" --- they don't follow spec
exactly, and because DOS and Windows and OS/2 programmed around them, it
is perceived that they "work". However, if you try to write drivers for
them starting from the "specs", you will run anew into every spec
deviation problem that the existing OS's of reasonable age have already
hit and worked around. This will take you forever, AND it will require
that you obtain samples of all the broken hardware to QA with.

Moral: if hardware people can save more money by deviating from spec
than it costs to have software people code around the deviation, they
will be allowed to deviate. If this weren't true, we wouldn't have
Winmodems and Winprinters.

Process Control and Memory Management are pretty much portable from
kernel to kernel, and anybody who thinks that, for example, the Linux
dispatcher algorithms couldn't be ported to OS/2 (or vice-versa) without
affecting more than a handful of modules is kidding himself. All of it
comes down to the question "what activities will I prioritize over which
others in terms of performance ?". This question, and its answers, have
very little to do with the actual hardware or the rest of the operating
system.

Moral: Process Control and Memory Management internals (as opposed to
API) are the easiest part of any kernel to change, since these internals
are largely confined to a handful of modules which have little to do
with anything else. Got a candidate OS but you don't like the
dispatcher ? Take a few days off and change it.

So, how should we evaluate a kernel or OS on which to base a new OS/2 ?
Simple: look to what it is about OS/2's kernel you liked.

The qualities of the OS/2 kernel that I hear praised the most are
stability and performance.

Theoretically, stability comes from correct programming the first time.
In practice, it comes from massive QA based on a huge amount of
runtime. A small group of enthusiasts can supply the former, but not
the latter. Regardless of how careful you are in coding, you will end
up correctly coding some non-optimal designs, and you won't find out
about it until people with a QA capability an order of magnitude greater
than yours (i.e. customers) try it and trip over it.

Performance is largely a function of optimal use of the hardware's
capabilities. Put another way, if you don't keep up with the hardware,
your performance will go straight to hell. Almost every CPU design
improvement is done for the sake of performance, so if you aren't in
there learning about and taking advantage of every one of them, you
might as well stay out of the game.

This is the fallacy of running around trying to find kernels to work
with. The whitepaper may look great, and the designers may be
enthusiastic; the project description may push all of the right buttons
in terms of what you want a kernel to do. But what matters is how
extensively the thing has been tested, both in terms of runtime/load and
hardware, and whether its maintainers are keeping up with every
improvement in every CPU they claim to support.

Most kernel projects are the equivalent of somebody's thesis project,
and don't meet either of these criteria. A kernel which has been tested
in a community of 50 students all of whom have similar hardware is not
the same as a kernel which has been tested in the IBM labs, the
worldwide Linux community, or even, god help us, at Microsoft. And the
toybox kernel just isn't going to give what you expect of an OS/2 kernel.

On the other hand, the qualities of OS/2 that are most praised above the
kernel level are the WPS, the GUI, and the filesystem. These have
little or nothing to do with the kernel, and would have the same look
and feel regardless of whose kernel you built them for.

My feeling is that Linux is the only open-source OS which meets the
performance and stability criteria, as well as the requirement for
device drivers.

In terms of performance, the new 2.6 kernel supports the Intel
hyper-threading technology (up to 50% performance improvement on a
uniprocessor system), which OS/2 never will; I seriously doubt that you
will find any other open source kernel which is keeping up with
processor hardware this well. The Linux memory manager is continually
rewritten and honed, as is the gcc compiler used to compile the kernel.

In terms of stability, Linux probably logs more runtime hours across the
globe than anything else except Windows. And in terms of device
drivers, driver development time for Linux is probably at least an order
of magnitude more (probably two orders more) than for any other
non-Windows OS.

To me, it comes down to the question of do you want to be able to run
what you perceive as OS/2 (e.g. WPS, PM, HPFS) or do you want, at an
essentially prohibitive cost, to be able to say "well, at least we
didn't use Linux", and get something that will either start out as
mediocre or quickly become mediocre ?

[admin]

#901 Re:[osFree] Re: Kernel Development
Expand Messages

criguada@libero.it
Dec 18 1:44 AM
Hi Frank,

Frank Griffin wrote:

> I hate to open an old wound, but this discussion has been had before, in
> depth. It contributed materially to the split between FreeOS and OSFree.

No problem, at least if we don't start another endless war-thread.
I was there at the time od FreeOS, and I was here when osFree started (actually
I was among those who made it start). And I was happy about the split, and when
I saw the old guys that made FreeOS die here I was NOT happy. But this is just
my opinion.

> To give you the short version, it goes something like this....
>
> A: We need a kernel because IBM isn't doing anything with the current
> one, or they're not doing enough, or we'd have to pay to get the new
> ones (or even the old ones).
>
> B: Why don't we base it on Linux, since Linux is pretty much the only OS
> that is coming anywhere close to staying current with device support ?
>
> C1: I don't know anything about kernel programming, but I'm absolutely
> against Linux because it isn't OS/2

The "I don't know anything about kernel programming" argument doesn't mean "I
don't know anything about kernel architectures", at least for me. And it should
be worded more like "I don't have experience in kernel programming".

Put simply, I don't like the traditional unices kernel design, and Linux
doesn't really deviate much from that. It seems that most of the people here
agrees about this, so why do you want me to state this once again?

On the other hand, if you think (and I hope this means that you DO have
experiance in kernel programming) that changing Linux' kernel scheduler and
threading model would be a matter of a few days of hacking away from a single
person, that please announce it on this list and START WORKING. The worst thing
that can happen is that some people will join and help you, and we all will have
to say "sorry, YOU were right".
Then, we all will be able to start ading a layer of compatibility over the Linux
kernel for OS/2 APIs.

> So, how should we evaluate a kernel or OS on which to base a new OS/2 ?
> Simple: look to what it is about OS/2's kernel you liked.

This is exactly what I tried to do. I knew I didn't like Linux nor Windows
(hence ReactOS), and tried to explain clearly _WHY_ I didn't like them, and
tried to suggest an already existing design that I think fits the original OS/2
design better.

Obviously, as staed from others, the device drivers problem arises, and that
leaves us only with Linux and ReactOS (if we DO want to avoid the problem).
Linux is the better tested and stable of the two, so again: if you think Linux'
kernel weaknesses (compared to OS/2) can be easily filled, please propose
something and start a SIG about it.

> On the other hand, the qualities of OS/2 that are most praised above the
> kernel level are the WPS, the GUI, and the filesystem. These have
> little or nothing to do with the kernel, and would have the same look
> and feel regardless of whose kernel you built them for.

This was clearly stated. I even proposed to start with running original IBM code
on top of the new kernel. This will allow us to squeze out bugs in the
compatibility layer, and start adding/changing things later.

> My feeling is that Linux is the only open-source OS which meets the
> performance and stability criteria, as well as the requirement for
> device drivers.

Don't know about the performance and stability, but it surely is the only one
that meets the requirements for device drivers.

> In terms of performance, the new 2.6 kernel supports the Intel
> hyper-threading technology (up to 50% performance improvement on a
> uniprocessor system), which OS/2 never will; I seriously doubt that you

This is to be verified. I don't know if OS/2 "nerver will" (I already heard
about some support coming from Serenity). And I'm very doubtful about the 50%
improvement... all the claims I've heard about (let apart Intel's) report much
lower improvements (10% or so).
OS/2's kernel still is very competitive, despite the fact that it is not
following very closely hardware improvements.
But that's not of interest for this discussion.

> To me, it comes down to the question of do you want to be able to run
> what you perceive as OS/2 (e.g. WPS, PM, HPFS) or do you want, at an
> essentially prohibitive cost, to be able to say "well, at least we
> didn't use Linux", and get something that will either start out as
> mediocre or quickly become mediocre ?

It's not only a question of exterior perception. It's the overall feeling that
must be preserved.

So (let me state it again, adding some more things said by other people here):

- I want OS/2 multitasking/multithreading performance (IOW the OS/2 scheduler
and threading model, or a similar performing one).

- I don't want to mess with kernel recompiles just to add devoce driver support
to the OS.

- I want a "multiple roots" file system model, not the "single root" model from
Linux. I don't know how deeply this is rooted in the kernel. Would be nice to
hear about this.

- I want OS/2 global consistency permeating the whole system, not Unix' mess. I
don't know how deeply this is rooted in Linux' kernel, probably little or
nothing. Would be nice to hear about this.

- X is out of the question. We need PM on top of this. X is already a problem
for Unix users (which are in fact trying to replace it).

Bye

Cris

[admin]

#902 Re: [osFree] Re: Kernel Development
Expand Messages

Lynn H. Maxson
Dec 18 7:32 AM
Frank and Cris,

Among the arguments left out you will find one related to,
one, the intial effort, and, two, the ongoing effort for an OS/2
replacement. The comparison came down to two choices, one
based on a microkernel approach and the other, a layered
approach. Actually both represent a layered approach, one
on a microkernel and the other on a kernel.

I contended then as now that layering on a kernel required
more both initial and ongoing effort than one on a
microkernel. In fact given the experience of ODIN, the VPC,
and Lindows I offer them in support of my position.

Every kernel has a microkernel. If it didn't, if no set of
common kernel functions existed, no microkernel could exist.
At issue we have only core functions and the possibility of
support for any personality layered upon them.

The only uncertainty I had (and still have) lies in finding
common support for the presentation services, the GUI, in use
by the different OS personalities. I have no problem with
imagining multiple OS personalities running concurrently. I do
not know if they can do so with a common look and feel.

Until I do, until I see a design, a detailed design, resolving
these issues, the core kernel (microkernel) and GUI functions, I
don't favor writing a single line of code. There's no sense
beginning something which you cannot complete. I don't base
it on not having sufficient resources, but not having a
complete design.

My efforts currently lie in improving the tool necessary to
minimize the resources necessary. As I have received pledges
of support from others in this endeavor I will pursue its
development in the coming year. At the same time I will
continue to visit the kernel and GUI design issue until I can
offer one complete to the lowest detail.

I still think that the most reasonable starting point lies in the
design of OS/2 for the PowerPC as it embodied all of the OS/2
API including GUI on a microkernel. At worst it offers an
approach to execute any single OS personality. At best it
offers an approach to execute multiple personalities
concurrently. Moreover to do so without performance
penalities for any.

Frank, I still enjoy your analysis even when I don't agree with
them.<g>

[admin]

#903 Choosing kernel
Expand Messages

Yuri Prokushev
Dec 18 8:13 AM
Hi.

IMHO,

1) We MUST make list of requirements for kernel
2) We CAN/MUST create comparation of kernels (represented as table)

So, requirements:

1) Widely supported binary device-driver model/Binary kernel
2) High-performance multitasking/multithreading model
3) Multiple roots for 'disks'
4) Possibility to support other widely known APIs (POSIX, OS/2)

All according REXX/SOM/PM/WPS is out of kernel selection. Only question is base
api (doscalls).

Any additions? Deletions? Changes?

wbr,
Yuri

[admin]

#904 Re: [osFree] Choosing kernel
Expand Messages

Lynn H. Maxson
Dec 18 11:53 AM
Yuri,

in my IT world requirements precede specifications which
precede analysis which precedes design which precedes
construction. Requirements normally enter as an informal
request which need translation into formal specifications.

To support the DOSCALLS api's as a requirement means listing
them in detail in a set of specifications. That detail includes
the api name, the set and order of parameters, and rules
governing them on input and output. The parameters end up
as variables and the rules regarding the values they can
assume.

From my perspective that means things like 'rc' for return
code need to have an individual specification as well as name
for all the varieties which exist with respect to returned
values possible.

I came close to doing this once before and would be willing to
carry it to completion to provide a detailed breakdown of
kernel api's and rules governing their use. If someone works
in parallel to provide a tabular comparison of microkernels as
you suggested, then we can select a bottom (a microkernel)
to support our top (the kernel api's). Then analysis will
determine if we have a connection between the top and
bottom. Then design will offer that connection in minimal
form. We can then decompose that minimal form into
different work units which people can then volunteer to
construct.

Note that you have two choices, a two-layered approach
based on a microkernel and an OS personality and a
three-layered approach based on a microkernel, a host OS
personality, and a client OS personality. In either instance we
have a basic choice in the microkernel. After that it just
depends on whether or not people want to master the Linux
api's to host the OS/2 client ones. Personally I don't
understand why a resource constrained effort would want to
master an extra layer.