Date: Sat, 29 Jul 2000 12:51:01 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@freebsd.org, sos@freebsd.org Subject: Re: CAM layer Message-ID: <Pine.BSF.4.10.10007291240540.67255-100000@beppo.feral.com> In-Reply-To: <20000729212605.A27295@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, the 'needs' was Justin's take on things. I'm not sure I agree. I tend= to see ATA like I implement SAF-TE inside SES- SCSI/CAM is a superset of what = ATA uses, although there are things in ANSI t13 committee that are not well represented within t10 (SCSI) yet but can be shoehorned in pretty easily. I still fail to see why the ATA chip hardware, which is admittedly where a = lot of Sos' good work lives, can't just be a SIM layer thing for CAM. There are= a couple of ATA specific properties that might have to be tunnelled from sa o= r da, but I'm not really sure I see a need for the large splitup. I was present at a lot of discussions at Sun in 1998 where, once again, the= y tried to resolve with the Solaris/Intel folks' cmdk driver (joins ATA && SC= SI with one disk driver- there was also, briefly, a cmtp driver) could be shot and the new ata stuff could be driven by the sd && st drivers. They didn't kill cmdk, but the Sparc/Solaris ATA stuff is not driven as it should be-= =20 but that was due to the same lack of initiative being shown here. I've comapers both the atapi && scsi midlayer source for Solaris 2.8- they're structured almost *exactly* the same. All of this indicates to me that ATA *drives* are not all that different fr= om SCSI drives. There are some differences, of course, but 95% of which are within control of the SIM to inform the XPT layer about what to do. There a= re probably a few extra things so that the periph drivers don't do something stupid, but that's the rest of what I see as a fairly small change. Would somebody (Jusgin? Sos?) please tell me I'm wrong, and if so, give specifics? -matt On Sat, 29 Jul 2000, Jeroen Ruigrok/Asmodai wrote: > -On [20000724 22:00], Justin T. Gibbs (gibbs@plutotech.com) wrote: > >In article <Pine.BSF.4.10.10007231355290.54040-100000@beppo.feral.com> y= ou wrote: > [you being Matthew Jacob] >=20 > >> What do you feel needs to change with FreeBSD's CAM implementation? > [Matt to S=F8ren] >=20 > >It needs to be made less SCSI centric. e.g. cam/scsi/cam_xpt_scsi.c > >with cam/cam_xpt.c offering only common glue. It has been on my > >list of things to do for a long time, but I just haven't gotten > >around to it. I think that a large part of the CAM/ATA/ATAPI > >issue is that the barrier to entry for new subsystems is too high... > >Someone has to do the "split it out" work first. >=20 > Ok, >=20 > so we need to get the following at least: >=20 > /usr/src/sys/cam/ > =09=09=09ata/ > =09=09=09common/ > =09=09=09scsi/ >=20 > for the directories. >=20 > I see that, for example, cam_xpt.c contains the quirk table, perhaps we > want to put this in a seperate file for each disksystem. >=20 > Of course, all SCSI functions would need to move towards scsi/ with > scsi_xpt.c being a more consistent name when it comes to that directory, > or when given the names in cam/ cam_xpt_scsi.c like Justin says. >=20 > Going by the scsi word in the files, we have at least these files to > clean up: >=20 > [asmodai@celestial] (15) $ grep -i scsi * | sed 's/\:.*//' | uniq > cam.c > cam.h > cam_ccb.h > cam_debug.h > cam_periph.c > cam_sim.c > cam_sim.h > cam_xpt.c >=20 > I can only help with the splitting of the files, I am SCSI/ATA clueless > when it comes to programming those systems. >=20 > --=20 > Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best = =20 > The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>; > Abandon hope, all ye who enter here... >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10007291240540.67255-100000>