Re: fuword(), suword(), etc.
Shawn wrote: On Fri, 2003-07-25 at 01:42, Terry Lambert wrote: I do know that even if they remove the bridge, they are unlikely to provide enough documentation to boot and run natively on the hardware without having IBM code setting up the bus arbitration and other bits that are currently undocumented. Why would IBM try to hide this? Wouldn't they *want* people to take full advantage of the processor for the best performance to help give their product a good image? Adaptec didn't document their hardware to prevent people from cloning its interface in order to leverage the driver developement effort and advocacy it took to get their drivers into Windows. Diamond Multimedia didn't document their video cards because they had a hardware guy instead of a Real Software Engineer design their BIOS interface, and there was no non-Diamond-BIOS-accessible table of the PAL imputs vs. the video mode self-docmented in their BIOS, and they wanted to be able to change PAL and BIOS in tandem to add updated features to their cards, without changing their overall card design. There are a lot of comapnies who don't document their hardware for reasons of liability, when their documentation is incorrect and thus causes their hardware to fail, sometimes by cooking. Intel doesn't docuyment their full errata on their processors because then people wouldn't buy stock-on-hand, if they knew a stepping without a particular errata existed that didn't have the problem in question. How much of an excuse do they need? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
geeze terry would you mind unhijacking this topic? The topic is Should we have an suptr() and fuptr() to match suword() and fuword()? On Fri, 25 Jul 2003, Terry Lambert wrote: [tonnes of absolutly irrelevant stuff] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Julian Elischer wrote: geeze terry would you mind unhijacking this topic? The topic is Should we have an suptr() and fuptr() to match suword() and fuword()? I'm not the one who posted the question without changing the subject line; please read the thread history. In answer to your question, my answer is still: How do you intend to deal with 32 and 64 bit address spaces on the same machine, if all you have is one function for the copyin and one for the copyout?. Or is there no intent to allow IA32 binaries to run on IA64, never ever ever? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Sat, Jul 26, 2003 at 12:08:29AM -0700, Terry Lambert wrote: In answer to your question, my answer is still: How do you intend to deal with 32 and 64 bit address spaces on the same machine, if all you have is one function for the copyin and one for the copyout?. Or is there no intent to allow IA32 binaries to run on IA64, never ever ever? What does that have to do with anything? Adding fuptr()/suptr() has no consequences for supporting or not supporting different memory models with different pointer sizes. The functions are defined to operate on native (kernel PoV) pointers. Any non- native (kernel PoV) ABI has a non-native ABI handler that does all the mapping, converting and copying bits from userland to kernel and vice versa. And I can't believe I actually wasted my time telling you this when you only have to use your head instead of your keyboard. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Thu, Jul 24, 2003, Terry Lambert wrote: Marcel Moolenaar wrote: for i386 it would be an alternate name for fuword32() and suword32() I'm not sure what it would be on other architectures fuword64 and suword64. PowerPC is like i386. PPC 970 explicitly supports mixed mode programming between user and kernel, as do most other 64 bit processors, in order to support legacy applications. It's actually unlikely that IBM will ever release enough documentation to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, and that you will be stuck with a 32 bit kernel that runs 64 bit apps, and which talks to IBM's internal undocumented glue on the bottom end while running in a virtual environment, such that the interfaces to that glue are not exposed in the source code they publish. Will any releases of MacOS X have the full 64 bit code? Will Darwin ever be released with the full 64 bit code? Adrian -- Adrian Chaddangryskul learning is bad [EMAIL PROTECTED] angryskul it just makes the people around you dumber (angryskul == [EMAIL PROTECTED])angryskul :( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Shawn wrote: On Thu, 2003-07-24 at 03:40, Terry Lambert wrote: It's actually unlikely that IBM will ever release enough documentation to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, and that you will be stuck with a 32 bit kernel that runs 64 bit apps, and which talks to IBM's internal undocumented glue on the bottom end while running in a virtual environment, such that the interfaces to that glue are not exposed in the source code they publish. That's very interesting to me as IBM has been rather forthcoming about making sure everyone knows that the 32bit bridge was only temporary and to not rely on it being there in the future. I would hope that would indicate that they may be willing to release more informaation in the future regarding this. Of course, what do I know? :p IBM doesn't want people running 32 bit code on their 64 bit hardware forever, and making it look bad, so they have stated publically that they intend to withdraw support for the 32 bit bridge in the future, I'll agree. As to whether this will really happen, or is just a scare tactic to prevent people from writing new code that depends on the bridge (which is supposed to be there only to provide support for old code), I don't know; I haven't worked for IBM for nearly 3 years now. Maybe Greg Lehey can comment. I do know that even if they remove the bridge, they are unlikely to provide enough documentation to boot and run natively on the hardware without having IBM code setting up the bus arbitration and other bits that are currently undocumented. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Adrian Chadd wrote: Will any releases of MacOS X have the full 64 bit code? Will Darwin ever be released with the full 64 bit code? I don't know; you could always ask Jordan. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Fri, 2003-07-25 at 01:42, Terry Lambert wrote: I do know that even if they remove the bridge, they are unlikely to provide enough documentation to boot and run natively on the hardware without having IBM code setting up the bus arbitration and other bits that are currently undocumented. Why would IBM try to hide this? Wouldn't they *want* people to take full advantage of the processor for the best performance to help give their product a good image? -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Wed, Jul 23, 2003 at 02:48:41PM -0700, Julian Elischer wrote:
+ I'd like to have a suptr and fuptr to be able to save and read
+ user pointers in a machine independent manner..
+ at the moment ia need to know the size of a pointer and select the
+ appropriate 32 or 64 version.. It would jus tbe another ENTRY files in
+ support.[sS] alongside teh appropriate sized entry
+ for each architecture so it wouldn't 'cost' anything..
+
+ for i386 it would be an alternate name for fuword32() and suword32()
+ I'm not sure what it would be on other architectures
+
+ comments?
Yes, good idea. I'm using for now something like this:
static __inline void *
fuptr(void *uaddr)
{
void *ptr;
if (copyin(uaddr, ptr, sizeof(void *)) != 0)
return ((void *)-1);
return (ptr);
}
For numbers is always better to use copyin(9)/copyout(9). Functions
like fubyte(9), etc. make no sens for me. -1 is returned on error or
if there is really -1, so one isn't able to find out if there is an
error or not.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: fuword(), suword(), etc.
Julian Elischer wrote: I'd like to have a suptr and fuptr to be able to save and read user pointers in a machine independent manner.. at the moment ia need to know the size of a pointer and select the appropriate 32 or 64 version.. It would jus tbe another ENTRY files in support.[sS] alongside teh appropriate sized entry for each architecture so it wouldn't 'cost' anything.. for i386 it would be an alternate name for fuword32() and suword32() I'm not sure what it would be on other architectures comments? You cannot be certain that specific user space pointers are 64 bits on a 32 bit kernel or 32 bits on on a 64 bit kernel, etc.. The reason for this is that you may wish to operate in a hybrid or backward compatability mode, or you may wish to operate the kernel in a smaller virtual address space than user space, or vice versa, as a developement decision. For example the PPC 970 (G5) processor has specific support for backward binary compatability, as does the AMD Hammer, the Intel Opteron (IA64), and the SPARC64. Probably it will be a long time before many commercial 32 bit applications are ported to 64 bit kernels, and you're going to want to be able to run the 32 bit applications. The point is that you will probably end up needing at least 4 macros each, if you have sized types on both ends, and two each, if you assume that the kernel pointer size is fixed on every architecture. Personally, I would call this a kernel is aware of the ABI for each of the applications it is currently running, and make it a flag in the system call table, if you insist on using a single name for the thing. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Marcel Moolenaar wrote: for i386 it would be an alternate name for fuword32() and suword32() I'm not sure what it would be on other architectures fuword64 and suword64. PowerPC is like i386. PPC 970 explicitly supports mixed mode programming between user and kernel, as do most other 64 bit processors, in order to support legacy applications. It's actually unlikely that IBM will ever release enough documentation to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, and that you will be stuck with a 32 bit kernel that runs 64 bit apps, and which talks to IBM's internal undocumented glue on the bottom end while running in a virtual environment, such that the interfaces to that glue are not exposed in the source code they publish. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Thu, 2003-07-24 at 03:40, Terry Lambert wrote: It's actually unlikely that IBM will ever release enough documentation to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, and that you will be stuck with a 32 bit kernel that runs 64 bit apps, and which talks to IBM's internal undocumented glue on the bottom end while running in a virtual environment, such that the interfaces to that glue are not exposed in the source code they publish. That's very interesting to me as IBM has been rather forthcoming about making sure everyone knows that the 32bit bridge was only temporary and to not rely on it being there in the future. I would hope that would indicate that they may be willing to release more informaation in the future regarding this. Of course, what do I know? :p -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
On Wed, Jul 23, 2003 at 02:48:41PM -0700, Julian Elischer wrote: I'd like to have a suptr and fuptr to be able to save and read user pointers in a machine independent manner.. Sounds good to me. for i386 it would be an alternate name for fuword32() and suword32() I'm not sure what it would be on other architectures fuword64 and suword64. PowerPC is like i386. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
