>> Architecture-dependent blob passed to mount(2) (aka nfs4_mount_data). >> If you want it to be a blob, at least have a decency to use encoding >> that would not depend on alignment rules and word size. Hell, you >> could use XDR - it's not that nfs would need something new to handle >> it. Or, better yet, use a normal string. > >Mount doesn't appear to permit a big enough blob though. It has a hard limit >of PAGE_SIZE.
That seems to me to be orthogonal to Al's point. You could make an architecture-independent format for that page that still contains addresses in user space of additional information. Which would presumably also have an architecture-independent format. But why is mount() special here? It's ancient tradition for Linux system calls to take as parameters, and return as results, in-memory structures that are dependent on local word size and endianness. Lots of them do. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
