Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: disk drivers (was What new system calls do you want in BSD?)
Message-ID: <22520@mimsy.umd.edu>
Date: 14 Feb 90 07:04:05 GMT
References: <12157@stealth.acf.nyu.edu> <19451@nuchat.UUCP>
Distribution: usa
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 28

In article <19451@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
>While I'm on the subject, a thought on disk/partition/file system
>organization:
>
>The current situation is really a mess, with all the partitioning
>and defect mapping burried down in *each* disk driver.  What we
>need is truly raw drivers for specific hardware and a generic
>indirect driver implementing "cooked" features -- mapping,
>partitioning, striping, mirroring -- in a *standard* way.

The partition code is not very big, and the defect mapping code is
extremely device dependent (so much so that only a few BSD drivers can
share it; they do this via subroutines in `dkbad.c').  The disk
label code, however, is larger, and I am trying to do something like
the above in a new device organisation I am working on (still in
design phase mostly).

Right now I am not interested in striping or mirroring, and do not want
to do anything that would affect the buffer cache code---striping has a
tendency to do this---since this code is changing: already the 4.4ish
code at Berkeley differs from what I am using here.  The idea, however,
is much the same: every hardware disk driver must provide a common
interface, and a software layer uses this to add standard features to
all disks.  (My scheme goes a bit further than this, but this is what
sparked it.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris