> > Which happens to be remarkably ugly. And it will not get better tomoorow...
>
> Its really only ugly in one way which is that you pass an int for the item
> rather than having a struct of all the data
You know as well as I do that as soon as we add it glibc folks _will_
start whin^Wasking for "just one more field". So structure is out of
question for pretty obvious reasons... Wanna bet that they'll ask for
maximal size of symlink that could be created in directory? Or truncate
long names vs. reject long names policy. And everything from /proc/mounts,
since "binary data is easier to parse". And case sensitivity. And
NLS used. And timezone of that filesystem. And SGID policy (BSD vs. SysV).
And subset of mode bits available on that fs. And ability to create
device nodes. And... There is a lot of crap that could be asked for.
General rule with GNU seems to be that _every_ piece of crap somebody
had thought about gets tossed into the mix.
Prediction:
* Any attempt to decide on a fixed structure will generate a flamewar,
where everyone and his mom will advocate their pet features.
* There will be regular requests to play syscall of the week game.
I.e. new version of pathconf(2) that will support more new features. Old
ones will not go away, indeed.
* There will be regular requests to make syscall versioned (read:
magic number + pointer to structure with layout depending on that number).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/