There's another school of thought too that says the kernel has no business parsing strings with all the security implications of doing so...
yeah, it's an interesting question. But Unix is based on parsing strings. The kernel already parses lots of strings for paths, for all kinds of reasons, so adding another element in the kernel that uses paths seems acceptable.
Well, if the nose of a camel comes in under the tent, the rest of the camel is sure to follow... Parsing a string path is rock simple, but are there two arguments or three for this command, and what happens if they are too long, or negative when you expect and fd, or or or. The CVE-archive is littered with people who thought parsing in the kernel was simple and easy...
The bigger problem for Plan 9 that started to bite was i8n. All the Plan 9 messages are English, oops. All the control messages are english. And so on.
And, further, that network architecture I referenced is much less efficient than the BSD model -- 5 system calls per accept! so that was starting to hit us here on the Akaros project, since we imported the entire Plan 9 network stack into akaros, along with the drivers. Linux left us in the dust on network connections/second. We were going to change it had Akaros continued.
That's the other reason to not do stings in the kernel: parsing is takes time.
I'll grant there's a balance here: A single int fd is nice so you don't have to pass a pointer to the device call function and provides a level of abstraction that blocks many bad data attacks. But even with this interface there's been issues with improper range checks for some interfaces.
Warner