From owner-freebsd-current  Fri Dec 12 14:40:35 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA01710
          for current-outgoing; Fri, 12 Dec 1997 14:40:35 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01698
          for <current@freebsd.org>; Fri, 12 Dec 1997 14:40:24 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id OAA11526;
	Fri, 12 Dec 1997 14:30:28 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd011502; Fri Dec 12 14:30:17 1997
Message-ID: <3491BA5B.41C67EA6@whistle.com>
Date: Fri, 12 Dec 1997 14:27:39 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Bruce Evans <bde@zeta.org.au>
CC: current@freebsd.org
Subject: Re: DEVFS: new sample code
References: <199712122023.HAA04091@godzilla.zeta.org.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Bruce Evans wrote:
> 
>
> >code. That's the whole point. To replace them with a more modular
> >interface.
> 
> I don't see any need to entirely replace them.

because they don't fit what I'm trying to do?

The slice code you wrote is a great piece of optimsed level-collapsed 
work, but for what I want to do, it's too non-modular (integrated?)
and the layers are collapsed too much for what I'm trying to 
achieve. The interfaces are different for each layer, 
(in fact there is no standard interface for them)
and you need to know too much about what is below you..
there is too much layer crossing, and it's too much designed
about the specifics of PC layouts. It doesn't fit with DEVFS well,
(because it only looks at the slices at OPEN time leading to a
chicken/egg problem)It has no support for handlers that can do
striping or mirroring or raid, or for dynamicly growing slices.
It has no support for recusive arbitrary partitionning, and it
cannot easily be extended to handle other partitionning schemes,
)e.g. MAC or SUN disks). It does not provide a usable framework
for new modules (e.g. a reliability layer (or bad144 shim). The drivers 
know too much about slicing and require duplicated code.


Now having said all that, It DOES do what it does do, very well.
It's just that it was not designrd to do what I want to be able to do.
(e.g. mount SUN disks, or do arbitrary slicing and recombination
of disk arrays etc.

The stuff I'm trying out is VERY EARLY code
but is definitly beyond the 'proof of concept' stage.
PHK has been working on something similar, and when I get the time
to really understand his stuff (I'm still sorting out his 
user-level test framework from the actual code) I'm going to
try integrate as many of his ideas as I can.

SOmetimes it comes time for software to give way to a new better
generation. e.g My SCSI code and thenew CAM scsi code.
I'm not saying that my stuff WILL replace the dsxxx() code,
but I at least want to try see if my ideas are feasable.


> 
> Bruce