Re: may b a minor error
Re: may b a minor error
- Subject: Re: may b a minor error
- From: Andrew Gallatin <email@hidden>
- Date: Fri, 16 Jun 2006 15:01:49 -0400 (EDT)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden