Date: Fri, 12 Dec 1997 14:27:39 -0800 From: Julian Elischer <julian@whistle.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: DEVFS: new sample code Message-ID: <3491BA5B.41C67EA6@whistle.com> References: <199712122023.HAA04091@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3491BA5B.41C67EA6>