On Tue, 26 Jan 1999 p...@originative.co.uk wrote: > > -----Original Message----- > > From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] > > Sent: Tuesday, January 26, 1999 10:41 AM > > To: Doug Rabson > > Cc: Archie Cobbs; Maxim Sobolev; curr...@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.
Poul is correct that this stuff is fairly easy. I did a sketch implementation of a simple disk interface with drivers for mbr and bsd labels and it seems to be the right direction to take. There are issues I didn't bother to tackle (device naming, geometry) but since Julian's slice code had this functionality and it is well understood, I don't think there would be problems. As far as ccd and vinum go, I thought that ccd would pick up disk partitions from the leaves of the slice tree and do its thing to create a virtual disk. This virtual disk would then be fed back into the disk probing system to spawn another partition tree. Vinum could do something similar but I think it has its own advanced ideas on partitioning. The system could be easily extended to probing the filesystem type. It would be really nice to automount partitions from removable media as it is inserted. I think the requirement that a user must use (root privileged) commands just to get to the files on a floppy/zip is ridiculous for someone used to Win32 systems. Perhaps the nebulous devd could be coerced into managing removable media as well (with configuration options for mounting, e.g. nosuid). And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
