Date: Tue, 26 Jan 1999 12:47:45 -0000 From: paul@originative.co.uk To: phk@critter.freebsd.dk, dfr@nlsystems.com Cc: archie@whistle.com, sobomax@altavista.net, current@FreeBSD.ORG, julian@whistle.com Subject: RE: DEVFS, the time has come... Message-ID: <A6D02246E1ABD2119F5200C0F0303D10FDDB@OCTOPUS>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Poul-Henning Kamp [mailto:phk@critter.freebsd.dk] > Sent: Tuesday, January 26, 1999 10:41 AM > To: Doug Rabson > Cc: Archie Cobbs; Maxim Sobolev; current@FreeBSD.ORG; Julian Elischer > Subject: Re: DEVFS, the time has come... > > > > >> No, it doesn't have to be SLICE. In particular, if we're going the > >> SLICE way, it should be done >right<, and Julians SLICE > code didn't > >> do that. (I know, I spent close to 6 months prototyping the concept > >> and julian had my code to work from). > > > >Wouldn't it be possible to fit this into the device system? > If we treat > >disks as devices and partition types as drivers, most of the > boring work > >of matching drivers to devices and keeping lists and trees > of objects will > >happen automatically. > > Well, as long as you remember that it is not a strict hierarchy: > I could slice two disks, mirror the slices and concatenate the > mirrors if I wanted to. Where does this happen though? If we go with Doug's idea (which seems quite neat), then the device subsystem will present devices for each of the slices/partitions that the low level disk handling code finds during the probe phase. The mirroring of slices and subsequent concatenation of the mirrors, or any other combination of slice munging that might take place happens later doesn't it, using something like vinum. If so then can't vinum become responsible for modifying the device view, i.e. if it creates a concatenated partition then it could remove the two "low level" slice devices and create a new disk device that represents the concatenated area. You might not want to remove the low level devices or it could be a vinum configuration option. If something like vinum doesn't exist then you're not going to be doing any mirroring or concatenation and Doug's solution would be fine for creating the device nodes needed to represent the "actual" layout of the disks, as opposed to a "view" of the disks that might be created by vinum et al. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6D02246E1ABD2119F5200C0F0303D10FDDB>