Oracle Europe BV Product Line Development
Phone: +31 3406 94211 Fax: +31 3406 65609
==============================
From: laakkone@klaava.Helsinki.FI (Tero Laakkonen)
Subject: tlA: reggae's Incoming dir must be chmod ugo+x...
Date: 14 Aug 1992 10:25:32 GMT
... so that people can cd into it.
-tero.
==============================
From: jhelberg@nl.oracle.com (Joost Helberg)
Subject: Re: loadable device drivers
Date: 14 Aug 1992 10:49:47 GMT
X-Disclaimer: This message was written by an unauthenticated user
at Oracle Corporation. The opinions expressed are those
of the user and not necessarily those of Oracle.
almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
: In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:
[deleted]
: > The kernel must be mapped when implementing loadable device drivers (to
: > get page-faults) so the kernel doesn't need contiguous memory --> less
: > problems allocating memory.
:
: Page-faults are deadly for most parts of the kernel. Unless the interrupt
: handling is changed in radical ways (see below), you don't want interrupt
: handlers and code that's called by them to reside in paged memory. (Besides
: the obvious case of device drivers that may be possibly invoked when
: handling a page fault.)
:
: Using the paging hardware to map kernel pages is a good idea, though.
:
: > - The kernel will never use more core than necessary. Only text/data really
: > used will be in core (that is using LRU algorithms).
:
: Yes, but you need interrupt queues and an interrupt scheduler to be able
: to accept interrupts from devices that can send more than one interrupt
: per interaction (i.e. SIOs) even if you have to fault in the driver first.
: Might be hairy to implement, although it looks like a very elegant
: solution for most interrupt problems.
:
: You also need a way to lock certain kernel areas in physical memory.
: (MM, at least one FS, scheduler, hd driver, some other kernel data
: structures, drivers for devices that expect a low interrupt latency, etc.)
:
You're right about all this; my idea came from the time I developed
streams drivers and streams drivers only. These can very easy be made
pageable in the sense that streams-modules/drivers get scheduled by the
scheduler as if they are user-processes. You can swap them if you want!
[deleted]
I think it is not a good idea to implement any driver as a loadable driver,
but with a new driver-interface (like STREAMS is) it is easy to implement,
without too much problems.
One could even implement a seperate driver-space (analog to user-space, with
its own mmu-tables) for each streams-driver instance, bus-errors etc. result
in core dumps in stead of terminal-dumbs!
I think (before STREAMS are implemented) that we should invest in defining
a configurable driver-interface for Linux, discussion in mailing-list
'configuration' at niksula.hut.fi or on the news.
Any comment?