From owner-freebsd-current Thu Feb 28 13:11:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id 2D91537B400; Thu, 28 Feb 2002 13:11:47 -0800 (PST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id NAA00441; Thu, 28 Feb 2002 13:11:00 -0800 (PST) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [162.62.64.10]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id MAA23643; Thu, 28 Feb 2002 12:53:29 -0800 (PST) Received: from hollin.btc.adaptec.com (hollin [162.62.149.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA11468; Thu, 28 Feb 2002 14:10:56 -0700 (MST) Received: (from scottl@localhost) by hollin.btc.adaptec.com (8.11.6/8.11.4) id g1SL8d106137; Thu, 28 Feb 2002 14:08:39 -0700 (MST) (envelope-from scott_long@btc.adaptec.com) X-Authentication-Warning: hollin.btc.adaptec.com: scottl set sender to scott_long@btc.adaptec.com using -f Subject: Re: Updated ATAPI/CAM patches From: Scott Long To: sos@freebsd.dk Cc: "Matthew N. Dodd" , "Kenneth D. Merry" , Julian Elischer , Thomas Quinot , freebsd-current@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: <200202282106.g1SL62U02937@freebsd.dk> References: <200202282106.g1SL62U02937@freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/1.0.1 Date: 28 Feb 2002 14:08:39 -0700 Message-Id: <1014930519.6021.16.camel@hollin.btc.adaptec.com> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2002-02-28 at 14:06, S=F8ren Schmidt wrote: > It seems Scott Long wrote: > > > As I have stated several times, I have no problem with ATAPI being > > > sent through CAM as long as the usual way stays (some of us cannot > > > afford the weight of those extra layers, nor loose functionality). > > > I'd do the integration somewhat differently to even further minimise=20 > > > the diffs, but that is really not the issue here... > > > So if we can get *serious* commitment from a committer to take up > > > these loose ends, lets talk about what to do, if not my offer stands = :) > >=20 > > I'll raise my hand here. I've been keenly interested in this for a > > while, since it will make my UDF work much simpler. I'm also getting m= y >=20 > Hmm, your UDF code should know nothing about the lower layers, but=20 > we've been over that already :) >=20 Yes, and hopefully the filesystem won't have to care, but tools like newfs_udf will. > > feet wet in CAM, and I have the two CAM gurus nearby if things get too > > hairy. I fully indend for this to be a cooperative effort with Thomas; > > I'm mainly raising my hand to take the abuse that will no doubt happen > > once in a while. >=20 > Sure, maybe we should make Thomas a committer so he could look after > it himself ? Interested ? Got the time ? I'm all ears for volounteers... >=20 Ummm, I'm volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message