At any rate it's their high performance chip based on the Core design
Confusingly, Intel's using "Core" in products using both the Pentium M microarchitecture (Yonah, a/k/a Intel Core Duo/Solo) and using the new Intel Core Microarchitecture (Conroe and Merom, a/k/a Intel Core 2 Duo and perhaps Solo).
I.e., Conroe's and Merom's microarchitecture is significantly different from Yonah's, even though they both have "Core" in their names.
The Core Duo is also in the MacBook / MacBook Pro - my understanding is that they're not actually using the 'laptop-oriented' Yonah, but the 'desktop-oriented' Core processors in their laptops.
Your understanding is incorrect. The only Core processor currently available is Yonah - Intel Core Duo and Intel Core Solo. (There's also a Yonah derivative, Sossaman, called the Dual-Core Xeon LV, but that's not used in any Apple machines.) Conroe is to be the "desktop-oriented" processor, but it's not out yet, and it - like the "laptop-oriented" Merom - will be called Intel Core 2 (Duo and, perhaps, Solo).
Remember how the Finder was the default FTP handler in 10.2, but would crash whenever you tried to use it for FTP?
I don't know about 10.2, but, at least in 10.3 and 10.4, the Finder knows little about FTP; it does know about Unix file systems, and a user-mode NFS server (mount_ftp) exposes an FTP server as a (read-only, as NFS doesn't let the server know when the client's closed the file, so it doesn't know when to put the file back) Unix file system. I've actually found that convenient at times (and anybody who says anything that includes the term "kioslave" at this point will be asked in what OS the shell and grep can use an ioslave - it was quite nice and Unixy to be able to just cd to the appropriate directory and grep *.log to scan the log files somebody'd put up on their FTP server).
Lacking a dnotify call, or just 'cause they're stupid, the Finder also doesn't update the desktop based on what's on it until you click on it.
It's spelled "kqueue", not "dnotify", and, as of 10.4, the Finder does use it. But, yes, it was a bit silly that my FreeBSD 4.x+KDE 3.0 laptop would update the desktop as soon as I'd moved something to or from ~/Desktop, while my PowerBook running OS X 10.3 wouldn't.
but speaking from Unix experience I'd say that there has to be some stable kernel API/syscall interface that you could clone either in a new development
Your Unix experience presumably doesn't include Solaris, then; as far as I know, Sun have never promised a stable system call interface - the ABI to Solaris is through procedure calls to dynamically-linked libraries, not through system calls.
The same is true in OS X - the system call interface, and the code in libSystem, can change in parallel, as long as the calls to procedures in libSystem don't change their ABI.
The Apple team gets all the work of the FreeBSD team
The Apple team gets to use the work of the FreeBSD team. Not all of it is easily usable, as Darwin isn't just a hacked-up FreeBSD - and not all of it is used.
which gets none of theirs
The FreeBSD team can, APSL issues permitting, use the work of the Apple team as it shows up in Darwin. They have used some of it - and not others, as not all of it is easily usable.
There was a release of Solaris 2.5.1 for PowerPC that was discontinued around the middle of 1996 (I think). Just like Apple, it's not unthinkable that Sun keeps a version ported to a few select architectures like the PowerPC
Re: "easy". That was the $64,000 question I asking about.
The answer is "no", especially if you have to re-implement all of the frameworks Mac applications use (heck, reimplementing it atop Darwin would be a significant amount of work, and you already have Mach messaging, at least some of the OS X daemons, and the additional system calls such as getattrlist(), getdirentriesattr(), exchangedata(), etc. if you're reimplementing it atop Darwin).
Mach is designed to host multiple API flavors, BSD is not. That's why they were able to bring out OS X with **FIVE** fully implemented "APIs"
No, it's not.
*Classic
Runs in a "Classic emulator" program, which makes, err, umm, BSD system calls and Mach message calls.
*Carbon
Which consists of libraries making, err, umm, BSD system calls and Mach message calls and calls to Core Foundation and the like (which also make BSD system calls and Mach message calls).
*Cocoa
Which consists of libraries making, err, umm, BSD system calls and Mach message calls and calls to Core Foundation and the like (which also make BSD system calls and Mach message calls).
*Java
Runs in a JVM making err, umm, BSD system calls and Mach message calls.
*BSD
Makes err, umm, BSD system calls and Mach message calls. (Yes, Mach message calls - a lot of the get* calls, e.g. getpw{ent,uid,nam}, make Mach calls to lookupd, for example.)
Mach in OS X supports one count 'em one personality. All the different development APIs run atop that personality (and libSystem and so on).
Although the underlying core architecture of Mac OS X, the Darwin kernel, is FreeBSD based
If they meant by "FreeBSD based" anything other than "some of the code in the Darwin kernel is based on FreeBSD code", they were wrong. Take a look at the FreeBSD kernel and xnu source if you don't believe me. For one thing, FreeBSD has no "osfmk" subdirectory, full of Mach code that implements Mach messaging and Mach tasks/threads (atop which BSD processes and pthreads are built in xnu) - and some of the OS X frameworks use Mach messaging, as do some of the OS X daemons (both open-source and closed-source).
Apple mentioned how "easy" is was to port Apple software over to Intel (or was it apple/intel?) - they said they have been doing it for 5 years.
...which has no bearing on how "easy" it'd be to port Apple software over to FreeBSD.
However, things like IOKIT and kext's is what makes it clear OS X does not have a monolithic kernel either.
If kexts make XNU not a monolithic kernel, then Solaris, various BSDs, most Linux distributions, and various commercial UNIXes other than Solaris don't have monolithic kernels, either.
As for IOKit, I'm not sure how it would make XNU not monolithic; what were you thinking of there?
Would you call it midi-kernel (as in micro, mini, midi, maxi, etc. ?).
Some call it - and the NT kernel - hybrid kernels, although there are some who debate whether a "hybrid kernel" is sufficiently different from a monolithic kernel to make a difference (see, for example, the thread that inspired Tanenbaum's comments).
BTW, the term used on the Wikipedia in at least some contexts for kernels that support loadable kernel modules is "monolithic kernel with modules", in case you think loadable kernel modules are sufficient to make a kernel not just a "monolithic kernel".
I'll guess: bit 29 in word 1 (30th bit, 2nd word) of the PTE
The PTE in the 64-bit documentation has two 64-bit words; bit 61 of the 2nd word is the no-execute bit.
It appears that bit 29 in the 32-bit PTE would correspond to bit 61 of the 64-bit PTE. I don't know whether any 32-bit PPCs implement that bit as an NX bit.
The standard desktop chips provide it with 256 MB resolution.
And, at least according to "PowerPC Operating Environment Architecture Book III Version 2.01", there's also a per-page no-execute bit; I don't know whether that's a feature that was added later than the per-segment no-execute bit (which I assume is what you were referring to).
I believe that you can only use Windows XP if you use filesystem NTFS
You believe incorrectly. I have an installation with FAT32 as the file system. I don't remember why the installation process defaulted to that (I presume it did, as I wouldn't have overridden a default of NTFS); it's on Virtual PC for Mac, so perhaps it defaults to FAT32 in that case.
Sure, 'the client can'... so it may be 'fixable' by adding code to the nfs client, but that's a bunch of extra code for something you don't need with UDP.
But if you're going to offer TCP support in the client, you should offer correct TCP support, for which you need the extra code.
The retransmit rates I see for nfs (nfsstats) on even the busiest clients are less than 0.05 percent. At rates like that, whatever TCP gains by doing smaller retransmits cannot weigh up agains the additional latency of SYN/ACK/RST TCP packets. Switching nfs to tcp will slow things down.
Presumably you meant "...the additional latency of ACK TCP packets"; if you're getting a significant number of SYN or RST packets, it means your client and/or server is closing connections a lot, in which case you're probably not going to be getting very good performance:-). So how many long-latency NFS requests - i.e., requests where the ACK can't be piggybacked on the NFS reply - do you see on your network?
The rest of the slides just make my point of TCP being the hard way to do nfs.
The rest of the slides don't talk about UDP implementation issues, such as Bill Nowicki's work on dynamically adjusting retransmission timers in NFS-over-UDP, so they only present one side of the story.
That actually is a problem with using tcp not udp... the server is stateless with UDP, hence if a server crashes the clients simply wait until the server comes back, after which everything resumes as if nothing happened. With TCP, the server doesn't know about the connection (the state) when it comes back, with UDP it doesn't need to know, so when the server comes back it can do the retransmit and the client continues as if nothing happened.
If the server comes back, it's not going to do a retransmit by itself, it'll transmit a reply in response to a client retransmit.
Whatever state happens to be maintained in the TCP connection is irrelevant to RPC or NFS; when the client gets a timeout from the TCP layer (if the server takes too long to come back), or gets a "connection broken" indication due to the server sending an RST in response to a TCP-layer timeout (if the server comes back quickly enough), then, as I explained in my previous posting (you know, the one to which you're replying), the client can just open a new connection and retransmit (probably at the NFS layer rather than at the RPC layer; RPC over TCP often doesn't bother with retransmission, leaving that up to TCP, but NFS clients, at least with hard mounts, do retransmissions themselves if they get back errors from the RPC layer) the requests to which it hasn't gotten any replies. The server will then transmit replies to those requests, and the client continues as if nothing ever happened.
I saw exactly that behavior from the Solaris client when I was developing the NFS-over-TCP support for the NetApp servers; this really does happen.
proto=_netid_ _netid_ is a value of network_id field from entry in the/etc/netconfig file. By default, the transport protocol used for the NFS mount is the first available connection oriented transport supported on both the client and the server. If no connection oriented transport is found, then the first available connectionless transport is used. This default behavior can be overridden with the proto=_netid_ option.
The Solaris 10 man page says much the same thing, but it explicitly indicates that this means "TCP first, then UDP if TCP isn't supported", and also mentions RDMA.
Why add the overhead and problems (see below) of tcp to an nfs mount?
Because the first problem they mention:
The disadvantage of using TCP is that it is not a stateless protocol like UDP. If your server crashes in the middle of a packet transmission, the client will hang and any shares will need to be unmounted and remounted.
is an implementation problem with the version of Linux's NFS client being described, not a problem of TCP. That paragraph can be replaced by "Linux's NFS-over-TCP client implementation, as of the writing of this document, is incomplete". A complete NFS-over-TCP cient implementation will, if the server crashes in the middle of a packet retransmission, attempt to open a new connection and, if that succeeds, will retransmit any requests to which it hadn't gotten any replies. An implementation that does that will not hang (if the server comes back) and will not require any unmounting and remounting of NFS mounts. The Solaris implementation is complete in that regard, as are, I suspect, most if not all of the Solaris-derived ones (such as commercial UN*Xes that have licensed Sun's implementation); I suspect the BSD implementations are complete in that regard as well.
The other problem listed is
The overhead incurred by the TCP protocol will result in somewhat slower performance than UDP under ideal network conditions, but the cost is not severe, and is often not noticable without careful measurement.
but, as they note, "the cost is not severe", and just because you happen to have ideal network conditions at time T, that doesn't necessarily mean you'll have them at time T + delta T.
The sad fact is, I enjoy having to muck with stuff. I think I'm truly in the minority here, but it's fun to tinker, especially when you can eventually get it to work.
You enjoy having to muck with stuff? I.e., you'd prefer a system that forced you to muck with stuff to a system that allowed you to work with stuff but didn't require it?
I think it's fun to tinker, too, but I'd prefer to have a system where the stuff I care less about tinkering with Just Works, leaving more time to timker with the stuff I care more about. (I.e., given a choice between mucking around with an X server configuration file to get the server to work with a machine's video adapter, and not having to do that and thus having more time to do development on a piece of free software, I'd pick the latter.)
Well, Intel seem to be saying that they're not yet shipping Intel Core Microarchitecture chips ("We expect processors based on Intel Core microarchitecture to start shipping in the third quarter of 2006."), and that the Core 2 chips use the Intel Core microarchitecture ("the Intel® Core(TM)2 processors for desktop and mobile computers are based on the Intel® Core(TM) microarchitecture"), so the Core 2 chips are the first "Intel Core" chips to use the new microarchitecture. (Whether they'll be the first chips at all to use it depends on when the first Intel Core microarchitecture Xeon chip (Woodcrest) ships.)
Booting will no longer be a graceful Apple graphic by default. It will be as detailed with as much garbage text as possible, announcing every single contributor to every package on the system.
That's what holding down Cmd-Opt-v while booting is for; turning the DB_PRT bit on in the debug flags might make that persistent. It's BSD-flavored, though, so you don't get quite so much in the way of contributor announcements.
Slashdot Mirror
Confusingly, Intel's using "Core" in products using both the Pentium M microarchitecture (Yonah, a/k/a Intel Core Duo/Solo) and using the new Intel Core Microarchitecture (Conroe and Merom, a/k/a Intel Core 2 Duo and perhaps Solo).
I.e., Conroe's and Merom's microarchitecture is significantly different from Yonah's, even though they both have "Core" in their names.
Your understanding is incorrect. The only Core processor currently available is Yonah - Intel Core Duo and Intel Core Solo. (There's also a Yonah derivative, Sossaman, called the Dual-Core Xeon LV, but that's not used in any Apple machines.) Conroe is to be the "desktop-oriented" processor, but it's not out yet, and it - like the "laptop-oriented" Merom - will be called Intel Core 2 (Duo and, perhaps, Solo).
I don't know about 10.2, but, at least in 10.3 and 10.4, the Finder knows little about FTP; it does know about Unix file systems, and a user-mode NFS server (mount_ftp) exposes an FTP server as a (read-only, as NFS doesn't let the server know when the client's closed the file, so it doesn't know when to put the file back) Unix file system. I've actually found that convenient at times (and anybody who says anything that includes the term "kioslave" at this point will be asked in what OS the shell and grep can use an ioslave - it was quite nice and Unixy to be able to just cd to the appropriate directory and grep *.log to scan the log files somebody'd put up on their FTP server).
It's spelled "kqueue", not "dnotify", and, as of 10.4, the Finder does use it. But, yes, it was a bit silly that my FreeBSD 4.x+KDE 3.0 laptop would update the desktop as soon as I'd moved something to or from ~/Desktop, while my PowerBook running OS X 10.3 wouldn't.
Your Unix experience presumably doesn't include Solaris, then; as far as I know, Sun have never promised a stable system call interface - the ABI to Solaris is through procedure calls to dynamically-linked libraries, not through system calls.
The same is true in OS X - the system call interface, and the code in libSystem, can change in parallel, as long as the calls to procedures in libSystem don't change their ABI.
What do you mean by "link the command line with the GUI"? And in what ways are you unable to do that in OS X?
Err, umm, are you saying that Samba isn't GPL code?
Or did you mean to say "xnu" when you said "Darwin"?
The Apple team gets to use the work of the FreeBSD team. Not all of it is easily usable, as Darwin isn't just a hacked-up FreeBSD - and not all of it is used.
The FreeBSD team can, APSL issues permitting, use the work of the Apple team as it shows up in Darwin. They have used some of it - and not others, as not all of it is easily usable.
Or maybe they're just letting the Polaris project (re-)do it for them. (Note that, unlike the original PPC port, the new one is big-endian.)
The answer is "no", especially if you have to re-implement all of the frameworks Mac applications use (heck, reimplementing it atop Darwin would be a significant amount of work, and you already have Mach messaging, at least some of the OS X daemons, and the additional system calls such as getattrlist(), getdirentriesattr(), exchangedata(), etc. if you're reimplementing it atop Darwin).
No, it's not.
Runs in a "Classic emulator" program, which makes, err, umm, BSD system calls and Mach message calls.
Which consists of libraries making, err, umm, BSD system calls and Mach message calls and calls to Core Foundation and the like (which also make BSD system calls and Mach message calls).
Which consists of libraries making, err, umm, BSD system calls and Mach message calls and calls to Core Foundation and the like (which also make BSD system calls and Mach message calls).
Runs in a JVM making err, umm, BSD system calls and Mach message calls.
Makes err, umm, BSD system calls and Mach message calls. (Yes, Mach message calls - a lot of the get* calls, e.g. getpw{ent,uid,nam}, make Mach calls to lookupd, for example.)
Mach in OS X supports one count 'em one personality. All the different development APIs run atop that personality (and libSystem and so on).
If they meant by "FreeBSD based" anything other than "some of the code in the Darwin kernel is based on FreeBSD code", they were wrong. Take a look at the FreeBSD kernel and xnu source if you don't believe me. For one thing, FreeBSD has no "osfmk" subdirectory, full of Mach code that implements Mach messaging and Mach tasks/threads (atop which BSD processes and pthreads are built in xnu) - and some of the OS X frameworks use Mach messaging, as do some of the OS X daemons (both open-source and closed-source).
...which has no bearing on how "easy" it'd be to port Apple software over to FreeBSD.
No, it's not. It's an OS the UNIX core of which uses a lot of code from FreeBSD, but it's not FreeBSD.
4. Network stacks, at least up to the transport layer, are implemented in kernel space.
If kexts make XNU not a monolithic kernel, then Solaris, various BSDs, most Linux distributions, and various commercial UNIXes other than Solaris don't have monolithic kernels, either.
As for IOKit, I'm not sure how it would make XNU not monolithic; what were you thinking of there?
Some call it - and the NT kernel - hybrid kernels, although there are some who debate whether a "hybrid kernel" is sufficiently different from a monolithic kernel to make a difference (see, for example, the thread that inspired Tanenbaum's comments).
BTW, the term used on the Wikipedia in at least some contexts for kernels that support loadable kernel modules is "monolithic kernel with modules", in case you think loadable kernel modules are sufficient to make a kernel not just a "monolithic kernel".
The PTE in the 64-bit documentation has two 64-bit words; bit 61 of the 2nd word is the no-execute bit.
It appears that bit 29 in the 32-bit PTE would correspond to bit 61 of the 64-bit PTE. I don't know whether any 32-bit PPCs implement that bit as an NX bit.
And, at least according to "PowerPC Operating Environment Architecture Book III Version 2.01", there's also a per-page no-execute bit; I don't know whether that's a feature that was added later than the per-segment no-execute bit (which I assume is what you were referring to).
You believe incorrectly. I have an installation with FAT32 as the file system. I don't remember why the installation process defaulted to that (I presume it did, as I wouldn't have overridden a default of NTFS); it's on Virtual PC for Mac, so perhaps it defaults to FAT32 in that case.
But if you're going to offer TCP support in the client, you should offer correct TCP support, for which you need the extra code.
Presumably you meant "...the additional latency of ACK TCP packets"; if you're getting a significant number of SYN or RST packets, it means your client and/or server is closing connections a lot, in which case you're probably not going to be getting very good performance :-). So how many long-latency NFS requests - i.e., requests where the ACK can't be piggybacked on the NFS reply - do you see on your network?
The rest of the slides don't talk about UDP implementation issues, such as Bill Nowicki's work on dynamically adjusting retransmission timers in NFS-over-UDP, so they only present one side of the story.
If the server comes back, it's not going to do a retransmit by itself, it'll transmit a reply in response to a client retransmit.
Whatever state happens to be maintained in the TCP connection is irrelevant to RPC or NFS; when the client gets a timeout from the TCP layer (if the server takes too long to come back), or gets a "connection broken" indication due to the server sending an RST in response to a TCP-layer timeout (if the server comes back quickly enough), then, as I explained in my previous posting (you know, the one to which you're replying), the client can just open a new connection and retransmit (probably at the NFS layer rather than at the RPC layer; RPC over TCP often doesn't bother with retransmission, leaving that up to TCP, but NFS clients, at least with hard mounts, do retransmissions themselves if they get back errors from the RPC layer) the requests to which it hasn't gotten any replies. The server will then transmit replies to those requests, and the client continues as if nothing ever happened.
I saw exactly that behavior from the Solaris client when I was developing the NFS-over-TCP support for the NetApp servers; this really does happen.
On some OSes. On others, it doesn't; see, for example, the Solaris 9 mount_nfs man page:
The Solaris 10 man page says much the same thing, but it explicitly indicates that this means "TCP first, then UDP if TCP isn't supported", and also mentions RDMA.
Because the first problem they mention:
is an implementation problem with the version of Linux's NFS client being described, not a problem of TCP. That paragraph can be replaced by "Linux's NFS-over-TCP client implementation, as of the writing of this document, is incomplete". A complete NFS-over-TCP cient implementation will, if the server crashes in the middle of a packet retransmission, attempt to open a new connection and, if that succeeds, will retransmit any requests to which it hadn't gotten any replies. An implementation that does that will not hang (if the server comes back) and will not require any unmounting and remounting of NFS mounts. The Solaris implementation is complete in that regard, as are, I suspect, most if not all of the Solaris-derived ones (such as commercial UN*Xes that have licensed Sun's implementation); I suspect the BSD implementations are complete in that regard as well.
The other problem listed is
but, as they note, "the cost is not severe", and just because you happen to have ideal network conditions at time T, that doesn't necessarily mean you'll have them at time T + delta T.
Including NFS, too? (Were using NFS-over-UDP or NFS-over-TCP?)
You enjoy having to muck with stuff? I.e., you'd prefer a system that forced you to muck with stuff to a system that allowed you to work with stuff but didn't require it?
I think it's fun to tinker, too, but I'd prefer to have a system where the stuff I care less about tinkering with Just Works, leaving more time to timker with the stuff I care more about. (I.e., given a choice between mucking around with an X server configuration file to get the server to work with a machine's video adapter, and not having to do that and thus having more time to do development on a piece of free software, I'd pick the latter.)
Well, Intel seem to be saying that they're not yet shipping Intel Core Microarchitecture chips ("We expect processors based on Intel Core microarchitecture to start shipping in the third quarter of 2006."), and that the Core 2 chips use the Intel Core microarchitecture ("the Intel® Core(TM)2 processors for desktop and mobile computers are based on the Intel® Core(TM) microarchitecture"), so the Core 2 chips are the first "Intel Core" chips to use the new microarchitecture. (Whether they'll be the first chips at all to use it depends on when the first Intel Core microarchitecture Xeon chip (Woodcrest) ships.)
Yes.
That's what holding down Cmd-Opt-v while booting is for; turning the DB_PRT bit on in the debug flags might make that persistent. It's BSD-flavored, though, so you don't get quite so much in the way of contributor announcements.