#891 From: Josщ Francisco Garcэa Martэnez <correo@...>
Date: Tue Dec 16, 2003 9:24 pm
Subject: Re: Kernel development jfgarcia_mx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi.
I agree in all points with Cris.
At least we have an important subject in the list.
Yuri Prokushev wrote:
> ** Reply to message from criguada@... on Tue, 16 Dec 2003
> 11:34:34 -0000
>
> > I was reading the "eComStation future" article by Don Eitner. His
> > perspective does have some right points, but it doesn't convince me
> > completely. So I tried putting in clear my thoughts, and now I'm
> > sharing them with you, to see if we can come up with something.
> >
> > 1) It is clear that the OS/2 community isn't after the osFree project,
> > either because they (we) don't have the strength to follow such a big
> > project, either because they've lost faith to osFree due to the leaked
> > sources problem.
> True. But things can be done step by step
>
> > 2) I think it is time to put hands on a kernel replacement. This could
> > even breath new life into the project, moving it into the "serious
> > projects" land, and attracting new programmers. I'm specifically
> > thinking about Knut Stange Osmundsen (sp?) which is a great low-level
> > programmer, and seems attracted by "interesting, nearly impossible"
> > tasks
> Heh, tasks seems not too impossible if just add not lot of missed
> features.
>
> > 3) Like Don, I think we should NOT reinvent the wheel. It should be
> > better to take an already established project and build a
> > "compatibility layer" on it, leaving native development for later
> stages.
> Exactly. Fully agree.
>
> > 4) Unlike Don, I DON'T think we should rewrite the whole thing, not
> > immediately at least. Let's build a compatibility layer on top of the
> > _kernel_ (doscalls, etc.), and try to run original IBM code on top of
> > it. Then move slowly towards replacing parts and adding features (and
> > better using the underlying kernel capabilities).
> Yep.
>
> > 5) In this view, I think it would be better NOT to use a _full_ OS,
> > with it's own established personality and tools, like *BSD is. It
> > would be better to build upon an open kernel that gives us the
> > features we need.
> Again, agree.
>
> > 6) Which possibilities dows we have? Let's see:
> > - *BSD (like Don says)
> > - Darwin (this is the actual base of the new MacOS. BSD-derived)
> > - Linux
> Ghm... From my point of view using kernel from different OS family
> (not so good
> idea. And poll result (Linux on second place) seems very strange for me.
>
> > This are the first that come to mind. Not one of these has me
> > satisfied. Why?
> >
> > - I am used to a desktop operating system, with a consistent look and
> > feel. Unices don't have a consistent look and feel.
> Heh. Darwin is example. Problem mostly in Workplace implementation &
> standartisation.
>
> > - I don't want to fiddle with kernel recompiles, etc. I don't know
> > well about *BSD and Darwin; surely Linux is going towards the "kernel
> > loadable modules" way, but it's still a long way to go.
> True. Recompiling kernel for any (ok, most of) new task... Grrr...
>
> > - I am used to a strong multitasking and multithreading kernel. Unices
> > lack at least in the multithreading capabiltites, and (at least in the
> > original Unix model) use plain round-robin scheduling.
> Again, I consider kernels of OSes from another family must not be
> selected
> as osFree base.
>
> > - All of these alternatives don't fit well with point (5) above.
> Exactly. *nixes is instumental environmet. Just great for developers (heh,
> sure?) but hell for users.
>
> > I started to think about an already existing kernel or OS that have
> > the capabilities we need. Again, let's see:
> >
> > - There's ReactOS, like someone said here. It is going on quite well
> > (at least this is what it looks like). We could use its kernel, but
> > would it make sense? It would have more sense to join the project and
> > build an OS/2 personality. Personally, I'd like a cleaner approach,
> > but it is a possibility.
> We can join to the project. But remember - ReactOS is _Windows_ clone
> (read as
> Win32 API). But we want to have OS/2 API. If OS/2 subsystem will be
> developed
> as part of ReactOS project then forgot about OS/2. It's Windows NT.
> ReactOS
> will act as NT, not OS/2. OS/2 subsystem will be just another
> compatability
> layer. But if OS/2 subsystem will be developed as core subsystem, then
> Win32
> will be treated as additional compatability API. Again, ReactOS
> project will
> force to use Explorer as the shell. But we need WPS (really, I consider
> SOM/CORBA must be core of osFree, not 'classic' PM API). We need REXX,
> ReactOS
> will force with WSS (windows scripting server).
>
> So, clear division of osFree project from ReactOS project (Win32
> implementation, to be clear) can be solution. And remember, results of
> osFree
> project can be used in ReactOS project and vice versa.
>
> > - There's OpenBeOS. The BeOS kernel traditionally had all that we
> > need, and it supported extended atributes on the file system like OS/2
> > (although this is not a kernel related thing, probably). OpenBeOS is
> > based on the NewOS kernel (newos.sf.net), which, in his author's
> > words, is designed to be easily customized.
> Know nothing about it yet.
>
> > Personally, I'd like to investigate this last possibility, and get
> > feedback from other group members, preferably those which (unlike me)
> > possess a good technical knowledge about kernel development, and are
> > willing to do something.
> nice to hear.
>
> > So, start adding comments, and please NO flames, this is not an
> > OS-War, and all that has been said is only my *personal* point of view.
> I'll try
>
> II try to describe my criterions in kernel selection:
>
> 1) divers avalability. As for generic devices as for new devices. Most
> preferrable - for any devices
> 2) CP/M family. Multiple filesystem roots. Example,
> devicename(macos?)/driveletter(CPM/DOS/WIN/OS2) assignment for
> physical/logical
> device/drive.
> 3) Fast and easy implementation of OS/2 API.
> 4) Dynamic-linking, not static, kernel design (as on drivers level as on
> application level)
> 5) Easy porting from other OSes
>
> According ReactOS (kernel):
>
> 1) I consider we will not have problems with drivers avalability. Most
> vendors
> produce drivers for NT.
> 2) NT/ReactOS is CP/M family system
> 3) In most cases OS/2 API will be implemented as easest wrappers
> around Native
> API functions. Also exists (public domain) implementation of OS/2
> DOSCALLS API
> on top of Win32 API (remember, Win32 is just easest wrappers on top
> Native API)
> 4) Dynamiclinking.
> 5) Porting from other OSes. Porting from Win32 OSes not a problem. ReactOS
> implementing Win32. Really, no any porting. Just corresponding subsystem.
> According DOS - NTVDM subsystemp. According Win16 - WoW (Windows on
> Windows)
> subsystem. *nix applications - POSIX subsystem good base for such ports.
>
> Really, support of base OS/2 API (doscalls) can be done easely and
> very fast.
> For this: a) LX loader b) port OS/2 on top of Win32 implementation to
> OS/2 on
> top of Native c) write missed functions.
>
> Native API contains most of required functions. Or, may be, all required
> functions.
>
> And we can easely configure OS to load any preffered shell and any
> prefferred
> subsystem by default.
>
> I consider ReactOS (kernel) is the best (or one of the best) solution.
> And main
> argument it is very quick implementation in comparation with other
> kernels.
>
> No problems with drivers (ideally), with support of 'mainstream'
> applications/fileformats, with kernel development {}.
>
> BTW, PM can be implemented via Win32k part of Win32 subsystem. Result
> - shared
> desktop with windows applications.
>
> wbr,
> Yuri
>
>
> To unsubscribe from this group, send an email to:
>
osFree-unsubscribe@yahoogroups.com
>
>
>
>
> *Yahoo! Groups Sponsor*
>
<
http://rd.yahoo.com/SIG=12cvrkqe2/M=259 ... egroupweb/
S=1705006559:HM/EXP=1071684249/A=1524963/R=0/*
http://hits.411web.com/cgi-bin/aut
oredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups links*
>
> * To visit your group on the web, go to:
>
http://groups.yahoo.com/group/osFree/
>
> * To unsubscribe from this group, send an email to:
>
osFree-unsubscribe@yahoogroups.com
> <mailto:
osFree-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <
http://docs.yahoo.com/info/terms/>.
>
>