On Wednesday 30 June 2010, David Howells wrote: > Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > Given a 64 bit flag word, you can start using bits for the version from > > the top and bits from the bottom for fields: > > I suppose. It's cleaner, though, to keep them separate. Yes, but it's a tradeoff. If separating them means you have to add another structure, I'd prefer having just a flags word with different kinds of bits. In particular since I don't think we actually need to worry about wildly different layouts. If struct oldstat had come with an extensibility concept like what you propose here, we would not have needed newstat, stat64 and xstat. > > Alternatively, you can also make it a 64 bit argument everywhere, which has > > some other small disadvantages. > > No, you can't. 32-bit systems can only pass 32-bit arguments. If you're > suggesting passing a pointer to a 64-bit argument instead, how's that any > different from my suggestion of a separate parameter block? I was thinking of splitting the 64 bit argument into two registers on 32 bit systems, like we do with other 64 bit input arguments (e.g. loff_t). While there is not much of a difference, I'd always prefer passing input arguments by register to a memory location when possible. > > The idea of a syscall API with multiple fixed-length and variable-length > > fields in the same structure scares me. If you want to go this far, > > it may be better to base the interface on netlink and allow querying > > multiple files at once. > > Urgh. Netlink is way too much overhead and even scarier. That's pretty much > a guarantee that people won't use it. It also has to work if CONFIG_NET=n. Exactly. Just resist the urge to add complexity bordering what we already have in netlink. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
