Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 12:20:45 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        "M. Warner Losh" <imp@bsdimp.com>, bright@mu.org, arch@FreeBSD.ORG
Subject:   Re: M_ flags summary.
Message-ID:  <Pine.GSO.4.10.10301221211510.29028-100000@pcnet1.pcnet.com>
In-Reply-To: <20030122100253.A76397@unixdaemons.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Jan 2003, Bosko Milekic wrote:
> On Tue, Jan 21, 2003 at 10:20:25PM -0700, M. Warner Losh wrote:
> > In message: <20030121224148.A75236@unixdaemons.com>
> >             Bosko Milekic <bmilekic@unixdaemons.com> writes:
> > :   I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is
> > :   fine but I do not think that defining them to anything other than 0 is
> > :   fine just so that we could add that KASSERT() that Warren suggested in
> > :   the allocation code.  As you point out, defining it to anything other
> > :   than 0 would actually break ABI compatibility.  Defining it to 0 for
> > :   KLD_MODULES would preserve both API and ABI compatibility for those
> > :   who actually care.  Certainly, both M_TRYWAIT and M_WAITOK would have
> > :   to be defined in order to maintain full backwards-API compatibility.
> > 
> > Actually, I think that we shouldn't define them to be 0 for modules.
> > Instead, we should define them to the new values.  However, we should
> > accpet '0' with the old meaning for a while (maybe with a printf).
> > There are going to be enough ABI changes between 5.0 and 5.branch that
> > worrying about this one is likely not worth the effort to do special
> > things for the modules.  It isn't going to be too much longer before
> > it becomes impossible for 5.0-RELEASE compiled modules to not operate
> > with 5.0-CURRENT.

  [ Good summary elided ]

Bosko convinces me.  One other thing.  How about adding another
version of malloc that _only_ acts as if M_NOWAIT was specified
and disallow M_NOWAIT from the original malloc()?  If flags
confusion is a problem, then provide versions of malloc()
that don't have flags as arguments, or perhaps don't allow
M_WAITOK or M_NOWAIT.

-- 
Dan Eischen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10301221211510.29028-100000>