Date: Tue, 3 Jul 2001 23:33:21 +0200 From: Joerg Wunsch <j@uriah.heep.sax.de> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys bio.h Message-ID: <20010703233321.C3398@uriah.heep.sax.de> In-Reply-To: <200107032051.f63KpIm01502@mass.dis.org>; from msmith@FreeBSD.org on Tue, Jul 03, 2001 at 01:51:18PM -0700 References: <20010703193214.A3398@uriah.heep.sax.de> <200107032051.f63KpIm01502@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
As Mike Smith wrote:
> > Because i need to fill in a cmd value anyway, and neither of the
> > existing didn't fit well. Maybe a single CMD_PRIVATE value would have
> > sufficed, but i rather followed the other examples (CMD_FLAG{1,2}
> > etc).
>
> Neither of these was at all necesssary.
Well, a bio_cmd /is/ necessary. ;-)
> > Also, using a void * would have complicated matters pretty much. It's
> > invalid to abuse a void * as an int
>
> Er, no it's not.
>
> void *foo;
> int bar;
>
> bar = (int)(uintptr_t)foo;
>
> foo = (void *)(uintptr_t)bar;
I think that's wrong C. AFAIR, an arbitrary /pointer/ is allowed to
be cast to a void *, and then cast back to just that arbitrary
pointer, and this is the only valid operation on void pointers.
Casting a scaler type to a void * and back is not a valid operation.
(First, the machine might have a different bit length for pointers and
scalars, and IMHO it's even possible that a machine has an entirely
different address space for pointers and scalars, something like the
IA32 architecture has different address spaces for memory and IO
pointers.)
Someone with a better standards background than me might comment on
this. For the time being, here's the reference to K&R2 (p 199):
``A6.8 Pointers to Void
Any pointer to an object may be converted to type void * without loss
of information. If the result is converted back to the original
pointer type, the original pointer is recovered. [...]''
So only pointers are allowed here.
> If you need a private 'command' structure to pass stuff around
> inside your driver, perhaps you should just create one?
I don't need a private structure (i would have malloced it then), just
a few values in a private scalar variable/field (only a couple of
values would have sufficed for me, but bde pointed out that something
like the ATA driver might have use for more distinct values here).
No, the normal driver's softc doesn't work very well since it's not
coupled to a request. (It would incidentally have worked just in that
case, since the caller waits for the strategy function to complete, so
noone else can setup a new request during that time. But abusing the
device's softc for things that logically belong into struct bio
wouldn't make things better.)
BIO_FORMAT has probably been wrong as well. It could have been
covered by a BIO_PRIVATE command + 32 bits of driver-private space in
struct bio that are not declared to be a pointer.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010703233321.C3398>