Messages in this thread | | | Date | Thu, 8 Mar 2007 12:53:26 -0800 | From | "Michael K. Edwards" <> | Subject | Re: [patch 2/5] signalfd v2 - signalfd core ... |
| |
On 3/8/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > So anybody who would "go with the Berkeley crowd" really shows a lot of > bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's > so long ago that I don't think there is any point in us trying to fix it > any more.
Well, they did invent the socket, which sucks less than a lot of other things. You would prefer STREAMS, perhaps? :-) My point is that this is a message-oriented problem, not a stream-oriented problem, and read() just isn't a very good interface for passing structured messages around. I agree that the details of recvmsg() ancillary data are fairly grotty (optimization based on micro-benchmarks, as usual, back in the PDP/VAX days), but the concept isn't that bad; you let netlink sockets into the kernel, didn't you?
> (But if somebody makes recvmgs a general VFS interface and makes it just > work for everything, I'd probably take the patch as a cleanup. I really > think it should have been a "struct file_operations" thing rather than > being a socket-only thing.. But since you couldn't portably use it > anyway, the thing is pretty moot)
sendmsg()/recvmsg() to a file makes perfect sense, if you put the equivalent of an llseek tuple into ancillary data. And it's also IMHO the right way to do file AIO -- open up a netlink socket to the entity that's scheduling the IOs for a given filesystem, use the SCM_RIGHTS mechanism to do indirect opens (your credentials could come over an AF_UNIX socket from a completely separate "open server" process), and multiplex all the AIO to that filesystem across the netlink socket.
If adding this to VFS is something you would seriously consider, I'll do the work. But I will need some coaching to work around my relative inexperience with the Linux core code and my lack of taste. :-)
Cheers, - Michael - 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/
| |