Date: Wed, 20 May 2009 10:26:12 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: arch@freebsd.org Subject: Re: Remove d_thread_t for 8.0 Message-ID: <20090520.102612.-1795528612.imp@bsdimp.com> In-Reply-To: <200905201124.24747.jhb@freebsd.org> References: <200905121020.18497.jhb@freebsd.org> <20090520.085924.-1935226744.imp@bsdimp.com> <200905201124.24747.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200905201124.24747.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: On Wednesday 20 May 2009 10:59:24 am M. Warner Losh wrote:
: > In message: <200905121020.18497.jhb@freebsd.org>
: > John Baldwin <jhb@freebsd.org> writes:
: > : In the same vein as purging BURN_BRIDGES stuff, is there any objection to
: > : removing d_thread_t from 8.0? It is intended as a compat shim to reduce
: > : diffs with 4.x. However, at this point drivers are not actively being
: merged
: > : back to 4.x, so I think it is no longer necessary.
: >
: > It was also intended to allow easier sharing for folks that were using
: > FreeBSD 4.x, 5.x, etc. I know that at least one user still has some
: > 4.x deployments, but I suspect that they are otherwise off 4.x so it
: > might not be a problem for them. It would be yet another thing to
: > change when going from 7.x to 8.x for them...
: >
: > We certainly should remove it from the drivers in the tree for 8.0.
: > Right now it is used in about a two dozen places.
:
: Even in a shared driver I believe the function prototypes for devsw routines
: would already have to be #ifdef'd due to the 'dev_t' -> 'struct cdev *'
: change which does have a similar foo_t typedef to ease the transition. Given
: that, any code compiled for 7.0+ is already using a function prototype that
: is not compatible with 4.x and there isn't a need for it to use d_thread_t.
: They can just use 'struct thread *' always when using 'struct cdev *'.
Yes. Let's eliminate it from the tree, and then talk about removing
it from conf.h :) There's other ways to paper over those issues, and I
know that they are relatively small in header files. But those
headers are likely beyond the scope of what the project has to
support..
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090520.102612.-1795528612.imp>