Re: DNS from a Kernel Extension
Re: DNS from a Kernel Extension
- Subject: Re: DNS from a Kernel Extension
- From: William Kucharski <email@hidden>
- Date: Sat, 11 Nov 2006 05:19:56 -0700
On Nov 10, 2006, at 7:45 PM, Josh Graessley wrote:
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
William Kucharski
email@hidden
_______________________________________________
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