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