Edgar Toernig <froese@gmx.de> wrote:
> The buffer cache and the low level btree/record management should be in the
> kernel. It's really hairy (and slow) to implement this for concurrent
> access in user space. A generic locking mechanism would be another candidate.
david parsons wrote:
> Why? It's not as if the relational database will be sharing any of
> its data areas with any other applications
If the app is single threaded and it is the only user of the file
everything is peanuts. If it's multi threaded you have two variants:
A) Everything is done in a single process or B) multiple processes
try to access the file at the same time. In case A the app has to
deal with multi threading itself which means you have to implement
a scheduler, locking schemes, buffer management, asynchronous I/O, ...
Case B has the advantage, that it may use some of the facilities already
present in the kernel (scheduler, buffer, async I/O) but the synchron-
ization between the processes is costly and some of the kernel facilities
doesn't suit the requirements of a db.
Case A gives you these elephants known as Oracle & Co and if you look at
the latest press releases (Oracle on raw iron) you'll see that they've
implement a whole OS in user space.
I talk about lightweight databases (libISAM) where the low level multi-
user stuff is taken care of in the kernel and the higher level
stuff (networking, authentication, SQL, maybe even transactions and
logging) is implemented in user space.
With your view of things, filesystems should be in user space, too.
Instead of blasting the semantics of the existent kernel API (completion
signals, mmap tricks, ordered writes) just to implement these beasts
one should give programmers a new kernel facility that is suited to
these kind of applications. (Btw, database vendors which have an OS
of their own have mostly (ever?) done it this way.) I assume, if such
a subsystem would have been available 15 years ago a lot of packages
(like NIS, bind, news, /etc/passwd, ...) would have a much cleaner and
simpler implementation.
Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/