On Mon, 12 Jan 2004, Robert Watson wrote: > I think the right strategy is to follow the minimalist approach now > (adopt the disk(9) API, rather than having Vinum generate character > devices) so that swap works on Vinum again, and so that when UFS moves > to speaking GEOM there's no loss of functionality. If we want to > completely reimplement Vinum, we should do that separately so as to > avoid loss of functionality during structural changes.
As many ways lead to Rome, how about the following scenario. I don't know if it's a clever way to do things, and I don't know if it's even possible to with GEOM, so some input is appreciated. *) Have separate GEOM classes for each of the different vinum objects (drive, sd, plex, volume). *) Let the drive geom taste the slices configured for vinum, read the on-disk config and then spawn the necessary other geoms (I'm not sure if the latter can be done in GEOM). *) I think this is a clean implementation, since the GEOM framework offers all the "background" needed to transform the IO requests. *) It would also be a good way to clean up the vinum code. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
