[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implement Solaris support for system-process-attributes and list-sys
From: |
Eli Zaretskii |
Subject: |
Re: implement Solaris support for system-process-attributes and list-system-processes |
Date: |
Thu, 18 Dec 2008 22:22:14 +0200 |
> Date: Thu, 18 Dec 2008 01:16:19 -0800 (PST)
> From: Dan Nicolaescu <address@hidden>
>
> #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.