From owner-freebsd-arch Wed Sep 26 11:57:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by hub.freebsd.org (Postfix) with ESMTP id 455F637B413 for ; Wed, 26 Sep 2001 11:57:09 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by philotas.hosting.pacbell.net id OAA02335; Wed, 26 Sep 2001 14:56:54 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <007f01c146bb$1f105fc0$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: "Daniel Eischen" Cc: References: Subject: Re: FD_LOCK, pthreads and drivers Date: Wed, 26 Sep 2001 11:43:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Will the next release of FreeBSD have the FD_LOCKs removed from the default installation? If so, when is that availible? ----- Original Message ----- From: "Daniel Eischen" To: "Alfred Perlstein" Cc: "mike varga" ; Sent: Thursday, September 13, 2001 5:54 PM Subject: Re: FD_LOCK, pthreads and drivers > On Thu, 13 Sep 2001, Alfred Perlstein wrote: > > * mike varga [010913 17:41] wrote: > > > I noticed that while testing the driver I wrote > > > for a crypto device, that only one thread > > > can be executing within the context of > > > my driver at a time. > > > > > > The problem is that the pthreads library > > > replaces the ioctl with another that exclusively > > > locks the file descriptor with calls to FD_LOCK/ > > > FD_UNLOCK. > > This isn't true for -current. I removed automatic locking of > file descriptors many months ago. > > > > Why? > > Indeed, it should be up to the application to provide protection > for I/O operations on the same file descriptor :-) Or at least > the threads library should stay out of the way and let the application > and kernel decide... > > > > I went to extremes to make sure that it > > > would be fully reentrant. > > > The driver/crypto accelerator now suffers > > > from slow performance. > > > > Under the native FreeBSD threading model there is only one > > process context. You'll want to use the linuxthreads port > > to do this. > > You can have multiple I/O requests within libc_r, but they > are all converted to non-blocking requests and the thread > scheduler periodically polls for I/O completion. If your > device driver doesn't support non-blocking operations, then > our threads library isn't going to help you much even in > -current where FD locking is disabled. > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 0:11:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 7FFEF37B430 for ; Thu, 27 Sep 2001 00:11:47 -0700 (PDT) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f8R7BlI29280 for ; Thu, 27 Sep 2001 00:11:47 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.11.6/8.11.5) id f8R7BkW11296 for arch@FreeBSD.org; Thu, 27 Sep 2001 00:11:46 -0700 (PDT) (envelope-from marcel) Date: Thu, 27 Sep 2001 00:11:46 -0700 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: makesyscalls.sh: Fix for NODEF type Message-ID: <20010927001146.A11131@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.3.21i 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 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Background: The Linuxulator port for alpha has the unique problem that two syscall numbers/entries map to the same syscall function. The syscall in question is setpgid()/linux_setpgid(). One of them is nothing more than a stub to work around a limitation in our syscall table generation. The following is a way to avoid having to create a stub in this case. When two identical syscalls are defined as having type NOPROTO, the only problem that remains is the fact that there will be a duplicate definition in *syscall.h. In sys/kern/makesyscalls.sh there's a way to suppress this: mark the syscall as type NODEF. Unfortunately this breaks the declaration of the syscall in *proto.h and is therefore useless in it's current form. The attached patch makes type NODEF work in follows. Assume we have the following entry in syscalls.master: 1 NODEF BSD foobar The only code generated for syscall 1 will be an entry in the syscall table (struct sysent sysent[]): { AS(foobar_args), (sy_call_t *)foobar }, /* 1 = NODEF */ This allows syscall functions to have multiple syscall number or entries. Is this an acceptable fix and/or interpretation for NODEF? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nodef.diff" Index: makesyscalls.sh =================================================================== RCS file: /home/ncvs/src/sys/kern/makesyscalls.sh,v retrieving revision 1.48 diff -u -r1.48 makesyscalls.sh --- makesyscalls.sh 12 Sep 2001 08:37:45 -0000 1.48 +++ makesyscalls.sh 27 Sep 2001 06:50:59 -0000 @@ -208,6 +208,7 @@ } if ($2 == "NODEF") { funcname=$4 + argssize = "AS(" $4 "_args)" return } if ($f != "{") @@ -320,7 +321,7 @@ argalias) > sysarg } if ($2 != "NOPROTO" && (!nosys || funcname != "nosys") && \ - (!lkmnosys || funcname != "lkmnosys")) { + (!lkmnosys || funcname != "lkmnosys") && $2 != "NODEF") { printf("%s\t%s __P((struct thread *, struct %s *))", rettype, funcname, argalias) > sysdcl printf(";\n") > sysdcl --n8g4imXOkfNTN/H1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 16:30:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0465E37B40A for ; Thu, 27 Sep 2001 16:30:55 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f8RNUsu51009 for ; Thu, 27 Sep 2001 17:30:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f8RNUn776995 for ; Thu, 27 Sep 2001 17:30:53 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109272330.f8RNUn776995@harmony.village.org> To: arch@freebsd.org Subject: Proposed change: d_thread_t for driver portability between 4.x and 5.x Date: Thu, 27 Sep 2001 17:30:49 -0600 From: Warner Losh 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 Right now I have to do some really ugly things in the pcic driver to make my driver portable between 4.x and 5.x. Surprising, the only ugly part is that stable has struct proc and current has struct thread for many parameters. Most drivers just shuffle these poitners around to various routines and don't need to look under the covers. As such, having a d_thread_t typedef would make it easier to write drivers that can be shared. Instead of saying struct proc *p, you'd say d_thread_t *p in its place. This will make it work for both -stable and -current without further kludges. Here's the diffs for -current: Index: conf.h =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/sys/sys/conf.h,v retrieving revision 1.133 diff -u -r1.133 conf.h --- conf.h 2001/09/12 08:38:05 1.133 +++ conf.h 2001/09/27 23:19:49 @@ -114,17 +114,18 @@ struct uio; struct knote; -typedef int d_open_t __P((dev_t dev, int oflags, int devtype, struct thread *td)); -typedef int d_close_t __P((dev_t dev, int fflag, int devtype, struct thread *td)); +typedef struct thread d_thread_t; +typedef int d_open_t __P((dev_t dev, int oflags, int devtype, d_thread_t *td)); +typedef int d_close_t __P((dev_t dev, int fflag, int devtype, d_thread_t *td)); typedef void d_strategy_t __P((struct bio *bp)); typedef int d_ioctl_t __P((dev_t dev, u_long cmd, caddr_t data, - int fflag, struct thread *td)); + int fflag, d_thread_t *td)); typedef int d_dump_t __P((dev_t dev)); typedef int d_psize_t __P((dev_t dev)); typedef int d_read_t __P((dev_t dev, struct uio *uio, int ioflag)); typedef int d_write_t __P((dev_t dev, struct uio *uio, int ioflag)); -typedef int d_poll_t __P((dev_t dev, int events, struct thread *td)); +typedef int d_poll_t __P((dev_t dev, int events, d_thread_t *td)); typedef int d_kqfilter_t __P((dev_t dev, struct knote *kn)); typedef int d_mmap_t __P((dev_t dev, vm_offset_t offset, int nprot)); @@ -133,7 +134,7 @@ typedef int l_read_t __P((struct tty *tp, struct uio *uio, int flag)); typedef int l_write_t __P((struct tty *tp, struct uio *uio, int flag)); typedef int l_ioctl_t __P((struct tty *tp, u_long cmd, caddr_t data, - int flag, struct thread *td)); + int flag, d_thread_t *td)); typedef int l_rint_t __P((int c, struct tty *tp)); typedef int l_start_t __P((struct tty *tp)); typedef int l_modem_t __P((struct tty *tp, int flag)); The -stable diffs are similar and can be found at: http://people.freebsd.org/~imp/conf-stable.diff http://people.freebsd.org/~imp/conf-current.diff The impact of those poeple not using this is 0. There are no places in the kernel that use d_thread_t for anything else that I can find, and its naming convention matches the d_XXXX_t that is already used in the device driver interface. I plan on committing this in a few days unless someone comes up with a good reason why I shouldn't do this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 16:45:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A37C937B41A for ; Thu, 27 Sep 2001 16:44:32 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA67522; Thu, 27 Sep 2001 17:39:59 -0700 (PDT) Date: Thu, 27 Sep 2001 17:39:59 -0700 (PDT) From: Julian Elischer To: Warner Losh Cc: arch@freebsd.org Subject: Re: Proposed change: d_thread_t for driver portability between 4.x and 5.x In-Reply-To: <200109272330.f8RNUn776995@harmony.village.org> 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 I think that it should have a Comment stating that it is a compatibility thing and that drivers for just -current should just use struct thread directly. Certainly any function that DOES look under the covers should be expressly forbidden from using d_thread_t. On Thu, 27 Sep 2001, Warner Losh wrote: > > Right now I have to do some really ugly things in the pcic driver to > make my driver portable between 4.x and 5.x. Surprising, the only > ugly part is that stable has struct proc and current has struct thread > for many parameters. Most drivers just shuffle these poitners around > to various routines and don't need to look under the covers. > > As such, having a d_thread_t typedef would make it easier to write > drivers that can be shared. Instead of saying struct proc *p, you'd > say d_thread_t *p in its place. This will make it work for both > -stable and -current without further kludges. > > Here's the diffs for -current: > > Index: conf.h > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/sys/sys/conf.h,v > retrieving revision 1.133 > diff -u -r1.133 conf.h > --- conf.h 2001/09/12 08:38:05 1.133 > +++ conf.h 2001/09/27 23:19:49 > @@ -114,17 +114,18 @@ > struct uio; > struct knote; > > -typedef int d_open_t __P((dev_t dev, int oflags, int devtype, struct thread *td)); > -typedef int d_close_t __P((dev_t dev, int fflag, int devtype, struct thread *td)); > +typedef struct thread d_thread_t; > +typedef int d_open_t __P((dev_t dev, int oflags, int devtype, d_thread_t *td)); > +typedef int d_close_t __P((dev_t dev, int fflag, int devtype, d_thread_t *td)); > typedef void d_strategy_t __P((struct bio *bp)); > typedef int d_ioctl_t __P((dev_t dev, u_long cmd, caddr_t data, > - int fflag, struct thread *td)); > + int fflag, d_thread_t *td)); > typedef int d_dump_t __P((dev_t dev)); > typedef int d_psize_t __P((dev_t dev)); > > typedef int d_read_t __P((dev_t dev, struct uio *uio, int ioflag)); > typedef int d_write_t __P((dev_t dev, struct uio *uio, int ioflag)); > -typedef int d_poll_t __P((dev_t dev, int events, struct thread *td)); > +typedef int d_poll_t __P((dev_t dev, int events, d_thread_t *td)); > typedef int d_kqfilter_t __P((dev_t dev, struct knote *kn)); > typedef int d_mmap_t __P((dev_t dev, vm_offset_t offset, int nprot)); > > @@ -133,7 +134,7 @@ > typedef int l_read_t __P((struct tty *tp, struct uio *uio, int flag)); > typedef int l_write_t __P((struct tty *tp, struct uio *uio, int flag)); > typedef int l_ioctl_t __P((struct tty *tp, u_long cmd, caddr_t data, > - int flag, struct thread *td)); > + int flag, d_thread_t *td)); > typedef int l_rint_t __P((int c, struct tty *tp)); > typedef int l_start_t __P((struct tty *tp)); > typedef int l_modem_t __P((struct tty *tp, int flag)); > > The -stable diffs are similar and can be found at: > http://people.freebsd.org/~imp/conf-stable.diff > http://people.freebsd.org/~imp/conf-current.diff > > The impact of those poeple not using this is 0. There are no places > in the kernel that use d_thread_t for anything else that I can find, > and its naming convention matches the d_XXXX_t that is already used in > the device driver interface. > > I plan on committing this in a few days unless someone comes up with a > good reason why I shouldn't do this. > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 16:47:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A3C5D37B40A for ; Thu, 27 Sep 2001 16:47:21 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f8RNlKu51098; Thu, 27 Sep 2001 17:47:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f8RNlJ777156; Thu, 27 Sep 2001 17:47:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109272347.f8RNlJ777156@harmony.village.org> To: Julian Elischer Subject: Re: Proposed change: d_thread_t for driver portability between 4.x and 5.x Cc: arch@freebsd.org In-reply-to: Your message of "Thu, 27 Sep 2001 17:39:59 PDT." References: Date: Thu, 27 Sep 2001 17:47:19 -0600 From: Warner Losh 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 Julian Elischer writes: : I think that it should have a Comment stating that it is a compatibility : thing and that drivers for just -current should just use struct thread : directly. Excellent idea. : Certainly any function that DOES look under the covers should be expressly : forbidden from using d_thread_t. Yes. I'll note that as well. Thanks for the feedback. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 17:38: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 9947637B407 for ; Thu, 27 Sep 2001 17:38:01 -0700 (PDT) Received: from laptop.baldwin.cx ([147.11.46.209]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA27074; Thu, 27 Sep 2001 17:36:46 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 27 Sep 2001 17:36:31 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Style Wars Cc: Warner Losh , 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 [ moved to -arch ] On 28-Sep-01 Julian Elischer wrote: > well maybe We can come up with a tweek to the standard that we can > all agree to... > and commit.. It is after all a 'living' document.. Certainly a viable option. I've seen a couple of ideas so far: 1) Use two tabs instead of one when types longer than one tab such as u_int64_t are used. 1a) Same as 1) but the tabs after after the type, not just the first word. 2) Use a space instead of a tab after types longer than one tab like we already do for queue macros. 3) (A new one) Just axe the tabs directly and change to always using a single space. Qualifiers like const and volatile reduce the usefulness of the tab as do long type names. 4) Have one column for qualifiers if any are present, one column for types and one for names, with each column separated by enough tabs such that each column lines up. Here's a sample struct in style(9) and the 3 listed ideas: style(9): struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 1) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 1a) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 2) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 3) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 4) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; 2) is probably the closest to existing style. My personal preference would be for 3) with an additional note about sorting so that within logical groups of members, you would sort the items such that the longest types are first. *shrug* I think 4) is just insane. Perhaps if you modified it so that it combined types and qualifiers into the same column it wouldn't be so bad however. I like green bikesheds. Specifically dark green, even forest green is pretty good. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 18: 4:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 834B137B405; Thu, 27 Sep 2001 18:04:25 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA67874; Thu, 27 Sep 2001 18:52:16 -0700 (PDT) Date: Thu, 27 Sep 2001 18:52:15 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: Warner Losh , arch@FreeBSD.org Subject: Re: Style Wars 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 Thu, 27 Sep 2001, John Baldwin wrote: > [ moved to -arch ] > > On 28-Sep-01 Julian Elischer wrote: > > well maybe We can come up with a tweek to the standard that we can > > all agree to... > > and commit.. It is after all a 'living' document.. > > Certainly a viable option. I've seen a couple of ideas so far: > > 1) Use two tabs instead of one when types longer than one tab such > as u_int64_t are used. > 1a) Same as 1) but the tabs after after the type, not just the > first word. In my experience this works best, but with the added thought that The aim is to get all the names to lign up as much as possible, so the tab occurs before the name (or "*"). In my personal favourite, if the name is pused out by the 'type' being too long, ta single space is put in.. See 1b) below.. Also you need to leave enough room for comments. that's why I think that trying to get the name in by column 24 is a good idea. Allowing 2 tabs so that composite and simple typed names can line up is I think not a great problem, but to work it requires that the tab occure after the type no after the first word.. I menat teh logical grouping is that way. The first word is not the entire type so it's silly to break the type 'half-way through'. > 2) Use a space instead of a tab after types longer than one tab like > we already do for queue macros. > 3) (A new one) Just axe the tabs directly and change to always using > a single space. Qualifiers like const and volatile reduce the > usefulness of the tab as do long type names. > 4) Have one column for qualifiers if any are present, one column for > types and one for names, with each column separated by enough tabs > such that each column lines up. > > Here's a sample struct in style(9) and the 3 listed ideas: > > style(9): > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 1) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 1a) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; 1b) struct foo { int f_type; /* comments start at column 40 */ struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; > > 2) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; This is what we have now, and it breaks down when there are composite types within the structure. It starts to become unreadable. > > 3) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 4) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 2) is probably the closest to existing style. My personal preference would be > for 3) with an additional note about sorting so that within logical groups of > members, you would sort the items such that the longest types are first. > *shrug* I think 4) is just insane. Perhaps if you modified it so that it > combined types and qualifiers into the same column it wouldn't be so bad > however. > > I like green bikesheds. Specifically dark green, even forest green is pretty > good. :) green is for wimps.. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 18:56:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id D247137B411; Thu, 27 Sep 2001 18:56:07 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f8S1u7290916; Thu, 27 Sep 2001 18:56:07 -0700 (PDT) (envelope-from obrien) Date: Thu, 27 Sep 2001 18:56:07 -0700 From: "David O'Brien" To: John Baldwin Cc: Julian Elischer , arch@FreeBSD.org Subject: Re: Style Wars Message-ID: <20010927185607.A90848@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Sep 27, 2001 at 05:36:31PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Thu, Sep 27, 2001 at 05:36:31PM -0700, John Baldwin wrote: > for 3) with an additional note about sorting so that within logical groups of > members, you would sort the items such that the longest types are first. Please clarify what you are saying here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 23: 4:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8C65C37B411 for ; Thu, 27 Sep 2001 23:04:10 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA68934 for ; Thu, 27 Sep 2001 23:51:18 -0700 (PDT) Message-ID: <3BB410B3.A2527C09@elischer.org> Date: Thu, 27 Sep 2001 22:54:59 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: KSE next steps... Content-Type: text/plain; charset=iso-8859-2 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 Well things seem to have setled down with -current and KSE part 2. so I guess it's time to start looking at the next steps. Here are some topics I'd like to look at: 1/ allocation schemes for threads/kses/ksegrps These need to be independently allocatable.. There are some questions however.. Should they be allocated from a zone allocator similar to that currently used for process structures? Should the vm object associated with threads structures be allocated and 'left' as it presently is (type stable storage)? Should the thread structure that comes with the proc structure be used as one of the threads for KSE operation, or should it be left untouched until KSE mode is stopped (or exit)? If we use the thread pre-packed with the proc there are some problems.. For example: it is intimatly associated with one process, but thread structs in KSE mode are transient, and might be given to a different process should it be needed there. (kernel thread structures are only 'used' when the thread enters the kernel due to a trap of some sort (e.g. syscall) until it returns back to user land). It provides the stack and storage for the thread to transfer from user to kernel and is 'empty' while the thread is running in user space. Another option might be to ALWAYS allocate them separatly.. That makes the first one just another thread struct... but it may be more 'expensive' to allocate tehm that way. (though thay could be cached...) 2/ When processes have a single state, (e.g. SLEEP, RUN etc.) it becomes possible for a process to simultaneously have threads in multiple states.. What do we do in all the places that current code assumes a single monolithic state, and how do we report the stat of such a process in /proc or ps? - My guess is that a single state 'KSE' for a process should indicate that no finer state information is available for that process until we add code to 'ps' to support it.. We can alter ps and friends to simply give up if they see that state.. 3/ similar for reporting wmesg information.. 4/ What does a process with 4 threads do if you send it a SIGTSTP and it has a number of threads (maybe on a different processor) presently suspended in syscalls or, maybe running in syscalls. (other questions later when I think of them..) The next steps: a) add allocators/destructors for threads, kses and ksegrps b) use them, and add code to fork() (and friends) to use them c) define the user interface so that uerland code can start to be planned. (I may just do that first.) d) add the syscalls to switch modes etc. e) make a single test syscall that exercises some of this...(no locking.. just simple) julian -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 27 23:50:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id E02CA37B408 for ; Thu, 27 Sep 2001 23:50:26 -0700 (PDT) Received: (qmail 28239 invoked from network); 28 Sep 2001 06:50:26 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Sep 2001 06:50:26 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010927185607.A90848@dragon.nuxi.com> Date: Thu, 27 Sep 2001 23:50:09 -0700 (PDT) From: John Baldwin To: arch@FreeBSD.org Subject: Re: Style Wars Cc: Julian Elischer 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 28-Sep-01 David O'Brien wrote: > On Thu, Sep 27, 2001 at 05:36:31PM -0700, John Baldwin wrote: >> for 3) with an additional note about sorting so that within logical groups >> of >> members, you would sort the items such that the longest types are first. > > Please clarify what you are saying here. Longest type measured as strlen(typename). :) I.e.: struct foo { const volatile f_cv; volatile int f_int; const char *f_name; struct mtx f_lock; u_int64_t f_64; int f_type; }; The reason is more obvious in a struct with multiple elements of the same type: struct new_lock_object { STAILQ_ENTRY(new_lock_object) lo_list; struct lock_class *lo_class; struct witness *lo_witness; const char *lo_name; const char *lo_wname; u_int lo_flags; }; -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 0:44:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 598A637B408 for ; Fri, 28 Sep 2001 00:44:13 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA69319 for ; Fri, 28 Sep 2001 01:20:37 -0700 (PDT) Message-ID: <3BB4259D.4AF78B4@elischer.org> Date: Fri, 28 Sep 2001 00:24:13 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: KSE next steps... References: <3BB410B3.A2527C09@elischer.org> Content-Type: text/plain; charset=iso-8859-2 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 > c) define the user interface so that userland code can start to be planned. Here are some ideas.. these are up for discussion.... /* embed this in the Userland thread info */ struct kt_context { struct kt_context *ktc_next_completed; mcontext_t ktc_ctx; void *ktc_UTS_private; unsigned int ktc_return_info; }; /* Need one of these per KSE. */ struct ks_mailbox { struct kt_context *ksm_curthread; struct kt_context *ksm_completed; /* runnable threads */ unsigned int ksm_upcall_reason; /* probably some info for delivering signals */ } possible syscalls.... int new_kse(struct ks_mailbox *mbox, int new_group); /* add a new KSE */ /* maybe in a new kse group */ int yield_kse(struct timespec *sleeptime); /* don't come back till */ /* time passed or work to do. */ int wake_kse(struct ks_mailbox *mbx); /* if we specify a yielded KSE * /* both will return. NULL wakes any. */ void exit_kse(); /* Will not return, but */ /* writes completion code in mailbox. */ int abort_thread(struct kt_context *ktc); /* if we find a thread in */ /* this process that has this ktc, */ /* then if it is sleeping, abort the syscall */ /* if it is running, let it continue but set */ /* flag so that if it tries to sleep, it aborts */ /* instead */ maybe reversing the sycall names... kse_new(), kse_yield(), kse_wake(), kse_exit(), thread_abort() how to start a KSE.... do a setjmp() Allocate a small stack. put the jump buf address on it.. temporarily switch to that stack. call a function that allocates the mailbox on that stack, fill in fields needed. call kse_new() with a pointer to the mailbox. return to the old stack by doing the longjmp(); new KSE will also return from the kse_new(); so the small stack must never be rewound... until after that thread calls kse_exit(). All upcalls will also return there... kernel gets address of ktc from the mailbox. If the thread is suspended, it will zero that field.. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 2: 1:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 8487B37B425 for ; Fri, 28 Sep 2001 02:01:13 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 6F20081D0D; Fri, 28 Sep 2001 04:01:13 -0500 (CDT) Date: Fri, 28 Sep 2001 04:01:13 -0500 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: KSE next steps... Message-ID: <20010928040113.B59854@elvis.mu.org> References: <3BB410B3.A2527C09@elischer.org> <3BB4259D.4AF78B4@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BB4259D.4AF78B4@elischer.org>; from julian@elischer.org on Fri, Sep 28, 2001 at 12:24:13AM -0700 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 * Julian Elischer [010928 02:44] wrote: > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > /* this process that has this ktc, */ > /* then if it is sleeping, abort the syscall */ > /* if it is running, let it continue but set */ > /* flag so that if it tries to sleep, it aborts */ > /* instead */ Unless I'm misunderstanding you, this will not be possible without a tremendous amount of work, a variation that may work is allowing the syscall to run to completion, returning the error code and then aborting it. Too much code would have to change if tsleep became a cancellation point. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 2:40:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C0E9637B410 for ; Fri, 28 Sep 2001 02:40:15 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA19064; Fri, 28 Sep 2001 19:40:07 +1000 Date: Fri, 28 Sep 2001 19:39:33 +1000 (EST) From: Bruce Evans X-X-Sender: To: Warner Losh Cc: Subject: Re: Proposed change: d_thread_t for driver portability between 4.x and 5.x In-Reply-To: <200109272330.f8RNUn776995@harmony.village.org> Message-ID: <20010928192532.M52718-100000@delplex.bde.org> 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 Thu, 27 Sep 2001, Warner Losh wrote: > Right now I have to do some really ugly things in the pcic driver to > make my driver portable between 4.x and 5.x. Surprising, the only > ugly part is that stable has struct proc and current has struct thread > for many parameters. Most drivers just shuffle these poitners around > to various routines and don't need to look under the covers. > > As such, having a d_thread_t typedef would make it easier to write > drivers that can be shared. Instead of saying struct proc *p, you'd > say d_thread_t *p in its place. This will make it work for both > -stable and -current without further kludges. This breaks 2 style rules :-). From style(9): Avoid using typedefs for structure types. Such typedefs make it impossi- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ble for applications to use pointers to such a structure opaquely, which is both possible and beneficial when using an ordinary struct tag. When convention requires a typedef, make its name match the struct tag. Avoid ^^^^^ typedefs ending in ``_t'', except as specified in Standard C or by POSIX. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These are wollman's rules, not KNF. I strongly agree with them, but we have too many of these personal rules which not everyone agreed to. I can see the use of d_thread_t^Hs if it is truly opaque. Declaring it only in or even including breaks its opaqueness. Unfortunately, the other rule-breaking declarations like d_open_t require including the full in device drivers. It's another bug that dev_t is not either truly opaque or declared as "struct foo *". > Here's the diffs for -current: > > Index: conf.h > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/sys/sys/conf.h,v > retrieving revision 1.133 > diff -u -r1.133 conf.h > --- conf.h 2001/09/12 08:38:05 1.133 > +++ conf.h 2001/09/27 23:19:49 > @@ -114,17 +114,18 @@ > struct uio; > struct knote; > > -typedef int d_open_t __P((dev_t dev, int oflags, int devtype, struct thread *td)); > -typedef int d_close_t __P((dev_t dev, int fflag, int devtype, struct thread *td)); > +typedef struct thread d_thread_t; > +typedef int d_open_t __P((dev_t dev, int oflags, int devtype, d_thread_t *td)); > +typedef int d_close_t __P((dev_t dev, int fflag, int devtype, d_thread_t *td)); The type need/should not be opaque to the implementation, so there should only be 1 1-line change to this file (to add a typedef). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 4:54:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5038D37B407 for ; Fri, 28 Sep 2001 04:54:52 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA00291; Fri, 28 Sep 2001 07:53:39 -0400 (EDT) Date: Fri, 28 Sep 2001 07:53:39 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <20010928040113.B59854@elvis.mu.org> 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 Fri, 28 Sep 2001, Alfred Perlstein wrote: > * Julian Elischer [010928 02:44] wrote: > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > /* this process that has this ktc, */ > > /* then if it is sleeping, abort the syscall */ > > /* if it is running, let it continue but set */ > > /* flag so that if it tries to sleep, it aborts */ > > /* instead */ > > Unless I'm misunderstanding you, this will not be possible without > a tremendous amount of work, a variation that may work is allowing > the syscall to run to completion, returning the error code and then > aborting it. Too much code would have to change if tsleep became > a cancellation point. Think of this as kill() on a process; it shouldn't be too different. If PCATCH is specified in the tsleep, then it is terminated immediately, otherwise it just remains pending until (and if) it is checked at a later point in time. Regardless of whether PCATCH is specified, the thread never returns to userland. The UTS is notified through an upcall in the same way that it would be if a thread blocked (but with a different completion status). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 4:55:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 164D737B407 for ; Fri, 28 Sep 2001 04:55:53 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 29C7881D0C; Fri, 28 Sep 2001 06:55:53 -0500 (CDT) Date: Fri, 28 Sep 2001 06:55:53 -0500 From: Alfred Perlstein To: Daniel Eischen Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... Message-ID: <20010928065553.D59854@elvis.mu.org> References: <20010928040113.B59854@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Fri, Sep 28, 2001 at 07:53:39AM -0400 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 * Daniel Eischen [010928 06:54] wrote: > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > * Julian Elischer [010928 02:44] wrote: > > > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > > /* this process that has this ktc, */ > > > /* then if it is sleeping, abort the syscall */ > > > /* if it is running, let it continue but set */ > > > /* flag so that if it tries to sleep, it aborts */ > > > /* instead */ > > > > Unless I'm misunderstanding you, this will not be possible without > > a tremendous amount of work, a variation that may work is allowing > > the syscall to run to completion, returning the error code and then > > aborting it. Too much code would have to change if tsleep became > > a cancellation point. > > Think of this as kill() on a process; it shouldn't be too different. > If PCATCH is specified in the tsleep, then it is terminated immediately, > otherwise it just remains pending until (and if) it is checked at a > later point in time. Regardless of whether PCATCH is specified, the > thread never returns to userland. The UTS is notified through an > upcall in the same way that it would be if a thread blocked (but with > a different completion status). This is quite different from winking out of existance when it tries to sleep. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 5: 5:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C5BE437B40E for ; Fri, 28 Sep 2001 05:05:22 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA02242; Fri, 28 Sep 2001 08:04:24 -0400 (EDT) Date: Fri, 28 Sep 2001 08:04:24 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <20010928065553.D59854@elvis.mu.org> 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 Fri, 28 Sep 2001, Alfred Perlstein wrote: > * Daniel Eischen [010928 06:54] wrote: > > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > > * Julian Elischer [010928 02:44] wrote: > > > > > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > > > /* this process that has this ktc, */ > > > > /* then if it is sleeping, abort the syscall */ > > > > /* if it is running, let it continue but set */ > > > > /* flag so that if it tries to sleep, it aborts */ > > > > /* instead */ > > > > > > Unless I'm misunderstanding you, this will not be possible without > > > a tremendous amount of work, a variation that may work is allowing > > > the syscall to run to completion, returning the error code and then > > > aborting it. Too much code would have to change if tsleep became > > > a cancellation point. > > > > Think of this as kill() on a process; it shouldn't be too different. > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > otherwise it just remains pending until (and if) it is checked at a > > later point in time. Regardless of whether PCATCH is specified, the > > thread never returns to userland. The UTS is notified through an > > upcall in the same way that it would be if a thread blocked (but with > > a different completion status). > > This is quite different from winking out of existance when it tries > to sleep. :) Perhaps it would be better named kse_interrupt_thread()? Julian, we also need another parameter on this syscall so the UTS can specify how the context should be saved (SA_RESTART or not). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 5:15:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0DBB437B40C for ; Fri, 28 Sep 2001 05:15:26 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA03656; Fri, 28 Sep 2001 08:14:26 -0400 (EDT) Date: Fri, 28 Sep 2001 08:14:25 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <3BB4259D.4AF78B4@elischer.org> 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 Fri, 28 Sep 2001, Julian Elischer wrote: > > c) define the user interface so that userland code can start to be planned. > Here are some ideas.. > these are up for discussion.... > > /* embed this in the Userland thread info */ > struct kt_context { > struct kt_context *ktc_next_completed; > mcontext_t ktc_ctx; > void *ktc_UTS_private; > unsigned int ktc_return_info; > }; > > /* Need one of these per KSE. */ > struct ks_mailbox { > struct kt_context *ksm_curthread; > struct kt_context *ksm_completed; /* runnable threads */ > unsigned int ksm_upcall_reason; > /* probably some info for delivering signals */ > } We need a way for the UTS to specify whether the KSE is in a critical region don't we? I imagine having a word in the mailbox that when non-zero the kernel will not make another upcall to this KSE. Or are we using the stack pointer to tell if the UTS is currently in a KSE upcall? If the latter, perhaps it is better to explicitly pass the stack (possibly along with the ucontext_t) into the KSE creation so that the kernel knows exactly what the stack limits are. > possible syscalls.... > > int new_kse(struct ks_mailbox *mbox, int new_group); /* add a new KSE */ > /* maybe in a new kse group */ > > int yield_kse(struct timespec *sleeptime); /* don't come back till */ > /* time passed or work to do. */ > > int wake_kse(struct ks_mailbox *mbx); /* if we specify a yielded KSE * > /* both will return. NULL wakes any. */ > > void exit_kse(); /* Will not return, but */ > /* writes completion code in mailbox. */ > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > /* this process that has this ktc, */ > /* then if it is sleeping, abort the syscall */ > /* if it is running, let it continue but set */ > /* flag so that if it tries to sleep, it aborts */ > /* instead */ > > maybe reversing the sycall names... > kse_new(), kse_yield(), kse_wake(), kse_exit(), thread_abort() Yes, please :-) And rename thread_abort to kse_thread_abort, kse_thread_interrupt, or kse_thread_kill. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 7: 7:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 107D737B410 for ; Fri, 28 Sep 2001 07:07:15 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f8SE7Du53616; Fri, 28 Sep 2001 08:07:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f8SE7C781171; Fri, 28 Sep 2001 08:07:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109281407.f8SE7C781171@harmony.village.org> To: Bruce Evans Subject: Re: Proposed change: d_thread_t for driver portability between 4.x and 5.x Cc: arch@FreeBSD.org In-reply-to: Your message of "Fri, 28 Sep 2001 19:39:33 +1000." <20010928192532.M52718-100000@delplex.bde.org> References: <20010928192532.M52718-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81163.1001686029.1@harmony.village.org> Date: Fri, 28 Sep 2001 08:07:12 -0600 From: Warner Losh 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 <20010928192532.M52718-100000@delplex.bde.org> Bruce Evans writes: : This breaks 2 style rules :-). From style(9): : : Avoid using typedefs for structure types. Such typedefs make it impossi- : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : ble for applications to use pointers to such a structure opaquely, which : is both possible and beneficial when using an ordinary struct tag. When : convention requires a typedef, make its name match the struct tag. Avoid : ^^^^^ : typedefs ending in ``_t'', except as specified in Standard C or by POSIX. : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : : These are wollman's rules, not KNF. I strongly agree with them, but we have : too many of these personal rules which not everyone agreed to. I know. But you can't typedef a struct to be another struct. And it is no more broken than then d_open_t and this file isn't used by userland progarms. : I can see the use of d_thread_t^Hs if it is truly opaque. Declaring it : only in or even including breaks its opaqueness. : Unfortunately, the other rule-breaking declarations like d_open_t require : including the full in device drivers. It's another bug : that dev_t is not either truly opaque or declared as "struct foo *". Right. This is a portability aid that we need because it is clear that doing drivers for -current and -stable is going to be a big pita and people will invent their own, possibly wrong, ways of doing this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 9: 3:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 65FD137B40D for ; Fri, 28 Sep 2001 09:03:46 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA71163; Fri, 28 Sep 2001 09:58:39 -0700 (PDT) Date: Fri, 28 Sep 2001 09:58:39 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: KSE next steps... In-Reply-To: <20010928040113.B59854@elvis.mu.org> 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 Fri, 28 Sep 2001, Alfred Perlstein wrote: > * Julian Elischer [010928 02:44] wrote: > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > /* this process that has this ktc, */ > > /* then if it is sleeping, abort the syscall */ > > /* if it is running, let it continue but set */ > > /* flag so that if it tries to sleep, it aborts */ > > /* instead */ > > Unless I'm misunderstanding you, this will not be possible without > a tremendous amount of work, a variation that may work is allowing > the syscall to run to completion, returning the error code and then > aborting it. Too much code would have to change if tsleep became > a cancellation point. It's already a cancelation point.. I'm talking about keeping exactly the same behaviour as presently used when you send a signal to a process that is sleeping.... > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 9:23:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E796C37B405 for ; Fri, 28 Sep 2001 09:23:39 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA71230; Fri, 28 Sep 2001 10:02:41 -0700 (PDT) Date: Fri, 28 Sep 2001 10:02:39 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <20010928065553.D59854@elvis.mu.org> 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 it doesn't wink out of existance.. it just returns with an error condition, to the user boundary.. it has to free anything it allocated on the way in.... On Fri, 28 Sep 2001, Alfred Perlstein wrote: > * Daniel Eischen [010928 06:54] wrote: > > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > > * Julian Elischer [010928 02:44] wrote: > > > > > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > > > /* this process that has this ktc, */ > > > > /* then if it is sleeping, abort the syscall */ > > > > /* if it is running, let it continue but set */ > > > > /* flag so that if it tries to sleep, it aborts */ > > > > /* instead */ > > > > > > Unless I'm misunderstanding you, this will not be possible without > > > a tremendous amount of work, a variation that may work is allowing > > > the syscall to run to completion, returning the error code and then > > > aborting it. Too much code would have to change if tsleep became > > > a cancellation point. > > > > Think of this as kill() on a process; it shouldn't be too different. > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > otherwise it just remains pending until (and if) it is checked at a > > later point in time. Regardless of whether PCATCH is specified, the > > thread never returns to userland. The UTS is notified through an > > upcall in the same way that it would be if a thread blocked (but with > > a different completion status). > > This is quite different from winking out of existance when it tries > to sleep. :) > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 9:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 87AC137B40D for ; Fri, 28 Sep 2001 09:23:43 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA71232; Fri, 28 Sep 2001 10:03:39 -0700 (PDT) Date: Fri, 28 Sep 2001 10:03:39 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: KSE next steps... 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 ah yes, I forgot that .. :-) On Fri, 28 Sep 2001, Daniel Eischen wrote: > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > * Daniel Eischen [010928 06:54] wrote: > > > On Fri, 28 Sep 2001, Alfred Perlstein wrote: > > > > * Julian Elischer [010928 02:44] wrote: > > > > > > > > > > int abort_thread(struct kt_context *ktc); /* if we find a thread in */ > > > > > /* this process that has this ktc, */ > > > > > /* then if it is sleeping, abort the syscall */ > > > > > /* if it is running, let it continue but set */ > > > > > /* flag so that if it tries to sleep, it aborts */ > > > > > /* instead */ > > > > > > > > Unless I'm misunderstanding you, this will not be possible without > > > > a tremendous amount of work, a variation that may work is allowing > > > > the syscall to run to completion, returning the error code and then > > > > aborting it. Too much code would have to change if tsleep became > > > > a cancellation point. > > > > > > Think of this as kill() on a process; it shouldn't be too different. > > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > > otherwise it just remains pending until (and if) it is checked at a > > > later point in time. Regardless of whether PCATCH is specified, the > > > thread never returns to userland. The UTS is notified through an > > > upcall in the same way that it would be if a thread blocked (but with > > > a different completion status). > > > > This is quite different from winking out of existance when it tries > > to sleep. :) > > Perhaps it would be better named kse_interrupt_thread()? > > Julian, we also need another parameter on this syscall so the UTS can > specify how the context should be saved (SA_RESTART or not). > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 15:45:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 7290B37B40B; Fri, 28 Sep 2001 15:45:10 -0700 (PDT) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id E855D1D169; Fri, 28 Sep 2001 23:45:07 +0100 (BST) Date: Fri, 28 Sep 2001 23:45:07 +0100 From: Paul Richards To: Julian Elischer , John Baldwin Cc: Warner Losh , arch@FreeBSD.org Subject: Re: Style Wars Message-ID: <441890000.1001717107@lobster.originative.co.uk> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Thursday, September 27, 2001 18:52:15 -0700 Julian Elischer wrote: > > > On Thu, 27 Sep 2001, John Baldwin wrote: > >> [ moved to -arch ] >> >> On 28-Sep-01 Julian Elischer wrote: >> > well maybe We can come up with a tweek to the standard that we can >> > all agree to... >> > and commit.. It is after all a 'living' document.. >> >> Certainly a viable option. I've seen a couple of ideas so far: >> >> 1) Use two tabs instead of one when types longer than one tab such >> as u_int64_t are used. >> 1a) Same as 1) but the tabs after after the type, not just the >> first word. > > In my experience this works best, but with the added thought that > The aim is to get all the names to lign up as much as possible, > so the tab occurs before the name (or "*"). Could we perhaps modify style to state intent rather than the method. The intent here is to align the names; attempting to formulate a set method is too rigid and causes people to leap up and down when style isn't followed to the letter even when the outcome is not good looking code. Can't we change the general tone of style to say things like "names should be aligned for ease of readibility" rather than the rigid "one tab after type" etc. To avoid lots of whitespace problems there can be a general guidline that "tabs will be used as much as possible and the tabstop is 8" or something so that the previous statement that "names should be aligned" will lead to the minimum number of tabs plus additional spacing being used to do the alignment. I think stating intent, rather than method will reduce a lot of the quibbling over style issues because people will understand what's being aimed for and won't bridle so much over dogmatic rules. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 16:23:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id C253837B40C; Fri, 28 Sep 2001 16:23:28 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA72766; Fri, 28 Sep 2001 17:17:13 -0700 (PDT) Date: Fri, 28 Sep 2001 17:17:12 -0700 (PDT) From: Julian Elischer To: Paul Richards Cc: John Baldwin , Warner Losh , arch@FreeBSD.org Subject: Re: Style Wars In-Reply-To: <441890000.1001717107@lobster.originative.co.uk> 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 Fri, 28 Sep 2001, Paul Richards wrote: > Could we perhaps modify style to state intent rather than the method. > > The intent here is to align the names; attempting to formulate a set method > is too rigid and causes people to leap up and down when style isn't > followed to the letter even when the outcome is not good looking code. > > Can't we change the general tone of style to say things like > > "names should be aligned for ease of readibility" > > rather than the rigid "one tab after type" etc. > > To avoid lots of whitespace problems there can be a general guidline that > "tabs will be used as much as possible and the tabstop is 8" or something > so that the previous statement that "names should be aligned" will lead to > the minimum number of tabs plus additional spacing being used to do the > alignment. > > I think stating intent, rather than method will reduce a lot of the > quibbling over style issues because people will understand what's being > aimed for and won't bridle so much over dogmatic rules. Not a bad idea. "When defining sub elements of a structure, tabs should be used to allign the name parts so as to ease reading." e.g. [example given in previous mail] (end quote) " > > > Paul Richards > FreeBSD Services Ltd > http://www.freebsd-services.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 16:31:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 40EEA37B432; Fri, 28 Sep 2001 16:31:49 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f8SNVlu55433; Fri, 28 Sep 2001 17:31:48 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id f8SNVj784249; Fri, 28 Sep 2001 17:31:45 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109282331.f8SNVj784249@harmony.village.org> To: Julian Elischer Subject: Re: Style Wars Cc: Paul Richards , John Baldwin , arch@FreeBSD.org In-reply-to: Your message of "Fri, 28 Sep 2001 17:17:12 PDT." References: Date: Fri, 28 Sep 2001 17:31:45 -0600 From: Warner Losh 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 Julian Elischer writes: : > I think stating intent, rather than method will reduce a lot of the : > quibbling over style issues because people will understand what's being : > aimed for and won't bridle so much over dogmatic rules. : : : Not a bad idea. : : "When defining sub elements of a structure, tabs should be used : to allign the name parts so as to ease reading." : e.g. : : [example given in previous mail] : (end quote) " The difficult part in doing intent based rules is that in the past we was many style commits back and forth as different people interpreted the rules differently. The more rigid the rules, the more anybody will know if things are in compliance. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 16:32: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id E5BA337B40E; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f8SNVkM33653; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8959B3809; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: Julian Elischer , Warner Losh , arch@FreeBSD.ORG Subject: Re: Style Wars In-Reply-To: Date: Fri, 28 Sep 2001 16:31:46 -0700 From: Peter Wemm Message-Id: <20010928233146.8959B3809@overcee.netplex.com.au> 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 John Baldwin wrote: > [ moved to -arch ] > > On 28-Sep-01 Julian Elischer wrote: > > well maybe We can come up with a tweek to the standard that we can > > all agree to... > > and commit.. It is after all a 'living' document.. > > Certainly a viable option. I've seen a couple of ideas so far: > > 1) Use two tabs instead of one when types longer than one tab such > as u_int64_t are used. > 1a) Same as 1) but the tabs after after the type, not just the > first word. 1b) Same as 1a), but also with 2) for types longer than two tabs. ie: "struct verylongtypename *foo;" > 2) Use a space instead of a tab after types longer than one tab like > we already do for queue macros. > style(9): > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 1) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; > > 1a) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; 1b) struct foo { int f_type; struct mtx f_lock; const char *f_name; volatile int f_int; u_int64_t f_64; const volatile char f_cv; TAILQ_ENTRY(foo) f_link; }; > 2) is probably the closest to existing style. My personal preference would b e > for 3) with an additional note about sorting so that within logical groups of > members, you would sort the items such that the longest types are first. > *shrug* I think 4) is just insane. Perhaps if you modified it so that it > combined types and qualifiers into the same column it wouldn't be so bad > however. > > I like green bikesheds. Specifically dark green, even forest green is pretty > good. :) I like 1b) which has some aspects of 2) (the space for overflows) Yes, 4) is insane. Lets Not Go There. :-) I could live with 3) but prefer 1b). There is a *lot* of code in 1b) style in the tree already. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 16:54:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 33BCD37B40E for ; Fri, 28 Sep 2001 16:54:19 -0700 (PDT) Received: (qmail 54639 invoked from network); 28 Sep 2001 23:54:18 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Sep 2001 23:54:18 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010928233146.8959B3809@overcee.netplex.com.au> Date: Fri, 28 Sep 2001 16:54:01 -0700 (PDT) From: John Baldwin To: Peter Wemm Subject: Re: Style Wars Cc: arch@FreeBSD.ORG, Warner Losh , Julian Elischer 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 28-Sep-01 Peter Wemm wrote: > John Baldwin wrote: >> [ moved to -arch ] >> >> On 28-Sep-01 Julian Elischer wrote: >> > well maybe We can come up with a tweek to the standard that we can >> > all agree to... >> > and commit.. It is after all a 'living' document.. >> >> Certainly a viable option. I've seen a couple of ideas so far: >> >> 1) Use two tabs instead of one when types longer than one tab such >> as u_int64_t are used. >> 1a) Same as 1) but the tabs after after the type, not just the >> first word. > > 1b) Same as 1a), but also with 2) for types longer than two tabs. > ie: "struct verylongtypename *foo;" > >> 2) Use a space instead of a tab after types longer than one tab like >> we already do for queue macros. I'm think 1b) is the one most people have favored so far and it is rather close to our existing style, so it's not that big of a change. Does anyone object to 1b)? It basically results in the following changes: use 2 tab spaces instead of 1 for type names, put the entire type name before the tab(s), and if the type is too long, just use a space. > 1b) > > struct foo { > int f_type; > struct mtx f_lock; > const char *f_name; > volatile int f_int; > u_int64_t f_64; > const volatile char f_cv; > TAILQ_ENTRY(foo) f_link; > }; -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 17: 1:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 8BF7E37B40B; Fri, 28 Sep 2001 17:01:46 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f8SNxDP98386; Fri, 28 Sep 2001 18:59:13 -0500 (CDT) (envelope-from jlemon) Date: Fri, 28 Sep 2001 18:59:13 -0500 From: Jonathan Lemon To: John Baldwin Cc: Peter Wemm , arch@FreeBSD.ORG, Warner Losh , Julian Elischer Subject: Re: Style Wars Message-ID: <20010928185913.U9056@prism.flugsvamp.com> References: <20010928233146.8959B3809@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: 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 Fri, Sep 28, 2001 at 04:54:01PM -0700, John Baldwin wrote: > > On 28-Sep-01 Peter Wemm wrote: > > John Baldwin wrote: > >> [ moved to -arch ] > >> > >> On 28-Sep-01 Julian Elischer wrote: > >> > well maybe We can come up with a tweek to the standard that we can > >> > all agree to... > >> > and commit.. It is after all a 'living' document.. > >> > >> Certainly a viable option. I've seen a couple of ideas so far: > >> > >> 1) Use two tabs instead of one when types longer than one tab such > >> as u_int64_t are used. > >> 1a) Same as 1) but the tabs after after the type, not just the > >> first word. > > > > 1b) Same as 1a), but also with 2) for types longer than two tabs. > > ie: "struct verylongtypename *foo;" > > > >> 2) Use a space instead of a tab after types longer than one tab like > >> we already do for queue macros. > > I'm think 1b) is the one most people have favored so far and it is rather close > to our existing style, so it's not that big of a change. Does anyone object to > 1b)? It basically results in the following changes: use 2 tab spaces instead > of 1 for type names, put the entire type name before the tab(s), and if the > type is too long, just use a space. I prefer 1) (and the 1b variant), but not 1a). (e.g.: ) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 17: 5:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5324037B406; Fri, 28 Sep 2001 17:05:10 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f8T059x97697; Fri, 28 Sep 2001 17:05:09 -0700 (PDT) (envelope-from obrien) Date: Fri, 28 Sep 2001 17:05:09 -0700 From: "David O'Brien" To: John Baldwin Cc: arch@FreeBSD.org, Julian Elischer Subject: Re: Style Wars Message-ID: <20010928170509.A97492@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010927185607.A90848@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Sep 27, 2001 at 11:50:09PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Thu, Sep 27, 2001 at 11:50:09PM -0700, John Baldwin wrote: > > On 28-Sep-01 David O'Brien wrote: > > On Thu, Sep 27, 2001 at 05:36:31PM -0700, John Baldwin wrote: > >> for 3) with an additional note about sorting so that within logical groups > >> of > >> members, you would sort the items such that the longest types are first. > > > > Please clarify what you are saying here. > > Longest type measured as strlen(typename). :) I.e.: That is what I thought you were saying -- that breaks the rule to sort the members by decreasing order of `sizeof'. (which is actually has a functionality element of it) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 17:44:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 47BA537B40C for ; Fri, 28 Sep 2001 17:44:18 -0700 (PDT) Received: (qmail 87880 invoked from network); 29 Sep 2001 00:44:17 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 29 Sep 2001 00:44:17 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010928170509.A97492@dragon.nuxi.com> Date: Fri, 28 Sep 2001 17:44:00 -0700 (PDT) From: John Baldwin To: "David O'Brien" Subject: Re: Style Wars Cc: Julian Elischer , 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 On 29-Sep-01 David O'Brien wrote: > On Thu, Sep 27, 2001 at 11:50:09PM -0700, John Baldwin wrote: >> >> On 28-Sep-01 David O'Brien wrote: >> > On Thu, Sep 27, 2001 at 05:36:31PM -0700, John Baldwin wrote: >> >> for 3) with an additional note about sorting so that within logical >> >> groups >> >> of >> >> members, you would sort the items such that the longest types are first. >> > >> > Please clarify what you are saying here. >> >> Longest type measured as strlen(typename). :) I.e.: > > That is what I thought you were saying -- that breaks the rule to sort > the members by decreasing order of `sizeof'. (which is actually has a > functionality element of it) "Within logical groups of members". Specifying the order of things in a struct is probably not going to be a fruitful cause, however. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 28 19: 4:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 6E60437B40A; Fri, 28 Sep 2001 19:04:35 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f8T24Tf99103; Fri, 28 Sep 2001 19:04:29 -0700 (PDT) (envelope-from obrien) Date: Fri, 28 Sep 2001 19:04:27 -0700 From: "David O'Brien" To: John Baldwin Cc: Julian Elischer , arch@FreeBSD.org Subject: Re: Style Wars Message-ID: <20010928190427.B98886@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010928170509.A97492@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Sep 28, 2001 at 05:44:00PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Fri, Sep 28, 2001 at 05:44:00PM -0700, John Baldwin wrote: > >> On 28-Sep-01 David O'Brien wrote: > >> > On Thu, Sep 27, 2001 at 05:36:31PM -0700, John Baldwin wrote: > >> >> for 3) with an additional note about sorting so that within logical > >> >> groups > >> >> of > >> >> members, you would sort the items such that the longest types are first. > >> > > >> > Please clarify what you are saying here. > >> > >> Longest type measured as strlen(typename). :) I.e.: > > > > That is what I thought you were saying -- that breaks the rule to sort > > the members by decreasing order of `sizeof'. (which is actually has a > > functionality element of it) > > "Within logical groups of members". Please define "within logical groups of members". That is one of the things I was hoping you'd clarify. :-) > Specifying the order of things in > a struct is probably not going to be a fruitful cause, however. It is done for alignment reasons. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 1:44:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 790C437B408; Sat, 29 Sep 2001 01:44:14 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id CAA74589; Sat, 29 Sep 2001 02:31:32 -0700 (PDT) Message-ID: <3BB58776.C41A6E56@elischer.org> Date: Sat, 29 Sep 2001 01:33:58 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: Peter Wemm , arch@FreeBSD.ORG, Warner Losh Subject: Re: Style Wars References: Content-Type: text/plain; charset=iso-8859-2 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 John Baldwin wrote: > > On 28-Sep-01 Peter Wemm wrote: > > John Baldwin wrote: > >> [ moved to -arch ] > >> > >> On 28-Sep-01 Julian Elischer wrote: > >> > well maybe We can come up with a tweek to the standard that we can > >> > all agree to... > >> > and commit.. It is after all a 'living' document.. > >> > >> Certainly a viable option. I've seen a couple of ideas so far: > >> > >> 1) Use two tabs instead of one when types longer than one tab such > >> as u_int64_t are used. > >> 1a) Same as 1) but the tabs after after the type, not just the > >> first word. > > > > 1b) Same as 1a), but also with 2) for types longer than two tabs. > > ie: "struct verylongtypename *foo;" > > > >> 2) Use a space instead of a tab after types longer than one tab like > >> we already do for queue macros. > > I'm think 1b) is the one most people have favored so far and it is rather close > to our existing style, so it's not that big of a change. Does anyone object to > 1b)? It basically results in the following changes: use 2 tab spaces instead > of 1 for type names, put the entire type name before the tab(s), and if the > type is too long, just use a space. that gets my vote.. note: 2 tabs may be overkill if the structure only contains simple types e.g. int, char, short... probably worth noting in style, that the intent is to try to approximatly align the names for ease of reading.... > > > 1b) > > > > struct foo { > > int f_type; > > struct mtx f_lock; > > const char *f_name; > > volatile int f_int; > > u_int64_t f_64; > > const volatile char f_cv; > > TAILQ_ENTRY(foo) f_link; > > }; > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 11: 2:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DC27337B40B; Sat, 29 Sep 2001 11:02:45 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8TI2jd38468; Sat, 29 Sep 2001 11:02:45 -0700 (PDT) (envelope-from dillon) Date: Sat, 29 Sep 2001 11:02:45 -0700 (PDT) From: Matt Dillon Message-Id: <200109291802.f8TI2jd38468@earth.backplane.com> To: John Baldwin Cc: Julian Elischer , Warner Losh , arch@FreeBSD.ORG Subject: Re: Style Wars References: 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 Ick. Is this going to turn into yet another thing in style that I am going to have to ignore? -Matt struct foo { int f_type; /* blah blah */ struct mtx f_lock; /* blah blah */ const char *f_name; /* blah blah */ volatile int f_int; /* blah blah */ u_int64_t f_64; /* blah blah */ TAILQ_ENTRY(foo) f_link; /* blah blah */ const volatile char f_cv; /* blah blah */ }; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 11:17:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 1BC5F37B409 for ; Sat, 29 Sep 2001 11:17:35 -0700 (PDT) Received: from mindspring.com (dialup-209.245.140.105.Dial1.SanJose1.Level3.net [209.245.140.105]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f8TIHTa01519; Sat, 29 Sep 2001 11:17:30 -0700 (PDT) Message-ID: <3BB6106A.A44644BB@mindspring.com> Date: Sat, 29 Sep 2001 11:18:18 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Alfred Perlstein , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... References: 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 Daniel Eischen wrote: [ ... pthread_kill ... ] > Think of this as kill() on a process; it shouldn't be too different. > If PCATCH is specified in the tsleep, then it is terminated immediately, > otherwise it just remains pending until (and if) it is checked at a > later point in time. Regardless of whether PCATCH is specified, the > thread never returns to userland. The UTS is notified through an > upcall in the same way that it would be if a thread blocked (but with > a different completion status). You need to read the manual page for pthread_kill(3P). Minimally, #include int pthread_kill(pthread_t thread, int sig); ...meaning that you can send _any_ signal, not just "SIGINT". The delivery is to a specific thread. This pretty much means triggering the EINTR cancellation, but doing the delivery in user space to a particular thread. The cancellation aspect assumes, of course, that SA_RESTART isn't specified (and/or siginterrupt(2) wasn't called). AIX has a nice brokeness in pthread_signal(3P), which results in MySQL and other programs which use it having a tough time. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 11:22:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 821F437B409; Sat, 29 Sep 2001 11:22:25 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA76556; Sat, 29 Sep 2001 12:03:09 -0700 (PDT) Message-ID: <3BB60D52.4A29F52E@elischer.org> Date: Sat, 29 Sep 2001 11:05:07 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Matt Dillon Cc: John Baldwin , Warner Losh , arch@FreeBSD.ORG Subject: Re: Style Wars References: <200109291802.f8TI2jd38468@earth.backplane.com> Content-Type: text/plain; charset=iso-8859-2 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 Matt Dillon wrote: > > Ick. Is this going to turn into yet another thing in style that I > am going to have to ignore? > > -Matt > > struct foo { > int f_type; /* blah blah */ > struct mtx f_lock; /* blah blah */ > const char *f_name; /* blah blah */ > volatile int f_int; /* blah blah */ > u_int64_t f_64; /* blah blah */ > TAILQ_ENTRY(foo) f_link; /* blah blah */ > const volatile char f_cv; /* blah blah */ > }; well what would your prefered style be? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 13: 4:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.gnf.org (relay.gnf.org [208.44.31.36]) by hub.freebsd.org (Postfix) with ESMTP id ECBC637B40A for ; Sat, 29 Sep 2001 13:04:22 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [10.0.0.11]) by relay.gnf.org (8.11.6/8.11.6) with ESMTP id f8TK4Mj22043 for ; Sat, 29 Sep 2001 13:04:22 -0700 Received: by mail.gnf.org (Postfix, from userid 888) id 6C99F11E504; Sat, 29 Sep 2001 13:03:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 6847511A577 for ; Sat, 29 Sep 2001 13:03:35 -0700 (PDT) Date: Sat, 29 Sep 2001 13:03:35 -0700 (PDT) From: Gordon Tetlow To: Subject: nfsd and mountd in the wrong place 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 nfsd and mountd are in /sbin rpcbind/portmap is in /usr/sbin nfsd and mountd aren't useful without rpcbind/portmap. And when was the last time you needed nfsd and mountd to boot your system? I just checked, NetBSD has already moved nfsd and mountd to /usr/sbin. Is there any reason why nfsd or mountd shouldn't be moved to /usr/sbin? -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 29 18:45: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id ED18637B408 for ; Sat, 29 Sep 2001 18:45:02 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id VAA26144; Sat, 29 Sep 2001 21:44:03 -0400 (EDT) Date: Sat, 29 Sep 2001 21:44:03 -0400 (EDT) From: Daniel Eischen To: Terry Lambert Cc: Alfred Perlstein , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE next steps... In-Reply-To: <3BB6106A.A44644BB@mindspring.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, 29 Sep 2001, Terry Lambert wrote: > Daniel Eischen wrote: > [ ... pthread_kill ... ] > > > Think of this as kill() on a process; it shouldn't be too different. > > If PCATCH is specified in the tsleep, then it is terminated immediately, > > otherwise it just remains pending until (and if) it is checked at a > > later point in time. Regardless of whether PCATCH is specified, the > > thread never returns to userland. The UTS is notified through an > > upcall in the same way that it would be if a thread blocked (but with > > a different completion status). > > You need to read the manual page for pthread_kill(3P). > > Minimally, > > #include > > int > pthread_kill(pthread_t thread, int sig); > > ...meaning that you can send _any_ signal, not just "SIGINT". The > delivery is to a specific thread. You misinterpret what I wrote. I just meant that abort_thread() behaves in the same way on a thread as kill() does on a process. The process leaves the kernel and returns to the installed signal handler (assuming the signal is unmasked). The same thing happens for abort_thread(), except instead of returning to a signal handler, it returns via an upcall. The mechanism for leaving the kernel need not be any different, except instead of using the signal trampoline to return, it uses an upcall. By default, a KSE enabled process will not get signals delivered in the normal way anyways. Signals will be delivered via an upcall, so you could just view abort_thread() as delivering a signal that can never be masked. > This pretty much means triggering the EINTR cancellation, but > doing the delivery in user space to a particular thread. The > cancellation aspect assumes, of course, that SA_RESTART isn't > specified (and/or siginterrupt(2) wasn't called). Right. But we're adding a flag to abort_thread() so the UTS can specify whether the thread's context should be saved as if it returned from the system call (with EINTR), or if it had not performed the syscall yet (SA_RESTART). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message