Menu
▾
▴
odin-os-devel — Talks about Odin development.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(15) |
Oct
(36) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Brian O. <bo...@pi...> - 2005-12-30 17:18:55
|
This project I guess is dead? The go! os pages are still up but of course totally inactive. Are the concepts of this OS found to be invalid? Is the "Think" component operating system more of a successor to this project? Just curious. As embedded systems start to become more and more popular (ie, nokia 770), it would seem logical that interest in these types of OS's would start to rise again. Of course that does depend on the hardware support available from the ARM processor family. |
|
From: Stanislav K. <be...@up...> - 2004-04-03 22:17:10
|
On Friday 02 April 2004 19:50, you wrote: > Read your name quite often going through the sourcecode. Yesterday i read= a > note in the doc/xml??? about a posible xml format for the idl files. If it > is of any help i might do that and write an xslt-file to make the .inf > files, an idl2xml and a DTD to verify the xml files. Wanted to practise > some more xml stuff anyway. XML stuff might help. It was only an experimental proposition tho, so I'm n= ot=20 sure we are ready to do anything with it yet, but if you feel so inclined -= =20 go for it, it might turn out useful. > Considering the "real" OS-stuff i got to say that i am pretty much a > newbie. But at the moment i got some ideas i want to play around with. The > code seems to be very good to do so since there does not seem to be much = in > libos/odin - so i can just start a new libos to play around. Yes, libos is the actual OS, so you can write many of them for every specif= ic=20 purpose (exokernel OS approach). Thats the one of the best odin points imho= -=20 the core is extremely flexible.. > At the moment i am quite busy. And i=B4ll guess i=B4ll be on holidays the= next > week. But afterwards i might start asking you some questions if you don= =B4t > mind. Yes, feel free. It'd be quite refreshing to update some of my knowledge too= =3D) =2D-=20 keep in touch. berkus. |
|
From: <mwi...@ix...> - 2004-04-02 14:30:06
|
Hello, > Please use this mailing list for communication, as I am sure we all are= =20 > interested in the future of Odin. Thank you. Ooops, sorry I=B4m studying in spain since some days and not used to the = mailer i=20 use here. So i replyed to your personal adresses instead of the list. May= be you=20 (berkus and Greg) can forword my mails to the list since i don=B4t have a= send=20 folder here right now - have to write my mails using public windows deskt= op=20 since it=B4s hard to get your hands on anything else here. thanks, max |
|
From: Stanislav K. <be...@up...> - 2004-04-02 08:42:51
|
On Thursday 01 April 2004 21:30, Greg Law wrote: > mwi...@ix... wrote: > > Hello, > > > > I just played around a bit with go! os until i realized, that the project > > moved. Would like to know if there is still anyone interested in odin os. > > As far as I know, no one is actively working on the project. I get a > request like yours every few months, and I always say that if you want > to pick it up I am more than happy for this. > > Since 2001 I have worked for a company making a "real" CBOS (amongst > other things), and this keeps me very busy. Therefore, I tend not to > have too much time to spend on Go/Odin. But if you want to pick it up > and work with it, I would strongly encourage that and provide whatever > support I can. > > Can I ask why you're interested in the project, and what you hope to do > with it? Yeah, I'm interested too. Tho Odin is in a really DEEP stagnation nowadays, its not dead. I'm fiddling with some bits here and there actually, just was too busy doing KDE work and my main job and family.. And since Greg is also employed man now, we never returned to really continuing with Odin. All your comments and commits are welcome. I really hope we still have odin-os.sf.net and odin.berlios.de alive =) If not i have a local arch copy mirrored to http://mirrors.sourcecontrol.net/be...@up...--2004/ - the really latest stuff is always there.. Please use this mailing list for communication, as I am sure we all are interested in the future of Odin. Thank you. -- keep in touch. berkus. |
|
From: Greg L. <gl...@ne...> - 2004-04-01 15:31:59
|
mwi...@ix... wrote: > Hello, > > I just played around a bit with go! os until i realized, that the project moved. > Would like to know if there is still anyone interested in odin os. As far as I know, no one is actively working on the project. I get a request like yours every few months, and I always say that if you want to pick it up I am more than happy for this. Since 2001 I have worked for a company making a "real" CBOS (amongst other things), and this keeps me very busy. Therefore, I tend not to have too much time to spend on Go/Odin. But if you want to pick it up and work with it, I would strongly encourage that and provide whatever support I can. Can I ask why you're interested in the project, and what you hope to do with it? Greg |
|
From: <mwi...@ix...> - 2004-03-31 18:23:05
|
Hello, I just played around a bit with go! os until i realized, that the project moved. Would like to know if there is still anyone interested in odin os. bye, Max |
|
From: Stanislav K. <be...@vi...> - 2001-11-14 06:42:11
|
Use The Source, Odin! Igor, report your progress... -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Ease of use, ease of programming, joy of power * |
|
From: Chris R. <chr...@br...> - 2001-10-24 13:13:41
|
Could someone, possibly the person that subscribed me in the first place, unsubscribe me, please. -- Chris. |
|
From: Stanislav K. <be...@vi...> - 2001-10-24 13:11:06
|
Use The Source, Odin! anyone got any ideas where did German go? )) -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * *Effective communication is the key to effective operation.* |
|
From: Chris R. <chr...@br...> - 2001-10-11 13:40:52
|
Just unsubscribe me, it's less hassle. Stanislav Karchebny wrote: > > Use The Source, Chris! > > Replying to your mail dated 11.10.2001 19:33, > about "[odin-os-devel] ATA delay talk": > > CR> What was wrong with them? > > Mein gott!!! > Chris get yourself normal mail client already... > Quoting 10kb of text isn't that good idea.... > > -- keep in touch. Stanislav Karchebny. > * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * > * Odin operating system development: http://odin-os.sf.net * > * I'm not sorry, I am having fun... * -- Chris. |
|
From: Chris R. <chr...@br...> - 2001-10-11 13:30:18
|
What was wrong with them?
ai...@li... wrote:
>
> Something seems to be wrong with replies from Chris, so I forward entire
> talk
>
> ------------------------------------------------------------------------
>
> Subject: Re: Re[2]: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 18:35:43 +0300
> From: ai...@li...
> To: berkus <odi...@li...>
>
> Yet more Q:
> When ATA driver resets the interface it should poll it for positive status
> for 31 seconds. There is no interrupt at the end of reset.
> Stupid endless reading of status register until timeout expires seems bad
> implementation for me, because lagre amount of CPU time (up to 31 second! )
> will be wasted on execution of high-priority thread.
> Is there any good way to implement this?
> Maybe driver initialization thread can lower its priority and enter this
> loop, then restore priority at the end? This way we can save some CPU time
> (not a big gain, but it's better than nothing).
>
> Any ideas on this are welcome.
> Igor
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 16:00:39 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> CC: berkus <odi...@li...>
> References: <200...@ns...>
>
> ai...@li... wrote:
> >
> > Yet more Q:
> > When ATA driver resets the interface it should poll it for positive status
> > for 31 seconds. There is no interrupt at the end of reset.
> > Stupid endless reading of status register until timeout expires seems bad
> > implementation for me, because lagre amount of CPU time (up to 31 second! )
> > will be wasted on execution of high-priority thread.
> > Is there any good way to implement this?
>
> Why not take a simple aproach;
>
> init ATA
> sleep(31)
> check status register.
>
> > Maybe driver initialization thread can lower its priority and enter this
> > loop, then restore priority at the end? This way we can save some CPU time
> > (not a big gain, but it's better than nothing).
> >
> > Any ideas on this are welcome.
> > Igor
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:24:00 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> ai...@li... wrote:
> >
> > > ai...@li... wrote:
> > > >
> > > > Yet more Q:
> > > > When ATA driver resets the interface it should poll it for positive
> > status
> > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > Stupid endless reading of status register until timeout expires seems
> > bad
> > > > implementation for me, because lagre amount of CPU time (up to 31
> > second! )
> > > > will be wasted on execution of high-priority thread.
> > > > Is there any good way to implement this?
> > >
> > > Why not take a simple aproach;
> > >
> > > init ATA
> > > sleep(31)
> > > check status register.
> > > Chris.
> >
> > Good, but if drive will become ready in, say, 10 msec and we'll wait for it
> > 31 sec - there's a little overhead, don't you think ?
> > Typically reset takes < 4 seconds (with normal modern drives from low-power
> > mode) or <1 sec if it is made from normal mode (I think driver should avoid
> > this)
>
> So why not:
>
> init ATA
> do {
> sleep(minimum_expected_time)
> device_ready = read device status;
> } while(!device_ready);
>
> So, you'll waste some time but probably little more than that's implied
> with dicking around with thread priorities, which presumably endup with
> a call via reschedule?
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:42:20 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> You either do as I suggest and find a useful 'minimum expected time'
> through investigation, or as you suggest have a low priority thread
> running in the background. I guess a more interesting question to ask is
> how much other work can you do before the ATA is ready to do work ie.
> where does the rest of the OS reside, if it's on that disk what else can
> you do?
>
> ai...@li... wrote:
> >
> > Your suggestion is the most obvious way, but...
> > There's no minimum expected time in the standard!
> > If you have an idea about this time (when standard states nothing, we may
> > invent this statement ourselves), I wait for you suggestions.
> >
> > Igor
> > > ai...@li... wrote:
> > > >
> > > > > ai...@li... wrote:
> > > > > >
> > > > > > Yet more Q:
> > > > > > When ATA driver resets the interface it should poll it for positive
> > > > status
> > > > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > > > Stupid endless reading of status register until timeout expires
> > seems
> > > > bad
> > > > > > implementation for me, because lagre amount of CPU time (up to 31
> > > > second! )
> > > > > > will be wasted on execution of high-priority thread.
> > > > > > Is there any good way to implement this?
> > > > >
> > > > > Why not take a simple aproach;
> > > > >
> > > > > init ATA
> > > > > sleep(31)
> > > > > check status register.
> > > > > Chris.
> > > >
> > > > Good, but if drive will become ready in, say, 10 msec and we'll wait
> > for it
> > > > 31 sec - there's a little overhead, don't you think ?
> > > > Typically reset takes < 4 seconds (with normal modern drives from
> > low-power
> > > > mode) or <1 sec if it is made from normal mode (I think driver should
> > avoid
> > > > this)
> > >
> > > So why not:
> > >
> > > init ATA
> > > do {
> > > sleep(minimum_expected_time)
> > > device_ready = read device status;
> > > } while(!device_ready);
> > >
> > > So, you'll waste some time but probably little more than that's implied
> > > with dicking around with thread priorities, which presumably endup with
> > > a call via reschedule?
> > >
> > > --
> > > Chris.
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re: [odin-os-devel] Drivers
> Date: Wed, 10 Oct 2001 17:53:11 +0100
> From: "Chris Randall" <chr...@br...>
> To: ai...@li...
> References: <200...@ns...>
>
> What does the rest of the world do?
>
> ai...@li... wrote:
> >
> > If the OS is on that disk, than I can do simple stupid polling loop,
> > because there's nothing we can do.
> > But there may be other components already loaded with that driver and they
> > may do something useful.
> > Even more: sometimes reset maybe needed not only during boot-up (interface
> > reset is the only way of waking a drive from deepest power-down mode)
> >
> > Igor
> >
> > > You either do as I suggest and find a useful 'minimum expected time'
> > > through investigation, or as you suggest have a low priority thread
> > > running in the background. I guess a more interesting question to ask is
> > > how much other work can you do before the ATA is ready to do work ie.
> > > where does the rest of the OS reside, if it's on that disk what else can
> > > you do?
> > >
> > >
> > > ai...@li... wrote:
> > > >
> > > > Your suggestion is the most obvious way, but...
> > > > There's no minimum expected time in the standard!
> > > > If you have an idea about this time (when standard states nothing, we
> > may
> > > > invent this statement ourselves), I wait for you suggestions.
> > > >
> > > > Igor
> > > > > ai...@li... wrote:
> > > > > >
> > > > > > > ai...@li... wrote:
> > > > > > > >
> > > > > > > > Yet more Q:
> > > > > > > > When ATA driver resets the interface it should poll it for
> > positive
> > > > > > status
> > > > > > > > for 31 seconds. There is no interrupt at the end of reset.
> > > > > > > > Stupid endless reading of status register until timeout expires
> > > > seems
> > > > > > bad
> > > > > > > > implementation for me, because lagre amount of CPU time (up to
> > 31
> > > > > > second! )
> > > > > > > > will be wasted on execution of high-priority thread.
> > > > > > > > Is there any good way to implement this?
> > > > > > >
> > > > > > > Why not take a simple aproach;
> > > > > > >
> > > > > > > init ATA
> > > > > > > sleep(31)
> > > > > > > check status register.
> > > > > > > Chris.
> > > > > >
> > > > > > Good, but if drive will become ready in, say, 10 msec and we'll
> > wait
> > > > for it
> > > > > > 31 sec - there's a little overhead, don't you think ?
> > > > > > Typically reset takes < 4 seconds (with normal modern drives from
> > > > low-power
> > > > > > mode) or <1 sec if it is made from normal mode (I think driver
> > should
> > > > avoid
> > > > > > this)
> > > > >
> > > > > So why not:
> > > > >
> > > > > init ATA
> > > > > do {
> > > > > sleep(minimum_expected_time)
> > > > > device_ready = read device status;
> > > > > } while(!device_ready);
> > > > >
> > > > > So, you'll waste some time but probably little more than that's
> > implied
> > > > > with dicking around with thread priorities, which presumably endup
> > with
> > > > > a call via reschedule?
> > > > >
> > > > > --
> > > > > Chris.
> > >
> > > --
> > > Chris.
>
> --
> Chris.
>
> ------------------------------------------------------------------------
>
> Subject: Re[2]: [odin-os-devel] Drivers
> Date: Thu, 11 Oct 2001 12:00:12 +0600
> From: "Stanislav Karchebny" <be...@vi...>
> Reply-To: berkus <odi...@li...>
> Organization: visual mechanics
> To: alar <odi...@li...>
> References: <200...@ns...>
> <3BC...@br...>
>
> >> Is there any good way to implement this?
>
> CR> Why not take a simple aproach;
>
> CR> init ATA
> CR> sleep(31)
> CR> check status register.
>
> Good idea. However, ATA may finish its resetting before 31 seconds
> expire and waiting that much can be frustrating for user (e.g. during
> bootup). A modification of this approach would be to check status
> register each 5 or 3 seconds or even each 1 second - this way not much
> cpu time is wasted and response time is adequate.
>
> -- keep in touch. Stanislav Karchebny.
> * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 *
> * Odin operating system development: http://odin-os.sf.net *
> * Components down to the metal *
--
Chris.
|
|
From: <ai...@li...> - 2001-10-11 11:32:32
|
Something seems to be wrong with replies from Chris, so I forward entire talk |
|
From: Stanislav K. <be...@vi...> - 2001-10-11 06:01:45
|
>> Is there any good way to implement this? CR> Why not take a simple aproach; CR> init ATA CR> sleep(31) CR> check status register. Good idea. However, ATA may finish its resetting before 31 seconds expire and waiting that much can be frustrating for user (e.g. during bootup). A modification of this approach would be to check status register each 5 or 3 seconds or even each 1 second - this way not much cpu time is wasted and response time is adequate. -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Components down to the metal * |
|
From: Chris R. <chr...@br...> - 2001-10-10 15:00:45
|
ai...@li... wrote: > > Yet more Q: > When ATA driver resets the interface it should poll it for positive status > for 31 seconds. There is no interrupt at the end of reset. > Stupid endless reading of status register until timeout expires seems bad > implementation for me, because lagre amount of CPU time (up to 31 second! ) > will be wasted on execution of high-priority thread. > Is there any good way to implement this? Why not take a simple aproach; init ATA sleep(31) check status register. > Maybe driver initialization thread can lower its priority and enter this > loop, then restore priority at the end? This way we can save some CPU time > (not a big gain, but it's better than nothing). > > Any ideas on this are welcome. > Igor -- Chris. |
|
From: <ai...@li...> - 2001-10-10 14:50:09
|
Yet more Q: When ATA driver resets the interface it should poll it for positive status for 31 seconds. There is no interrupt at the end of reset. Stupid endless reading of status register until timeout expires seems bad implementation for me, because lagre amount of CPU time (up to 31 second! ) will be wasted on execution of high-priority thread. Is there any good way to implement this? Maybe driver initialization thread can lower its priority and enter this loop, then restore priority at the end? This way we can save some CPU time (not a big gain, but it's better than nothing). Any ideas on this are welcome. Igor |
|
From: Greg L. <gl...@ne...> - 2001-10-04 07:37:23
|
Stanislav Karchebny wrote: ... >=20 > However, I don't want mem_mgr to rely on some ORB.* defines or > anything - we can dynamically change ORB as well as mem_mgr, so they > better cooperate. >=20 > So the ORB (in its current implementation) returns locations of its > stack, code and static data... (Other implementations however, may > allocate additional regions..) OK, you win again :-) G --=20 ____________________________________________ Greg Law NexWave Solutions (http://www.nexwave-solutions.com) NexWave Building - CS 89006 1068, Rue de la Vieille Poste 34967 MONTPELLIER Cedex 2 - FRANCE Tel. : +33 (0) 4 99 52 89 89 - Fax : +33 (0) 4 99 52 89 88 _______________________________________________ This message is confidential; its contents do not constitute a commitment by NexWave Solutions except where provided for in a written agreement between you and NexWave Solutions. Any unauthorized disclosure use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient, please notify the sender immediately. Ce message est confidentiel; son contenu ne repr=E9sente en aucun cas un engagement de la part de la soci=E9t=E9 NexWave Solutions. Sous r=E9serve= de tout accord conclu par =E9crit entre vous et la soci=E9t=E9 NexWave Solut= ions. Toute publication, utilisation ou diffusion, m=EAme partielle, doit =EAtr= e autoris=E9e pr=E9alablement. Si vous n'=EAtes pas destinataire de ce mess= age, merci de b |
|
From: Greg L. <gl...@ne...> - 2001-10-04 07:12:52
|
Stanislav Karchebny wrote: >=20 > Use The Source, Greg! >=20 > Replying to your mail dated 04.10.2001 12:59, > about "[odin-os-devel] memory manager interface": >=20 > GL> This will certainly want to be a privileged method since it is a > GL> security flaw to allow untrusted components to do this. But then, = why > GL> can't things that need to create_at just call the ORB's create > GL> directly? The job of the mem_mgr is to decide where at is. If > GL> create_at doesn't do that, what does is it's purpose? >=20 > This is privileged method and its purpose it to keep track of which > memory was allocated. If you just call orb::create() there will be no > record that this block of memory is acquired... OK, fair enough >=20 > GL> Also, extending the idl compiler so that it accepts variadic argume= nts > GL> should be trivial. >=20 > ehh... I'll try.... yacc/lex aren't my best friends. Well, you could just say have a type like "variadic" to get it through the IDL compiler, and hash-define that variadic to ... Should work. Greg >=20 > -- keep in touch. Stanislav Karchebny. > * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * > * Odin operating system development: http://odin-os.sf.net * > *Effective communication is the key to effective operation.* --=20 ____________________________________________ Greg Law NexWave Solutions (http://www.nexwave-solutions.com) NexWave Building - CS 89006 1068, Rue de la Vieille Poste 34967 MONTPELLIER Cedex 2 - FRANCE Tel. : +33 (0) 4 99 52 89 89 - Fax : +33 (0) 4 99 52 89 88 _______________________________________________ This message is confidential; its contents do not constitute a commitment by NexWave Solutions except where provided for in a written agreement between you and NexWave Solutions. Any unauthorized disclosure use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient, please notify the sender immediately. Ce message est confidentiel; son contenu ne repr=E9sente en aucun cas un engagement de la part de la soci=E9t=E9 NexWave Solutions. Sous r=E9serve= de tout accord conclu par =E9crit entre vous et la soci=E9t=E9 NexWave Solut= ions. Toute publication, utilisation ou diffusion, m=EAme partielle, doit =EAtr= e autoris=E9e pr=E9alablement. Si vous n'=EAtes pas destinataire de ce mess= age, merci de b |
|
From: Greg L. <gl...@ne...> - 2001-10-04 07:02:02
|
But what is the use of the ORB reporting its static memory usage, since as soon as this happens, the information is out of date? (CDT may have grown or shrunk)=20 Greg Stanislav Karchebny wrote: >=20 > Use The Source, Greg! >=20 > Replying to your mail dated 04.10.2001 12:55, > about "[odin-os-devel] memory manager": >=20 > GL> The reason I don't think the ORB can transfer its memory usage is t= hat > GL> it changes as the CDT grows upwards. Hence the nomem exception sch= eme. >=20 > I can put it the other way - the ORB could return its own _static_ > memory usage. > The reason why I don't want libos interrogate GDT directly is that if > we're about giving all GDT/CDT internals manipulation to the ORB, > libos should not tackle them on itself. > And since the ORB is the only GDT/CDT allocator this doesn't prevent > it from throwing nomem in case mem_mgr suddenly overlaps CDT. >=20 > -- keep in touch. Stanislav Karchebny. > * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * > * Odin operating system development: http://odin-os.sf.net * > * I'm not sorry, I am having fun... * --=20 ____________________________________________ Greg Law NexWave Solutions (http://www.nexwave-solutions.com) NexWave Building - CS 89006 1068, Rue de la Vieille Poste 34967 MONTPELLIER Cedex 2 - FRANCE Tel. : +33 (0) 4 99 52 89 89 - Fax : +33 (0) 4 99 52 89 88 _______________________________________________ This message is confidential; its contents do not constitute a commitment by NexWave Solutions except where provided for in a written agreement between you and NexWave Solutions. Any unauthorized disclosure use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient, please notify the sender immediately. Ce message est confidentiel; son contenu ne repr=E9sente en aucun cas un engagement de la part de la soci=E9t=E9 NexWave Solutions. Sous r=E9serve= de tout accord conclu par =E9crit entre vous et la soci=E9t=E9 NexWave Solut= ions. Toute publication, utilisation ou diffusion, m=EAme partielle, doit =EAtr= e autoris=E9e pr=E9alablement. Si vous n'=EAtes pas destinataire de ce mess= age, merci de b |
|
From: Stanislav K. <be...@vi...> - 2001-10-04 05:33:59
|
Use The Source, Odin!
libos/odin/idl/mem_mgr.idl:
/* Memory manager */
interface mem_mgr
{
void ctor();
void dtor();
uint create( uint type, uint param_count/* FIXME: need dynamic, uint param1, uint param2, uint param3*/ );
uint create_at( uint type, uint base, uint param_count/* FIXME: need dynamic, uint param1, uint param2, uint param3*/ );
uint destroy( comp to_go );
uint install( uint img );
void uninstall( uint type );
uint get_addr( comp c );
void linear( uint amnt );
comp get_statistics(); /* return statistics in well-defined-format read-only data comp */
};
Any comments? (hehe..as usual :)
-- keep in touch. Stanislav Karchebny.
* be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 *
* Odin operating system development: http://odin-os.sf.net *
* I'm not sorry, I am having fun... *
|
|
From: Stanislav K. <be...@vi...> - 2001-10-04 05:33:59
|
Use The Source, Odin! For a memory manager to operate correctly, it would be good if ORB could return its own memory map via special call - e.g. currently ORB takes only stack area right below video memory and some space starting at 1Meg towards top of memory. However, even in this simple case mem_mgr needs to know ORB's stack size so that not overwrite it in the lower memory. Any proposals for such interface are welcome (this call might be similar to modern BIOSes "System Memory Map" call). -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Components down to the metal * |
|
From: <ai...@li...> - 2001-10-03 13:55:16
|
> alar> Do you have an idea about how network driver interface will look like? > > Not yet clear. But something like sink/source I guess :) I think sink/source is adequate for "socket library", but not suitable for interaction between driver and protocol. > alar> What network hardware do you want to start with? > alar> Do you have good description of NE2000 hardware? (I don't) > > I'd plan to start from simplest drivers I find. Probably dig in > FreeBSD and Linux sources a bit. I didn't look for docs yet (milestone > 5 is too far), but I'll find when I search :) |
|
From: Stanislav K. <be...@vi...> - 2001-10-03 08:03:22
|
Use The Source, aik! Replying to your mail dated 03.10.2001 1:33, about "[odin-os-devel] reaction": alar> Sometimes people even send mail with JavaScripts in it, but I don't care NON-HTML MAIL FOREVER. PS. :P -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Components down to the metal * |
|
From: Stanislav K. <be...@vi...> - 2001-10-03 08:02:54
|
Use The Source, aik! Replying to your mail dated 03.10.2001 1:32, about "[odin-os-devel] reaction": alar> Hey, wait! alar> QNX is "just another Linux" from first glance: the same files in /etc, the Well, QNX is much alot like Go! in this manner. -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Engineering, design and art. * |
|
From: Stanislav K. <be...@vi...> - 2001-10-03 08:02:32
|
Use The Source, Chris! Replying to your mail dated 03.10.2001 1:34, about "[odin-os-devel] reaction": CR> Graphics, pah. At least in graphics you can quote normally :)) -- keep in touch. Stanislav Karchebny. * be...@vi... * http://ber.k45.ru * ICQ UIN 49516372 * * Odin operating system development: http://odin-os.sf.net * * Ease of use, ease of programming, joy of power * |
|
From: <ai...@li...> - 2001-10-02 16:59:39
|
One more Q: when ATA-high driver receives a request from upper level and translates it into many requests to ATA-low and one of requests fails, should it proceed with the rest or abort them? An example: filesystem requests reading of a long file ( say, 1000 sectors) , but ATA-low can read no more than 100 sectors at a time. ATA-high translates that request into many small read requests that ATA-low can handle. |
