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