• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: may b a minor error
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: may b a minor error


  • Subject: Re: may b a minor error
  • From: Andrew Gallatin <email@hidden>
  • Date: Fri, 16 Jun 2006 11:00:53 -0400 (EDT)

Michael Smith writes:
 >
 > On Jun 15, 2006, at 1:49 PM, Andrew Gallatin wrote:
 > > Terry Lambert writes:
 > >> On Jun 15, 2006, at 6:12 AM, Andrew Gallatin wrote:
 > >>
 > >> More than a theory; I've personally made kernel changes in this area
 > >
 > > I honestly wasn't trying to bait you, but since you seem to be baiting
 > > me...
 > >
 > >> for 64 bit support in the Tiger release that would break code that
 > >> was
 > >> using promiscuous knowledge of the structure contents, instead of
 > >> using an accessor/mutator.  The idea is to replace data interfaces
 > >
 > > This would not be required if you had a 64-bit kernel.
 >
 > 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.

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?  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.

 > It's fair to say that the folks making these decisions aren't
 > *complete* idiots.

No, not *complete* I suppose.

 > >> with accessor/mutator functions to insulate the underlying
 > >> implementation from necessary data structure changes.
 > >>
 > >> This is actually a fundamental Computer Science concept for object
 > >> oriented programming.  There's a good Wikipedia article on it at:
 > >>
 > >> 	<http://en.wikipedia.org/wiki/Accessor>
 > >>
 > >> Look in the second section, or seqrch in the page for "accessor".
 > >
 > > Is it found right between "slow" and "inefficent" ? :)
 > >
 > > 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?  :)

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

  • Follow-Ups:
    • Re: may b a minor error
      • From: Michael Smith <email@hidden>
    • Re: may b a minor error
      • From: Stephane Sudre <email@hidden>
References: 
 >may b a minor error (From: sugumaran narayanan <email@hidden>)
 >Re: may b a minor error (From: Andrew Gallatin <email@hidden>)
 >Re: may b a minor error (From: Terry Lambert <email@hidden>)
 >Re: may b a minor error (From: Andrew Gallatin <email@hidden>)
 >Re: may b a minor error (From: Michael Smith <email@hidden>)

  • Prev by Date: Re: may b a minor error
  • Next by Date: Re: may b a minor error
  • Previous by thread: Re: may b a minor error
  • Next by thread: Re: may b a minor error
  • Index(es):
    • Date
    • Thread