3 ms·

> Which is what I said. It's a "file" in name only. No, it is the very definition of a file from the OS perspective. There is no other applicable definition to

> Which is what I said. It's a "file" in name only. No, it is the very definition of a file from the OS perspective. There is no other applicable definition to the OS. You seem to conflate files with disk storage, in which case not just plan9, not just Linux but the entirety of UNIX history seems to have flown past you. That files are a nothing but abstract handles that implements the VFS interface to serve every conceivable function - where regular file is treated no differently than a device driver - is the entire point of modern UNIX. If this is the part you are stuck on it is not a surprise that both the existing Linux kernel APIs and trivial (and quite frankly, perfectly ergonomic and efficient) alternatives like the plan9 API seem so foreign to you. "read and write structs" is the most normal thing for an application to do, whether you are reading JSON from disk, communicating over UNIX domain sockets with raw C structs, or sending protobuf over the network. "But thank God it's not implemented in Linux" - Linux has many of these APIs already and it constantly grows, see for example all of /dev, /sys and /proc, not to mention FUSE and support for the 9P protocol to use all of plan9's services as-is.

mike_hock 3y ago
I couldn't care less about the weird nomenclature, but it seems to have confused a lot of people since they insist that just because every object is called a "file," everything needs to be shoehorned into the concept of file nodes in a virtual filesystem tree. You don't get one object == one file node, you get one object == a subdirectory with lots of file nodes that you have to open and close independently. That should tell you that your pattern doesn't work. (With enough effort, you can of course always shoehorn everything into an ill-conceived concept (and you did), but if you have to bend over backwards to make it fit, you should just admit it doesn't fit.) It works for /dev, but definitely not for the mess that is /sys and /proc. "Reading and writing structs" is the most natural thing to do when you're forced to serialize your data. You then design wrappers around that serialization that expose a sane, type-safe API on each end.

mike_hock 3y ago

I couldn't care less about the weird nomenclature, but it seems to have confused a lot of people since they insist that just because every object is called a "file," everything needs to be shoehorned into the concept of file nodes in a virtual filesystem tree. You don't get one object == one file node, you get one object == a subdirectory with lots of file nodes that you have to open and close independently. That should tell you that your pattern doesn't work. (With enough effort, you can of course always shoehorn everything into an ill-conceived concept (and you did), but if you have to bend over backwards to make it fit, you should just admit it doesn't fit.) It works for /dev, but definitely not for the mess that is /sys and /proc. "Reading and writing structs" is the most natural thing to do when you're forced to serialize your data. You then design wrappers around that serialization that expose a sane, type-safe API on each end.