Messages in this thread | | | Date | Sun, 9 Jun 2002 10:49:50 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] Futex Asynchronous Interface |
| |
On Sun, 9 Jun 2002, Peter Wächtler wrote: > > Still you can open a file in the namespace and write some commands to it. > Then it turns out to be a socket on port 25: > > fd=open("/dev/socket",O_RDWR); > write(fd,"connect stream 25\n",sizeof(..)); > write(fd,"helo mail.my.com\n",..);
Yes, obviously you can avoid system calls entirely, and replace all of them with read/write of commands.
This is not even a very uncommon idea: the above is basically message passing, and is largely how many microkernels work. Except they don't call it read/write, they tend to call it send/recv, and they aren't "file descriptors", they are "ports".
It has advantages: because you only have one set of primitives, it's more easily abtracted at that level, meaning that you can (and people do) make it distributed etc without having to worry about local semantics.
It has disadvantages too: performance tends to be bad (you have to copy around and parse the commands that are no longer implicit in the system call number), and while there is a high level of abstraction on one level ("everything is a 'port' that can receive or send messages), at some point the proverbial shit hits the fan and you've moved the details behind the abstraction down (and now the data stream is no longer just bytes, but has a meaning in itself).
But yes, the sequences
open("/dev/socket") -> socket() write(fd,"connect stream 25") -> connect()
are obviously "equivalent". It's not my personal favourite equivalence, though. I'd much rather add the information at _open_ time, and make it a name-space issue, so that you'd do something like
open("//sockfs/dst=123.45.67.89:25", O_RDWR);
instead. Which is _also_ entirely equivalent, of course (the "namespace" approach does require that you be able to do "fd-relative" lookups, so that you could also do
sk = open("//sockfs", O_RDWR); sk2 = fd_open(sk, "dst=123.45.67.89:25", O_RDWR);
which is actually useful even in regular files too, just as a way of doing directory-relative file opens without having to do a "chdir()").
HOWEVER, the fact is that exactly because they are equivalent, there is no real difference between them. So you might as well just use the old UNIX behaviour, and if you want to open sockets from a script, you use any of the already _existing_ socket script helpers. For port 25, you have one called "sendmail". For port 80, you have things like "lynx -source".
And you have tons of things like "netpipes", for doing generic scripting of sockets.
The fact is, trying to come up with new ways to do the same old thing is _not_ a good idea. It may look cool to expose sockets in the namespace, but what's the actual added advantage over existing standard practices? Unless that can be shown, there's just no point.
Do a google search for "netpipes", I'm sure you'll find it can do what you wanted.
Sorry to rain on the "cool feature" parade, but I want to see some _advantage_ from exposing new names in the namespace.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |