Date: Tue, 24 Feb 1998 11:23:04 +1030 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au>, "Justin T. Gibbs" <gibbs@plutotech.com> Cc: hackers@FreeBSD.ORG Subject: Re: New SoftUpdates test kit Message-ID: <19980224112304.63148@freebie.lemis.com> In-Reply-To: <199802230034.QAA08989@dingo.cdrom.com>; from Mike Smith on Sun, Feb 22, 1998 at 04:34:40PM -0800 References: <199802230022.RAA20633@pluto.plutotech.com> <199802230034.QAA08989@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 February 1998 at 16:34:40 -0800, Mike Smith wrote:
>>> Ugh. How else is a driver supposed to attach extra information to a
>>> buf or group of bufs? The b_driver field was the only clean way I
>>> could implement request fragmentation in the wfd driver.
>>
>>> From taking a 2 second look at the code, it seems that the problem is
>> that you are attempting to store information in struct buf that should
>> really be encapsulated in the atapi equivalent of "scsi_xfer" or as it
>> is in CAM, the CCB. This structure would have a buf pointer in it.
>
> This means creating a new structure holding a buf reference and an
> single integer counter, and then managing memory allocation for this
> new structure type, and passing it around instead of the buf.
Wouldn't it make more sense to pass around an extended buf structure,
as ccd and vinum do? Put the buf at the start, and you can pass it to
all the routines that normally hand buf structures:
struct rqelement {
struct buf b; /* buf structure */
int sdoffset; /* offset in subdisk */
int useroffset; /* offset in user buffer */
int sectors; /* length of transfer */
int plexno; /* we are in rq->prq [plexno] */
int sdno; /* subdisk number */
#ifdef RAID5
int psdno; /* subdisk with parity */
#endif
/* Ways to find other components */
int driveno; /* drive number */
struct request *rq; /* pointer to the request */
};
> You're right, it almost certainly is the "correct" solution, but not
> necessarily the simplest. *sigh*
It's not much harder. The real problem is how to allocate them. As
John pointed out, there's a possibility of deadlock.
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?19980224112304.63148>