> On Sun, Sep 28, 2008 at 5:18 PM, David Powell > <david.pow...@sun.com> wrote: > > David Bartley wrote: > >>> > >>> Backing up, what problem are you trying to solve? > >> > >> I want to use procfs.h while having large file > support; there's a few > >> lines that disallow this: > >> > >> #if !defined(_LP64) && _FILE_OFFSET_BITS == 64 > >> #error "Cannot use procfs in the large file > compilation environment" > >> #endif > > > > If you want to use both procfs and large files, > you can use the > > transitional large file compilation environment, > documented in > > lfcompile64(5). It is less convenient than using > the normal large > > files interfaces (you must explicitly use > large-file interfaces, e.g. > > open64() instead of open()), but is compatible > with things like > > procfs.h. > > Thanks for the info. I'm still a bit curious as to > what the underlying > reason for #error above is.
AFAIK, procfs was created in such a way that a 64-bit process can monitor anything (given appropriate permissions), but a 32-bit process can only monitor other 32-bit processes, but when the latter happens, the 32-bit process sees everything in its "native" size. In other words, the size of the data objects that procfs makes available depend on the model of the process accessing it. The kernel part includes code to vary its behavior according the the model of the requesting process, but the include file has to result in matching behavior in user space. AFAIK, the kernel has no way of knowing that a 32-bit process was compiled with large file support, only that it's a 32-bit process vs a 64-bit process. So to do what you want to do, there's no good way to use the more painless large file compilation environment, and you end up doing what they other poster said and using the transitional interfaces of the *64() form. This perhaps may make more sense considering what the pressure might have been to be backwards-compatible with. procfs has been around since before 64-bit. It also might make sense to think of both 32-bit and 64-bit versions of the OS itself (still present on x86, and present at one time for SPARC, which is only 64-bit now). Under those conditions, doing something new (having a 32-bit process control or observe a 64-bit process) was probably less important than having existing 32-bit processes be able to continue working with one another in the expected way; 64-bit processes, being new anyway, would have to have extra code to deal with any differences between controlling a 32-bit vs 64-bit client. I don't promise that I got all of that right. But I think I got close enough that it makes sense if you think about it why procfs.h behaves the way it does. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
