disk drivers (was What new system calls do you want in BSD?)

Chris Torek chris at mimsy.umd.edu
Wed Feb 14 18:04:05 AEST 1990


In article <19451 at nuchat.UUCP> steve at 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 at cs.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.unix.wizards mailing list