Two pieces of code someone really ought to write
rondam.blogspot.com
Two pieces of code someone really ought to write
1–10 of 36 posts
Re: Two pieces of code someone really ought to write
#2Regarding your first point... You forget one thing: you open a file and get a file descriptor. If you open a socket (though it takes 3 calls), it also returns a file descriptor. Sockets can then be written to and read from just like files. Won't even get started then about the fact that sockets allow you to do just about any type of networking, and are very abstract by purpose, to allow a variety of uses.
Re: Two pieces of code someone really ought to write
#3There are a few attempts to make sockets look like a Unix filesystem, but none seem to have caught on, perhaps partly because sockets are pretty portable, while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes", are inevitably tied to a particular OS flavor.
I believe Plan9 was the first to have support for the idea, though, and NetBSD has had it as an option for about 15 years, though I'm not sure if it's currently maintained. Here's an old paper about NetBSD's implementation: http://www.kohala.com/start/portals.ps
The existence of netcat also makes it a bit less pressing imo. In the cases where I want a quick shell script that does sockets, I can use netcat as basically a socket library. It's not the everything-is-a-file style of Unixy coding, but it is at least the pipe-simple-utilities style of Unixy coding. And if I want to write a "real app" in some higher-level language, the language can wrap socket-opening at the library level to look like file-opening if it wants to, so it doesn't really have to be done by the OS.
Re: Two pieces of code someone really ought to write
#4Regarding the first point (socket as file), Plan 9 operating system is not using any system call for socket but use a pseudo file-system /net.
http://doc.cat-v.org/plan_9/4th_edition/papers/net/
Using the same approach in a fuse implementation would make sense.
Re: Two pieces of code someone really ought to write
#5Regarding your first point... You forget one thing: you open a file and get a file descriptor. If you open a socket (though it takes 3 calls), it also returns a file descriptor. Sockets can then be written to and read from just like files. Won't even get started then about the fact that sockets allow you to do just about any type of networking, and are very abstract by purpose, to allow a variety of uses.
Sounds like opening a socket could be reduced to one call, so why not fopen()? Seems like it'd be an easy thing to get into a kernel, any reason not to?
Re: Two pieces of code someone really ought to write
#6You can sorta get what he's asking for with a bash feature.
http://tldp.org/LDP/abs/html/devref1.html#DEVTCP
Re: Two pieces of code someone really ought to write
#7The first issue is a programming language problem, not an OS problem. His language of choice exposes the direct low-level API, which is not usually what application-level programmers want.
A few library functions, and the problem is solved without FUSE or a performance impact. And it's still portable to everywhere.
Re: Two pieces of code someone really ought to write
#8About the first point: several people have mentioned plan9, GNU awk also handles sockets as a virtual filesystem. You seem to think it's better handled at an OS level (and I agree), but it's a good way to try it out.
Re: Two pieces of code someone really ought to write
#9There are a few attempts to make sockets look like a Unix filesystem, but none seem to have caught on, perhaps partly because sockets are pretty portable, while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes", are inevitably tied to a particular OS flavor. I believe Plan9 was the first to have support for the idea, though, and NetBSD has had it…
> while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes"
FUSE runs on pretty everything, doesn't it?
Re: Two pieces of code someone really ought to write
#10The first issue is a programming language problem, not an OS problem. His language of choice exposes the direct low-level API, which is not usually what application-level programmers want. A few library functions, and the problem is solved without FUSE or a performance impact. And it's still portable to everywhere.
But then you have to implement the solution in every language, while with FUSE, you implement it once and each language runtime instantly has access to it.