[openbeos] Re: Add-ons/Module problems/ideas??

En réponse à Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>:

> >
> >I am listening to the audio from the Linux symposium in Ottawa this
> year.  The 
> >module presentation is quite interesting because, to me, it shows how
> much 
> >better OpenBeOS should be able to do this, especially with its concepts
> of
> >bus managers and userland add-ons. [Caveat: I was not at the
> conference, so
> >I cannot know what transpired in the after talk chats.]    At one point
> Rusty 
> >Russell(?) suggests that Linux get rid of modules all-together. That 
> >astounded me because under Linux:
> 
> I think that he might have been smoking some of RMS' drugs. ;-)
> 
> [snip]
> 
> >Anyhow, my questions to the OpenBeOS community are:
> >
> >Does anyone else here card about these issues?
> 
> Yes, we do. The main reason that you don't see them discussed here is
> that
> they are already decided for R1. In the name of compatability and of
> having 
> a spec "out of the gate". Right, wrong or otherwise, that was my call.
> 
> >Is the BeOS 5.0.3 implementation of addons good enough for OpenBeOS R1?
>   
> 
> Sure. Addons, as a whole, I think, are excellent. I don't remember
> anyone having
> *any* complaints about addons or modules in terms of how they work.
> 

Actually, an load_addon_etc() with B_REUSE_ADDON flag would be nice.
That is, maintain a ref count, just like kernel modules.


> >Doesn't everybody here want a kernel that blows Linux out of the water
> 
> >(excluding drivers which must come from 3rd parties)?   
> 
> Of course. And we will/do. Our kernel as it stands today is not feature
> complete, but
> it is already much better about SMP, IMHO, than Linux 2.4. It is much
> smaller and very
> fast. Of course, that is without some of the features that we will need
> (terminals come to
> mind). And remember, too, that Linux is "other-optimized" - it is
> designed and built to
> be a server. That is a different goal than ours - we intend to be a
> desktop OS. That means 
> things like we will "waste" more CPU cycles task switching more
> frequently, but will be 
> more responsive. We will have less focus on some of the more batch
> oriented directions
> and more on the light weight interactive. As with all design, there are
> tradeoffs. 
> 
> >P.S. I seem to have misplace the URL for the audio, but I can forward
> the
> >few ogg files that I downloaded to anyone who needs them.  Don't
> bother
> 
> I would like them.
> 
> 
> 
>

Other related posts: