Date: Sat, 01 Aug 1998 11:04:49 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Peter Dufault <dufault@hda.com> Cc: gibbs@plutotech.com (Justin T. Gibbs), ckempf@enigami.com, ken@plutotech.com, freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <199808011710.LAA20922@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 01 Aug 1998 05:43:43 EDT." <199808010943.FAA13542@hda.hda.com>
index | next in thread | previous in thread | raw e-mail
>Minor nit not addressing locking issues - the old SCSI layer >intercepted the control device at the top and passed unknown SCSI >commands to common code at the bottom. Since one of my goals was >to pull duplicated code to a single place I want to point that out. >However, duplicated code kept sneaking back in to all the drivers. The issue here really isn't about duplicated code, but that different types of device clients should go through different peripheral instances in order for locking and proper transaction scheduling to occur. The fact that the different peripheral instances (pass12 and cd5 for instance) access the same underlying device is only known by the device table in the transport layer and the routines that allow a peripheral instance to lock a device for exclusive access. This means that the system can properly guarantee priority scheduling even if both a pass and another peripheral instance are active on the same device (e.g. userland RAID or database application doing RAW SCSI I/O). It also means that should a lock be necessary it isn't the case that all drivers need to consider which minor device issued the request to know whether to honor the lock or not. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808011710.LAA20922>