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 or 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, they tried to resolve with the Solaris/Intel folks' cmdk driver (joins ATA && SCSI 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- 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 from 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 are 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> you wrote: > [you being Matthew Jacob] > > >> What do you feel needs to change with FreeBSD's CAM implementation? > [Matt to Søren] > > >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. > > Ok, > > so we need to get the following at least: > > /usr/src/sys/cam/ > ata/ > common/ > scsi/ > > for the directories. > > 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. > > 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. > > Going by the scsi word in the files, we have at least these files to > clean up: > > [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 > > I can only help with the splitting of the files, I am SCSI/ATA clueless > when it comes to programming those systems. > > -- > Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best > The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>; > Abandon hope, all ye who enter here... > 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>