site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Nov 10, 2006, at 7:45 PM, Josh Graessley wrote: William Kucharski kucharsk@mac.com _______________________________________________ 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... The kernel, if it was given a name or a list of addresses could do some intelligent stuff. In user space, you would need to open a new socket for each connection attempt. In the kernel, if there was a connect to name or connect to list, the kernel could start by sending the first syn to the the first address, wait for some time, then send the next syn and so on. The kernel could accept the first syn-ack to come back from any of those initial syns it sent. Once it got a syn-ack back, it would reject packets from any other addresses and finish up the three way handshake. The kernel could apply some smarts to try the best addresses first. An application wouldn't have to worry about the nitty gritty stuff and we wouldn't have to waste time creating lots of sockets or writing complicated code to have multiple sockets attempting simultaneous asynchronous connects. This is really, really the wrong approach. One should never attempt to fix bad application design by making the kernel more complex. I subscribe to the theory that what's in the kernel should ONLY be code implementing things that can absolutely not be done any other way in user space, whether because they access private kernel data not visible to the outside world or because they change some vital system state. The example you describe COULD be implemented that way, but really that's sort of taking a sledgehammer to the situation. This type of thing should be done in the application by either doing intelligent name resolution or by simultaneously attempting connect()s to each IP address resolved in some type of hierarchical order. Since it's Mac OS X, firing off multiple threads seems like the PERFECT way to implement this. Lightweight and able to take advantage of simultaneous execution across multiple cores and processors. If it's really a goal to try and "fix" bad applciations, there should be a LIBRARY interface to do this. To give an example, Microsoft started out implementing their GUI window management routines for Windows NT in user land, the way they should be. To speed up execution (and avoid context switching), they moved the windowing code into the NT kernel. On the surface this makes sense, but it also makes the entire system more fragile - now bugs in the windowing code can crash the machine. Not good. Somewhat ironically, the whole reason the Mach kernel, upon which Mac OS X is based, was written was as a microkernel, with the idea that the BSD and System V kernels had become bloated with far too much extraneous code, most of which could really be handled by userland daemons. The fact that the Mach pager is an external daemon is one good example of this. Mach was designed so user utilities could handle any task, rather than just manipulate files as is the case with either BSD or SYSV UNIX. This makes the idea of bloating the Mac OS X kernel with code such as this even more reprehensible to me. Doing DNS in the kernel would present a number of challenges. DNS is sort of one level above arp and we do arp in the kernel, so DNS is too much of a stretch. The problem is that people pollute their name resolution with all kinds of other crap from the /etc/hosts file to a variety of directory services plug-ins. Getting access to that stuff in the kernel is not feasible. Not to mention that BIND has been the subject of any number of security holes, so putting that kind of code in the kernel is an even worse idea. :-) Then again, you know that, so I'm preaching to the choir here, I'm just trying to dissuade anyone else from the idea. :D This email sent to site_archiver@lists.apple.com