Date: Wed, 28 Feb 2001 23:26:46 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... Message-ID: <Pine.LNX.4.21.0102282322340.5102-100000@zeppo.feral.com> In-Reply-To: <Pine.BSF.4.21.0103011719200.1753-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think it is not fundamentally broken for type 'long' on machines with
> >=64 bit longs, but subr_bus.c:resource_find_hard() is missing support
> for longs. It uses strtoul() to convert the string to a number and then
> blindly assigns the number to an int. It also ignores range errors
> reported by strtoul(), of course.
But the main point here is that one doesn't really want longs- one wants the
size one wants, or one wants the string.
> > hint.isp.0.portwnn="w50000000aaaa0000"
> > hint.isp.0.nodewnn="w50000000aaaa0001"
> >
> > in order to get the string so I can then do a kernel strtouq on the portion
> > past the 'w'... *phppptttttt*
>
> Try changing resource_find_hard() to produce a RES_LONG instead of a
> RES_INT.
I don't believe this will help for anytihing but alpha, will it?
> > >
> > > I'm converting a driver over to using device hints instead of
> > > getenv_*, and one thing has stubbed my toe. The current resource types are:
> > >
> > >
> > > /*
> > > * Resources from config(8).
> > > */
> > > typedef enum {
> > > RES_INT, RES_STRING, RES_LONG
> > > } resource_type;
> > >
> > > But I've been happily using a getenv_quad for a 64 bit WWN override.
> > >
> > > It strikes me that RES_INT and RES_LONG are too vague (as well as useless).
> > > How hard would it be to change these to RES_INT32 and RES_INT64?
>
> Fairly hard, and backwards. You would have to fix the abovementioned
> problems in the gnu toolchain for RES_INT64 to work right on i386's.
> Fixed-width types are even less appropriate than int/long in most places,
> including here. Non-vague types would be typedefed types like
> vm_offset_t for memory addresses, etc. I think we don't need fully
> typedefed types for hints (just use uintmax_t for all numeric values),
> but they might be worth it for resource_foo_t_value().
>
> BTW, resource_long_value() isn't used anywhere. This is probably an
> i386ism (resource_long_value() is useless when sizeof(int) == sizeof(long)).
> This is a bug in "machine-independent" code link /sys/isa/isahint.c
> (it uses resource_int_value() for memory addresses...).
Memory addresses on ISA? Tsk... < 16MB...
I'm now inclined to think that RES_INT (unsized) an RES_STRING is sufficient
as long as you can coerce RES_STRING. The general usage of integers for hints
will satisfy most drivers that will use this stuff. The strings can then be
interpreted as need be- it's not really that bad in FreeBSD because there's a
very rich set of C-library like functions.
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0102282322340.5102-100000>