Date: Sun, 22 Feb 1998 18:32:33 +1030 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: New SoftUpdates test kit Message-ID: <19980222183233.41134@freebie.lemis.com> In-Reply-To: <199802220738.XAA06227@dingo.cdrom.com>; from Mike Smith on Sat, Feb 21, 1998 at 11:38:57PM -0800 References: <19980222175710.04357@freebie.lemis.com> <199802220738.XAA06227@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 21 February 1998 at 23:38:57 -0800, Mike Smith wrote:
>>> Could you chain these headers off the private fields at the end of the
>>> buf structure, or is the feature set there too small?
>>
>> Hmmm. Sometimes it pays to RTFM. No, wait, there is no FM. OK, RTFS
>> then.
>
> 8/
>
>>> (NB. the wfd driver already uses one of these, it not being terribly
>>> clear to me at the time who they were really for use by.)
>>
>> Well, they're used in scsi_ioctl.c and wfd.c, and that's the only
>> place I've been able to find them. But it's a good idea, and it might
>> be the way to save the ccd driver if that's what's eating it.
>
> The reason I asked is that if you depend on the extra state that you use
> being preserved despite you passing the bufs out to other drivers, it
> might pay to impose some sort of policy on which of the fields are
> available for what usage.
>
> Of course, if vinum is at the top of the food chain and only uses the
> private data internally, then you win.
Good point. It passes them on to a disk driver. Theoretically, I
suppose, that could be wfd, though I can't think who'd want to use it
that way.
Yes, you're right. We need to think about this more carefully. I'm
following up to -hackers, where maybe this discussion should have been
all along. To summarize for those who haven't seen this before:
Julian Elischer has provided some patches to -CURRENT for Kirk
McKusick's soft updates. We''re currently testing them, and have
found a few bugs which Julian's looking at.
One of these bugs concerns CCD, which crashes. Kirk has expressed
an opinion that the buffer headers aren't initialized correctly.
He's out of town (whatever that may mean) for a week, so we may not
find out until then.
In the meantime, I commented on the fact that ccd and my new volume
driver, vinum, both use extended buf structures which aren't
allocated in the normal way, and that maybe this is the problem.
Mike then suggested (above) that the extensions could be chained off
the pointers b_driver1 and b_driver2, both claimed to be "for
private use by the driver". This is where we get to the top of this
message.
Mike, back to the discussion of policy. vinum needs some way to
associate the buffer returned to the b_iodone function with its
internal requests. CCD does this by including the buffer header in
the internal request. The obvious alternative is to use one of
b_driver[12] to point to the other information. The trouble is that
scsi_strategy seems to use both of them. Consider a few
possibilities:
1. Dodge around the usage. It seems to be related to ioctls, which
are (so far :-) never issued by vinum.
2. Modify the SCSI code to only use one of these pointers.
3. Add additional pointers. With a current length of 292 bytes,
another pointer or two might not make a big difference.
Greg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980222183233.41134>