site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Michael Smith writes:
On Jun 16, 2006, at 8:00 AM, Andrew Gallatin wrote:
Michael Smith writes:
Of course, if there was a 64-bit kernel, it wouldn't run on 32-bit hardware, and it would require a complete re-write of every device driver in existence.
The speedbump of Tiger required so many recompiles anyway that you probably could have gotten most drivers for free just by having the latest version of Xcode build drivers by default as fat 32/64 bit binaries.
What was that about "baiting"? You know as well as I do that you can't just "recompile" your average driver to get a 64-bit version, and you certainly can't sell it for money without testing it.
I guess I've gotten too used to our drivers where 64-bit is the normal test/dev environment. BTW, Apple's 32bit kernel / 64-bit userspace bizzaro-world took me weeks of work for our HPC drivers.
Contrary to what passes for popular opinion here, that isn't the sort of change that Apple would typically foist on developers without plenty of notice.
You forgot to mention those developers would have to pay a $500/yr ADC fee to be informed, and then wouldn't be allowed to talk about it in public forums, like this list.
Above Terry mentioned changes to the size and/or layout of a struct uio. What do you do about old (10.2 era) drivers compiled when the uio accessors did not exist? Do they just fail to load after Terry's change? Or do they corrupt kernel memory?
All of this stuff is versioned. If it's possible and necessary to export different versions of the interfaces, then those can be implemented as shims and old drivers that require them will match and be taken care of.
It seems to me that you're going to have to have a flag-day of 10.4 anyway, and that 10.x ( x <=3) drivers are going to stop working because of your kernel changes.
Absolutely. The question is simply whether it happens once, or for every major release.
I really doubt you'd be touching core structures every major release.
Solaris has a much, much more stable driver ABI than you guys do (drivers compiled before MacOSX even existed still work) and it allows direct access to structures (like uio).
Sure, and if you want to assume that changes in hardware architecture and the way software uses that hardware stopped fifteen years ago then that model works fine.
What, like NextStep's IOKit that MacOSX uses? :)
More bait? I believe in your last breath you were complaining that I/O Kit changes too fast...
No, I was complaining about the KPIs being inflicted on us. I cringe every time I write "m = mbuf_next(m)". Should I cringe at this? Is the kernel linker smart enough to replace these function calls with m = m->m_next at link time, or do these function calls really happen? Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com