From: Dan Nicolaescu <dann@ics.uci.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: implement Solaris support for system-process-attributes and list-system-processes
Date: Thu, 18 Dec 2008 23:45:32 -0800 (PST) [thread overview]
Message-ID: <200812190745.mBJ7jWVe015085@mothra.ics.uci.edu> (raw)
In-Reply-To: <u4p11fd3d.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Dec 2008 22:22:14 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
> > 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/ ?
That file is included everywhere, so it might not be a good idea at this point.
> > 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.
How does this sound:
- move the procfs_list_system_processes and procfs_system_process_attributes to sysdep.c
- remove the procfs_ prefix
- add the proper #defines (HAVE_PROCFS can probably be used by a few OSes)
- the default implementations just return Qnil
- make Fsystem_process_attributes and Flist_system_processes just call
list_system_processes and system_process_attributes
- rename the w32 versions to system_process_attributes and list_system_processes
- remove the PROCATTR and LISTPROC macros
?
next prev parent reply other threads:[~2008-12-19 7:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 9:16 implement Solaris support for system-process-attributes and list-system-processes Dan Nicolaescu
2008-12-18 20:22 ` Eli Zaretskii
2008-12-19 7:45 ` Dan Nicolaescu [this message]
2008-12-19 8:35 ` Eli Zaretskii
2008-12-19 19:51 ` Dan Nicolaescu
2008-12-20 12:10 ` Eli Zaretskii
2008-12-19 8:48 ` Miles Bader
2008-12-19 19:51 ` Dan Nicolaescu
2008-12-20 3:40 ` Miles Bader
2008-12-20 3:50 ` Dan Nicolaescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812190745.mBJ7jWVe015085@mothra.ics.uci.edu \
--to=dann@ics.uci.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).