Menu
▾
▴
elysium-developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(81) |
Mar
(26) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nick J. <ni...@na...> - 2000-02-18 11:54:29
|
Well, I don't have a Pentium III, but I've just succesfully tried it on the
following machines:
K6-2 400mhz
256mb RAM
Pentium 200MMX
64mb RAM
486 DX/4 100mhz
16mb RAM
Pentium 90mhz (laptop)
32mb RAM
486 ?mhz (laptop)
8mb RAM
None of the machines I used had any problems. Hope this helps somewhat.
--
- Nick Jennings
Email: ni...@na...
Web : http://nick.namodn.com
-
|
|
From: Kasper V. L. <ve...@da...> - 2000-02-18 09:02:51
|
Hi, The latest demonstration disk image (elysium02172000-image.gz) seems to have a problem with some hardware. I don't know if it's GNU GRUB or the Elysium kernel, but on one particular machine - a Pentium III with 128 Mb RAM - the machine just hangs once the kernel and the modules have been loaded. I'll look into the problem, but I need to know if anyone else has experienced anything like this. /Kasper |
|
From: Kasper V. L. <ve...@da...> - 2000-02-17 14:06:35
|
Hi, There's a new demonstration disk image available from the Elysium project page at SourceForge (http://sourceforge.net/project/?group_id=1260). The new disk image demonstrates that the Elysium system is capable of handling everything needed to implement a basic console. /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Kasper V. L. <ve...@da...> - 2000-02-17 14:00:50
|
> > We still need to work on PCT (protected control transfer) - anyone?
>
> [snip] I've lost my Insight CD (damm!) but can you explain how the upcalling works? I've only used TSS before.
>
> popl %eax
> popl %eax
> movl %cr3,%eax
> iret
>
> I think that's the code (from memory), it sets up the page tables but does the iret pop stuff off the argument stack? And does that drop the privelage level?
The code is correct. It doesn't set up any page tables, but it does
change the page directory. The assembly code you've included in your
posting is the implementation of a function with the following
prototype:
extern void _process_run(uint32_t cr3, uint32_t eip, uint32_t cs,
uint32_t eflags, uint32_t esp,
uint32_t ss) __attribute__ ((noreturn));
The compiler will push the arguments from right to left leaving the
stack something like this:
[...:ss:esp:eflags:cs:eip:cr3:ret]
^
stack top
The first instruction (popl %eax) just removes the return address,
because we don't need it. The stack is now:
[...:ss:esp:eflags:cs:eip:cr3]
^
stack top
Next we pop the physical address of the page directory we want to switch
to from the stack (popl %eax) and do the context switch. The stack now
looks something like:
[...:ss:esp:eflags:cs:eip]
^
stack top
When we issue the 'iret' instruction the CPU will remove the eip, cs,
and eflags from the stack. The CPU can tell by code segment selector
that we're returning to user-level. This will make the CPU pop the ss
and esp from the stack as well. We're now running in user-space at
address eip with a stack specified by ss:esp.
Hope this helps!
/Kasper
--
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218 | Phone: (+45) 8942 5680
Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich
|
|
From: Adam L. <ag...@li...> - 2000-02-17 08:58:18
|
On Wed, Feb 16, 2000 at 07:37:10PM +0100, Kasper Verdich Lund wrote: > Hi guys, > > I've added user-level IRQ handling stuff to the Elysium kernel. The > 'init' module shows how to hook the interrupt generated from an IRQ - in > this particular case IRQ 1 (keyboard) - and I'll be implementing a > keyboard driver in a few days. Before this week is over we'll have a > primitive shell up and running :-) > > We still need to work on PCT (protected control transfer) - anyone? Well, I've got some free time coming up. I've got some other stuff to do but I'll take a look. I've lost my Insight CD (damm!) but can you explain how the upcalling works? I've only used TSS before. popl %eax popl %eax movl %cr3,%eax iret I think that's the code (from memory), it sets up the page tables but does the iret pop stuff off the argument stack? And does that drop the privelage level? AGL |
|
From: Kasper V. L. <ve...@da...> - 2000-02-16 18:39:23
|
Hi guys, I've added user-level IRQ handling stuff to the Elysium kernel. The 'init' module shows how to hook the interrupt generated from an IRQ - in this particular case IRQ 1 (keyboard) - and I'll be implementing a keyboard driver in a few days. Before this week is over we'll have a primitive shell up and running :-) We still need to work on PCT (protected control transfer) - anyone? /Kasper |
|
From: Kasper V. L. <ve...@da...> - 2000-02-16 07:38:04
|
Hi guys,
I've imported the initial source code for the init process. Browse the
CVS repository to find it. It doesn't do anything useful - yet - but it
shows you how to write code on top of the Elysium kernel. If you build a
GRUB bootdisk and specify the following:
kernel= (fd0)/elysium.kernel.tgz
module= (fd0)/elysium.init.tgz
and copy the appropriate files (elysium.{init,kernel}.tgz) from the
right directories (/{kernel,init}/bin) you'll have something similar to
the bootdisk image available from the Elysium web site. You should know
that on the bootdisk image I've built two different init processes to
illustrate that multitasking indeed works.
/Kasper
|
|
From: Kasper V. L. <ve...@da...> - 2000-02-14 09:06:11
|
> > [snipped something about a DSM system] > > This is great, since exokernels are so flexable we should be able to borrow > (read steal ;) their code. Do you know what licence this work might be done > under? I think I'll be working together with them on this one - and if I get my way the source code will be GPL'ed (at least open-source). > BTW: Do you update the CVS? It's very `stable' I've been working on implementing the IRQ handling stuff that has been discussed - once that is done we should be able to build the first drivers for our system: the keyboard driver, and the text mode video driver. It's nearly there... have patience. On the other hand I wouldn't mind if someone would try implementing a basic PCT (protected control transfer) mechanism. These system calls should do the trick: /* register an PCT upcall entry */ int sys_pct_register(uint32_t entry); /* do a PCT */ int sys_pct(pid_t pid); The semantics would be to transfer control to the other process donating the remaining time-slices of the current quantum to the other process. It should be fairly simple to implement - add the PCT entry to the process_s structure, implement the system calls (have a look at _process_run() for inspiration on doing the upcall).... /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Adam L. <ag...@li...> - 2000-02-13 17:27:56
|
On Sun, Feb 13, 2000 at 12:47:17PM +0100, Kasper Verdich Lund wrote: > Hi fellow developers, >=20 > First of all I'm sorry that I've been unable to participate in the latest > discussions. Thursday I did a presentation on the Elysium architecture at > Trinity College, Dublin. It went well - in fact they're considering using > the Elysium kernel for a research project in distributed shared memory > systems. The goal of the project to create a virtual machine running in > distributed shared memory across several machines. There will be an > implementation for Linux, but since coherence protocols and such might > benefit from the sort of application-specific optimizations the Elysium > system allows for they're considering porting it to Elysium. >=20 > This is great, since exokernels are so flexable we should be able to borrow= =20 (read steal ;) their code. Do you know what licence this work might be done= =20 under? BTW: Do you update the CVS? It's very `stable' AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Kasper V. L. <ve...@da...> - 2000-02-13 11:49:40
|
Hi fellow developers, First of all I'm sorry that I've been unable to participate in the latest discussions. Thursday I did a presentation on the Elysium architecture at Trinity College, Dublin. It went well - in fact they're considering using the Elysium kernel for a research project in distributed shared memory systems. The goal of the project to create a virtual machine running in distributed shared memory across several machines. There will be an implementation for Linux, but since coherence protocols and such might benefit from the sort of application-specific optimizations the Elysium system allows for they're considering porting it to Elysium. I've setup the elysium-developers mailing list so that replies are directed to the mailing list. Is this what we want? or would you rather reply directly to sender and then optionally cc to the mailing list? /Kasper ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-02-12 02:51:14
|
> > Elysium will be microkernel-based exokernel, so there will > be so called LibOS'es on the top of Elysium kernel. > The communication between LibOS'es and kernel could be implemented with > dedicated system call or dedicated memory location in kernel for message > passing. > A microkernel is different from an exokernel. We minimise abstractions in an exokernel. That is why IPC is also in user space provided by the particular libos that an application uses. |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-02-12 02:47:29
|
> 2. What type of environment will the core OS be? > > Is it going to be a GUI OS, such as BeOS (if you haven't heard of or > checked out BeOS yet, you really should, it's not open source, but > they've got a seemingly really next generation OS. > > Or will it be more like that of the UNIX's. with a text based core OS, > and perhaps a seperate layer for graphics? > > Or maybe something completely different? It IS something different. Whether it will be a GUI or not is simply not in the kernel. It depends on how you design the libos running on top of the exokernel. The exokernel only provides protection. All other traditional OS functionality is implemented outside the kernel. That means graphics, ipc virtual memory, etc. You can make it any way you like. The libos is very much accessible to the programmer and he can customize it anyway he likes. Any bad code is guaranteed not to corrupt any other. Malicious code only shoots itself so to speak. |
|
From: Adam L. <ag...@li...> - 2000-02-11 19:04:32
|
On Fri, Feb 11, 2000 at 11:05:42AM -0800, Nick Jennings wrote: > On Fri, Feb 11, 2000 at 06:41:08PM +0000, Adam Langley wrote: > > > > If you want some info I can send you .ps files from MIT PDOS (the peopl= e who > > wrote the early exokernels) > >=20 >=20 > That'd be great! thanks. >=20 Ok, try http://www.agl.uklinux.net/exo-sosp97.ps.gz http://www.agl.uklinux.net/exokernel-sosp95.ps.gz http://www.agl.uklinux.net/thesis.ps.gz (Big, but complete) Hope it helps AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Nick J. <ni...@na...> - 2000-02-11 18:54:56
|
On Fri, Feb 11, 2000 at 06:41:08PM +0000, Adam Langley wrote:
>
> If you want some info I can send you .ps files from MIT PDOS (the people who
> wrote the early exokernels)
>
That'd be great! thanks.
--
- Nick Jennings
Email: ni...@na...
Web : http://nick.namodn.com
-
|
|
From: Adam L. <ag...@li...> - 2000-02-11 18:42:43
|
On Thu, Feb 10, 2000 at 02:32:48PM -0800, Nick Jennings wrote: >=20 > Hello, >=20 > I have been reading all the posts to the list, though alot of it is > over my head at the current moment, I have a copy of the kernel checked o= ut > and have been updating it and trying to follow what i being talked about, > while viewing the code referenced in some of the discussions etc.=20 >=20 > I have read the little information there is on the webpage at > elysium.sourceforge.net and have somequestions, forgive me if they may be > worded the wrong way, or asked from an inexperience point of view. I am, > very inexperienced. >=20 If you want some info I can send you .ps files from MIT PDOS (the people who wrote the early exokernels) AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Hannu H. <hhe...@he...> - 2000-02-11 13:44:17
|
Sorry my last empty reply! ----- Original Message ----- From: Nick Jennings <ni...@na...> To: Elysium Developers <ely...@li...> Sent: Friday, February 11, 2000 12:32 AM Subject: [elysium-developers] Elysium Vision? > > Hello, > <clip> > 1. I get the idea that the kernel is supposed to be "minimalistic" leaving > it up to the applications to speak directly to the hardware in order to > gain performance increases. > > First of all, Is this true? Maybe someone could explain it in better > words than I just did? > > If this is true, then wouldn't this make developing applications. > > 1.1. much more difficult, i.e. requiring software developers to deal > with handling direct video access and any other piece of hardware > it required the use of. instead of developing system level tools > to handle the hardware, and abstract it for the application > developer, sort of the same concept as windowing toolkits like > GTK etc. > > 1.2. much more dangerous, increasing the probability of misusing > hardware, either on purpose, or in error. > > 2. What type of environment will the core OS be? > > Is it going to be a GUI OS, such as BeOS (if you haven't heard of or > checked out BeOS yet, you really should, it's not open source, but > they've got a seemingly really next generation OS. > > Or will it be more like that of the UNIX's. with a text based core OS, > and perhaps a seperate layer for graphics? <clip> > Or maybe something completely different? > > > -- > - Nick Jennings > Email: ni...@na... > Web : http://nick.namodn.com > - > I'm not sure if any one has responded you in private email, but if I understand: Elysium will be microkernel-based exokernel, so there will be so called LibOS'es on the top of Elysium kernel. The communication between LibOS'es and kernel could be implemented with dedicated system call or dedicated memory location in kernel for message passing. But actually I would have also some more info about Elysium future vision etc... What about this pthreads design status? Hannu Heikkinen hhe...@he... Vaisala Oyj www.vaisala.com University of Helsinki www.helsinki.fi |
|
From: Hannu H. <hhe...@he...> - 2000-02-11 13:25:06
|
----- Original Message ----- From: Nick Jennings <ni...@na...> To: Elysium Developers <ely...@li...> Sent: Friday, February 11, 2000 12:32 AM Subject: [elysium-developers] Elysium Vision? > > Hello, > > I have been reading all the posts to the list, though alot of it is > over my head at the current moment, I have a copy of the kernel checked out > and have been updating it and trying to follow what i being talked about, > while viewing the code referenced in some of the discussions etc. > > I have read the little information there is on the webpage at > elysium.sourceforge.net and have somequestions, forgive me if they may be > worded the wrong way, or asked from an inexperience point of view. I am, > very inexperienced. > > 1. I get the idea that the kernel is supposed to be "minimalistic" leaving > it up to the applications to speak directly to the hardware in order to > gain performance increases. > > First of all, Is this true? Maybe someone could explain it in better > words than I just did? > > If this is true, then wouldn't this make developing applications. > > 1.1. much more difficult, i.e. requiring software developers to deal > with handling direct video access and any other piece of hardware > it required the use of. instead of developing system level tools > to handle the hardware, and abstract it for the application > developer, sort of the same concept as windowing toolkits like > GTK etc. > > 1.2. much more dangerous, increasing the probability of misusing > hardware, either on purpose, or in error. > > 2. What type of environment will the core OS be? > > Is it going to be a GUI OS, such as BeOS (if you haven't heard of or > checked out BeOS yet, you really should, it's not open source, but > they've got a seemingly really next generation OS. > > Or will it be more like that of the UNIX's. with a text based core OS, > and perhaps a seperate layer for graphics? > > Or maybe something completely different? > > > -- > - Nick Jennings > Email: ni...@na... > Web : http://nick.namodn.com > - > > _______________________________________________ > elysium-developers mailing list > ely...@li... > http://lists.sourceforge.net/mailman/listinfo/elysium-developers |
|
From: Nick J. <ni...@na...> - 2000-02-10 22:22:10
|
Hello, I have been reading all the posts to the list, though alot of it is over my head at the current moment, I have a copy of the kernel checked out and have been updating it and trying to follow what i being talked about, while viewing the code referenced in some of the discussions etc. I have read the little information there is on the webpage at elysium.sourceforge.net and have somequestions, forgive me if they may be worded the wrong way, or asked from an inexperience point of view. I am, very inexperienced. 1. I get the idea that the kernel is supposed to be "minimalistic" leaving it up to the applications to speak directly to the hardware in order to gain performance increases. First of all, Is this true? Maybe someone could explain it in better words than I just did? If this is true, then wouldn't this make developing applications. 1.1. much more difficult, i.e. requiring software developers to deal with handling direct video access and any other piece of hardware it required the use of. instead of developing system level tools to handle the hardware, and abstract it for the application developer, sort of the same concept as windowing toolkits like GTK etc. 1.2. much more dangerous, increasing the probability of misusing hardware, either on purpose, or in error. 2. What type of environment will the core OS be? Is it going to be a GUI OS, such as BeOS (if you haven't heard of or checked out BeOS yet, you really should, it's not open source, but they've got a seemingly really next generation OS. Or will it be more like that of the UNIX's. with a text based core OS, and perhaps a seperate layer for graphics? Or maybe something completely different? -- - Nick Jennings Email: ni...@na... Web : http://nick.namodn.com - |
|
From: Kasper V. L. <ve...@da...> - 2000-02-10 09:48:42
|
As far as I know all functions that are in .h files are static and used only during initialization (where they're called once) or used in time-critical situations where inlining is expected and needed for efficiency. The use of 'static inline' initialization functions in header files actually *saves* a few bytes of code, but the cost is that it is confusing, since you wouldn't normally expect to find much code in header files. --------------------------------------------------------- This mail was sent through Eoffice: http://www.eoffice.dk |
|
From: Adam L. <ag...@li...> - 2000-02-09 11:14:17
|
I was looking thru the code last night (CVS from the weekend), and I'm a little worried about the amount of code you put in .h files. The func are static (so they don't conflict) but it wastes space. AGL |
|
From: Jakob R. A. <ro...@da...> - 2000-02-08 16:53:10
|
"Kasper Verdich Lund" <ve...@da...> writes: > * packet arrives (bit set in ISR) > * IRQ 9 handler called > * packet arrives (bit set in IRR, and in ISR) > * IRQ 9 handler ends > * IRQ 9 handler called (because the bit in the IRR is transferred to ISR on > EOI) > * IRQ 9 handler ends > > Of course this doesn't work for any number of packet arrivals since the > level of buffering is static (1 buffer register). Does anyone know anything > about how it's handled by the Linux kernel? No idea. However isn't the purpose of the IRQ simply to signal that "something has happened that requires attention"? What has happened and how much attention is required isn't stated in the IRQ, so an IRQ handler for a NIC would probably process all available packets before returning, in which case we won't lose any packets. At most, we will risk firing an IRQ handler for a packet that has already been handled, but that's another discussion. In my happy-go-lucky DOS days, I wrote a serial port driver and a sound card driver using this scheme, without problems. /Jakob. -- Jakob Roland Andersen, ro...@da... Office 540.030 - Phone (8942)3141 |
|
From: Kasper V. L. <ve...@da...> - 2000-02-08 15:57:32
|
> > Is it a problem that a handler for an IRQ never can be interrupted by > > another request for the same IRQ? > > I don't think so. The IRQ will be dropped if that come too fast > wont they? That must happen in all kernels so someone else must > have solved the problem, if there is a problem to solve. I think > we might have a problem with somethings like net cards: > > * Packet arrives > * IRQ 9 handler called > * Packet arrives > * IRQ 9 handler ends > > Now I think the second IRQ would be dropped by the PIC, not qued. > so the second packet wouldn't be handled. But cards might have a > way around this (e.g. a register to poll, at the end of the handler.) There is some level of buffering in the PIC - in the sense that while an interrupt is being serviced the appropriate bit in the ISR will remain high (until we send a specific EOI), but AFAIK the bits in the IRR (which is the 8-bit register the devices sets bits in by pulling some IRQ line) are free to be 1. So in your example it would actually be something like: * packet arrives (bit set in ISR) * IRQ 9 handler called * packet arrives (bit set in IRR, and in ISR) * IRQ 9 handler ends * IRQ 9 handler called (because the bit in the IRR is transferred to ISR on EOI) * IRQ 9 handler ends Of course this doesn't work for any number of packet arrivals since the level of buffering is static (1 buffer register). Does anyone know anything about how it's handled by the Linux kernel? /Kasper |
|
From: Adam L. <ag...@li...> - 2000-02-08 15:47:03
|
On Tue, Feb 08, 2000 at 02:49:36PM +0100, Kasper Verdich Lund wrote: > > > A - low-latency - solution could be: > > > * a device generates IRQ 7 > > > * the running process is interrupted by interrupt 0x27 which traps to > the kernel > > > * the kernel calls the IRQ handler for IRQ 7 using a task state segment > > > > So in this case the kernel saves state? > > Yes, either the kernel saves the state or the CPU does it automatically - it > depends on wether we use task state segments (the hardware way) or not. > > > > * when the handler is done (this might be time bounded) it returns using > iret > > > > Erm, no. The kernel is calling (thus it's an upcall into > > userland), therefore wouldn't the process return w/ a simple ret? > > If we choose to use task state segments the way to return to the previous > task (in this case normally the kernel) is via a iret instruction. I refer > to the Intel Architecture Software Developer's Manual (Vol. 3, 6-10): > > "The processor transfers execution to another task ... when the current task > executes an IRET when the NT flag in the EFLAGS is set." > > On the other hand if we choose not to use hardware saving of state the > process should use RET - so you're somewhat right. > Ah, ok. I've got the Insight Cd somewhere (I'd better read it sometime)! > Details on the Proposal > ======================= > So my proposal (using task state segments) is to have a task state segment > for each IRQ (at least 1 - 15, we need IRQ 0 for the scheduler). Whenever > the IRQ fires the kernel will switch to the IRQ handler task. If an IRQ > handler is running it can only be interrupted by another IRQ handler with > higher priority (that's the way the PIC works), and since the kernel doesn't > acknowledge the IRQ (by sending the EOI) before the IRQ handler is done the > IRQ handler will never be interrupted by itself. Fx if an IRQ handler for > IRQ 7 is running it will never be interrupted by another IRQ 7 handler. > > One possible scenario is the following: > * process A is running > * process A is interrupted by IRQ 7 handler > * IRQ 7 handler is interrupted by IRQ 1 handler (which has higher priority) > * IRQ 1 handler terminates with an IRET > * IRQ 7 handler is resumed > * IRQ 7 handler terminates with an IRET > * process A is resumed > > Is it a problem that a handler for an IRQ never can be interrupted by > another request for the same IRQ? I don't think so. The IRQ will be dropped if that come too fast wont they? That must happen in all kernels so someone else must have solved the problem, if there is a problem to solve. I think we might have a problem with somethings like net cards: * Packet arrives * IRQ 9 handler called * Packet arrives * IRQ 9 handler ends Now I think the second IRQ would be dropped by the PIC, not qued. so the second packet wouldn't be handled. But cards might have a way around this (e.g. a register to poll, at the end of the handler.) AGL |
|
From: Kasper V. L. <ve...@da...> - 2000-02-08 13:51:38
|
> > A - low-latency - solution could be: > > * a device generates IRQ 7 > > * the running process is interrupted by interrupt 0x27 which traps to the kernel > > * the kernel calls the IRQ handler for IRQ 7 using a task state segment > > So in this case the kernel saves state? Yes, either the kernel saves the state or the CPU does it automatically - it depends on wether we use task state segments (the hardware way) or not. > > * when the handler is done (this might be time bounded) it returns using iret > > Erm, no. The kernel is calling (thus it's an upcall into > userland), therefore wouldn't the process return w/ a simple ret? If we choose to use task state segments the way to return to the previous task (in this case normally the kernel) is via a iret instruction. I refer to the Intel Architecture Software Developer's Manual (Vol. 3, 6-10): "The processor transfers execution to another task ... when the current task executes an IRET when the NT flag in the EFLAGS is set." On the other hand if we choose not to use hardware saving of state the process should use RET - so you're somewhat right. Details on the Proposal ======================= So my proposal (using task state segments) is to have a task state segment for each IRQ (at least 1 - 15, we need IRQ 0 for the scheduler). Whenever the IRQ fires the kernel will switch to the IRQ handler task. If an IRQ handler is running it can only be interrupted by another IRQ handler with higher priority (that's the way the PIC works), and since the kernel doesn't acknowledge the IRQ (by sending the EOI) before the IRQ handler is done the IRQ handler will never be interrupted by itself. Fx if an IRQ handler for IRQ 7 is running it will never be interrupted by another IRQ 7 handler. One possible scenario is the following: * process A is running * process A is interrupted by IRQ 7 handler * IRQ 7 handler is interrupted by IRQ 1 handler (which has higher priority) * IRQ 1 handler terminates with an IRET * IRQ 7 handler is resumed * IRQ 7 handler terminates with an IRET * process A is resumed Is it a problem that a handler for an IRQ never can be interrupted by another request for the same IRQ? /Kasper |
|
From: Adam L. <ag...@li...> - 2000-02-08 13:35:37
|
On Tue, Feb 08, 2000 at 10:42:49AM +0100, Kasper Verdich Lund wrote: > > I'm not sure that IRQ sharing can be done securely w/o the > > kernel. There is no reason that processes that need the bind to > > IRQ's, need to trust each other. How can we make sure that a > > process will pass on an IRQ event to others? (without using the > > kernel, that is). But the line can be drawn later. > > I agree - we need some *trusted* software to handle the sharing of IRQs, but > IMHO it should be implemented as a trusted server process on top of the > kernel. Ah, ok. Fair enough > > > As for IRQ latency: For keyboards, latency is not a big issue. > > However for things like sound cards and network cards it is more > > important. But all OS's have bottom-halfs (therefore some > > latency) and w/o the kernel saving state I don't see another way > > of doing it. > > A - low-latency - solution could be: > * a device generates IRQ 7 > * the running process is interrupted by interrupt 0x27 which traps to the > kernel > * the kernel calls the IRQ handler for IRQ 7 using a task state segment So in this case the kernel saves state? > * when the handler is done (this might be time bounded) it returns using > iret Erm, no. The kernel is calling (thus it's an upcall into userland), therefore wouldn't the process return w/ a simple ret? > * the kernel is resumed by the iret and the kernel issues an EOI And the kernel would return w/ iret. > * finally the kernel returns to the formerly running process This sounds good. AGL |
