Date: Sat, 21 Mar 2009 21:03:34 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: luigi@FreeBSD.org, phk@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) Message-ID: <20090321200334.GB3102@garage.freebsd.pl> In-Reply-To: <gq1975$p1k$1@ger.gmane.org> References: <20090319081936.GA32750@onelab2.iet.unipi.it> <b649e5e0903190441m2d511107qd95cb3cd566b11f7@mail.gmail.com> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> <gq1975$p1k$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 21, 2009 at 12:34:37AM +0100, Ivan Voras wrote: > Not only with naming and device creation - the proxy classes cannot be > "normal" classes because it's common that "normal" classes do a lot of > initialization in .taste. (i.e. there at least needs to be a flag for > proxy classes) There are many leaf GEOM classes where taste is never used and also non-leaf classes that don't use tasting (like gbde or geli). Those aren't special GEOM classes in any way. I recommend reading phk's GEOM tutorial from BSDCon 2003. You can find an interesting slide which seems to sum up this thread quite nicely: Special GEOM classes. --------------------- - There are no special GEOM classes. I wonder if phk changed his opinion over time. :) Maybe instead of adding special providers and GEOM classes, the infrastructure should be extended in some way, so that we won't use provider term to describe something that isn't really a regular GEOM provider. On the other hand disk scheduler provides kind of transformation, the only real problem is usability - doing it in the same way as the other GEOM classes will make it much more problematic to use. Current patch makes it much easier to use, but violates infrastructure. Another thing came to my mind. Currently GEOM does nothing to prevent situation where there are two GEOM providers using the same name - we just end up with two /dev/foo entires which is a bit surprising. I was wondering if we couldn't clean this up (at least partially) and implement insert/remove functionality for GEOM in one go. For example we have /dev/ad0 provider created by the DISK class. We create another provider /dev/ad0 of SCHED class. Then we insert SCHED:/dev/ad0 on top of DISK:/dev/ad0. GEOM will reconnect all existing consumers from DISK:/dev/ad0 to SCHED:/dev/ad0 and connect SCHED consumer to DISK:/dev/ad0. Also, GEOM will show only one /dev/ad0 entry in /dev/ - the one which comes from a geom with higher rank count. Now whoever wants to open /dev/ad0 will end up opening SCHED:/dev/ad0 (so there won't be a problem with new consumers). Of course providers that come from geoms with the same rank count would still be a problem, but... Also instead of rank count we could only allow connected providers to cover their children. What do you guys think? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJxUgWForvXbEpPzQRAgusAJ9CuyQCglytexSqaGymGpgE0XocFQCgtH4D OxsTYEHDdFBRZTH+ojl2gMw= =wUBW -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090321200334.GB3102>