Re: implement Solaris support for system-process-attributes and list-system-processes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 18 Dec 2008 01:16:19 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> 
> #ifdef SOLARIS2
> #if !defined (_LP64) && defined (_FILE_OFFSET_BITS) &&  (_FILE_OFFSET_BITS  ==  64)
> #define PROCFS_FILE_OFFSET_BITS_HACK 1
> #undef _FILE_OFFSET_BITS
> #else
> #define PROCFS_FILE_OFFSET_BITS_HACK 0
> #endif
> #include <procfs.h>
> #if PROCFS_FILE_OFFSET_BITS_HACK ==  1
> #define _FILE_OFFSET_BITS 64
> #endif
> #endif /* SOLARIS2 */
> 
> procfs.h is the header file that contains the proc data structures, but
> it has an #error if compiled in 32 bit mode and _FILE_OFFSET_BITS is
> 64.
> emacs/src/config.in will define _FILE_OFFSET_BITS to 64 when compiled on
> a 32 bit solaris system.  Hence the above hackery.

Can this hackery be moved to a Solaris-specific header file in src/s/ ?

> 2. process.c has a function `procfs_list_system_processes' that works on
> Solaris (and probably on all systems that use a /proc).  
> The problem is that procfs_list_system_processes is inside a #ifdef HAVE_PROCFS
> that contains a few other functions (time_from_jiffies, get_up_time)
> that are Linux specific.
> Should I move those functions inside a #ifdef LINUX ?

I guess GNU_LINUX would be better, and perhaps move them to sysdep.c
while at that.

> 4. Flist_system_processes and Fsystem_process_attributes use the
> LISTPROC and PROCATTR macros for function calls that need to be defined in src/s/*.h 
> These macros are different from how other platform specific functions
> are implemented in emacs, and they seem to be a bit redundant: the
> functions to implement these are system specific anyway....

I hoped that systems with procfs will have only minor differences,
that's why I opted for these macros.  In addition, having the macros
provides an easy way of switching between 2 different implementations
on the same platform.  But these are not very important reasons, so I
don't object to some different solution.

> So what's the best way to integrate Solaris support?
> Again the existing procfs_list_system_processes function can probably be
> used by all systems using /proc, but procfs_system_process_attributes
> is very likely to be OS specific. 

If /proc systems are different to the degree that splitting them into
a common part and OS-specific parts is impractical or unjustified, I
think the implementations of procfs_system_process_attributes should
be moved to sysdep.c, and there we could have a separate variant for
each OS.