Date: Sun, 3 Feb 2013 18:11:45 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: arch@freebsd.org, current@freebsd.org Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203161145.GQ2522@kib.kiev.ua> In-Reply-To: <20130203155718.GA6204@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--mi2hulEOATkNQ14l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2013 at 04:57:18PM +0100, Marius Strobl wrote: > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > Hi, > > I finished the last (insignificant) missed bits in the Jeff' physbio > > work. Now I am asking for the last round of testing and review, esp. for > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > > controllers which drivers are changed by the patchset. Please do test > > this before the patchset is committed into HEAD ! > >=20 > > The plan is to commit the patch somewhere in two weeks from this moment. > > The patch is required for the finalizing of the unmapped I/O work for U= FS > > I did in parallel, which I hope to finish shortly after the commit. > >=20 > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > >=20 >=20 > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9) > be a requirement for disk controller drivers? Generally speaking, no. I plan to do the gradual migration of the drivers, definitely not forcing the unmapped bios down to the drivers which are not tested yet. In the patch, driver indicates the support for unmapped bios by a DISKFLAG. If flag is set, driver could receive both mapped and unmapped bios, and use of the bus_dmamap_load_ccb(), while formally is only convenience, is essentially the requirement. If driver does not set the flag, it receives the same i/o requests as it does now. Geom performs transient compat mapping for the unmapped requests on its own for such drivers. As result, driver does not need a change. My plan is to convert ahci(4) and then some often used high-profile drivers like mfi(4) and mps(4). I can also hope for isci(4) help. Everything else, IMO, could be done on the best efforts basis, when both developers time and testing facilities are available. Jeff wanted to do all driver conversion in one pass, but IMO this is unrealistic. Still, I started write some helpers which should provide the transient one-page mappings for PIO modes. You can look at some previous version of the unmapped patch at http://people.freebsd.org/~kib/misc/unmapped.8.patch. It only contain a hack for ahci(4), which should be fixed properly after physbio is committed. --mi2hulEOATkNQ14l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDoxBAAoJEJDCuSvBvK1BqJQP/RpIphfsDzjo53QLX3+xnClm OB8WWZvZpxc3qOXPd5pKeOYggeE/6hkrUIL7AMlmg0qNKU7RXQmVJkcX+Yiuke5h oL1LSyIEBFuz8j7ks04H8ZOTjZpQQDeXYJPTrkNXcHqKWWZMMfsCZU1YNmzc0Shi m2ot3p7sL5gqUFaodC0qRejP5OOiMkdplwuSmyi3atoobrdMjqeadpDYCj6Ia9RU QBmWtr22Pj3AmVczK6L5jLk+uq7Al+ezwGEN4Bt5oT5B6pQMc8la6PyPNHVNdflA pW4qG0Pw4l6Gn/9ccpC001T8XJYq18j7U6yJIp1azoongTMmS1PFUssohSBtCwl0 q1xu3FTsh5U+M8z2HuxOyLiL1Eduf2uqFxnqPFuX0q0m9Wb3mCVauRd2sKkL8kvi WmW2x+PTuYiiFxU9MvtABZPWa8UVSpLJl30u2ptDheNb9vWmPBhfXps3bO8J0nN1 hIsdPJ+A0yevdqeLIDy6mdB7fUuEogHdCL9u9KtoOptpUPeiXpmUK7PsSyTz6G89 4Oz7jbSfmYGUY0rqiR+gfFZDa+4L8jYFYpxuneyGpTY77FvjCFrZ3efrJbbFj2r5 siu7GASJna3KgjQpj1G3UAU7j3dTuybRvBGd6/tKCbARSBGOcq2nYic3DpLVwJq9 kLGLoOEyKX9j+oJlWRtl =idda -----END PGP SIGNATURE----- --mi2hulEOATkNQ14l--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130203161145.GQ2522>