From owner-freebsd-scsi Mon Oct 6 00:40:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA11067 for freebsd-scsi-outgoing; Mon, 6 Oct 1997 00:40:39 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA11062 for ; Mon, 6 Oct 1997 00:40:36 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA29502; Mon, 6 Oct 1997 00:35:25 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd029500; Mon Oct 6 07:35:24 1997 Date: Mon, 6 Oct 1997 00:34:20 -0700 (PDT) From: Julian Elischer To: Joerg Wunsch cc: freebsd-scsi@FreeBSD.ORG Subject: Re: New SCSI Framework Patches Available In-Reply-To: <19971006070933.HO48297@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 6 Oct 1997, J Wunsch wrote: > As Julian Elischer wrote: > > > I'd rather see byte offsets ASAP, so that it matches the resid and > > other count values. of course it makes it easier to accidentally > > try do non-alligned transfers, but if you are making that big a, > > then othingis likely to help you except having your code rejected > > too much. > > (Well, i can't parse the above sentence really, but hope to have > figured out what it meant. :) sorry typing on a bad line.. I think what was showing on my screen and what was sent did not correlate.. should read: "making that big a mess of things, then nothing is likely to help you, except having your code (should have said requests) rejected too much" i.e lots of really annoying messages to prod you into fixing it. > > Drivers are expected to reject requests that don't match the > underlying physical device anyway. IMHO, all (most ?) of our drivers > do this already. That's why people see an EINVAL when trying to > disklabel a 2048-byte sectored MO media (the label is attempted to be > read/written with a granularity of 512 bytes). > > (General consensus) yes > > > though I'd like to leave the b_pblkno, or maybe make it a b_poffset. > > What for? Hmm, maybe. Slices are evil. :-) you have to store the physical block number etc. somewhere so that when the request returns the original info is not destroyed, because the read request may be broken by physio() to be done in several chunks and you don't want to lose info. in fact the trouble is that you really want to save the initial state of the buf struct, or have a different version for each layer you go through.. I'm re-implimenting the slice code, and have run up against this. I'm not sure which entries in the buf I can clobber at low layers, and which I can't. I have the generic framework up and running, and slices being dynamically added etc. from a scsi disk vi an MBR handler. I have not yet written the disklabel handler. I'm using a floppy for testing.. :) (have fdisk'd a floppy) > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) >