Article on Unixlib

Alex Waugh alex at
Mon Jan 31 12:58:00 PST 2005


An update on my plans. An updated process structure is below. Changes
from before are as follows.

The environment handlers are no longer handled by SUL. I now think it
will be simplest to keep them under the control of the program as I
mentioned in my last post.
All SUL routines called from the program will take their first
parameter as the address of the process structure (or possibly the
existing SUL key), so SUL can identify which process it is being called
tty structs have been added to the process structure, and the
device specific function calls have been moved out of the tty struct
into an array of handlers similar to the __dev array in dev.c
The console and rs423 members are initialised to NULL by SUL, then when
the program first opens a tty the program will allocate the structure
(using sul_malloc) and set the handle field of the relevant
__unixlib_fd_handle structure to point to it.

Every where that currently manipulates file descriptors like
__u->fd[fd].dflag would be changed to getfd(fd)->dflag

#define getfd(fdes) ((struct __unixlib_fd *)(void *) \
(((char *)(__proc->file_descriptors)) + ((fdes) * __proc->fdsize)))

There are some things I'm still not sure about, and would appreciate any

If a program that has its heap in a dynamic area calls fork(), should
the dynamic area be duplicated? I'm tempted to say no, and programs
that need all their address space duplicating should ensure the heap
gets put in the wimpslot.

Currently a child process will try to use the same dynamic area as its
parent if it wants a DA for the heap. I could add a field to the proc
structure to support this, but it might be simpler just to create a new
DA for the child. It might waste slightly more address space, but if
you're worried about that then you should probably keep the heap in the
wimpslot anyway.

There are a few other things that technically should be shared with
child processes, such as the rusage struct. It probably wouldn't be much
work, but I'm not sure if there is any practical value in doing so.

Finally, if there are no objections then I'll remove the
__UNIXLIB_FEATURE_DEV_RS423 options. I don't really see the benefit in
having them configurable, it doesn't save much space by turning them
off, and it might cause problems if a parent process has them enabled
and a child doesn't.

struct __sul_process
  void *(*sul_malloc)(struct __sul_process *, size_t size);
  void (*sul_free)(struct __sul_process *, void *ptr);
  __pid_t pid;
  __pid_t ppid;
  __mode_t umask;
  char **environ;
  void *(*set_wimpslot)(struct __sul_process *, int);
  pid_t (*sul_fork)(struct __sul_process *);
  pid_t (*sul_vfork)(struct __sul_process *);
  __os_error *(*exec)(struct __sul_process *, char *cli);
  void *file_descriptors;
  int maxfd;           /* Number of entries in the file_descriptors array */
  int fdsize;          /* Size of a struct __unixlib_fd */
  int fdhandlesize;    /* Size of a struct __unixlib_fd_handle */
  int tty_type;
  struct tty *console;
  struct tty *rs423;

/* File descriptor structure definition. One per fd */
struct __unixlib_fd
  unsigned int __magic; /* magic number for descriptor validity */
  unsigned int dflag; /* File descriptor flags.  */
  struct __unixlib_fd_handle *devicehandle;
  int fflag; /* File status flags (attribs for opening a file) */

/* Multiple __unixlib_fd structures may point to one of these */
struct __unixlib_fd_handle {
  int refcount;
  unsigned int type; /* Device type (tty, socket etc. ) */
  void *handle; /* device specific field (i.e. socket, file handle) */

struct tty
  int type;             /* tty type */
  int refcount;
  struct termios t[1];
  struct winsize w[1];
  int sx,cx;		/* screen x, character x */
  int cnt;		/* number of characters in input buffer */
  char *ptr;		/* read pointer in input buffer */
  int lookahead;	/* [1 byte or -1] lookahead to allow select() */
  char buf[MAX_INPUT];  /* input buffer */
  char del[MAX_INPUT];  /* number of displayed characters for character cx */


Alex Waugh                                           alex at

PHP, Roots, Subversion, WebJames and more from

More information about the gcc mailing list