June 2006 - Darwin-kernel - lists.apple.com

Is there any dummy provider
by Pavan Chebbi 19 Jun '06

19 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eEQnzGG/fUwtm9g2PINivygWLSSMfA34UKiKS5ArsrSoiopEOKsZzE4W+uq17twrS0XtlVOmRjno+YNR6r5IIwW/TJwN4MwZexPaG2KyxqNkNgTkAhyLBOwaSy99sKV2NzxCJ30vbCLn9A0tpJJe3UrAKAUotM9zx/9MDyfBwOw= ; _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Michael Smith 17 Jun '06

17 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 16, 2006, at 12:54 PM, Andrew Gallatin wrote: That way, drivers wouldn't have to leave their object modules, they could just jump into their own private copies of the functions they would otherwise have called... Brilliant. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I'm talking about a scheme where, when the module is loaded, its code is re-written by the "kernel linker" (or kextload, or whatever does the relocation when loading a kext) and re-writes KPI functions to do direct structure access. This re-writing code is kernel dependent and could be supplied, for example, via the commpage. This would be similar to what Digital UNIX did when they patched out SMP locks at runtime on UP systems. That's a really innovative scheme... you could have little patch areas that you rewrote all the KPI functions into - and in fact you could optimise it by copying directly from the KPI function implementation in the kernel. (Yes, I am well aware of the point you're trying to make. In a few cases it might actually be useful, but vtable-style indirection isn't the big evil here...) This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Andrew Gallatin 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Michael Smith writes: > > > 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? > > Thanks to the glory of pipelining, branch prediction and speculative > execution, they're much cheaper than you think, but no, if you were > to think about it for a second you would realise that an abstract KPI > would be worthless if it worked out that way. No, it would be worthless if it happened at compile time. That's not what I mean. By "kernel linker" I meant at module load time, not at driver compile/link time. I'm talking about a scheme where, when the module is loaded, its code is re-written by the "kernel linker" (or kextload, or whatever does the relocation when loading a kext) and re-writes KPI functions to do direct structure access. This re-writing code is kernel dependent and could be supplied, for example, via the commpage. This would be similar to what Digital UNIX did when they patched out SMP locks at runtime on UP systems. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Michael Smith 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 16, 2006, at 12:01 PM, Andrew Gallatin wrote: 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. Despite that having happened for every major release since 10.0, except where it couldn't because it would break something? Thanks to the glory of pipelining, branch prediction and speculative execution, they're much cheaper than you think, but no, if you were to think about it for a second you would realise that an abstract KPI would be worthless if it worked out that way. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… 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? This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Andrew Gallatin 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Michael Smith 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 16, 2006, at 8:00 AM, Andrew Gallatin wrote: 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. 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. 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. Absolutely. The question is simply whether it happens once, or for 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. More bait? I believe in your last breath you were complaining that I/O Kit changes too fast... = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Michael Smith writes: 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. What, like NextStep's IOKit that MacOSX uses? :) This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Justin C. Walker 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 16, 2006, at 08:12 , Stephane Sudre wrote: Cheers, Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds ----------- I'm beginning to like the cut of his jibberish. ----------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 16 juin 06, at 17:00, Andrew Gallatin wrote: [snip] What, like NextStep's IOKit that MacOSX uses? :) Are you sure I/O Kit is from NeXTStep? The DriverKit looks like to be Obj-C. http://www.channelu.com/NeXT/NeXTStep/3.3/nd/OperatingSystem/ Part3_DriverKit/Concepts/Preface.htmld/index.html IOKit is derived, in a loose sense, from DriverKit, but as you note, there is a language difference. There was a lot of grousing when Apple discussed basing the device driver model in Mac OS X on Objected-C, so they redid the design with C++ more-or-less in mind. This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Stephane Sudre 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 16 juin 06, at 17:00, Andrew Gallatin wrote: 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> 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. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Look in the second section, or seqrch in the page for "accessor". What, like NextStep's IOKit that MacOSX uses? :) Are you sure I/O Kit is from NeXTStep? The DriverKit looks like to be Obj-C. http://www.channelu.com/NeXT/NeXTStep/3.3/nd/OperatingSystem/ Part3_DriverKit/Concepts/Preface.htmld/index.html This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Andrew Gallatin 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: may b a minor error
by Andrew Gallatin 16 Jun '06

16 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Terry Lambert writes: > > ...there's also those of us who are on this list, and try to help out > by voluntarily answering developer questions, but who have day jobs > working on code, and no ability to officially speak for Apple, > including but not limited to, commitments to work on documentation > instead of code, or ability to make forward looking statements. We > also can't disclose Apple confidential WWDC or "developer kitchen" > slides, talks, or reference materials. This a symptom of the broader problem of Apple's secretive, control-freak nature and the unfortunate resulting disconnect of Apple software engineers from the developer community. This is what makes Darwin being "open source" a joke compared to something like Sun's OpenSolaris. In contrast to you guys not being able to make forward looking statements, Sun employees working on Solaris are pretty much required to push new code publically through OpenSolaris, and discuss technical changes on OpenSolaris mailing lists, in public, before they happen. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0