#351 From: "sandervl2000" <sandervl2000@...>
Date: Sat Mar 2, 2002 12:40 pm
Subject: Re: Linux + OS/2 layer sandervl2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., "Michal Necasek" <michaln@p...> wrote:
> >When I have to make a list of good kernel designs (that I know),
then
> >the order is: NT, OS/2, Linux, Win9x
> Hmm, I thought Win9x was in the "horrible design" category<g>?
Let me give some marks to clear it up: 7+, 6.5, 6, 1.
Satisfied?
> But other than that I agree with your ordering. The only fault
> of the NT kernel is that it's maybe a little overengineered.
That's true. It's too complex in some areas.
Sander
Part 12 - Feb 26 2002
Re: Part 12
#352 From: "sandervl2000" <sandervl2000@...>
Date: Sat Mar 2, 2002 12:50 pm
Subject: Re: Linux + OS/2 layer sandervl2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
> > Not to mention the total lack of backwards compatibility for
> > driver binaries.
> Interesting, I never looked at it that way. You're right, they added
> something to the module loading mechanism to detect kernel
> version/driver version mismatches and prevent the driver from
> loading. I think however that in most cases it will be enough to >
> re'make' the driver again to get it working.
I don't think companies would like to rebuild and retest their drivers
for every minor kernel update. Especially if they're reluctant to
release the driver sources.
> What about the trick to put parts of Win32 subsystem in ring 0,
> just for performance reasons? That's not very elegant I think...?
Putting ring 3 code in the kernel has nothing to do with kernel
design.
> What about BeOS? It was object oriented designed from the ground
> up, and it performes very well. I once had several movies running on
I've heard good things about BeOS as well, but have never used or
studied it. (that's why I said I was listing kernels that I'm familiar
with)
> just an audio stream disturbed. If someone keeps 'ping'ing my
> machine, it just gets locked up for me, apparantly busy handling the
> interrupts of the NIC. And what about the priority inversion bug in
> Windows NT? This is the reason why OS/2 has soft-realtime support and
> NT hasn't.
I was talking about over kernel design. Not implementation.
And I never said NT is perfect. Multitasking in OS/2 is much better
than in NT.
Sander
Date: Sat Mar 2, 2002 12:50 pm
Subject: Re: Linux + OS/2 layer sandervl2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
> > Not to mention the total lack of backwards compatibility for
> > driver binaries.
> Interesting, I never looked at it that way. You're right, they added
> something to the module loading mechanism to detect kernel
> version/driver version mismatches and prevent the driver from
> loading. I think however that in most cases it will be enough to >
> re'make' the driver again to get it working.
I don't think companies would like to rebuild and retest their drivers
for every minor kernel update. Especially if they're reluctant to
release the driver sources.
> What about the trick to put parts of Win32 subsystem in ring 0,
> just for performance reasons? That's not very elegant I think...?
Putting ring 3 code in the kernel has nothing to do with kernel
design.
> What about BeOS? It was object oriented designed from the ground
> up, and it performes very well. I once had several movies running on
I've heard good things about BeOS as well, but have never used or
studied it. (that's why I said I was listing kernels that I'm familiar
with)
> just an audio stream disturbed. If someone keeps 'ping'ing my
> machine, it just gets locked up for me, apparantly busy handling the
> interrupts of the NIC. And what about the priority inversion bug in
> Windows NT? This is the reason why OS/2 has soft-realtime support and
> NT hasn't.
I was talking about over kernel design. Not implementation.
And I never said NT is perfect. Multitasking in OS/2 is much better
than in NT.
Sander
Re: Part 12
#353 From: "Daniel Caetano" <djcaetano@...>
Date: Sun Mar 3, 2002 8:49 pm
Subject: My point of view... djcaetano
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
People (Developers and Users),
I've be reading all postings on FreeOS mail list
(which I had created to join people - not to lead -
but it didn't work by several reasons) and some days
ago I read about this new list.
I registered to it and as I'm used to I started to
read the initial (and the latest) posts.
I'm afraid the project fall down in the same pit
as FreeOS had fallen... a sad thing that take away
my motivation.
Guys, I'll tell a history for you all.
Some months ago, Be Inc. almost gone bankrupt due
to the fact it cannot "fight" with M$, even with a
superior Operating System (in several aspects even
better than OS/2). Then Be found the only way to
avoid this problem on selling everything (including
BeOS) to Palm.
Palm directors as fast as they can said they would
discontinue BeOS. The BeOS developers would be
incorporated to PalmOS development, and Be was
discontinued since that time. The users were simply
ignored.
Some time ago, the same history: BeOS code leaked.
Someone got it and caused a major problem. Someone
thought on using it on the OBOS (Open BeOS) development.
After many ethic discussions, they decided to not use
the original BeOS code to develop OBOS... but sometimes
they "take a look" on it. The OBOS project is up and
running. Somewhat slowly, but I think in some time they'll
have something.
Why am I saying this? Well... I know that some pieces of
OS/2 were leaked some years ago, but it seems that a little
time ago most of base code was leaked. Interesting. This
code was available on some of the most known OS/2 Warez sites.
It disappeared from most of them. But I think a lot of people
got it. It's copyrighted material and CANNOT be used without
license of IBM, not even to build temporary things with
some note on the license. It simply can't be used that way.
Also, it cannot be distributed. In fact, it's a crime to
distribute it, since every piece of it probably has a copyright
notice. It's not a crime own it, though.
So, those that already have the code should keep it by
themselves and make a rudimentar documentation, and answer
questions when needed, peeking into the code. Anything
different from this would be illegal. A detailed document
can be created, but then IBM can argue that the info used
to build osFree was obtained on illegal ways.
Notice that IBM itself can be prosecuted by the code
leak, since probably there is code *not* from IBM there.
And IBM will be very happy to have someone to blame on.
I'm not naive. This code was not "stolen". It was
probably intentionaly leaked by some IBMer that like
OS/2 and want it to contnue living, in despite of "IBM
Management Directions". I think this guy had done it
right. It's up to us to use the code as a way to kill
doubts, not as a base. Following this path, IBM or
any other enterprise will hardly have a proof to go to
the court.
I don't know who owns the code, and do not want to
know. I hope only these guys keep it in secret and hope
they have the sufficient knowledge to look for something
when necessary and "inform" the comunity in a casual way.
It's illegal? Maybe. But it would be also on other ways.
Cloning only the known facts of OS/2 would never bring a
10% compatible OS. And even "empiric tests" are considered
reverse engineering, which is as illegal as using leaked
(not stolen) code.
I agree that lots of things must be rewritten on OS/2. So,
a scratch approach can bring us a lot of advantages. But will
take a lot of time. But it'll take forever if no one starts
it. And now, with a place to look on details of the
implementation when needed, there is no reason to consider
it an impossible task.
I think it's wise get a uK such as MACH or any other and
implement OS/2 on top of it, but I do not like the idea of Linux,
for reasons I had already pointed several times on FreeOS, and
I do not want to start another discussion (because this was the
reason I lost my motivation that time).
I do not want to generate a flame war, but I think Linux is
not good enough, and thats all.
The driver availability is not a point. Linux has a small
number of drivers also, and they'll be even smaller in the
future. Linux has already start to suffer the effect of
"saturated media". The press headlines do not point Linux
anymore. Something similar to what happened to OS/2 Warp
in 1993 to 1995. A big "boom" then a dark time.
I do not think Linux will perish, I do not think it's
development will be stalled. I just think once the fever
had gone away, only a small numbers of developers will
continue supporting it (maybe even smaller than today's
OS/2 support, because no one will pay to Sci-Tech develop
drivers, as IBM had done).
I think there are talented guys to develop an OS/2 clone
(and *this* was the reason I started the FreeOS... to look
forward and see if the list could join people capable of
it). Of course it'll take time. But if the OS is developed
wisely, it'll work for a long and long time. I think the
initial approach may focus "general compatibility": standard,
keyboard, VESA video, and this kind of thing. Even sound is
not something we should worry about in the initial stages,
but when it become needed, implement a simple digital driver.
Specific hardware should be implemented only in the future,
since most of the OS will not work in the initial stages,
and in the future the hardware will be different from today's,
turning any effort on drivers to actual hardwares a unwise
way to use the time.
And I think the driver should be a new model. And uK allows
us to have drivers in a higher level, easy to program, portable
and better: more than one driver model can be implemented.
None of these benefits are taken on the Linux approach that
is bluring every OS/2 project.
I hope someone start to do something. I really can't. I'm
not capable of starting such a project. I can help, but not
start it.
If real work will be done, count on me. But don't count
on me on discussions about abstraction of OS programming,
alien programming languages that do everything alone and
doing the work of ten years of a million of men with
10 mens in 2 months. I'm not an academic. And not was those
that created OS/2, BeOS or even Linux.
Just my 2 (hundred) cents about this topic.
[]'s
Daniel Caetano
djcaetano@...
..."A necessidade de criatividade e' o que contribui para a
mudanca. A criatividade mantem o criador vivo." (Frank Herbert)
http://soulmatrix.dynodns.net/ - This OS/2 system uptime is 0 days 12:09 hours.
Date: Sun Mar 3, 2002 8:49 pm
Subject: My point of view... djcaetano
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
People (Developers and Users),
I've be reading all postings on FreeOS mail list
(which I had created to join people - not to lead -
but it didn't work by several reasons) and some days
ago I read about this new list.
I registered to it and as I'm used to I started to
read the initial (and the latest) posts.
I'm afraid the project fall down in the same pit
as FreeOS had fallen... a sad thing that take away
my motivation.
Guys, I'll tell a history for you all.
Some months ago, Be Inc. almost gone bankrupt due
to the fact it cannot "fight" with M$, even with a
superior Operating System (in several aspects even
better than OS/2). Then Be found the only way to
avoid this problem on selling everything (including
BeOS) to Palm.
Palm directors as fast as they can said they would
discontinue BeOS. The BeOS developers would be
incorporated to PalmOS development, and Be was
discontinued since that time. The users were simply
ignored.
Some time ago, the same history: BeOS code leaked.
Someone got it and caused a major problem. Someone
thought on using it on the OBOS (Open BeOS) development.
After many ethic discussions, they decided to not use
the original BeOS code to develop OBOS... but sometimes
they "take a look" on it. The OBOS project is up and
running. Somewhat slowly, but I think in some time they'll
have something.
Why am I saying this? Well... I know that some pieces of
OS/2 were leaked some years ago, but it seems that a little
time ago most of base code was leaked. Interesting. This
code was available on some of the most known OS/2 Warez sites.
It disappeared from most of them. But I think a lot of people
got it. It's copyrighted material and CANNOT be used without
license of IBM, not even to build temporary things with
some note on the license. It simply can't be used that way.
Also, it cannot be distributed. In fact, it's a crime to
distribute it, since every piece of it probably has a copyright
notice. It's not a crime own it, though.
So, those that already have the code should keep it by
themselves and make a rudimentar documentation, and answer
questions when needed, peeking into the code. Anything
different from this would be illegal. A detailed document
can be created, but then IBM can argue that the info used
to build osFree was obtained on illegal ways.
Notice that IBM itself can be prosecuted by the code
leak, since probably there is code *not* from IBM there.
And IBM will be very happy to have someone to blame on.
I'm not naive. This code was not "stolen". It was
probably intentionaly leaked by some IBMer that like
OS/2 and want it to contnue living, in despite of "IBM
Management Directions". I think this guy had done it
right. It's up to us to use the code as a way to kill
doubts, not as a base. Following this path, IBM or
any other enterprise will hardly have a proof to go to
the court.
I don't know who owns the code, and do not want to
know. I hope only these guys keep it in secret and hope
they have the sufficient knowledge to look for something
when necessary and "inform" the comunity in a casual way.
It's illegal? Maybe. But it would be also on other ways.
Cloning only the known facts of OS/2 would never bring a
10% compatible OS. And even "empiric tests" are considered
reverse engineering, which is as illegal as using leaked
(not stolen) code.
I agree that lots of things must be rewritten on OS/2. So,
a scratch approach can bring us a lot of advantages. But will
take a lot of time. But it'll take forever if no one starts
it. And now, with a place to look on details of the
implementation when needed, there is no reason to consider
it an impossible task.
I think it's wise get a uK such as MACH or any other and
implement OS/2 on top of it, but I do not like the idea of Linux,
for reasons I had already pointed several times on FreeOS, and
I do not want to start another discussion (because this was the
reason I lost my motivation that time).
I do not want to generate a flame war, but I think Linux is
not good enough, and thats all.
The driver availability is not a point. Linux has a small
number of drivers also, and they'll be even smaller in the
future. Linux has already start to suffer the effect of
"saturated media". The press headlines do not point Linux
anymore. Something similar to what happened to OS/2 Warp
in 1993 to 1995. A big "boom" then a dark time.
I do not think Linux will perish, I do not think it's
development will be stalled. I just think once the fever
had gone away, only a small numbers of developers will
continue supporting it (maybe even smaller than today's
OS/2 support, because no one will pay to Sci-Tech develop
drivers, as IBM had done).
I think there are talented guys to develop an OS/2 clone
(and *this* was the reason I started the FreeOS... to look
forward and see if the list could join people capable of
it). Of course it'll take time. But if the OS is developed
wisely, it'll work for a long and long time. I think the
initial approach may focus "general compatibility": standard,
keyboard, VESA video, and this kind of thing. Even sound is
not something we should worry about in the initial stages,
but when it become needed, implement a simple digital driver.
Specific hardware should be implemented only in the future,
since most of the OS will not work in the initial stages,
and in the future the hardware will be different from today's,
turning any effort on drivers to actual hardwares a unwise
way to use the time.
And I think the driver should be a new model. And uK allows
us to have drivers in a higher level, easy to program, portable
and better: more than one driver model can be implemented.
None of these benefits are taken on the Linux approach that
is bluring every OS/2 project.
I hope someone start to do something. I really can't. I'm
not capable of starting such a project. I can help, but not
start it.
If real work will be done, count on me. But don't count
on me on discussions about abstraction of OS programming,
alien programming languages that do everything alone and
doing the work of ten years of a million of men with
10 mens in 2 months. I'm not an academic. And not was those
that created OS/2, BeOS or even Linux.
Just my 2 (hundred) cents about this topic.
[]'s
Daniel Caetano
djcaetano@...
..."A necessidade de criatividade e' o que contribui para a
mudanca. A criatividade mantem o criador vivo." (Frank Herbert)
http://soulmatrix.dynodns.net/ - This OS/2 system uptime is 0 days 12:09 hours.
Re: Part 12
#354 From: "JMA" <mail@...>
Date: Mon Mar 4, 2002 6:24 pm
Subject: Re: My point of view... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 03 Mar 2002 14:49:19 -0300 (EST), Daniel Caetano wrote:
>
> People (Developers and Users),
>
> I'm afraid the project fall down in the same pit
>as FreeOS had fallen... a sad thing that take away
>my motivation.
>
No.
While the people that has started doing things have mostly
talked to me using private email I must say we have started.
I have started with a few cmd line utils and a few other people
have also started. Someone has written a TREE.EXE
replacement that is almost there and while this is not much
its a definite start.
And yes, this is all done without a build environment set up,
the webpage (www.osfree.org) is still my very quick muckup
and we have no place to put code !
It seems there are people that are eager to start and I think my
suggestion to start with cmd tools (for the people that cannot
do CPAPI/kernel things) is something that people has waited for.
The dont want to wait for a wizbang kernel, they rather start now.
This does not in any way mean that I dont want people to go and
start looking at kernel stuff and start writing the CPAPI layer.
Its just that I want everyone to have a chance to help out !
> Some time ago, the same history: BeOS code leaked.
>Someone got it and caused a major problem. Someone
>thought on using it on the OBOS (Open BeOS) development.
>After many ethic discussions, they decided to not use
>the original BeOS code to develop OBOS... but sometimes
>they "take a look" on it. The OBOS project is up and
>running. Somewhat slowly, but I think in some time they'll
>have something.
>
Take a look at the OpenBeOs project page: (http://www.openbeos.org/, faq)
======================================================
I heard a rumor that some official BeOS source code has been leaked.
That would be great for the OpenBeOS project, right?
Wrong!
To be crystal clear about this, OpenBeOS wants in no way to come in contact
with or be associated with any leaked BeOS source code. Having access to that
code could potentially be very damaging to the project, not to mention a legal
nightmare.
======================================================
They more or less says that they dont want the code and dont want anyone (in
their project) to even "take a look" at it. A bit further down they speak about
people that cannot help in the project since they have been BeOS developers.
So, osFree would have a hard time accepting stuff from people that tell us they
"took a look" when they did their code. On the other hand, we cannot assume
everything is "contaminated" just couse somebody says "everyone has it".
>notice. It's not a crime own it, though.
>
According to US and EU laws it is.
> Notice that IBM itself can be prosecuted by the code
>leak, since probably there is code *not* from IBM there.
>And IBM will be very happy to have someone to blame on.
>
Assuming they even care...
> It's illegal? Maybe. But it would be also on other ways.
>Cloning only the known facts of OS/2 would never bring a
>10% compatible OS. And even "empiric tests" are considered
>reverse engineering, which is as illegal as using leaked
>(not stolen) code.
>
Hmmm. I'm not at all sure of that. Its definitly legal to debug
through the kernel.
> I think it's wise get a uK such as MACH or any other and
>implement OS/2 on top of it, but I do not like the idea of Linux,
>for reasons I had already pointed several times on FreeOS, and
>I do not want to start another discussion (because this was the
>reason I lost my motivation that time).
>
> I do not want to generate a flame war, but I think Linux is
>not good enough, and thats all.
>
I choose not to look at the kernel, just to get the ball rolling.
The main thing in OS/2 that needs to be cloned is the CPAPI.
If we can clone that we can run almost everything ontop it.
VIOapps, PM and WPS uses that and does not talk to hardware
nor kernel but in a few situations.
Lets build a good CPAPI layer and build it so it can be placed on
more than one kernel. Then we can much more easily switch
kernel.
But we (as a small group in a small community) should stay away from
kernel development. It takes lots of work and time and will take just
time and work from whats good with OS/2.
Unless you all feel that the best thing with OS/2 is the kernel and
drivers interface
> If real work will be done, count on me. But don't count
>on me on discussions about abstraction of OS programming,
>alien programming languages that do everything alone and
>doing the work of ten years of a million of men with
>10 mens in 2 months. I'm not an academic. And not was those
>that created OS/2, BeOS or even Linux.
>
Now, get in contact with webmaster@... and ask him
if you can help with fixing the pages at www.osfree.org.
Then if you can, help out with build environment etc.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Mon Mar 4, 2002 6:24 pm
Subject: Re: My point of view... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 03 Mar 2002 14:49:19 -0300 (EST), Daniel Caetano wrote:
>
> People (Developers and Users),
>
> I'm afraid the project fall down in the same pit
>as FreeOS had fallen... a sad thing that take away
>my motivation.
>
No.
While the people that has started doing things have mostly
talked to me using private email I must say we have started.
I have started with a few cmd line utils and a few other people
have also started. Someone has written a TREE.EXE
replacement that is almost there and while this is not much
its a definite start.
And yes, this is all done without a build environment set up,
the webpage (www.osfree.org) is still my very quick muckup
and we have no place to put code !
It seems there are people that are eager to start and I think my
suggestion to start with cmd tools (for the people that cannot
do CPAPI/kernel things) is something that people has waited for.
The dont want to wait for a wizbang kernel, they rather start now.
This does not in any way mean that I dont want people to go and
start looking at kernel stuff and start writing the CPAPI layer.
Its just that I want everyone to have a chance to help out !
> Some time ago, the same history: BeOS code leaked.
>Someone got it and caused a major problem. Someone
>thought on using it on the OBOS (Open BeOS) development.
>After many ethic discussions, they decided to not use
>the original BeOS code to develop OBOS... but sometimes
>they "take a look" on it. The OBOS project is up and
>running. Somewhat slowly, but I think in some time they'll
>have something.
>
Take a look at the OpenBeOs project page: (http://www.openbeos.org/, faq)
======================================================
I heard a rumor that some official BeOS source code has been leaked.
That would be great for the OpenBeOS project, right?
Wrong!
To be crystal clear about this, OpenBeOS wants in no way to come in contact
with or be associated with any leaked BeOS source code. Having access to that
code could potentially be very damaging to the project, not to mention a legal
nightmare.
======================================================
They more or less says that they dont want the code and dont want anyone (in
their project) to even "take a look" at it. A bit further down they speak about
people that cannot help in the project since they have been BeOS developers.
So, osFree would have a hard time accepting stuff from people that tell us they
"took a look" when they did their code. On the other hand, we cannot assume
everything is "contaminated" just couse somebody says "everyone has it".
>notice. It's not a crime own it, though.
>
According to US and EU laws it is.
> Notice that IBM itself can be prosecuted by the code
>leak, since probably there is code *not* from IBM there.
>And IBM will be very happy to have someone to blame on.
>
Assuming they even care...
> It's illegal? Maybe. But it would be also on other ways.
>Cloning only the known facts of OS/2 would never bring a
>10% compatible OS. And even "empiric tests" are considered
>reverse engineering, which is as illegal as using leaked
>(not stolen) code.
>
Hmmm. I'm not at all sure of that. Its definitly legal to debug
through the kernel.
> I think it's wise get a uK such as MACH or any other and
>implement OS/2 on top of it, but I do not like the idea of Linux,
>for reasons I had already pointed several times on FreeOS, and
>I do not want to start another discussion (because this was the
>reason I lost my motivation that time).
>
> I do not want to generate a flame war, but I think Linux is
>not good enough, and thats all.
>
I choose not to look at the kernel, just to get the ball rolling.
The main thing in OS/2 that needs to be cloned is the CPAPI.
If we can clone that we can run almost everything ontop it.
VIOapps, PM and WPS uses that and does not talk to hardware
nor kernel but in a few situations.
Lets build a good CPAPI layer and build it so it can be placed on
more than one kernel. Then we can much more easily switch
kernel.
But we (as a small group in a small community) should stay away from
kernel development. It takes lots of work and time and will take just
time and work from whats good with OS/2.
Unless you all feel that the best thing with OS/2 is the kernel and
drivers interface
> If real work will be done, count on me. But don't count
>on me on discussions about abstraction of OS programming,
>alien programming languages that do everything alone and
>doing the work of ten years of a million of men with
>10 mens in 2 months. I'm not an academic. And not was those
>that created OS/2, BeOS or even Linux.
>
Now, get in contact with webmaster@... and ask him
if you can help with fixing the pages at www.osfree.org.
Then if you can, help out with build environment etc.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 12
#355 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Mar 5, 2002 10:13 am
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"...Lets build a good CPAPI layer and build it so it can be placed
on more than one kernel. Then we can much more easily switch
kernel. ..."
As a retired IBM employee I find myself disqualified from
participating in the coding of the kernel. That leaves me with
participating in the documentation only. However, we may as well
put this portable CPAPI issue to rest. If you haven't the
resources to produce a single kernel, you have even less to
produce multiple.
Everything from the CPAPI on down is part of the kernel. Implicit
in this remark is that the CPAPI is somehow an OS personality
sitting on top of some unspecified layer. What isn't said is that
from the CPAPI on down to the fundamental APIs is an architecture.
No matter how you word it you have an architected, logical
hierarchy from the highest to lowest APIs. To make a layered cut
somewhere within that hierarchy, to say that which is above is
portable and that which is below is not is to say the least
illogical.
The microkernel results from the assertion that there is lowest
set of APis which depend upon no other and upon which higher level
APIs up to the "application" layer depend. Each API has a name, a
set of parameters, a defined set of processes, an input, and an
output, all of which define an architected data and control flow.
There is no "cut" on any path or "cuts" on any set of paths that
defines a minimal "cut" less than those of the microkernel.
In short it is the microkernel which is "portable" in that by
definition (and intent) any OS personality can be built upon it.
The microkernel with any OS personality makes up a complete
kernel. The microkernel with multiple OS personalities makes up a
complete set of kernels.
As applications, which also include utilities, commands, and
programming languages, e.g. REXX and JAVA, are written to the
CPAPI layer they are not portable across OSes without being
rewritten and thus requiring separate maintenance as well as
additional synchronization. However, it is possible to write
every OS CPAPI to a single microkernel API. There's no
requirement for synchronization among OS personalities nor a
requirement for portability of any application across more than
one supported OS personality.
So the microkernel provides the least effort path for OS
personality and application writers. Moreover it does not require
a rewrite of an existing application to a different CPAPI, if that
CPAPI is supported as an OS personality on a microkernel.
So the argument is that you have a lowest level set of APIs
dependent upon no other and on which higher level APIs to the
CPAPI level may be built. The issue is the set of the lowest
level APIs. An agreement on these effectively defines the
possibilities of an CPAPI set of an OS personality, the
development of which can proceed asynchronously.
It is clear that the architecture of the lowest level can have a
performance impact. This says that there is at least one equal in
performance to that on which any given OS personality is placed.
The argument is not microkernel versus non-microkernel. Instead
it is an argument about architecture. The lowest level APIs
exist. That is a given. It is the nature of their existence,
their architecture, at issue here.
So if the MACH kernel(s) do not offer maximum performance, don't
use it (them). The same for any other microkernel, including
variations like ReactOS. If your desire is to produce an open
source clone of OS/2, what better future for OS/2 than one in
which multiple other OS personalities are also cloned. You not
only preserve individual application investments in different OS
personalities, but open up a new marketplace for vendors currently
restricted to a single OS personality.
Like Daniel Caetano I favor the microkernel approach, but one so
architected as to provide the maximum in performance, uses the
least reasources, offers the most in quality (stability and
security), offers the most in function, and requires the least in
overall maintenance. If there was such an assembly language guru,
he could not improve upon this system.
I know of no reason why writing a kernel, a hierarchical set of
APIs, is more difficult than writing any sophisticated application
system of comparable layering. Having written and participated in
writing several operating systems in the 60's, I've seen nothing
in terms of enhancements since that time. Certainly not with the
introduction of UNIX and C, which in terms of progress was
regressive IMHO. No one should be frightened in terms of lack of
experience.
The secret lies in analysis and design, producing the architecture
of APIs. You can begin with the lowest level, the micro- or
core-kernel and the highest level (of any OS personality). Then
through an iterative process create an OS personality that not
only offers its current CPAPI, but extends with others, with other
function, not currently (or easily) available in any native OS.
In doing that you don't have to worry about Linux or Microsoft.
They will have to worry about you. That puts you in the driver's
seat.
Analysis and design is not coding, but the work which should
precede it. You can assume the OS/2 CPAPI in your coding efforts,
because it is a given. Understand that no such given exists, no
defined architecture exists, below that level. To start coding in
it prior to having such an defined architecture is to love to
rewrite more than write.<g>
The ReactOS people supposedly have such an architecture. The only
issue is the possibilities of their lowest level APIs. If they
are not as complete functionally as some of those presented in the
different microkernel efforts, then we should reject it. If they
are, then we should consider using it as a starting point, given
that no performance hits are builtin. If they are, reject it.
There's no need and certainly no marketing advantage in producing
less than the best. There's certainly no extra effort required
overall in doing so.
Date: Tue Mar 5, 2002 10:13 am
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"...Lets build a good CPAPI layer and build it so it can be placed
on more than one kernel. Then we can much more easily switch
kernel. ..."
As a retired IBM employee I find myself disqualified from
participating in the coding of the kernel. That leaves me with
participating in the documentation only. However, we may as well
put this portable CPAPI issue to rest. If you haven't the
resources to produce a single kernel, you have even less to
produce multiple.
Everything from the CPAPI on down is part of the kernel. Implicit
in this remark is that the CPAPI is somehow an OS personality
sitting on top of some unspecified layer. What isn't said is that
from the CPAPI on down to the fundamental APIs is an architecture.
No matter how you word it you have an architected, logical
hierarchy from the highest to lowest APIs. To make a layered cut
somewhere within that hierarchy, to say that which is above is
portable and that which is below is not is to say the least
illogical.
The microkernel results from the assertion that there is lowest
set of APis which depend upon no other and upon which higher level
APIs up to the "application" layer depend. Each API has a name, a
set of parameters, a defined set of processes, an input, and an
output, all of which define an architected data and control flow.
There is no "cut" on any path or "cuts" on any set of paths that
defines a minimal "cut" less than those of the microkernel.
In short it is the microkernel which is "portable" in that by
definition (and intent) any OS personality can be built upon it.
The microkernel with any OS personality makes up a complete
kernel. The microkernel with multiple OS personalities makes up a
complete set of kernels.
As applications, which also include utilities, commands, and
programming languages, e.g. REXX and JAVA, are written to the
CPAPI layer they are not portable across OSes without being
rewritten and thus requiring separate maintenance as well as
additional synchronization. However, it is possible to write
every OS CPAPI to a single microkernel API. There's no
requirement for synchronization among OS personalities nor a
requirement for portability of any application across more than
one supported OS personality.
So the microkernel provides the least effort path for OS
personality and application writers. Moreover it does not require
a rewrite of an existing application to a different CPAPI, if that
CPAPI is supported as an OS personality on a microkernel.
So the argument is that you have a lowest level set of APIs
dependent upon no other and on which higher level APIs to the
CPAPI level may be built. The issue is the set of the lowest
level APIs. An agreement on these effectively defines the
possibilities of an CPAPI set of an OS personality, the
development of which can proceed asynchronously.
It is clear that the architecture of the lowest level can have a
performance impact. This says that there is at least one equal in
performance to that on which any given OS personality is placed.
The argument is not microkernel versus non-microkernel. Instead
it is an argument about architecture. The lowest level APIs
exist. That is a given. It is the nature of their existence,
their architecture, at issue here.
So if the MACH kernel(s) do not offer maximum performance, don't
use it (them). The same for any other microkernel, including
variations like ReactOS. If your desire is to produce an open
source clone of OS/2, what better future for OS/2 than one in
which multiple other OS personalities are also cloned. You not
only preserve individual application investments in different OS
personalities, but open up a new marketplace for vendors currently
restricted to a single OS personality.
Like Daniel Caetano I favor the microkernel approach, but one so
architected as to provide the maximum in performance, uses the
least reasources, offers the most in quality (stability and
security), offers the most in function, and requires the least in
overall maintenance. If there was such an assembly language guru,
he could not improve upon this system.
I know of no reason why writing a kernel, a hierarchical set of
APIs, is more difficult than writing any sophisticated application
system of comparable layering. Having written and participated in
writing several operating systems in the 60's, I've seen nothing
in terms of enhancements since that time. Certainly not with the
introduction of UNIX and C, which in terms of progress was
regressive IMHO. No one should be frightened in terms of lack of
experience.
The secret lies in analysis and design, producing the architecture
of APIs. You can begin with the lowest level, the micro- or
core-kernel and the highest level (of any OS personality). Then
through an iterative process create an OS personality that not
only offers its current CPAPI, but extends with others, with other
function, not currently (or easily) available in any native OS.
In doing that you don't have to worry about Linux or Microsoft.
They will have to worry about you. That puts you in the driver's
seat.
Analysis and design is not coding, but the work which should
precede it. You can assume the OS/2 CPAPI in your coding efforts,
because it is a given. Understand that no such given exists, no
defined architecture exists, below that level. To start coding in
it prior to having such an defined architecture is to love to
rewrite more than write.<g>
The ReactOS people supposedly have such an architecture. The only
issue is the possibilities of their lowest level APIs. If they
are not as complete functionally as some of those presented in the
different microkernel efforts, then we should reject it. If they
are, then we should consider using it as a starting point, given
that no performance hits are builtin. If they are, reject it.
There's no need and certainly no marketing advantage in producing
less than the best. There's certainly no extra effort required
overall in doing so.
Re: Part 12
#356 From: "timur_tabi" <timur@...>
Date: Tue Mar 5, 2002 7:53 pm
Subject: Re: Linux + OS/2 layer timur_tabi
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
>
> Interesting, I never looked at it that way. You're right, they added
> something to the module loading mechanism to detect kernel
> version/driver version mismatches and prevent the driver from
loading. I
> think however that in most cases it will be enough to re'make' the
> driver again to get it working.
The Linux kernel is designed such that all drivers must be compiled
with the kernel. You don't just add a driver to an existing kernel -
you need to recompile the kernel itself. There are two reasons why
it's done this way:
1. It's more difficult to add binary compatibility to the kernel - you
would need to create hundreds of APIs and then "lock" them so that
they don't change from one kernel release to another.
2. The current method promotes the Open Source agenda. Allowing
binary compatibility makes it much easier to release binary-only
drivers. What makes this more interesting is that it actually works -
companies that wouldn't normally release their source code have done
so to support Linux.
What makes this problem so onerous is that I'm not familiar with any
Linux distribution that makes it easy to recompile the kernel. For
some reason, I've never seen any distribution that installs the kernel
source in such a manner that you can just type in "make install" and
have it built the EXACT same kernel that is running in your system.
Red Hat, for instance, installs the kernel source, but puts the
configuration files somewhere else. You need to determine which
config file to use, copy it to the right place, then much around with
it a bit more, execute a few commands, edit lilo.conf, reboot and
cross your fingers. Oh, and if you want to build an OPTIMIZED kernel,
forget it. You'll need to do all the work yourself. God forbid
someone writes a utility that scans your current configuration and
builds a compatible .config file.
Linux #1 problem is that none of the distribution vendors really
understand what "user friendly" really means.
Date: Tue Mar 5, 2002 7:53 pm
Subject: Re: Linux + OS/2 layer timur_tabi
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Bert Thomas <bert@b...> wrote:
>
> Interesting, I never looked at it that way. You're right, they added
> something to the module loading mechanism to detect kernel
> version/driver version mismatches and prevent the driver from
loading. I
> think however that in most cases it will be enough to re'make' the
> driver again to get it working.
The Linux kernel is designed such that all drivers must be compiled
with the kernel. You don't just add a driver to an existing kernel -
you need to recompile the kernel itself. There are two reasons why
it's done this way:
1. It's more difficult to add binary compatibility to the kernel - you
would need to create hundreds of APIs and then "lock" them so that
they don't change from one kernel release to another.
2. The current method promotes the Open Source agenda. Allowing
binary compatibility makes it much easier to release binary-only
drivers. What makes this more interesting is that it actually works -
companies that wouldn't normally release their source code have done
so to support Linux.
What makes this problem so onerous is that I'm not familiar with any
Linux distribution that makes it easy to recompile the kernel. For
some reason, I've never seen any distribution that installs the kernel
source in such a manner that you can just type in "make install" and
have it built the EXACT same kernel that is running in your system.
Red Hat, for instance, installs the kernel source, but puts the
configuration files somewhere else. You need to determine which
config file to use, copy it to the right place, then much around with
it a bit more, execute a few commands, edit lilo.conf, reboot and
cross your fingers. Oh, and if you want to build an OPTIMIZED kernel,
forget it. You'll need to do all the work yourself. God forbid
someone writes a utility that scans your current configuration and
builds a compatible .config file.
Linux #1 problem is that none of the distribution vendors really
understand what "user friendly" really means.
Re: Part 12
#357 From: "tomleem7659" <jersey@...>
Date: Tue Mar 5, 2002 11:23 pm
Subject: Microwindows gui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I was referred to microwindows gui when I asked the
FreeDOS group about a small graphical user interface
that could be used with their FreeDOS software
(http://www.freedos.org) and be used to start programs
without having to go their directories. I found the
microwindows gui web site (http://www.microwindows.org).
Can this be used with the 'osfree' project? I believe
it is open source.
TomLeeM
Date: Tue Mar 5, 2002 11:23 pm
Subject: Microwindows gui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I was referred to microwindows gui when I asked the
FreeDOS group about a small graphical user interface
that could be used with their FreeDOS software
(http://www.freedos.org) and be used to start programs
without having to go their directories. I found the
microwindows gui web site (http://www.microwindows.org).
Can this be used with the 'osfree' project? I believe
it is open source.
TomLeeM
Re: Part 12
#358 From: "Seth" <snberk@...>
Date: Tue Mar 5, 2002 10:04 pm
Subject: Re: Digest Number 23 snberk4055
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I have only just started reading this digest - but I have
question:
I have read in the digests that there is group trying to clone
BeOS, and this group (or two?) trying to clone OS/2. And maybe
there are other groups trying to clone other OSes. The BeOS
group and this group seem to be wanting to stay away from leaked
source code. In that case - why are you trying to clone? Why
not just build it from the ground up? If you are going to stay
away from the sources, then it seems to me that it is just as
much work to build something that looks like an existing
structure, as a completely new structure. And a clone of
anything will always be judged (partly) by how much it resembles
the original, flaws and all, as well as how well it actually
works.
As a non-developer, I don't much care *how* the system works, as
long as it is stable and runs the hardware and software I use.
I like OS/2 because of this and because of the WPS. Any new
open source OS would *have* to have a WPS (in function if not in
appearance) to be at all attractive to me. Whether the new WPS
ran on Linux or BeOS or something new is not big deal to me - if
it works. Rewriting the WPS to be portable has some interesting
implications. If you could easily graft it onto
Linux/Unix/freeBeOS/something-yet-to-be-created.
Or I could be totally out to lunch.
Seth
Date: Tue Mar 5, 2002 10:04 pm
Subject: Re: Digest Number 23 snberk4055
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I have only just started reading this digest - but I have
question:
I have read in the digests that there is group trying to clone
BeOS, and this group (or two?) trying to clone OS/2. And maybe
there are other groups trying to clone other OSes. The BeOS
group and this group seem to be wanting to stay away from leaked
source code. In that case - why are you trying to clone? Why
not just build it from the ground up? If you are going to stay
away from the sources, then it seems to me that it is just as
much work to build something that looks like an existing
structure, as a completely new structure. And a clone of
anything will always be judged (partly) by how much it resembles
the original, flaws and all, as well as how well it actually
works.
As a non-developer, I don't much care *how* the system works, as
long as it is stable and runs the hardware and software I use.
I like OS/2 because of this and because of the WPS. Any new
open source OS would *have* to have a WPS (in function if not in
appearance) to be at all attractive to me. Whether the new WPS
ran on Linux or BeOS or something new is not big deal to me - if
it works. Rewriting the WPS to be portable has some interesting
implications. If you could easily graft it onto
Linux/Unix/freeBeOS/something-yet-to-be-created.
Or I could be totally out to lunch.
Seth
Re: Part 12
#359 From: "JMA" <mail@...>
Date: Wed Mar 6, 2002 1:07 pm
Subject: Re: Digest Number 23 mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 11:04:13 -0800 (PST), Seth wrote:
>I have only just started reading this digest - but I have
>question:
>
>I have read in the digests that there is group trying to clone
>BeOS, and this group (or two?) trying to clone OS/2. And maybe
>there are other groups trying to clone other OSes. The BeOS
>group and this group seem to be wanting to stay away from leaked
>source code. In that case - why are you trying to clone? Why
<SNIP>
>open source OS would *have* to have a WPS (in function if not in
>appearance) to be at all attractive to me. Whether the new WPS
>ran on Linux or BeOS or something new is not big deal to me - if
>it works. Rewriting the WPS to be portable has some interesting
>implications. If you could easily graft it onto
>Linux/Unix/freeBeOS/something-yet-to-be-created.
>
>Or I could be totally out to lunch.
>
Well, there is nothing wrong with a good lunch
Cloning (here) means looking at the existing OS and making
something that acts and looks as much as possible like it.
Reasons to stay away from source has already been stated.
Now building something new is nice but it gives a few questions:
- What apps would it run ? Building an OS with no apps is futile.
And if we dont support OS/2 apps then why do this at all.
osFree is a OS/2 clone, not a Windows or BeOS clone.
- Are there drivers ? Same here.
- What should it look and act like ?
The people here wants to continue to use as much as possible
of OS/2. Some like kernel (few though). Some like the API,
some like PM and some like WPS. If we will ever get a group
we must get enough people interested.
You want WPS, WPS is linked to an object model (Corba) and PM
as a rendering agent. If you do a portable WPS you have to have
a object model and a rendering agent. I can assure you it would be
an enourmous task to graft it onto things like Linux or BeOS and
still be able to easily port wps apps there.
The biggest reason for keeping it as close to OS/2 as possible it for
us to
a) Run unmodified OS/2 binaries
b) OS/2 is layered, if we make a CPAPI we can put the command
line and tools there. PM uses the CPAPI and commandline tools,
WPS uses PM. We have to cut somewhere unless we want to '
emulate OS2BOOT and the CPAPI seems to be the best place
c) We want to keep the knowledge we have all gathered through the
years. If we were novices with no OS/2 knowledgen then we should
just grab another OS.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Wed Mar 6, 2002 1:07 pm
Subject: Re: Digest Number 23 mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Tue, 05 Mar 2002 11:04:13 -0800 (PST), Seth wrote:
>I have only just started reading this digest - but I have
>question:
>
>I have read in the digests that there is group trying to clone
>BeOS, and this group (or two?) trying to clone OS/2. And maybe
>there are other groups trying to clone other OSes. The BeOS
>group and this group seem to be wanting to stay away from leaked
>source code. In that case - why are you trying to clone? Why
<SNIP>
>open source OS would *have* to have a WPS (in function if not in
>appearance) to be at all attractive to me. Whether the new WPS
>ran on Linux or BeOS or something new is not big deal to me - if
>it works. Rewriting the WPS to be portable has some interesting
>implications. If you could easily graft it onto
>Linux/Unix/freeBeOS/something-yet-to-be-created.
>
>Or I could be totally out to lunch.
>
Well, there is nothing wrong with a good lunch
Cloning (here) means looking at the existing OS and making
something that acts and looks as much as possible like it.
Reasons to stay away from source has already been stated.
Now building something new is nice but it gives a few questions:
- What apps would it run ? Building an OS with no apps is futile.
And if we dont support OS/2 apps then why do this at all.
osFree is a OS/2 clone, not a Windows or BeOS clone.
- Are there drivers ? Same here.
- What should it look and act like ?
The people here wants to continue to use as much as possible
of OS/2. Some like kernel (few though). Some like the API,
some like PM and some like WPS. If we will ever get a group
we must get enough people interested.
You want WPS, WPS is linked to an object model (Corba) and PM
as a rendering agent. If you do a portable WPS you have to have
a object model and a rendering agent. I can assure you it would be
an enourmous task to graft it onto things like Linux or BeOS and
still be able to easily port wps apps there.
The biggest reason for keeping it as close to OS/2 as possible it for
us to
a) Run unmodified OS/2 binaries
b) OS/2 is layered, if we make a CPAPI we can put the command
line and tools there. PM uses the CPAPI and commandline tools,
WPS uses PM. We have to cut somewhere unless we want to '
emulate OS2BOOT and the CPAPI seems to be the best place
c) We want to keep the knowledge we have all gathered through the
years. If we were novices with no OS/2 knowledgen then we should
just grab another OS.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 12
#360 Re: [osFree] Re: Linux + OS/2 layer
Expand Messages
Bert Thomas
Mar 6, 2002
timur_tabi wrote:
>
> --- In osFree@y..., Bert Thomas <bert@b...> wrote:
> >
>
> > Interesting, I never looked at it that way. You're right, they added
> > something to the module loading mechanism to detect kernel
> > version/driver version mismatches and prevent the driver from
> loading. I
> > think however that in most cases it will be enough to re'make' the
> > driver again to get it working.
>
> The Linux kernel is designed such that all drivers must be compiled
> with the kernel. You don't just add a driver to an existing kernel -
> you need to recompile the kernel itself. There are two reasons why
> it's done this way:
I know you are very experienced in this area (kernel/driver development,
OS architecture, etc) and therefore I am very supprised by this
statement, especially coming from you. AFAIK, in "classical" Unix
drivers are build into the kernel. In remember that SCO's Unix for
example used that structure, and in order for an user to
add/remove/change a driver he/she would have to relink te kernel;
drivers were distributed as object files.
Linux originally took this path, but later on they changed it to support
loading drivers at runtime. Ok, nowadays the kernel still supports it to
compile drivers into the kernel, but that is mainly for special
application and certain drivers for "special" hardware. OS/2 also has
some "drivers" build into the kernel if I remember correctly. I think it
had something to do with the clock/timer hardware.
> 1. It's more difficult to add binary compatibility to the kernel - you
> would need to create hundreds of APIs and then "lock" them so that
> they don't change from one kernel release to another.
Would you really need hundreds of APIs for a driver??? OS/2's DevHelp
doesn't support hundreds of function calls, does it?
Linux drivers in principle use a very well defined set of APIs and
structures. I am not a very skilled driver developer, but I have written
several loadable kernel modules for Linux. None of them needed something
other than just this basic API set. It was just recently that I
discovered that my "old" drivers wouldn't work on a new kernel. Not
because something had changed in the APIs or internal structure, but
just because they added that version detection mechanism.
(OT: trying to load the original driver resulted in a very obscure
message. I searched for a description in the "LKM howto", and it
explained: this is Unix, and descriptive messages are seen as a sign of
weakness")
> 2. The current method promotes the Open Source agenda. Allowing
> binary compatibility makes it much easier to release binary-only
> drivers. What makes this more interesting is that it actually works -
> companies that wouldn't normally release their source code have done
> so to support Linux.
I aggree on the interesting part, but I doubt this was the goal of the
designers. In theory, they could write (and some even do!) loadable
modules for every major version of the kernel and make only the object
binaries available).
>
> What makes this problem so onerous is that I'm not familiar with any
> Linux distribution that makes it easy to recompile the kernel. For
> some reason, I've never seen any distribution that installs the kernel
> source in such a manner that you can just type in "make install" and
> have it built the EXACT same kernel that is running in your system.
SuSE does, though it (SuSE) has many disadvantages in many other area's.
> Red Hat, for instance, installs the kernel source, but puts the
> configuration files somewhere else. You need to determine which
> config file to use, copy it to the right place, then much around with
> it a bit more, execute a few commands, edit lilo.conf, reboot and
> cross your fingers. Oh, and if you want to build an OPTIMIZED kernel,
> forget it. You'll need to do all the work yourself. God forbid
> someone writes a utility that scans your current configuration and
> builds a compatible .config file.
And what about 'make menuconfig' ? Not user friendly enough?
>
> Linux #1 problem is that none of the distribution vendors really
> understand what "user friendly" really means.
>
Isn't that just something in the nature of Unix?
Don't get me wrong, I aggree with you on the disadvantages of Linux, but
as far as I can tell your statement was just false.
Bert
Expand Messages
Bert Thomas
Mar 6, 2002
timur_tabi wrote:
>
> --- In osFree@y..., Bert Thomas <bert@b...> wrote:
> >
>
> > Interesting, I never looked at it that way. You're right, they added
> > something to the module loading mechanism to detect kernel
> > version/driver version mismatches and prevent the driver from
> loading. I
> > think however that in most cases it will be enough to re'make' the
> > driver again to get it working.
>
> The Linux kernel is designed such that all drivers must be compiled
> with the kernel. You don't just add a driver to an existing kernel -
> you need to recompile the kernel itself. There are two reasons why
> it's done this way:
I know you are very experienced in this area (kernel/driver development,
OS architecture, etc) and therefore I am very supprised by this
statement, especially coming from you. AFAIK, in "classical" Unix
drivers are build into the kernel. In remember that SCO's Unix for
example used that structure, and in order for an user to
add/remove/change a driver he/she would have to relink te kernel;
drivers were distributed as object files.
Linux originally took this path, but later on they changed it to support
loading drivers at runtime. Ok, nowadays the kernel still supports it to
compile drivers into the kernel, but that is mainly for special
application and certain drivers for "special" hardware. OS/2 also has
some "drivers" build into the kernel if I remember correctly. I think it
had something to do with the clock/timer hardware.
> 1. It's more difficult to add binary compatibility to the kernel - you
> would need to create hundreds of APIs and then "lock" them so that
> they don't change from one kernel release to another.
Would you really need hundreds of APIs for a driver??? OS/2's DevHelp
doesn't support hundreds of function calls, does it?
Linux drivers in principle use a very well defined set of APIs and
structures. I am not a very skilled driver developer, but I have written
several loadable kernel modules for Linux. None of them needed something
other than just this basic API set. It was just recently that I
discovered that my "old" drivers wouldn't work on a new kernel. Not
because something had changed in the APIs or internal structure, but
just because they added that version detection mechanism.
(OT: trying to load the original driver resulted in a very obscure
message. I searched for a description in the "LKM howto", and it
explained: this is Unix, and descriptive messages are seen as a sign of
weakness")
> 2. The current method promotes the Open Source agenda. Allowing
> binary compatibility makes it much easier to release binary-only
> drivers. What makes this more interesting is that it actually works -
> companies that wouldn't normally release their source code have done
> so to support Linux.
I aggree on the interesting part, but I doubt this was the goal of the
designers. In theory, they could write (and some even do!) loadable
modules for every major version of the kernel and make only the object
binaries available).
>
> What makes this problem so onerous is that I'm not familiar with any
> Linux distribution that makes it easy to recompile the kernel. For
> some reason, I've never seen any distribution that installs the kernel
> source in such a manner that you can just type in "make install" and
> have it built the EXACT same kernel that is running in your system.
SuSE does, though it (SuSE) has many disadvantages in many other area's.
> Red Hat, for instance, installs the kernel source, but puts the
> configuration files somewhere else. You need to determine which
> config file to use, copy it to the right place, then much around with
> it a bit more, execute a few commands, edit lilo.conf, reboot and
> cross your fingers. Oh, and if you want to build an OPTIMIZED kernel,
> forget it. You'll need to do all the work yourself. God forbid
> someone writes a utility that scans your current configuration and
> builds a compatible .config file.
And what about 'make menuconfig' ? Not user friendly enough?
>
> Linux #1 problem is that none of the distribution vendors really
> understand what "user friendly" really means.
>
Isn't that just something in the nature of Unix?
Don't get me wrong, I aggree with you on the disadvantages of Linux, but
as far as I can tell your statement was just false.
Bert