Date: Thu, 1 Mar 2001 20:46:23 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Jacob <mjacob@feral.com> Cc: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... Message-ID: <Pine.BSF.4.21.0103012026000.2734-100000@besplex.bde.org> In-Reply-To: <Pine.LNX.4.21.0102282322340.5102-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Feb 2001, Matthew Jacob wrote: [bde wrote] > > 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. One also wants error checking. The main point of having central handling of the conversion instead of making everything convert the string is to centralize the error handling. > > > 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? No. i386's currently just don't support resource values with size > 32 bits. You mentioned a need for 128 bits in other mail. This would have to be handled as a string. Perhaps the same for > 32 bits or at least for > sizeof(long) bytes. > > 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... Is there a standard for isa memory addresses? They could be mapped anywhere. Another problem with resource_*_value() is that resource_long_value() doesn't return "int" resources although it could. The caller has to know the type. > 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. I agree. The set is too rich :-). Bruce 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.BSF.4.21.0103012026000.2734-100000>