From owner-freebsd-arch Sun Nov 10 17:28:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2963237B401 for ; Sun, 10 Nov 2002 17:28:26 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 553A043E3B for ; Sun, 10 Nov 2002 17:28:22 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id gAAHWZ59035339; Sun, 10 Nov 2002 09:32:35 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200211101732.gAAHWZ59035339@beastie.mckusick.com> To: arch@freebsd.org Subject: Shared-memory version of macros Cc: bostic@sleepycat.com (Keith Bostic) X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick Date: Sun, 10 Nov 2002 09:32:35 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am proposing to add a new version of the macros that are designed to work in shared memory. The man page and actual macros are included below. Search for NEW to find the additions to the existing macros. Since these are not needed by the kernel, I propose to create a new file /usr/include/queue.h which will contain the new shared memory version of the queue macros and also include to pull in the existing set of queue macros. The include of is to avoid duplication and possible divergence of the original macro set. Note that these shared memory macros are being contributed by the folks that produce Berkeley DB and have been heavily tested in a shared memory application, so they are known to work. Kirk McKusick =-=-=-=-= # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # queue.3.txt # shqueue.h # echo x - queue.3.txt sed 's/^X//' >queue.3.txt << 'END-of-queue.3.txt' XQUEUE(3) System Library Functions Manual QUEUE(3) X XNAME X SLIST_EMPTY, SLIST_ENTRY, SLIST_FIRST, SLIST_FOREACH, SLIST_HEAD, X SLIST_HEAD_INITIALIZER, SLIST_INIT, SLIST_INSERT_AFTER, X SLIST_INSERT_HEAD, SLIST_NEXT, SLIST_REMOVE_HEAD, SLIST_REMOVE, X STAILQ_CONCAT, STAILQ_EMPTY, STAILQ_ENTRY, STAILQ_FIRST, STAILQ_FOREACH, X STAILQ_HEAD, STAILQ_HEAD_INITIALIZER, STAILQ_INIT, STAILQ_INSERT_AFTER, X STAILQ_INSERT_HEAD, STAILQ_INSERT_TAIL, STAILQ_LAST, STAILQ_NEXT, X STAILQ_REMOVE_HEAD, STAILQ_REMOVE, LIST_EMPTY, LIST_ENTRY, LIST_FIRST, X LIST_FOREACH, LIST_HEAD, LIST_HEAD_INITIALIZER, LIST_INIT, X LIST_INSERT_AFTER, LIST_INSERT_BEFORE, LIST_INSERT_HEAD, LIST_NEXT, X LIST_REMOVE, TAILQ_CONCAT, TAILQ_EMPTY, TAILQ_ENTRY, TAILQ_FIRST, X TAILQ_FOREACH, TAILQ_FOREACH_REVERSE, TAILQ_HEAD, TAILQ_HEAD_INITIALIZER, X TAILQ_INIT, TAILQ_INSERT_AFTER, TAILQ_INSERT_BEFORE, TAILQ_INSERT_HEAD, X TAILQ_INSERT_TAIL, TAILQ_LAST, TAILQ_NEXT, TAILQ_PREV, TAILQ_REMOVE - X implementations of singly-linked lists, singly-linked tail queues, lists X and tail queues X[NEW] X SH_LIST_EMPTY, SH_LIST_ENTRY, SH_LIST_FIRST, SH_LIST_FIRST_P, X SH_LIST_FOREACH, SH_LIST_HEAD, SH_LIST_HEAD_INITIALIZER, SH_LIST_INIT, X SH_LIST_INSERT_AFTER, SH_LIST_INSERT_BEFORE, SH_LIST_INSERT_HEAD, X SH_LIST_NEXT, SH_LIST_NEXTP, SH_LIST_REMOVE, SH_TAILQ_EMPTY, X SH_TAILQ_ENTRY, SH_TAILQ_FIRST, SH_TAILQ_FIRSTP, SH_TAILQ_FOREACH, X SH_TAILQ_FOREACH_REVERSE, SH_TAILQ_HEAD, SH_TAILQ_HEAD_INITIALIZER, X SH_TAILQ_INIT, SH_TAILQ_INSERT_AFTER, SH_TAILQ_INSERT_BEFORE, X SH_TAILQ_INSERT_HEAD, SH_TAILQ_INSERT_TAIL, SH_TAILQ_LAST, X SH_TAILQ_NEXT, SH_TAILQ_PREV, SH_TAILQ_PREVP, SH_TAILQ_REMOVE - X implementations of singly-linked lists, singly-linked tail queues, lists X and tail queues for use in shared memory situations X XSYNOPSIS X #include X X SLIST_EMPTY(SLIST_HEAD *head); X X SLIST_ENTRY(TYPE); X X SLIST_FIRST(SLIST_HEAD *head); X X SLIST_FOREACH(TYPE *var, SLIST_HEAD *head, SLIST_ENTRY NAME); X X SLIST_HEAD(HEADNAME, TYPE); X X SLIST_HEAD_INITIALIZER(SLIST_HEAD head); X X SLIST_INIT(SLIST_HEAD *head); X X SLIST_INSERT_AFTER(TYPE *listelm, TYPE *elm, SLIST_ENTRY NAME); X X SLIST_INSERT_HEAD(SLIST_HEAD *head, TYPE *elm, SLIST_ENTRY NAME); X X SLIST_NEXT(TYPE *elm, SLIST_ENTRY NAME); X X SLIST_REMOVE_HEAD(SLIST_HEAD *head, SLIST_ENTRY NAME); X X SLIST_REMOVE(SLIST_HEAD *head, TYPE *elm, TYPE, SLIST_ENTRY NAME); X X STAILQ_CONCAT(STAILQ_HEAD *head1, STAILQ_HEAD *head2); X X STAILQ_EMPTY(STAILQ_HEAD *head); X X STAILQ_ENTRY(TYPE); X X STAILQ_FIRST(STAILQ_HEAD *head); X X STAILQ_FOREACH(TYPE *var, STAILQ_HEAD *head, STAILQ_ENTRY NAME); X X STAILQ_HEAD(HEADNAME, TYPE); X X STAILQ_HEAD_INITIALIZER(STAILQ_HEAD head); X X STAILQ_INIT(STAILQ_HEAD *head); X X STAILQ_INSERT_AFTER(STAILQ_HEAD *head, TYPE *listelm, TYPE *elm, X STAILQ_ENTRY NAME); X X STAILQ_INSERT_HEAD(STAILQ_HEAD *head, TYPE *elm, STAILQ_ENTRY NAME); X X STAILQ_INSERT_TAIL(STAILQ_HEAD *head, TYPE *elm, STAILQ_ENTRY NAME); X X STAILQ_LAST(STAILQ_HEAD *head, TYPE, STAILQ_ENTRY NAME); X X STAILQ_NEXT(TYPE *elm, STAILQ_ENTRY NAME); X X STAILQ_REMOVE_HEAD(STAILQ_HEAD *head, STAILQ_ENTRY NAME); X X STAILQ_REMOVE(STAILQ_HEAD *head, TYPE *elm, TYPE, STAILQ_ENTRY NAME); X X LIST_EMPTY(LIST_HEAD *head); X X LIST_ENTRY(TYPE); X X LIST_FIRST(LIST_HEAD *head); X X LIST_FOREACH(TYPE *var, LIST_HEAD *head, LIST_ENTRY NAME); X X LIST_HEAD(HEADNAME, TYPE); X X LIST_HEAD_INITIALIZER(LIST_HEAD head); X X LIST_INIT(LIST_HEAD *head); X X LIST_INSERT_AFTER(TYPE *listelm, TYPE *elm, LIST_ENTRY NAME); X X LIST_INSERT_BEFORE(TYPE *listelm, TYPE *elm, LIST_ENTRY NAME); X X LIST_INSERT_HEAD(LIST_HEAD *head, TYPE *elm, LIST_ENTRY NAME); X X LIST_NEXT(TYPE *elm, LIST_ENTRY NAME); X X LIST_REMOVE(TYPE *elm, LIST_ENTRY NAME); X X TAILQ_CONCAT(TAILQ_HEAD *head1, TAILQ_HEAD *head2, TAILQ_ENTRY NAME); X X TAILQ_EMPTY(TAILQ_HEAD *head); X X TAILQ_ENTRY(TYPE); X X TAILQ_FIRST(TAILQ_HEAD *head); X X TAILQ_FOREACH(TYPE *var, TAILQ_HEAD *head, TAILQ_ENTRY NAME); X X TAILQ_FOREACH_REVERSE(TYPE *var, TAILQ_HEAD *head, HEADNAME, X TAILQ_ENTRY NAME); X X TAILQ_HEAD(HEADNAME, TYPE); X X TAILQ_HEAD_INITIALIZER(TAILQ_HEAD head); X X TAILQ_INIT(TAILQ_HEAD *head); X X TAILQ_INSERT_AFTER(TAILQ_HEAD *head, TYPE *listelm, TYPE *elm, X TAILQ_ENTRY NAME); X X TAILQ_INSERT_BEFORE(TYPE *listelm, TYPE *elm, TAILQ_ENTRY NAME); X X TAILQ_INSERT_HEAD(TAILQ_HEAD *head, TYPE *elm, TAILQ_ENTRY NAME); X X TAILQ_INSERT_TAIL(TAILQ_HEAD *head, TYPE *elm, TAILQ_ENTRY NAME); X X TAILQ_LAST(TAILQ_HEAD *head, HEADNAME); X X TAILQ_NEXT(TYPE *elm, TAILQ_ENTRY NAME); X X TAILQ_PREV(TYPE *elm, HEADNAME, TAILQ_ENTRY NAME); X X TAILQ_REMOVE(TAILQ_HEAD *head, TYPE *elm, TAILQ_ENTRY NAME); X X[NEW] X SH_LIST_EMPTY(LIST_HEAD *head); X X SH_LIST_ENTRY; X X SH_LIST_FIRST(SH_LIST_HEAD *head, TYPE); X X SH_LIST_FIRSTP(SH_LIST_HEAD *head, TYPE); X X SH_LIST_FOREACH(TYPE *var, SH_LIST_HEAD *head, SH_LIST_ENTRY NAME, TYPE); X X SH_LIST_HEAD(HEADNAME); X X SH_LIST_HEAD_INITIALIZER(SH_LIST_HEAD head); X X SH_LIST_INIT(SH_LIST_HEAD *head); X X SH_LIST_INSERT_AFTER(TYPE *listelm, TYPE *elm, SH_LIST_ENTRY NAME, TYPE); X X SH_LIST_INSERT_BEFORE(TYPE *listelm, TYPE *elm, SH_LIST_ENTRY NAME, TYPE); X X SH_LIST_INSERT_HEAD(SH_LIST_HEAD *head, TYPE *elm, SH_LIST_ENTRY NAME, X TYPE); X X SH_LIST_NEXT(TYPE *elm, SH_LIST_ENTRY NAME, TYPE); X X SH_LIST_NEXTP(TYPE *elm, SH_LIST_ENTRY NAME, TYPE); X X SH_LIST_REMOVE(TYPE *elm, SH_LIST_ENTRY NAME, TYPE); X X SH_TAILQ_EMPTY(SH_TAILQ_HEAD *head); X X SH_TAILQ_ENTRY; X X SH_TAILQ_FIRST(SH_TAILQ_HEAD *head, TYPE); X X SH_TAILQ_FIRSTP(SH_TAILQ_HEAD *head, TYPE); X X SH_TAILQ_FOREACH(TYPE *var, SH_TAILQ_HEAD *head, SH_TAILQ_ENTRY NAME, X TYPE); X X SH_TAILQ_FOREACH_REVERSE(TYPE *var, SH_TAILQ_HEAD *head, HEADNAME, X SH_TAILQ_ENTRY NAME, TYPE); X X SH_TAILQ_HEAD(HEADNAME); X X SH_TAILQ_HEAD_INITIALIZER(SH_TAILQ_HEAD head); X X SH_TAILQ_INIT(SH_TAILQ_HEAD *head); X X SH_TAILQ_INSERT_AFTER(SH_TAILQ_HEAD *head, TYPE *listelm, TYPE *elm, X SH_TAILQ_ENTRY NAME, TYPE); X X SH_TAILQ_INSERT_BEFORE(TYPE *listelm, TYPE *elm, SH_TAILQ_ENTRY NAME, X TYPE); X X SH_TAILQ_INSERT_HEAD(SH_TAILQ_HEAD *head, TYPE *elm, SH_TAILQ_ENTRY NAME, X TYPE); X X SH_TAILQ_INSERT_TAIL(SH_TAILQ_HEAD *head, TYPE *elm, SH_TAILQ_ENTRY NAME, X TYPE); X X SH_TAILQ_LAST(SH_TAILQ_HEAD *head, HEADNAME, TYPE); X X SH_TAILQ_NEXT(TYPE *elm, SH_TAILQ_ENTRY NAME, TYPE); X X SH_TAILQ_NEXTP(TYPE *elm, SH_TAILQ_ENTRY NAME, TYPE); X X SH_TAILQ_PREV(TYPE *elm, HEADNAME, SH_TAILQ_ENTRY NAME, TYPE); X X SH_TAILQ_REMOVE(SH_TAILQ_HEAD *head, TYPE *elm, SH_TAILQ_ENTRY NAME, X TYPE); X XDESCRIPTION X These macros define and operate on four types of data structures: singly- X linked lists, singly-linked tail queues, lists, and tail queues. All X four structures support the following functionality: X 1. Insertion of a new entry at the head of the list. X 2. Insertion of a new entry after any element in the list. X 3. O(1) removal of an entry from the head of the list. X 4. O(n) removal of any entry in the list. X 5. Forward traversal through the list. X X Singly-linked lists are the simplest of the five data structures and sup- X port only the above functionality. Singly-linked lists are ideal for X applications with large datasets and few or no removals, or for imple- X menting a LIFO queue. X X Singly-linked tail queues add the following functionality: X 1. Entries can be added at the end of a list. X 2. They may be concatenated. X However: X 1. All list insertions must specify the head of the list. X 2. Each head entry requires two pointers rather than one. X 3. Code size is about 15% greater and operations run about 20% X slower than singly-linked lists. X X Singly-linked tailqs are ideal for applications with large datasets and X few or no removals, or for implementing a FIFO queue. X X All doubly linked types of data structures (lists and tail queues) addi- X tionally allow: X 1. Insertion of a new entry before any element in the list. X 2. O(1) removal of any entry in the list. X However: X 1. Each elements requires two pointers rather than one. X 2. Code size and execution time of operations (except for X removal) is about twice that of the singly-linked data-struc- X tures. X X Linked lists are the simplest of the doubly linked data structures and X support only the above functionality over singly-linked lists. X X Tail queues add the following functionality: X 1. Entries can be added at the end of a list. X 2. They may be traversed backwards, from tail to head. X 3. They may be concatenated. X However: X 1. All list insertions and removals must specify the head of the X list. X 2. Each head entry requires two pointers rather than one. X 3. Code size is about 15% greater and operations run about 20% X slower than singly-linked lists. X X In the macro definitions, TYPE is the name of a user defined structure, X that must contain a field of type SLIST_ENTRY, STAILQ_ENTRY, LIST_ENTRY, X or TAILQ_ENTRY, named NAME. The argument HEADNAME is the name of a user X defined structure that must be declared using the macros SLIST_HEAD, X STAILQ_HEAD, LIST_HEAD, or TAILQ_HEAD. See the examples below for fur- X ther explanation of how these macros are used. X X[NEW] X Shared memory lists and tail queues are for use in memory shared X by multiple processes. Macros designed for this case begin with the X prefix 'SH_' and store offset information rather than pointers. X Addresses of elements are calculated at time of access by the macros X provided and are relative to the callers address space. This allows X a processes to use shared memory functions to map lists or tail X queues into memory at locations that may not be consistent with the X other processes doing the same. X X All the rules regarding the access patterns of offset based X lists and tail queues are identical to the pointer based macros. X X The API is largely identical to the non-shared memory lists and X tail queues, with the exception that in some cases an additional X TYPE argument is needed. X XSINGLY-LINKED LISTS X A singly-linked list is headed by a structure defined by the SLIST_HEAD X macro. This structure contains a single pointer to the first element on X the list. The elements are singly linked for minimum space and pointer X manipulation overhead at the expense of O(n) removal for arbitrary ele- X ments. New elements can be added to the list after an existing element X or at the head of the list. An SLIST_HEAD structure is declared as fol- X lows: X X SLIST_HEAD(HEADNAME, TYPE) head; X X where HEADNAME is the name of the structure to be defined, and TYPE is X the type of the elements to be linked into the list. A pointer to the X head of the list can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro SLIST_HEAD_INITIALIZER evaluates to an initializer for the list X head. X X The macro SLIST_EMPTY evaluates to true if there are no elements in the X list. X X The macro SLIST_ENTRY declares a structure that connects the elements in X the list. X X The macro SLIST_FIRST returns the first element in the list or NULL if X the list is empty. X X The macro SLIST_FOREACH traverses the list referenced by head in the for- X ward direction, assigning each element in turn to var. X X The macro SLIST_INIT initializes the list referenced by head. X X The macro SLIST_INSERT_HEAD inserts the new element elm at the head of X the list. X X The macro SLIST_INSERT_AFTER inserts the new element elm after the ele- X ment listelm. X X The macro SLIST_NEXT returns the next element in the list. X X The macro SLIST_REMOVE_HEAD removes the element elm from the head of the X list. For optimum efficiency, elements being removed from the head of X the list should explicitly use this macro instead of the generic X SLIST_REMOVE macro. X X The macro SLIST_REMOVE removes the element elm from the list. X XSINGLY-LINKED LIST EXAMPLE X SLIST_HEAD(slisthead, entry) head = X SLIST_HEAD_INITIALIZER(head); X struct slisthead *headp; /* Singly-linked List head. */ X struct entry { X ... X SLIST_ENTRY(entry) entries; /* Singly-linked List. */ X ... X } *n1, *n2, *n3, *np; X SLIST_INIT(&head); /* Initialize the list. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X SLIST_INSERT_HEAD(&head, n1, entries); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X SLIST_INSERT_AFTER(n1, n2, entries); X SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */ X free(n2); X n3 = SLIST_FIRST(&head); X SLIST_REMOVE_HEAD(&head, entries); /* Deletion from the head. */ X free(n3); X /* Forward traversal. */ X SLIST_FOREACH(np, &head, entries) X np-> ... X while (!SLIST_EMPTY(&head)) { /* List Deletion. */ X n1 = SLIST_FIRST(&head); X SLIST_REMOVE_HEAD(&head, entries); X free(n1); X } X XSINGLY-LINKED TAIL QUEUES X A singly-linked tail queue is headed by a structure defined by the X STAILQ_HEAD macro. This structure contains a pair of pointers, one to X the first element in the tail queue and the other to the last element in X the tail queue. The elements are singly linked for minimum space and X pointer manipulation overhead at the expense of O(n) removal for arbi- X trary elements. New elements can be added to the tail queue after an X existing element, at the head of the tail queue, or at the end of the X tail queue. A STAILQ_HEAD structure is declared as follows: X X STAILQ_HEAD(HEADNAME, TYPE) head; X X where HEADNAME is the name of the structure to be defined, and TYPE is X the type of the elements to be linked into the tail queue. A pointer to X the head of the tail queue can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro STAILQ_HEAD_INITIALIZER evaluates to an initializer for the X tail queue head. X X The macro STAILQ_CONCAT concatenates the tail queue headed by head2 onto X the end of the one headed by head1 removing all entries from the former. X X The macro STAILQ_EMPTY evaluates to true if there are no items on the X tail queue. X X The macro STAILQ_ENTRY declares a structure that connects the elements in X the tail queue. X X The macro STAILQ_FIRST returns the first item on the tail queue or NULL X if the tail queue is empty. X X The macro STAILQ_FOREACH traverses the tail queue referenced by head in X the forward direction, assigning each element in turn to var. X X The macro STAILQ_INIT initializes the tail queue referenced by head. X X The macro STAILQ_INSERT_HEAD inserts the new element elm at the head of X the tail queue. X X The macro STAILQ_INSERT_TAIL inserts the new element elm at the end of X the tail queue. X X The macro STAILQ_INSERT_AFTER inserts the new element elm after the ele- X ment listelm. X X The macro STAILQ_LAST returns the last item on the tail queue. If the X tail queue is empty the return value is undefined. X X The macro STAILQ_NEXT returns the next item on the tail queue, or NULL X this item is the last. X X The macro STAILQ_REMOVE_HEAD removes the element at the head of the tail X queue. For optimum efficiency, elements being removed from the head of X the tail queue should use this macro explicitly rather than the generic X STAILQ_REMOVE macro. X X The macro STAILQ_REMOVE removes the element elm from the tail queue. X XSINGLY-LINKED TAIL QUEUE EXAMPLE X STAILQ_HEAD(stailhead, entry) head = X STAILQ_HEAD_INITIALIZER(head); X struct stailhead *headp; /* Singly-linked tail queue head. */ X struct entry { X ... X STAILQ_ENTRY(entry) entries; /* Tail queue. */ X ... X } *n1, *n2, *n3, *np; X STAILQ_INIT(&head); /* Initialize the queue. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X STAILQ_INSERT_HEAD(&head, n1, entries); X n1 = malloc(sizeof(struct entry)); /* Insert at the tail. */ X STAILQ_INSERT_TAIL(&head, n1, entries); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X STAILQ_INSERT_AFTER(&head, n1, n2, entries); X /* Deletion. */ X STAILQ_REMOVE(&head, n2, entry, entries); X free(n2); X /* Deletion from the head. */ X n3 = STAILQ_FIRST(&head); X STAILQ_REMOVE_HEAD(&head, entries); X free(n3); X /* Forward traversal. */ X STAILQ_FOREACH(np, &head, entries) X np-> ... X /* TailQ Deletion. */ X while (!STAILQ_EMPTY(&head)) { X n1 = STAILQ_FIRST(&head); X STAILQ_REMOVE_HEAD(&head, entries); X free(n1); X } X /* Faster TailQ Deletion. */ X n1 = STAILQ_FIRST(&head); X while (n1 != NULL) { X n2 = STAILQ_NEXT(n1, entries); X free(n1); X n1 = n2; X } X STAILQ_INIT(&head); X XLISTS X A list is headed by a structure defined by the LIST_HEAD macro. This X structure contains a single pointer to the first element on the list. X The elements are doubly linked so that an arbitrary element can be X removed without traversing the list. New elements can be added to the X list after an existing element, before an existing element, or at the X head of the list. A LIST_HEAD structure is declared as follows: X X LIST_HEAD(HEADNAME, TYPE) head; X X where HEADNAME is the name of the structure to be defined, and TYPE is X the type of the elements to be linked into the list. A pointer to the X head of the list can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro LIST_HEAD_INITIALIZER evaluates to an initializer for the list X head. X X The macro LIST_EMPTY evaluates to true if their are no elements in the X list. X X The macro LIST_ENTRY declares a structure that connects the elements in X the list. X X The macro LIST_FIRST returns the first element in the list or NULL if the X list is empty. X X The macro LIST_FOREACH traverses the list referenced by head in the for- X ward direction, assigning each element in turn to var. X X The macro LIST_INIT initializes the list referenced by head. X X The macro LIST_INSERT_HEAD inserts the new element elm at the head of the X list. X X The macro LIST_INSERT_AFTER inserts the new element elm after the element X listelm. X X The macro LIST_INSERT_BEFORE inserts the new element elm before the ele- X ment listelm. X X The macro LIST_NEXT returns the next element in the list, or NULL if this X is the last. X X The macro LIST_REMOVE removes the element elm from the list. X XLIST EXAMPLE X LIST_HEAD(listhead, entry) head = X LIST_HEAD_INITIALIZER(head); X struct listhead *headp; /* List head. */ X struct entry { X ... X LIST_ENTRY(entry) entries; /* List. */ X ... X } *n1, *n2, *n3, *np; X LIST_INIT(&head); /* Initialize the list. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X LIST_INSERT_HEAD(&head, n1, entries); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X LIST_INSERT_AFTER(n1, n2, entries); X n3 = malloc(sizeof(struct entry)); /* Insert before. */ X LIST_INSERT_BEFORE(n2, n3, entries); X LIST_REMOVE(n2, entries); /* Deletion. */ X free(n2); X /* Forward traversal. */ X LIST_FOREACH(np, &head, entries) X np-> ... X while (!LIST_EMPTY(&head)) { /* List Deletion. */ X n1 = LIST_FIRST(&head); X LIST_REMOVE(n1, entries); X free(n1); X } X n1 = LIST_FIRST(&head); /* Faster List Deletion. */ X while (n1 != NULL) { X n2 = LIST_NEXT(n1, entries); X free(n1); X n1 = n2; X } X LIST_INIT(&head); X X[NEW] XSHARED MEMORY LISTS X A shared memory list is headed by a structure defined by the X SH_LIST_HEAD macro. This structure contains a single offset to X the first element on the list stored as a ssize_t representing the X distance in bytes from the location of the head structure in memory X to the first element in memory. X X As with the implementation of list, the elements are doubly linked X so that an arbitrary element can be removed without traversing the X list. New elements can be added to the list after an existing X element, before an existing element, or at the head of the list. X All elements store offsets, just as the list head does, rather than X addresses of neighboring elements. All operations on these X elements use the address of a element supplied by a caller to then X calculate the relative address of effected elements. As type X information is not stored within the head and each of the elements X items must be cast as appropriate when accessed. To accomplish X this some macros require an additional TYPE argument. A X SH_LIST_HEAD structure is declared as follows: X X SH_LIST_HEAD(HEADNAME) head; X X where HEADNAME is the name of the structure to be defined. A pointer X to the head of the list can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro SH_LIST_HEAD_INITIALIZER evaluates to an initializer for the X list head. X X The macro SH_LIST_EMPTY evaluates to true if their are no elements in X the list. X X The macro SH_LIST_ENTRY declares a structure that connects the elements X in the list. SH_LIST_ENTRY is a bit different than LIST_ENTRY in that X it takes no arguments and is used to insert the list next and prev X structures. This can be declared as: X X struct list_element { X ... X SH_LIST_ENTRY list_entries; X ... X }; X X (The names list_element and list_entries are user selectable.) X X The macro SH_LIST_FIRST returns the first element in the list or NULL X if the list is empty. X X The macro SH_LIST_FIRSTP is much like SH_LIST_FIRST except that it X does not first check for an empty list and may evaluate to an address X of no merit if the list is in fact empty. Use this macro only when X the list is not empty perhapes in conjunction with SH_LIST_EMPTY. X X The macro SH_LIST_FOREACH traverses the list referenced by head in X the forward direction, assigning each element in turn to var. X X The macro SH_LIST_INIT initializes the list referenced by head. X X The macro SH_LIST_INSERT_HEAD inserts the new element elm at the X head of the list. X X The macro SH_LIST_INSERT_AFTER inserts the new element elm after X the element listelm. X X The macro SH_LIST_INSERT_BEFORE inserts the new element elm before X the element listelm. X X The macro SH_LIST_NEXT returns the next element in the list, or NULL X if this is the last. X X The macro SH_LIST_NEXTP is much like SH_LIST_NEXT except that it X does not first check for the end of the list and may evaluate to an X address of no merit if listelm is last element. X X The macro SH_LIST_REMOVE removes the element elm from the list. X X The macro SH_LIST_REMOVE_HEAD removes the first element elm from X the list. X X XSHARED MEMORY SINGLY-LINKED LIST EXAMPLE X SH_LIST_HEAD(listhead) head = X SH_LIST_HEAD_INITIALIZER(head); X struct listhead *headp; /* List head. */ X struct entry { X ... X SH_LIST_ENTRY entries; /* List. */ X ... X } *n1, *n2, *n3, *np; X SH_LIST_INIT(&head); /* Initialize the list. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X SH_LIST_INSERT_HEAD(&head, n1, entries, entry); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X SH_LIST_INSERT_AFTER(n1, n2, entries, entry); X n3 = malloc(sizeof(struct entry)); /* Insert before. */ X SH_LIST_INSERT_BEFORE(n2, n3, entries, entry); X SH_LIST_REMOVE(n2, entries, entry); /* Deletion. */ X free(n2); X /* Forward traversal. */ X SH_LIST_FOREACH(np, &head, entries, entry) X np-> ... X while (!SH_LIST_EMPTY(&head)) { /* List Deletion. */ X n1 = SH_LIST_FIRST(&head, entry); X SH_LIST_REMOVE(n1, entries, entry); X free(n1); X } X n1 = SH_LIST_FIRST(&head, entry); /* Faster List Deletion. */ X while (n1 != NULL) { X n2 = SH_LIST_NEXT(n1, entries, entry); X free(n1); X n1 = n2; X } X SH_LIST_INIT(&head); X X XTAIL QUEUES X A tail queue is headed by a structure defined by the TAILQ_HEAD macro. X This structure contains a pair of pointers, one to the first element in X the tail queue and the other to the last element in the tail queue. The X elements are doubly linked so that an arbitrary element can be removed X without traversing the tail queue. New elements can be added to the tail X queue after an existing element, before an existing element, at the head X of the tail queue, or at the end of the tail queue. A TAILQ_HEAD struc- X ture is declared as follows: X X TAILQ_HEAD(HEADNAME, TYPE) head; X X where HEADNAME is the name of the structure to be defined, and TYPE is X the type of the elements to be linked into the tail queue. A pointer to X the head of the tail queue can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro TAILQ_HEAD_INITIALIZER evaluates to an initializer for the tail X queue head. X X The macro TAILQ_CONCAT concatenates the tail queue headed by head2 onto X the end of the one headed by head1 removing all entries from the former. X X The macro TAILQ_EMPTY evaluates to true if there are no items on the tail X queue. X X The macro TAILQ_ENTRY declares a structure that connects the elements in X the tail queue. X X The macro TAILQ_FIRST returns the first item on the tail queue or NULL if X the tail queue is empty. X X The macro TAILQ_FOREACH traverses the tail queue referenced by head in X the forward direction, assigning each element in turn to var. var is set X to NULL if the loop completes normally, or if there were no elements. X X The macro TAILQ_FOREACH_REVERSE traverses the tail queue referenced by X head in the reverse direction, assigning each element in turn to var. X X The macro TAILQ_INIT initializes the tail queue referenced by head. X X The macro TAILQ_INSERT_HEAD inserts the new element elm at the head of X the tail queue. X X The macro TAILQ_INSERT_TAIL inserts the new element elm at the end of the X tail queue. X X The macro TAILQ_INSERT_AFTER inserts the new element elm after the ele- X ment listelm. X X The macro TAILQ_INSERT_BEFORE inserts the new element elm before the ele- X ment listelm. X X The macro TAILQ_LAST returns the last item on the tail queue. If the X tail queue is empty the return value is undefined. X X The macro TAILQ_NEXT returns the next item on the tail queue, or NULL if X this item is the last. X X The macro TAILQ_PREV returns the previous item on the tail queue, or NULL X if this item is the first. X X The macro TAILQ_REMOVE removes the element elm from the tail queue. X XTAIL QUEUE EXAMPLE X TAILQ_HEAD(tailhead, entry) head = X TAILQ_HEAD_INITIALIZER(head); X struct tailhead *headp; /* Tail queue head. */ X struct entry { X ... X TAILQ_ENTRY(entry) entries; /* Tail queue. */ X ... X } *n1, *n2, *n3, *np; X TAILQ_INIT(&head); /* Initialize the queue. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X TAILQ_INSERT_HEAD(&head, n1, entries); X n1 = malloc(sizeof(struct entry)); /* Insert at the tail. */ X TAILQ_INSERT_TAIL(&head, n1, entries); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X TAILQ_INSERT_AFTER(&head, n1, n2, entries); X n3 = malloc(sizeof(struct entry)); /* Insert before. */ X TAILQ_INSERT_BEFORE(n2, n3, entries); X TAILQ_REMOVE(&head, n2, entries); /* Deletion. */ X free(n2); X /* Forward traversal. */ X TAILQ_FOREACH(np, &head, entries) X np-> ... X /* Reverse traversal. */ X TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries) X np-> ... X /* TailQ Deletion. */ X while (!TAILQ_EMPTY(&head)) { X n1 = TAILQ_FIRST(&head); X TAILQ_REMOVE(&head, n1, entries); X free(n1); X } X /* Faster TailQ Deletion. */ X n1 = TAILQ_FIRST(&head); X while (n1 != NULL) { X n2 = TAILQ_NEXT(n1, entries); X free(n1); X n1 = n2; X } X TAILQ_INIT(&head); X X[NEW] XSHARED MEMORY TAIL QUEUES X A shared memory tail queue is headed by a structure defined by the X SH_TAILQ_HEAD macro. This structure containst a pair of offsets, X one to the first element in the tail queue and the other to the last X element in the tail queue. X X The elements are doubly linked so that an arbitrary element can be X removed without traversing the tail queue. New elements can be X added to the tail queue after an existing element, before an X existing element, at the head or the end of the tail queue. All X elements store offsets, rather than addresses of neighboring X elements. All operations on these elements use the address of a X element supplied by a caller to then calculate the relative address X of effected elements. As type information is not stored within X the head and each of the elements items must be cast as appropreate X when accessed. To accomplish this some macros require an X additional TYPE argument. A SH_TAILQ_HEAD structure is declared X as follows: X X SH_TAILQ_HEAD(HEADNAME) head; X X where HEADNAME is the name of the structure to be defined. A pointer X to the head of the tail queue can later be declared as: X X struct HEADNAME *headp; X X (The names head and headp are user selectable.) X X The macro SH_TAILQ_HEAD_INITIALIZER evaluates to an initializer for the X tail queue head. X X The macro SH_TAILQ_EMPTY evaluates to true if their are no elements in X the tail queue. X X The macro SH_TAILQ_ENTRY declares a structure that connects the elements X in the tail queue. SH_TAILQ_ENTRY is a bit different than TAILQ_ENTRY in X that it takes no arguments and is used to insert the tail queue next and X prev structures. This can be declared as: X X struct list_element { X ... X SH_TAILQ_ENTRY list_entries; X ... X }; X X (The names list_element and list_entries are user selectable.) X X The macro SH_TAILQ_FIRST returns the first element in the tail queue or X NULL if the tailq is empty. X X The macro SH_TAILQ_FIRSTP is much like SH_TAILQ_FIRST except that it X does not first check for an empty tailq and may evaluate to an address X of no merit if the tailq is in fact empty. Use this macro only when X the tailq is not empty perhapes in conjunction with SH_TAILQ_EMPTY. X X The macro SH_TAILQ_FOREACH traverses the tailq referenced by head in X the forward direction, assigning each element in turn to var. X X The macro SH_TAILQ_FOREACH_REVERSE traverses the tailq referenced by X head in the reverse direction, assigning each element in turn to var. X X The macro SH_TAILQ_INIT initializes the tail queue referenced by head. X X The macro SH_TAILQ_INSERT_HEAD inserts the new element elm at the X head of the tail queue. X X The macro SH_TAILQ_INSERT_AFTER inserts the new element elm after X the element listelm. X X The macro SH_TAILQ_INSERT_BEFORE inserts the new element elm before X the element listelm. X X The macro SH_TAILQ_NEXT returns the next element in the tail queue, X or NULL if this is the last. X X The macro SH_TAILQ_NEXTP is much like SH_TAILQ_NEXT except that it X does not first check for the end of the tail queue and may evaluate to X an address of no merit if listelm is last element. X X The macro SH_TAILQ_LAST returns the last element in the tail queue, or X NULL if this is the last. X X The macro SH_TAILQ_PREV returns the previous element in the tail queue, X or NULL if this is the last. X X The macro SH_TAILQ_REMOVE removes the element elm from the tailq. X X The macro SH_TAILQ_REMOVE_HEAD removes the first element elm from X the tailq. X X XSHARED MEMORY SINGLY-LINKED TAILQ EXAMPLE X SH_TAILQ_HEAD(listhead) head = X SH_TAILQ_HEAD_INITIALIZER(head); X struct listhead *headp; /* Tailq head. */ X struct entry { X ... X SH_TAILQ_ENTRY entries; /* Tailq. */ X ... X } *n1, *n2, *n3, *np; X SH_TAILQ_INIT(&head); /* Initialize the tailq. */ X n1 = malloc(sizeof(struct entry)); /* Insert at the head. */ X SH_TAILQ_INSERT_HEAD(&head, n1, entries, entry); X n2 = malloc(sizeof(struct entry)); /* Insert after. */ X SH_TAILQ_INSERT_AFTER(n1, n2, entries, entry); X n3 = malloc(sizeof(struct entry)); /* Insert before. */ X SH_TAILQ_INSERT_BEFORE(n2, n3, entries, entry); X SH_TAILQ_REMOVE(n2, entries, entry); /* Deletion. */ X free(n2); X /* Forward traversal. */ X SH_TAILQ_FOREACH(np, &head, entries, entry) X np-> ... X while (!SH_TAILQ_EMPTY(&head)) { /* Tailq Deletion. */ X n1 = SH_TAILQ_FIRST(&head, entry); X SH_TAILQ_REMOVE(n1, entries, entry); X free(n1); X } X n1 = SH_TAILQ_FIRST(&head, entry); /* Faster Tailq Deletion. */ X while (n1 != NULL) { X n2 = SH_TAILQ_NEXT(n1, entries, entry); X free(n1); X n1 = n2; X } X SH_TAILQ_INIT(&head); X X XHISTORY X The queue functions first appeared in 4.4BSD. X XBSD January 24, 1994 BSD END-of-queue.3.txt echo x - shqueue.h sed 's/^X//' >shqueue.h << 'END-of-shqueue.h' X/*- X * Copyright (c) 1996-2002 X * Sleepycat Software. All rights reserved. X * X * $Id: shqueue.h,v 11.11 2002/10/17 15:05:04 gburd Exp $ X */ X X#ifndef _SYS_SHQUEUE_H_ X#define _SYS_SHQUEUE_H_ X X/* X * This file defines two types of data structures: lists and tail queues X * similarly to the include file . X * X * The difference is that this set of macros can be used for structures that X * reside in shared memory that may be mapped at different addresses in each X * process. In most cases, the macros for shared structures exactly mirror X * the normal macros, although the macro calls require an additional type X * parameter, only used by the HEAD and ENTRY macros of the standard macros. X * X * Since we use relative offsets of type ssize_t rather than pointers, 0 X * (aka NULL) is a valid offset and cannot be used to indicate the end X * of a list. Therefore, we use -1 to indicate end of list. X * X * The macros ending in "P" return pointers without checking for end or X * beginning of lists, the others check for end of list and evaluate to X * either a pointer or NULL. X * X * For details on the use of these macros, see the queue(3) manual page. X */ X X#if defined(__cplusplus) Xextern "C" { X#endif X X/* X * Shared memory list definitions. X */ X#define SH_LIST_HEAD(name) \ Xstruct name { \ X ssize_t slh_first; /* first element */ \ X} X X#define SH_LIST_HEAD_INITIALIZER(head) \ X { -1 } X X#define SH_LIST_ENTRY \ Xstruct { \ X ssize_t sle_next; /* relative offset to next element */ \ X ssize_t sle_prev; /* relative offset of prev element */ \ X} X X/* X * Shared memory list functions. X */ X X#define SH_LIST_EMPTY(head) \ X ((head)->slh_first == -1) X X#define SH_LIST_FIRSTP(head, type) \ X ((struct type *)(((u_int8_t *)(head)) + (head)->slh_first)) X X#define SH_LIST_FIRST(head, type) \ X (SH_LIST_EMPTY(head) ? NULL : \ X ((struct type *)(((u_int8_t *)(head)) + (head)->slh_first))) X X#define SH_LIST_NEXTP(elm, field, type) \ X ((struct type *)(((u_int8_t *)(elm)) + (elm)->field.sle_next)) X X#define SH_LIST_NEXT(elm, field, type) \ X ((elm)->field.sle_next == -1 ? NULL : \ X ((struct type *)(((u_int8_t *)(elm)) + (elm)->field.sle_next))) X X /* X *__SH_LIST_PREV_OFF is private API. It calculates the address of X * the elm->field.sle_next member of a SH_LIST structure. All offsets X * between elements are relative to that point in SH_LIST structures. X */ X#define __SH_LIST_PREV_OFF(elm, field) \ X ((ssize_t *)(((u_int8_t *)(elm)) + (elm)->field.sle_prev)) X X#define SH_LIST_PREV(elm, field, type) \ X (struct type *)((ssize_t)elm - (*__SH_LIST_PREV_OFF(elm, field))) X X#define SH_LIST_FOREACH(var, head, field, type) \ X for ((var) = SH_LIST_FIRST((head), type); \ X (var); \ X (var) = SH_LIST_NEXT((var), field, type)) X X#define SH_PTR_TO_OFF(src, dest) \ X ((ssize_t)(((u_int8_t *)(dest)) - ((u_int8_t *)(src)))) X X/* X * Given correct A.next: B.prev = SH_LIST_NEXT_TO_PREV(A) X * in a list [A, B] X * The prev value is always the offset from an element to its preceeding X * element's next location, not the beginning of the structure. To get X * to the beginning of an element structure in memory given an element X * do the following: X * A = B - (B.prev + (&B.next - B)) X * Take the element's next pointer and calculate what the corresponding X * Prev pointer should be -- basically it is the negation plus the offset X * of the next field in the structure. X */ X#define SH_LIST_NEXT_TO_PREV(elm, field) \ X (((elm)->field.sle_next == -1 ? 0 : -(elm)->field.sle_next) + \ X SH_PTR_TO_OFF(elm, &(elm)->field.sle_next)) X X#define SH_LIST_INIT(head) (head)->slh_first = -1 X X#define SH_LIST_INSERT_BEFORE(head, listelm, elm, field, type) do { \ X if (listelm == SH_LIST_FIRST(head, type)) { \ X SH_LIST_INSERT_HEAD(head, elm, field, type); \ X } else { \ X (elm)->field.sle_next = SH_PTR_TO_OFF(elm, listelm); \ X (elm)->field.sle_prev = SH_LIST_NEXT_TO_PREV( \ X SH_LIST_PREV((listelm), field, type), field) + \ X (elm)->field.sle_next; \ X (SH_LIST_PREV(listelm, field, type))->field.sle_next = \ X (SH_PTR_TO_OFF((SH_LIST_PREV(listelm, field, \ X type)), elm)); \ X (listelm)->field.sle_prev = SH_LIST_NEXT_TO_PREV(elm, field); \ X } \ X} while (0) X X#define SH_LIST_INSERT_AFTER(listelm, elm, field, type) do { \ X if ((listelm)->field.sle_next != -1) { \ X (elm)->field.sle_next = SH_PTR_TO_OFF(elm, \ X SH_LIST_NEXTP(listelm, field, type)); \ X SH_LIST_NEXTP(listelm, field, type)->field.sle_prev = \ X SH_LIST_NEXT_TO_PREV(elm, field); \ X } else \ X (elm)->field.sle_next = -1; \ X (listelm)->field.sle_next = SH_PTR_TO_OFF(listelm, elm); \ X (elm)->field.sle_prev = SH_LIST_NEXT_TO_PREV(listelm, field); \ X} while (0) X X#define SH_LIST_INSERT_HEAD(head, elm, field, type) do { \ X if ((head)->slh_first != -1) { \ X (elm)->field.sle_next = \ X (head)->slh_first - SH_PTR_TO_OFF(head, elm); \ X SH_LIST_FIRSTP(head, type)->field.sle_prev = \ X SH_LIST_NEXT_TO_PREV(elm, field); \ X } else \ X (elm)->field.sle_next = -1; \ X (head)->slh_first = SH_PTR_TO_OFF(head, elm); \ X (elm)->field.sle_prev = SH_PTR_TO_OFF(elm, &(head)->slh_first); \ X} while (0) X X#define SH_LIST_REMOVE(elm, field, type) do { \ X if ((elm)->field.sle_next != -1) { \ X SH_LIST_NEXTP(elm, field, type)->field.sle_prev = \ X (elm)->field.sle_prev - (elm)->field.sle_next; \ X *__SH_LIST_PREV_OFF(elm, field) += (elm)->field.sle_next;\ X } else \ X *__SH_LIST_PREV_OFF(elm, field) = -1; \ X} while (0) X X#define SH_LIST_REMOVE_HEAD(head, field, type) do { \ X if (!SH_LIST_EMPTY(head)) { \ X SH_LIST_REMOVE(SH_LIST_FIRSTP(head, type), field, type);\ X } \ X} while (0) X X/* X * Shared memory tail queue definitions. X */ X#define SH_TAILQ_HEAD(name) \ Xstruct name { \ X ssize_t stqh_first; /* relative offset of first element */ \ X ssize_t stqh_last; /* relative offset of last's next */ \ X} X X#define SH_TAILQ_HEAD_INITIALIZER(head) \ X { -1, 0 } X X#define SH_TAILQ_ENTRY \ Xstruct { \ X ssize_t stqe_next; /* relative offset of next element */ \ X ssize_t stqe_prev; /* relative offset of prev's next */ \ X} X X/* X * Shared memory tail queue functions. X */ X X#define SH_TAILQ_EMPTY(head) \ X ((head)->stqh_first == -1) X X#define SH_TAILQ_FIRSTP(head, type) \ X ((struct type *)((u_int8_t *)(head) + (head)->stqh_first)) X X#define SH_TAILQ_FIRST(head, type) \ X (SH_TAILQ_EMPTY(head) ? NULL : SH_TAILQ_FIRSTP(head, type)) X X#define SH_TAILQ_NEXTP(elm, field, type) \ X ((struct type *)((u_int8_t *)(elm) + (elm)->field.stqe_next)) X X#define SH_TAILQ_NEXT(elm, field, type) \ X ((elm)->field.stqe_next == -1 ? NULL : \ X ((struct type *)((u_int8_t *)(elm) + (elm)->field.stqe_next))) X X /* X * __SH_TAILQ_PREV_OFF is private API. It calculates the address of X * the elm->field.stqe_next member of a SH_TAILQ structure. All X * offsets between elements are relative to that point in SH_TAILQ X * structures. X */ X#define __SH_TAILQ_PREV_OFF(elm, field) \ X ((ssize_t *)(((u_int8_t *)(elm)) + (elm)->field.stqe_prev)) X X#define SH_TAILQ_PREVP(elm, field, type) \ X (struct type *)((ssize_t)elm - (*__SH_TAILQ_PREV_OFF(elm, field))) X X#define SH_TAILQ_PREV(head, elm, field, type) \ X (((elm) == SH_TAILQ_FIRST(head, type)) ? NULL : \ X (struct type *)((ssize_t)elm - (*__SH_TAILQ_PREV_OFF(elm, field)))) X X /* X * __SH_TAILQ_LAST_OFF is private API. It calculates the address of X * the stqe_next member of a SH_TAILQ structure in the last element X * of this list. All offsets between elements are relative to that X * point in SH_TAILQ structures. X */ X#define __SH_TAILQ_LAST_OFF(head) \ X ((ssize_t *)(((u_int8_t *)(head)) + (head)->stqh_last)) X X#define SH_TAILQ_LAST(head, field, type) \ X (SH_TAILQ_EMPTY(head) ? NULL : \ X (struct type *)((ssize_t)(head) + \ X ((ssize_t)((head)->stqh_last) - \ X ((ssize_t)SH_PTR_TO_OFF(SH_TAILQ_FIRST(head, type), \ X &(SH_TAILQ_FIRST(head, type)->field.stqe_next)))))) X X/* X * Given correct A.next: B.prev = SH_TAILQ_NEXT_TO_PREV(A) X * in a list [A, B] X * The prev value is always the offset from an element to its preceeding X * element's next location, not the beginning of the structure. To get X * to the beginning of an element structure in memory given an element X * do the following: X * A = B - (B.prev + (&B.next - B)) X */ X#define SH_TAILQ_NEXT_TO_PREV(elm, field) \ X (((elm)->field.stqe_next == -1 ? 0 : \ X (-(elm)->field.stqe_next) + \ X SH_PTR_TO_OFF(elm, &(elm)->field.stqe_next))) X X#define SH_TAILQ_FOREACH(var, head, field, type) \ X for ((var) = SH_TAILQ_FIRST((head), type); \ X (var); \ X (var) = SH_TAILQ_NEXT((var), field, type)) X X#define SH_TAILQ_FOREACH_REVERSE(var, head, field, type) \ X for ((var) = SH_TAILQ_LAST((head), field, type); \ X (var); \ X (var) = SH_TAILQ_PREV((head), (var), field, type)) X X#define SH_TAILQ_INIT(head) { \ X (head)->stqh_first = -1; \ X (head)->stqh_last = SH_PTR_TO_OFF(head, &(head)->stqh_first); \ X} X X#define SH_TAILQ_INSERT_HEAD(head, elm, field, type) do { \ X if ((head)->stqh_first != -1) { \ X (elm)->field.stqe_next = \ X (head)->stqh_first - SH_PTR_TO_OFF(head, elm); \ X SH_TAILQ_FIRSTP(head, type)->field.stqe_prev = \ X SH_TAILQ_NEXT_TO_PREV(elm, field); \ X } else { \ X (head)->stqh_last = \ X SH_PTR_TO_OFF(head, &(elm)->field.stqe_next); \ X (elm)->field.stqe_next = -1; \ X } \ X (head)->stqh_first = SH_PTR_TO_OFF(head, elm); \ X (elm)->field.stqe_prev = \ X SH_PTR_TO_OFF(elm, &(head)->stqh_first); \ X} while (0) X X#define SH_TAILQ_INSERT_TAIL(head, elm, field) do { \ X (elm)->field.stqe_next = -1; \ X (elm)->field.stqe_prev = \ X -SH_PTR_TO_OFF(head, elm) + (head)->stqh_last; \ X if ((head)->stqh_last == \ X SH_PTR_TO_OFF((head), &(head)->stqh_first)) \ X (head)->stqh_first = SH_PTR_TO_OFF(head, elm); \ X else \ X *__SH_TAILQ_LAST_OFF(head) = -(head)->stqh_last + \ X SH_PTR_TO_OFF((elm), &(elm)->field.stqe_next) + \ X SH_PTR_TO_OFF(head, elm); \ X (head)->stqh_last = \ X SH_PTR_TO_OFF(head, &((elm)->field.stqe_next)); \ X} while (0) X X#define SH_TAILQ_INSERT_BEFORE(head, listelm, elm, field, type) do { \ X if (listelm == SH_TAILQ_FIRST(head, type)) { \ X SH_TAILQ_INSERT_HEAD(head, elm, field, type); \ X } else { \ X (elm)->field.stqe_next = SH_PTR_TO_OFF(elm, listelm); \ X (elm)->field.stqe_prev = SH_TAILQ_NEXT_TO_PREV( \ X SH_TAILQ_PREVP((listelm), field, type), field) + \ X (elm)->field.stqe_next; \ X (SH_TAILQ_PREVP(listelm, field, type))->field.stqe_next =\ X (SH_PTR_TO_OFF((SH_TAILQ_PREVP(listelm, field, type)), \ X elm)); \ X (listelm)->field.stqe_prev = \ X SH_TAILQ_NEXT_TO_PREV(elm, field); \ X } \ X} while (0) X X#define SH_TAILQ_INSERT_AFTER(head, listelm, elm, field, type) do { \ X if ((listelm)->field.stqe_next != -1) { \ X (elm)->field.stqe_next = (listelm)->field.stqe_next - \ X SH_PTR_TO_OFF(listelm, elm); \ X SH_TAILQ_NEXTP(listelm, field, type)->field.stqe_prev = \ X SH_TAILQ_NEXT_TO_PREV(elm, field); \ X } else { \ X (elm)->field.stqe_next = -1; \ X (head)->stqh_last = \ X SH_PTR_TO_OFF(head, &elm->field.stqe_next); \ X } \ X (listelm)->field.stqe_next = SH_PTR_TO_OFF(listelm, elm); \ X (elm)->field.stqe_prev = SH_TAILQ_NEXT_TO_PREV(listelm, field); \ X} while (0) X X#define SH_TAILQ_REMOVE(head, elm, field, type) do { \ X if ((elm)->field.stqe_next != -1) { \ X SH_TAILQ_NEXTP(elm, field, type)->field.stqe_prev = \ X (elm)->field.stqe_prev + \ X SH_PTR_TO_OFF(SH_TAILQ_NEXTP(elm, \ X field, type), elm); \ X *__SH_TAILQ_PREV_OFF(elm, field) += elm->field.stqe_next;\ X } else { \ X (head)->stqh_last = (elm)->field.stqe_prev + \ X SH_PTR_TO_OFF(head, elm); \ X *__SH_TAILQ_PREV_OFF(elm, field) = -1; \ X } \ X} while (0) X X#if defined(__cplusplus) X} X#endif X#endif /* !_SYS_SHQUEUE_H_ */ END-of-shqueue.h exit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 10 19:43:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01D8037B401 for ; Sun, 10 Nov 2002 19:43:58 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD19F43E91 for ; Sun, 10 Nov 2002 19:43:57 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A333EAE313; Sun, 10 Nov 2002 19:43:57 -0800 (PST) Date: Sun, 10 Nov 2002 19:43:57 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: arch@freebsd.org, Keith Bostic Subject: Re: Shared-memory version of macros Message-ID: <20021111034357.GC39178@elvis.mu.org> References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211101732.gAAHWZ59035339@beastie.mckusick.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Kirk McKusick [021110 17:29] wrote: > I am proposing to add a new version of the macros that > are designed to work in shared memory. The man page and actual macros It seems a like a very useful addition, I've not seen anything else freely available to accomplish the same thing. Dr. McKusick, if you have an "in" with any of the standards bodies it would be really, _Really_, _REALLY_ nice to see some form of the BSD queue macros become part of the standard such that they will be named and behave consitantly across Unix/all platforms. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 10 20:17:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2073837B401 for ; Sun, 10 Nov 2002 20:17:25 -0800 (PST) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id A885943E6E for ; Sun, 10 Nov 2002 20:17:24 -0800 (PST) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id EA1419BC3; Sun, 10 Nov 2002 23:08:34 -0500 (EST) Date: Sun, 10 Nov 2002 23:08:34 -0500 From: Mike Barcroft To: Alfred Perlstein Cc: Kirk McKusick , arch@freebsd.org, Keith Bostic Subject: Re: Shared-memory version of macros Message-ID: <20021110230834.D52940@espresso.q9media.com> References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> <20021111034357.GC39178@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021111034357.GC39178@elvis.mu.org>; from bright@mu.org on Sun, Nov 10, 2002 at 07:43:57PM -0800 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein writes: > * Kirk McKusick [021110 17:29] wrote: > > I am proposing to add a new version of the macros that > > are designed to work in shared memory. The man page and actual macros > > It seems a like a very useful addition, I've not seen anything > else freely available to accomplish the same thing. > > Dr. McKusick, if you have an "in" with any of the standards bodies > it would be really, _Really_, _REALLY_ nice to see some form of > the BSD queue macros become part of the standard such that they > will be named and behave consitantly across Unix/all platforms. You'll have to wait about 4 years to propose it for inclusion in the next POSIX revision. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 10 20:20:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C022837B401 for ; Sun, 10 Nov 2002 20:20:30 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C1B843E88 for ; Sun, 10 Nov 2002 20:20:30 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id gAB4KTen047756 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 10 Nov 2002 23:20:29 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id gAB4KQWN047755; Sun, 10 Nov 2002 23:20:26 -0500 (EST) (envelope-from wollman) Date: Sun, 10 Nov 2002 23:20:26 -0500 (EST) From: Garrett Wollman Message-Id: <200211110420.gAB4KQWN047755@khavrinen.lcs.mit.edu> To: bright@mu.org Subject: Re: Shared-memory version of macros X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20021111034357.GC39178@elvis.mu.org> References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20021111034357.GC39178@elvis.mu.org> you write: >Dr. McKusick, if you have an "in" with any of the standards bodies >it would be really, _Really_, _REALLY_ nice to see some form of >the BSD queue macros become part of the standard such that they >will be named and behave consitantly across Unix/all platforms. Extraordinarily unlikely to happen. My guess (having just spoken with Kirk about some standards-related issues) is that he's probably not involved in the standards process right now. My own feeling is that this sort of interface is not one which would be standardized by any of the usual suspects (ANSI X3J11, IEEE P1003.1, or The Open Group) as it (except for these new macros) can be implemented entirely in Strictly Conforming C, so there is no reason applications could not supply it at need. Generally speaking, the standards bodies prefer to adopt only those interfaces which are either universal or meet a particular unmet need which is impossible to implement without help from The Implementation. (This is a marked contrast to ANSI X3J16, the C++ committee, which seems never to have seen an interface it didn't like.) -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 0:16:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5673037B401 for ; Mon, 11 Nov 2002 00:16:46 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7857D43E7B for ; Mon, 11 Nov 2002 00:16:45 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gAB8GJOr050081; Mon, 11 Nov 2002 09:16:19 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick Cc: arch@FreeBSD.ORG, bostic@sleepycat.com (Keith Bostic) Subject: Re: Shared-memory version of macros In-Reply-To: Your message of "Sun, 10 Nov 2002 09:32:35 PST." <200211101732.gAAHWZ59035339@beastie.mckusick.com> Date: Mon, 11 Nov 2002 09:16:19 +0100 Message-ID: <50080.1037002579@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200211101732.gAAHWZ59035339@beastie.mckusick.com>, Kirk McKusick wr ites: >I am proposing to add a new version of the macros that >are designed to work in shared memory. Sounds useful. There is one thing about sys/queue I don't like: #define SLIST_HEAD(name, type) \ struct name { \ struct type *slh_first; /* first element */ \ } In fact I positively hate this because a grep for "struct[ \t]*foobar" fails to trigger on SLIST_HEAD(foobarhead, foobar); I would really like to see that fixed. As for various standards groups standarizing this or not, I would say that it doesn't surprise me that they don't: It would be useful if they did. By not standardizing it, they make sure that we have a mix of autoconf crap and incompatible rotting versions all over the place, something which is sure to generate more need for standardization work. :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 1:16:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA3B637B401 for ; Mon, 11 Nov 2002 01:16:19 -0800 (PST) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4A743E6E for ; Mon, 11 Nov 2002 01:16:18 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18BAfy-0000EI-00; Mon, 11 Nov 2002 12:16:10 +0300 Subject: Re: NO_WERROR and the kernel From: "Vladimir B. " Grebenschikov To: Bill Fenner Cc: imp@bsdimp.com, arch@FreeBSD.ORG In-Reply-To: <200210262214.PAA12021@windsor.research.att.com> References: <200210262214.PAA12021@windsor.research.att.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Inc. Message-Id: <1037006168.686.6.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 11 Nov 2002 12:16:09 +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =F7 Sun, 27.10.2002, =D7 02:14, Bill Fenner =CE=C1=D0=C9=D3=C1=CC: > That patch adds pretty much exactly what >=20 > | Revision 1.16 / Mon Jul 22 00:15:01 2002 UTC (3 months ago) by peter=20 > | Changes since 1.15: +0 -5 lines > |=20 > | The transition time for -Werror has been gone for a while. We are now > | sufficiently clean that we can fix any new problems or mark individual > | files as not being ready for -Werror. >=20 > removed. I think that it was to handle the case where people still had > NO_WERROR for userland but the kernel was warning-free and wanted to stay > that way. Is LINT now Werror proof ? I have found that=20 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=3Dcp850 make a lot of warnings, and can't be compiled with -Werror. > Bill --=20 Vladimir B. Grebenschikov SWsoft Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 8:13: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F109C37B401 for ; Mon, 11 Nov 2002 08:13:00 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A4BC43E4A for ; Mon, 11 Nov 2002 08:13:00 -0800 (PST) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 9C64B1E1F3; Mon, 11 Nov 2002 11:12:54 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA00907; Mon, 11 Nov 2002 11:12:54 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA08086; Mon, 11 Nov 2002 08:12:53 -0800 (PST) Message-Id: <200211111612.IAA08086@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vova@sw.ru Subject: Re: NO_WERROR and the kernel Cc: arch@FreeBSD.ORG References: <200210262214.PAA12021@windsor.research.att.com> <1037006168.686.6.camel@vbook> Date: Mon, 11 Nov 2002 08:12:52 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Is LINT now Werror proof ? It presumably was in July (on i386), or Peter wouldn't have made the change that he did. It may have rotted since then, but the tinderbox is supposed to catch any regressions in that. >I have found that > >options SC_DFLT_FONT >makeoptions SC_DFLT_FONT=cp850 > >make a lot of warnings, and can't be compiled with -Werror. These aren't in LINT. You can build with -DWERROR=, or add "nowerror" to the files entry for the file that gets the warnings. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 8:18:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A00E37B401 for ; Mon, 11 Nov 2002 08:18:44 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AE2F43E6E for ; Mon, 11 Nov 2002 08:18:44 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id BDBC4AE165; Mon, 11 Nov 2002 08:18:34 -0800 (PST) Date: Mon, 11 Nov 2002 08:18:34 -0800 From: Maxime Henrion To: "Vladimir B. Grebenschikov" Cc: Bill Fenner , imp@bsdimp.com, arch@FreeBSD.ORG Subject: Re: NO_WERROR and the kernel Message-ID: <20021111161834.GZ26605@elvis.mu.org> References: <200210262214.PAA12021@windsor.research.att.com> <1037006168.686.6.camel@vbook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037006168.686.6.camel@vbook> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Vladimir B. Grebenschikov wrote: > ? Sun, 27.10.2002, ? 02:14, Bill Fenner ???????: > > That patch adds pretty much exactly what > > > > | Revision 1.16 / Mon Jul 22 00:15:01 2002 UTC (3 months ago) by peter > > | Changes since 1.15: +0 -5 lines > > | > > | The transition time for -Werror has been gone for a while. We are now > > | sufficiently clean that we can fix any new problems or mark individual > > | files as not being ready for -Werror. > > > > removed. I think that it was to handle the case where people still had > > NO_WERROR for userland but the kernel was warning-free and wanted to stay > > that way. > > Is LINT now Werror proof ? > > I have found that > > options SC_DFLT_FONT > makeoptions SC_DFLT_FONT=cp850 > > make a lot of warnings, and can't be compiled with -Werror. Could you give us the warning messages? It seems to work fine here. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 9:13:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D0637B401 for ; Mon, 11 Nov 2002 09:13:34 -0800 (PST) Received: from marvin.bsdng.org (24-159-234-52.jvl.wi.charter.com [24.159.234.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D1343E75 for ; Mon, 11 Nov 2002 09:13:33 -0800 (PST) (envelope-from mkm@marvin.bsdng.org) Received: from marvin.bsdng.org (marvin [127.0.0.1]) by marvin.bsdng.org (8.12.6/8.12.5) with ESMTP id gABHCZet015650; Mon, 11 Nov 2002 11:12:36 -0600 (CST) (envelope-from mkm@marvin.bsdng.org) Received: (from mkm@localhost) by marvin.bsdng.org (8.12.6/8.12.6/Submit) id gABHCZxh015649; Mon, 11 Nov 2002 11:12:35 -0600 (CST) Date: Mon, 11 Nov 2002 11:12:35 -0600 From: Kyle Martin To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: Shared-memory version of macros Message-ID: <20021111171235.GA15329@marvin.bsdng.org> References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> <20021111034357.GC39178@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021111034357.GC39178@elvis.mu.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Nov 10, 2002 at 07:43:57PM -0800, Alfred Perlstein wrote: > Dr. McKusick, if you have an "in" with any of the standards bodies > it would be really, _Really_, _REALLY_ nice to see some form of > the BSD queue macros become part of the standard such that they > will be named and behave consitantly across Unix/all platforms. its not that hard to get your "in", simply join the IEEE-SA, itll cost you about $35 iirc. then sign up to vote on the standards, joining PASC and proposing standards is free. -- Kyle Martin mkm@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 14: 7:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FD7D37B401 for ; Mon, 11 Nov 2002 14:07:32 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AD3A43E4A for ; Mon, 11 Nov 2002 14:07:31 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id gABM6aEs032582; Mon, 11 Nov 2002 17:06:37 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200211101732.gAAHWZ59035339@beastie.mckusick.com> References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> Date: Mon, 11 Nov 2002 17:06:35 -0500 To: Kirk McKusick , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Shared-memory version of macros Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:32 AM -0800 11/10/02, Kirk McKusick wrote: >Since these are not needed by the kernel, I propose to create a >new file /usr/include/queue.h which will contain the new shared >memory version of the queue macros and also include >to pull in the existing set of queue macros. The include of > is to avoid duplication and possible divergence >of the original macro set. Hmm. So, as a question of include-file naming, does "sys/" imply that it's tied to the system kernel in some sense? I mean, why would this imply "queue.h", while the earlier macros imply "sys/queue.h"? (I'm just wondering. Certainly the changes seem fine to me. But if I'm using the older macros in some userland program, should I reference or ? ) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 14:32: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B9CC37B401 for ; Mon, 11 Nov 2002 14:32:06 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A9F743E6E for ; Mon, 11 Nov 2002 14:32:05 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id gABMW459037409; Mon, 11 Nov 2002 14:32:04 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200211112232.gABMW459037409@beastie.mckusick.com> To: Garance A Drosihn Subject: Re: Shared-memory version of macros Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Mon, 11 Nov 2002 17:06:35 EST." Date: Mon, 11 Nov 2002 14:32:04 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Date: Mon, 11 Nov 2002 17:06:35 -0500 > To: Kirk McKusick , arch@FreeBSD.ORG > From: Garance A Drosihn > Subject: Re: Shared-memory version of macros > > At 9:32 AM -0800 11/10/02, Kirk McKusick wrote: > >Since these are not needed by the kernel, I propose to create a > >new file /usr/include/queue.h which will contain the new shared > >memory version of the queue macros and also include > >to pull in the existing set of queue macros. The include of > > is to avoid duplication and possible divergence > >of the original macro set. > > Hmm. So, as a question of include-file naming, does "sys/" imply > that it's tied to the system kernel in some sense? I mean, why > would this imply "queue.h", while the earlier macros imply > "sys/queue.h"? > > (I'm just wondering. Certainly the changes seem fine to me. But > if I'm using the older macros in some userland program, should I > reference or ? ) > > -- > Garance Alistair Drosehn = gad@gilead.netel.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu Historically /usr/include/sys was used to include files that provided headers that included interfaces between the kernel and userland. For example, describes that stat structure which is filled in by the kernel and used by userland applications. Since the queue macros do not describe any kernel/userland shared structures, they belong in /usr/include. They are much more like which describes purely userland structures like FILE *. However, we canot move from the /sys/sys directory as it is needed by the kernel (indeed was originally developed for the kernel) as there is another rule which says that the kernel headers need to be self contained (that is the kernel cannot depend on anything in /usr/include). So, there is the dilemma of duplicating the queue macros used in the kernel in a /usr/include file, or trying to avoid divergence by pulling in the kernel macros from /usr/include/sys. As for what userland applications should do, once exists, they should always use that file. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 11 15:44:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35A2737B401 for ; Mon, 11 Nov 2002 15:44:12 -0800 (PST) Received: from user-10cm7of.cable.mindspring.com (user-10cm7of.cable.mindspring.com [64.203.31.15]) by mx1.FreeBSD.org (Postfix) with SMTP id D384643E6E for ; Mon, 11 Nov 2002 15:44:04 -0800 (PST) (envelope-from wikne@bigfoot.com) Received: from genie.com (concentric.net [75.25.83.122]) by concentric.net (8.11.6/8.11.6) with ESMTP id 11267 for ; Mon, 11 Nov 2002 23:44:05 +0000 From: "fisherm" To: "" Subject: Bullet proof bulk email friendly hosting & cheap mass email campaigns. X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 Date: Mon, 11 Nov 2002 23:44:05 +0000 Message-ID: <106112592dufkCiuhhevg1ruj@delphi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We are the marketing specialists www.host4bulk.com that provide cheap bullet proof bulk email friendly hosting for your website ($400 for one month of bullet proof hosting) and cheap bulk email campaigns ($200 for 1 million emails sent) As you may already know, many web hosting companies have Terms of Service (TOS) or Acceptable Use Policies (AUP) against the delivery of emails advertising or promoting your web site. If your web site host receives complaints or discovers that your web site has been advertised in email broadcasts, they may disconnect your account and shut down your web site. Our mission is to solve your problem and provide you with bulk email friendly hosting. You don't have to worry about your website being closed again. Adult and gambling sites welcomed. No set up fee. You may advertise your website by using your own resources or using 3rd party's service. However we can do all the advertising for your business. You just sit, relax and see how your income grows constantly. We guarantee the lowest prices on the web for our web hosting and bulk email campaigns. We only ask $200 us dollars for 1 million emails sent with your ad. We don't use duplicate emails. Our email base is up to date and it is updated weekly. Our current email data base contains over 50.000.000 emails sorted by various parameters to meet your specific needs. No competitors may offer this price. The lowest price you can find on the net is well over $500 for 1 million Don't make the mistake of bulk emailing directly to your website without bulletproof web hosting. Your web host will close your account and shut your site down in no time! No matter how long you have been with them, how much you are paying them, or how beautiful your site is. There are companies charging thousands for bulletproof web hosting and they can't keep you up and running like we can. If you host with us, your site will NOT BE SHUT DOWN due to complaints! Bulk email campaign together with bullet proof hosting will bring your business to success. Just imagine how many people will learn about your business or product at a really low price. Bulk email is considered to be the most effective way to advertise on the net. It is hundreds times effective than banner, solo ad and other campaigns. Once people use our service they always come back for more. We can always provide websites that use bulk email campaigns with our new reliable way to accept credit cards on the net without the need to open merchant account. You can start accepting credit card payments in second. It is totally free. Visit our website at http://www.host4bulk.com for more information and to order your bulk email hosting or/and email campaign. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 3:17:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CC2337B494; Tue, 12 Nov 2002 03:17:26 -0800 (PST) Received: from mail4.caramail.com (mail4.caramail.com [213.193.13.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4EF043E75; Tue, 12 Nov 2002 03:17:25 -0800 (PST) (envelope-from kseseko@caramail.com) Received: from caramail.com (www14.caramail.com [213.193.13.24]) by mail4.caramail.com (Postfix) with SMTP id 2B88B154F1; Tue, 12 Nov 2002 11:41:38 +0100 (MET) From: kseseko seko To: kseseko@caramail.com Message-ID: <1037097359002000@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [216.139.169.154] Mime-Version: 1.0 Subject: Greetings Date: Tue, 12 Nov 2002 11:35:59 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0020001037097359_ID" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0020001037097359_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Kuzo M. Seseko Alternative Email Address: suun4us@yahoo.com My name is Kuzo Mobutu Seseko, the daughter of the late President of Republic of Zaire, now living in exile in South Africa. The circumstances that led to my living in South Africa at the moment cannot be new to you , I know you must know the history of my family. However , during the days of my father=92s reign we were into solid minerals exploration and mining which was the soul base of our family business, mostly diamond and gold. But unfortunately, before my father passed on, he was on exile in Europe which made it impossible for us to organize our businesses especially mining before the political hostility which saw him out of office began. Last year a security company in our country wrote me informing me of a deposit made by my father in my name which is still with them. I intended leaving the deposit with them sequel to my return home so that I can fall on that to start up a business ,but unfortunately, the rebel hostilities at home which have refused to stop up till this moment has made me to think otherwise. Hence I am considering asking the security company to transfer the sum to an oversea country with a stable economy and favorable political condition, so that I can find an indigenous business man / investor in that country to work with in partnership and invest this money. I know your country is an advanced democracy with a more stable economy than that of African countries. Hence I would want us to seek how to invest this sum agreeing on a working percentage.However due to my living status here in South Africa I would want you to keep this offer confidential. Get back to me suggesting what we are to do, while I will furnish you with my contact telephone numbers and fax in South Africa and that of my lawyers. I wish you strength. K. Seseko. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0020001037097359_ID-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 4: 1:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3DA237B401 for ; Tue, 12 Nov 2002 04:01:17 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A28443E4A for ; Tue, 12 Nov 2002 04:01:16 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id E6681534E; Tue, 12 Nov 2002 13:01:13 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Kirk McKusick Cc: arch@freebsd.org, bostic@sleepycat.com (Keith Bostic) Subject: Re: Shared-memory version of macros References: <200211101732.gAAHWZ59035339@beastie.mckusick.com> From: Dag-Erling Smorgrav Date: Tue, 12 Nov 2002 13:01:12 +0100 In-Reply-To: <200211101732.gAAHWZ59035339@beastie.mckusick.com> (Kirk McKusick's message of "Sun, 10 Nov 2002 09:32:35 -0800") Message-ID: Lines: 10 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kirk McKusick writes: > I am proposing to add a new version of the macros that > are designed to work in shared memory. The man page and actual macros > are included below. Terrific! I'm all for! DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 6:10:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 835A537B401 for ; Tue, 12 Nov 2002 06:10:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7D043E42 for ; Tue, 12 Nov 2002 06:10:25 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id gACE9mOo034525; Tue, 12 Nov 2002 09:09:48 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 12 Nov 2002 09:09:48 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Heffner Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 9 Nov 2002, Mike Heffner wrote: > Sorry to come in late on this discussion. I was originally one of the > people who was interested in the importing of lukemftpd and merging in > some of the FreeBSD'isms, etc.. Unfortunately, due to school and $ work > I haven't had the time necessary that I had hoped to devote to it. > However, as soon as I get a -current box together I plan to continue > where I left off with this. > > Yes, as many people have mentioned, Luke is more than willing to merge > in changes from FreeBSD to lukemftpd (take for example the many changes > to lukemftp that he accepted and then released a new version of). Luke > is typically very busy, but I've generally found that if a patch is > produced that is acceptable and doesn't require much time on his part to > integrate, he will merge it into lukemftp[d]. > > I plan to pick up the PRs that have been opened against it and remove > the ambiguities that lukemftpd is 'the ftpd'. I will also try to merge > as many of the critical aspects from ftpd as possible (eg, the > login.conf support) before 5.0-R. If anyone else has worked on any of > these, please let me know so that we can coordinate. You do realize that we're in a feature freeze right now, and will be in a code freeze within days, right? You're coming up a dollar short, and a day late. This is the reason I've trying to press for a resolution for weeks now. I'm deeply concerned that we've imported software without doing any of the necessary mergework and adaptation, and are now apparently planning to ship it. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 9: 1:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5AF337B401; Tue, 12 Nov 2002 09:01:36 -0800 (PST) Received: from mail2.qc.uunet.ca (mail2.qc.uunet.ca [198.168.54.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7138543E3B; Tue, 12 Nov 2002 09:01:32 -0800 (PST) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.studio.espresso-com.com ([216.94.147.57]) by mail2.qc.uunet.ca (8.9.3/8.9.3) with ESMTP id MAA12089; Tue, 12 Nov 2002 12:01:16 -0500 Received: from anarcat by xtanbul.studio.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 18BePR-0000AH-00; Tue, 12 Nov 2002 12:01:05 -0500 Date: Tue, 12 Nov 2002 12:01:05 -0500 From: The Anarcat To: Robert Watson Cc: Mike Heffner , Garance A Drosihn , arch@freebsd.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021112170102.GA32440@xtanbul.studio.espresso-com.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG How hard would it be to pull to plug on lukemftp[d] and (say) put it back in -ports, for now? On Tue Nov 12, 2002 at 09:09:48AM -0500, Robert Watson wrote: [...] > > You do realize that we're in a feature freeze right now, and will be in a > code freeze within days, right? You're coming up a dollar short, and a > day late. This is the reason I've trying to press for a resolution for > weeks now. I'm deeply concerned that we've imported software without > doing any of the necessary mergework and adaptation, and are now > apparently planning to ship it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 9:14:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EFD737B401 for ; Tue, 12 Nov 2002 09:14:48 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7732743E4A for ; Tue, 12 Nov 2002 09:14:47 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id gACHE4Oo042294; Tue, 12 Nov 2002 12:14:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 12 Nov 2002 12:14:03 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: The Anarcat Cc: Mike Heffner , Garance A Drosihn , arch@freebsd.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021112170102.GA32440@xtanbul.studio.espresso-com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 12 Nov 2002, The Anarcat wrote: > How hard would it be to pull to plug on lukemftp[d] and (say) put it > back in -ports, for now? At this point I see no reason to pull the plug on lukemftp; my concerns lie primarily with lukemftpd. From a purely technical perspective, it would be trivial to remove lukemftpd from the tree, or even from the build. The social engineering issues are where you'd probably find the challenges. > On Tue Nov 12, 2002 at 09:09:48AM -0500, Robert Watson wrote: > [...] > > > > You do realize that we're in a feature freeze right now, and will be in a > > code freeze within days, right? You're coming up a dollar short, and a > > day late. This is the reason I've trying to press for a resolution for > > weeks now. I'm deeply concerned that we've imported software without > > doing any of the necessary mergework and adaptation, and are now > > apparently planning to ship it. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 9:23:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51D0637B401 for ; Tue, 12 Nov 2002 09:23:42 -0800 (PST) Received: from marvin.bsdng.org (24-159-234-52.jvl.wi.charter.com [24.159.234.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8278043E42 for ; Tue, 12 Nov 2002 09:23:41 -0800 (PST) (envelope-from mkm@marvin.bsdng.org) Received: from marvin.bsdng.org (marvin [127.0.0.1]) by marvin.bsdng.org (8.12.6/8.12.5) with ESMTP id gACHLvet018802; Tue, 12 Nov 2002 11:21:57 -0600 (CST) (envelope-from mkm@marvin.bsdng.org) Received: (from mkm@localhost) by marvin.bsdng.org (8.12.6/8.12.6/Submit) id gACHLrJm018800; Tue, 12 Nov 2002 11:21:53 -0600 (CST) Date: Tue, 12 Nov 2002 11:21:52 -0600 From: Kyle Martin To: Kirk McKusick Cc: arch@freebsd.org Subject: Re: Shared-memory version of macros Message-ID: <20021112172152.GC15329@marvin.bsdng.org> References: <200211112232.gABMW459037409@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211112232.gABMW459037409@beastie.mckusick.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Nov 11, 2002 at 02:32:04PM -0800, Kirk McKusick wrote: > > Historically /usr/include/sys was used to include files that > provided headers that included interfaces between the kernel > and userland. For example, describes that > stat structure which is filled in by the kernel and used > by userland applications. Since the queue macros do not > describe any kernel/userland shared structures, they belong > in /usr/include. They are much more like which > describes purely userland structures like FILE *. However, > we canot move from the /sys/sys directory as > it is needed by the kernel (indeed was originally developed > for the kernel) as there is another rule which says that > the kernel headers need to be self contained (that is the > kernel cannot depend on anything in /usr/include). So, there > is the dilemma of duplicating the queue macros used in the > kernel in a /usr/include file, or trying to avoid divergence > by pulling in the kernel macros from /usr/include/sys. As > for what userland applications should do, once > exists, they should always use that file. > perhaps "#include" could appear in /usr/include/queue.h with some typical #ifdef glue in -- Kyle Martin mkm@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 12 15:25:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C92E37B401 for ; Tue, 12 Nov 2002 15:25:29 -0800 (PST) Received: from marvin.bsdng.org (24-159-234-52.jvl.wi.charter.com [24.159.234.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A55243E4A for ; Tue, 12 Nov 2002 15:25:28 -0800 (PST) (envelope-from mkm@marvin.bsdng.org) Received: from marvin.bsdng.org (marvin [127.0.0.1]) by marvin.bsdng.org (8.12.6/8.12.5) with ESMTP id gACNNYet020468; Tue, 12 Nov 2002 17:23:35 -0600 (CST) (envelope-from mkm@marvin.bsdng.org) Received: (from mkm@localhost) by marvin.bsdng.org (8.12.6/8.12.6/Submit) id gACNNY7j020467; Tue, 12 Nov 2002 17:23:34 -0600 (CST) Date: Tue, 12 Nov 2002 17:23:34 -0600 From: Kyle Martin To: Kirk McKusick Cc: arch@freebsd.org Subject: Re: Shared-memory version of macros Message-ID: <20021112232334.GA20358@marvin.bsdng.org> References: <20021112172152.GC15329@marvin.bsdng.org> <200211122310.gACNA159039354@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211122310.gACNA159039354@beastie.mckusick.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Nov 12, 2002 at 03:10:01PM -0800, Kirk McKusick wrote: > > On Mon, Nov 11, 2002 at 02:32:04PM -0800, Kirk McKusick wrote: > > Historically /usr/include/sys was used to include files that > > provided headers that included interfaces between the kernel > > and userland. For example, describes that > > stat structure which is filled in by the kernel and used > > by userland applications. Since the queue macros do not > > describe any kernel/userland shared structures, they belong > > in /usr/include. They are much more like which > > describes purely userland structures like FILE *. However, > > we canot move from the /sys/sys directory as > > it is needed by the kernel (indeed was originally developed > > for the kernel) as there is another rule which says that > > the kernel headers need to be self contained (that is the > > kernel cannot depend on anything in /usr/include). So, there > > is the dilemma of duplicating the queue macros used in the > > kernel in a /usr/include file, or trying to avoid divergence > > by pulling in the kernel macros from /usr/include/sys. As > > for what userland applications should do, once > > exists, they should always use that file. > > > > perhaps "#include" could appear in > /usr/include/queue.h with some typical #ifdef > glue in > > > I am not sure what you mean by the above. The > file is already protected with #ifndef _SYS_QUEUE_H_ against > multiple inclusion. Did you have something else in mind? > The #ifdef I was referring to was _KERNEL, which is already there :) -- Kyle Martin mkm@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 13 10:58:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67F0137B401 for ; Wed, 13 Nov 2002 10:58:38 -0800 (PST) Received: from scrooge.etek.chalmers.se (scrooge.etek.chalmers.se [129.16.32.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B5743E91 for ; Wed, 13 Nov 2002 10:58:35 -0800 (PST) (envelope-from b@etek.chalmers.se) Received: from scrooge.etek.chalmers.se (b@localhost [127.0.0.1]) by scrooge.etek.chalmers.se (8.12.3/8.12.3) with ESMTP id gADIwR9E027614 for ; Wed, 13 Nov 2002 19:58:27 +0100 (CET) (envelope-from b@etek.chalmers.se) Received: from localhost (b@localhost) by scrooge.etek.chalmers.se (8.12.3/8.12.3/Submit) with ESMTP id gADIwQHi027611 for ; Wed, 13 Nov 2002 19:58:27 +0100 (CET) X-Authentication-Warning: scrooge.etek.chalmers.se: b owned process doing -bs Date: Wed, 13 Nov 2002 19:58:26 +0100 (CET) From: Magnus B{ckstr|m To: arch@freebsd.org Subject: Proposal: buslib(9) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archers, In response to a JKH task posted by Poul-Henning Kamp, here is my proposal for a small "bus library". The intent of the library is to factor out some commonly occuring code idioms in device drivers. The problem as stated splits into two parts: One is the allocation and deallocation of bus resources that every driver performs regardless of bus type, the other is the bus-specific hopscotch that PCI drivers do (set the power mode and register access modes, and make up a text description the device, etc.) The two parts are practically orthogonal, and I chose to tackle them one at a time. So, enter buslib(9) :-) Check http://www.etek.chalmers.se/~b/buslib/ for preliminary man pages and patches. To summarise, using buslib: pci/if_xl.c + pci/if_xlreg.h shrank by 42 lines pci/if_sis.c + pci/if_sisreg.h shrank by 25 lines dev/fxp/* shrank by 9 lines Ocular inspection of other drivers lead me to believe these figures are typical. Binary code shrinks slightly as well, by some hundred bytes per driver. xl(4) and fxp(4) survived conversion and work fine, sis(4) compiles but I have no hardware to test it on. Converting a driver to use buslib is approximately a 20-minute job. This is my first attempt at contributing code to FreeBSD; thus comments, advice, and criticism of (almost) any nature are highly welcome. Magnus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 14 18:39:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7688B37B401 for ; Thu, 14 Nov 2002 18:39:35 -0800 (PST) Received: from yahoo.samart.co.th (tidkeaw.samart.co.th [203.149.0.14]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D02043E7B for ; Thu, 14 Nov 2002 18:39:33 -0800 (PST) (envelope-from iddi@hotmail.com) Received: (qmail 20703 invoked from network); 15 Nov 2002 02:47:34 -0000 Received: from unknown (HELO ardency.samart.co.th) ([10.0.0.11]) (envelope-sender ) by 10.0.0.22 (qmail-ldap-1.03) with SMTP for ; 15 Nov 2002 02:47:34 -0000 Received: (qmail 19093 invoked from network); 15 Nov 2002 02:48:40 -0000 Received: from unknown (HELO yahoo.samart.co.th) ([203.149.32.130]) (envelope-sender ) by yahoo.samart.co.th (qmail-ldap-1.03) with SMTP for ; 15 Nov 2002 02:48:40 -0000 Message-Id: <1037327963.149@samart.co.th> Date: Fri, 15 Nov 2002 09:39:23 0700 To: freebsd-arch@FreeBSD.org From: "getrich" Subject: มีของดีมาบอก.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Part-Time Job!! สำหรับนักเรียน นักศึกษา และผู้ทำงานประจำ คุณต้องการงานแบบนี้บ้างไหม…?? -งาน parttime ทำงานที่บ้านได้ ถ้าคุณใช้ Internet เป็น -ทำงานเพียงวันละ 2-3 ชม. -รายได้ 5,000 – 15,000 บาท ถ้าคุณเป็นคนหนึ่งที่ทำงานประจำหรือยังไม่มีงานทำ นักศึกษาที่กำลังศึกษาอยู่ ผู้ว่างงาน หรือผู้ที่ยังพอมีเวลาว่างจากงานประจำ มีคุณสมบัติเบื้องต้นดังนี้ 1. มีทัศนคติที่ดี 2. พร้อมที่จะเรียนรู้ เนื่องจากเป็นระบบใหม่จึงต้องให้มีการอบรมให้ตามความเหมาะสม 3. ต้องการที่จะทำงานอย่างจริงจัง อยากที่จะเปลี่ยนฐานะทางการเงินของตนเอง และอยากมีรายได้จากการทำงานตรงนี้จริงๆ ทุกอย่างเป็นไปได้ ใน สนใจรับข้อมูลเพิ่มเติมฟรี ได้ที่ http://ejobthailand.net/getrich อย่า !…………….. เป็นแค่เพียงคนที่นั่งรอโอกาส To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 15 16:21:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6F2537B4C3 for ; Fri, 15 Nov 2002 16:21:14 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E35943E4A for ; Fri, 15 Nov 2002 16:21:14 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id gAG0L8p43031 for ; Fri, 15 Nov 2002 19:21:08 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 15 Nov 2002 19:21:08 -0500 (EST) From: Jeff Roberson To: arch@freebsd.org Subject: Software Watchdog Message-ID: <20021115191632.U22491-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sean Kelly has implemented a software watchdog based on input from myself and Peter. This works through a simple watcdog daemon that checks in with the kernel every so often. The kernel complains via hardclock() if the watchdog times out. This will be very useful for debugging hard lockups because hardclock() comes in through a fast intr. There are few things that will stop hardclock() from firing. Below I have included some snipits from an email Sean sent me. Here's what I've got so far: 1. Kernel watchdog a. Three sysctls i. debug.watchdog.timeout: Number of seconds allowed to go without a reset ii. debug.watchdog.reset: Upon read or write, resets the watchdog timer iii. debug.watchdog.enabled: When >0, perform watchdog checks. b. 'options WATCHDOG' or 'options INVARIANTS' to compile with watchdog code c. watchdog(4) manpage 2. Userland support a. /usr/sbin/watchdogd i. Performs stat("/etc") test ii. Awakens periodically and resets watchdog via d.w.reset sysctl iii. Sets d.w.enabled=1 on start and d.w.enabled=0 on exit. iv. Proper signal handling. v. Writes pidfile in /var/run/watchdogd.pid b. watchdogd(8) manpage c. /etc/rc check for watchdogd_enabled="YES" d. /etc/rc.d/watchdogd rcNG script e. Addition of 'watchdogd_enabled="NO"' to /etc/defaults/rc.conf I have a short TODO list as well: * Deal with when ticks overflows (this will be pretty easy) * Do multiple instances of interrupt and backtrace outputs a few seconds apart. (This will be pretty easy) * Flesh out the watchdogd daemon to do more checks once I figure out what checks people advise it do. And by checks, I mean "test a, b, and c must not fail or I won't reset the watchdog." What I have so far is available for viewing at http://www.zombie.org/watchdog.diff I believe this functionality will be invaluable for debugging 5.0. I'd like to have this included as soon as the todo list is covered and it gets a proper review. Comments? Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 15 22:50:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A4C537B401 for ; Fri, 15 Nov 2002 22:50:37 -0800 (PST) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB66743E77 for ; Fri, 15 Nov 2002 22:50:36 -0800 (PST) (envelope-from winter@jurai.net) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.6/8.12.5) with ESMTP id gAG6oZ6D053624 for ; Sat, 16 Nov 2002 01:50:35 -0500 (EST) (envelope-from winter@jurai.net) Date: Sat, 16 Nov 2002 01:50:35 -0500 (EST) From: "Matthew N. Dodd" To: freebsd-arch@freebsd.org Subject: bus_alloc_resource() abusers will be fixed. Message-ID: <20021116014238.R69283-100000@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm going to fix all the abuses of the 'count' parameter to the bus_alloc_resource() call. 'count' isn't the size of the allocation. The resource must specify a start and a length and not rely on 'count' to fake up an allocation that works. As far as I can tell, most of the abusers are ones that can use PNPBIOS or ISA hints. This will fix stuff like this: unknown: can't assign resources (port) It will require that hints specify a 'portsize' or 'msize' variable for each 'port' or 'maddr' that has a size > than 1. I'll post my patches for MAINTAINER review but this needs to get fixed before we roll out a release that uses the hints mechanism so we don't get locked into supporting the broken usage. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 1: 6:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB2A437B401 for ; Sat, 16 Nov 2002 01:06:16 -0800 (PST) Received: from critter.freebsd.dk (host30-212.bsdcon.customer.bit.nl [213.136.30.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C5F743E91 for ; Sat, 16 Nov 2002 01:06:15 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gAG95YN3005012; Sat, 16 Nov 2002 10:05:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: Software Watchdog In-Reply-To: Your message of "Fri, 15 Nov 2002 19:21:08 EST." <20021115191632.U22491-100000@mail.chesapeake.net> Date: Sat, 16 Nov 2002 10:05:34 +0100 Message-ID: <5011.1037437534@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20021115191632.U22491-100000@mail.chesapeake.net>, Jeff Roberson wr ites: >Sean Kelly has implemented a software watchdog based on input from myself >and Peter. This works through a simple watcdog daemon that checks in with >the kernel every so often. The kernel complains via hardclock() if the >watchdog times out. This will be very useful for debugging hard lockups >because hardclock() comes in through a fast intr. There are few things >that will stop hardclock() from firing. Does it have hooks for supporting hardware watchdogs ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 7:28:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9823A37B401 for ; Sat, 16 Nov 2002 07:28:41 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D4743E77 for ; Sat, 16 Nov 2002 07:28:40 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (tnt-77-54.ct.dialin.ntplx.com [209.54.77.54]) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id gAGFSc03002352; Sat, 16 Nov 2002 10:28:38 -0500 (EST) Message-ID: <3DD66393.40AFC73@vigrid.com> Date: Sat, 16 Nov 2002 10:26:11 -0500 From: Daniel Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: What to do with userland *context() functions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG After adding *context() as system calls, we no longer need the userland versions. But I would like to use them in libc_r and they might be useful to someone else writing their own userland threading library. As of now, we need different variants of them for libpthread, so they aren't expected to be used there. How do folks feel about keeping them in libc, but named as _getctx, _setctx, _swapctx? They would be similar to _setjmp/_longjmp which don't save/restore the signal mask. It'll add a little bloat to libc and they are only present for i386 and alpha archs. I'll have them repo-copied to libc_r if the consensus is to remove them from libc. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 8:49:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E0337B401 for ; Sat, 16 Nov 2002 08:49:54 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FBD543E4A for ; Sat, 16 Nov 2002 08:49:53 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAGGnoDP097274; Sat, 16 Nov 2002 16:49:50 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: What to do with userland *context() functions Date: Sat, 16 Nov 2002 16:49:50 +0000 User-Agent: KMail/1.4.3 References: <3DD66393.40AFC73@vigrid.com> In-Reply-To: <3DD66393.40AFC73@vigrid.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211161649.50346.dfr@nlsystems.com> X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 16 November 2002 3:26 pm, Daniel Eischen wrote: > After adding *context() as system calls, we no longer > need the userland versions. But I would like to use > them in libc_r and they might be useful to someone else > writing their own userland threading library. As of > now, we need different variants of them for libpthread, > so they aren't expected to be used there. > > How do folks feel about keeping them in libc, but named > as _getctx, _setctx, _swapctx? They would be similar > to _setjmp/_longjmp which don't save/restore the signal > mask. It'll add a little bloat to libc and they are > only present for i386 and alpha archs. > > I'll have them repo-copied to libc_r if the consensus is > to remove them from libc. I'm not quite sure why libc_r can't use the standard swapcontext system=20 call. Is it something to do with the signal mask? It seems to defeat=20 the object to create a bunch of nice standard functions for low-level=20 thread switching and then not use them. Plus it means we need to=20 maintain two (or three) variations of the same code, which seems wrong. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 10: 7:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A341837B401 for ; Sat, 16 Nov 2002 10:07:22 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3135A43E3B for ; Sat, 16 Nov 2002 10:07:22 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id gAGI7Gaw023543; Sat, 16 Nov 2002 13:07:16 -0500 (EST) Date: Sat, 16 Nov 2002 13:07:16 -0500 (EST) From: Daniel Eischen To: Doug Rabson Cc: arch@FreeBSD.ORG Subject: Re: What to do with userland *context() functions In-Reply-To: <200211161649.50346.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 16 Nov 2002, Doug Rabson wrote: > On Saturday 16 November 2002 3:26 pm, Daniel Eischen wrote: > > After adding *context() as system calls, we no longer > > need the userland versions. But I would like to use > > them in libc_r and they might be useful to someone else > > writing their own userland threading library. As of > > now, we need different variants of them for libpthread, > > so they aren't expected to be used there. > > > > How do folks feel about keeping them in libc, but named > > as _getctx, _setctx, _swapctx? They would be similar > > to _setjmp/_longjmp which don't save/restore the signal > > mask. It'll add a little bloat to libc and they are > > only present for i386 and alpha archs. > > > > I'll have them repo-copied to libc_r if the consensus is > > to remove them from libc. > > I'm not quite sure why libc_r can't use the standard swapcontext system > call. Is it something to do with the signal mask? It seems to defeat > the object to create a bunch of nice standard functions for low-level > thread switching and then not use them. Plus it means we need to > maintain two (or three) variations of the same code, which seems wrong. The threads libraries don't need to save/restore the process signal mask, so using userland versions of *context() optimizes thread switches. Libpthread already has its own set of userland context switching and libc_r is using _setjmp/_longjmp. For archs without userland *context() functions of some sort, we'll use the system calls. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 13:25:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D08737B401 for ; Sat, 16 Nov 2002 13:25:25 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A7543E3B for ; Sat, 16 Nov 2002 13:25:10 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGLOq0N039853; Sat, 16 Nov 2002 13:24:55 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGLOqUq001354; Sat, 16 Nov 2002 13:24:52 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gAGLOdf0001353; Sat, 16 Nov 2002 13:24:39 -0800 (PST) (envelope-from marcel) Date: Sat, 16 Nov 2002 13:24:39 -0800 From: Marcel Moolenaar To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: What to do with userland *context() functions Message-ID: <20021116212439.GA1298@dhcp01.pn.xcllnt.net> References: <3DD66393.40AFC73@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD66393.40AFC73@vigrid.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Nov 16, 2002 at 10:26:11AM -0500, Daniel Eischen wrote: > After adding *context() as system calls, we no longer > need the userland versions. But I would like to use > them in libc_r and they might be useful to someone else > writing their own userland threading library. As of > now, we need different variants of them for libpthread, > so they aren't expected to be used there. > > How do folks feel about keeping them in libc, but named > as _getctx, _setctx, _swapctx? They would be similar > to _setjmp/_longjmp which don't save/restore the signal > mask. It'll add a little bloat to libc and they are > only present for i386 and alpha archs. I'd like them to be removed from libc. I tend to agree with Doug that the duplication (3 as it stands) is unattractive. Since libc_r has a short life expectancy, I would probably not bother to move them to libc_r. IMO, YMMV. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 13:50: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51CF137B404; Sat, 16 Nov 2002 13:50:04 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F24943E42; Sat, 16 Nov 2002 13:50:03 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id gAGLnR8L289180; Sat, 16 Nov 2002 16:49:27 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020426.095955.80136029.imp@village.org> References: <1019819253.450.389.camel@gurney.reilly.home> <20020426.095955.80136029.imp@village.org> Date: Sat, 16 Nov 2002 16:49:26 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: re@FreeBSD.ORG, imp@village.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Back in April 2002, we went through a debate on getting 'diff' to generate the line "No newline at end-of-file" for the situation where one file has a newline as it's last character, and the other file (being compared by diff) does not have that last newline. At the time, the stumbling block was that our version of patch did not understand what to do with that line. A few years ago, Brian Feldman (aka green@FreeBSD.org) changed our diff to *not* put that line out, because of the issue with patch. Back on April 26/2002, M. Warner Losh wrote: >My plans had always been to back out Green's change (with Green's >permission, btw) when there was a patch that could grok things. >The back out wouldn't be MFC'd until after at least one release. >Since this was historical FreeBSD behavior, and modern patches >grok the end of line things, I see this as a no brainer: just do >it once patch is patched :-) I installed changes to our 'patch' so it does the right thing with the "No newline" line. This was MFC'ed just before 4.6-release. We're now past 4.7-release. I would like to now make the one-line change to 'diff' so it will (once again) generate that line, and I would like to do that before 5.0-release, and also MFC it into -stable. I assume people would prefer that I do it after 5.0-dp2, but I would like to get it in for 5.0-release. Would this be okay with everyone, particularly with re@freebsd? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 16 15:38:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7669837B401; Sat, 16 Nov 2002 15:38:33 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63AE743E3B; Sat, 16 Nov 2002 15:38:32 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gAGNcUpk005598; Sat, 16 Nov 2002 16:38:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 16 Nov 2002 16:38:25 -0700 (MST) Message-Id: <20021116.163825.34762621.imp@bsdimp.com> To: drosih@rpi.edu Cc: arch@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: References: <20020426.095955.80136029.imp@village.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : Would this be okay with everyone, particularly with re@freebsd? I'm cool with that. Thanks for picking up my dropped ball. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message