Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jan 2003 20:51:28 -0500 (EST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        Nate Lawson <nate@root.org>, Bruce Evans <bde@zeta.org.au>, Alfred Perlstein <alfred@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi
Message-ID:  <20030121204518.F46974-100000@mail.chesapeake.net>
In-Reply-To: <20030121203745.A74950@unixdaemons.com>

next in thread | previous in thread | raw e-mail | index | archive | help
 On Tue, 21 Jan 2003, Bosko Milekic wrote:

>
> On Tue, Jan 21, 2003 at 05:29:47PM -0800, Nate Lawson wrote:
> > On Wed, 22 Jan 2003, Bruce Evans wrote:
> > > > On Tue, 21 Jan 2003, Alfred Perlstein wrote:
> > > > >   Log:
> > > > >   Remove M_TRYWAIT/M_WAITOK/M_WAIT.  Callers should use 0.
> > > > >   Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
> > >
> > > Robert Watson wrote:
> > > > Hmm.  I guess I missed the discussion; I'm a bit behind on mailing lists.
> > > > To improve code portability and careful thinking by developers, what I'd
> > > > like to see is something more like the following: M_WAITOK, which
> > > > explicitly requests sleeping indefinitely, M_NOWAIT, which explicitly
> > > > requests no sleeping.  Rather than a "default" value, a
> > >
> > > That's exactly what M_WAITOK was supposed to do.  Developers just had to
> > > think about it since it wasn't really a flag so it was not easy to check
> > > automatically.
> >
> > I like Robert's approach -- keep the flags as they were before but give
> > M_WAITOK a value other than 0 and deprecate passing in 0 as an arg.  This
> > change only would affect binary kld compat and if 0 only generated a
> > printf warning (one-shot) but still meant M_WAITOK for a little while,
> > that would ease the migration.
> >
> > -Nate
>
>   The compatibility argument doesn't really carry that much weight
>   'cause you have to remember that our semantics are actually different
>   from the other BSDs.  I can certainly confirm this for the mbuf code.
>   For example, we already have a different name for the "wait"
>   equivalent of the flag (it's M_TRYWAIT not M_WAIT) and, further,
>   calling the allocator function with M_TRYWAIT for us doesn't mean the
>   same thing as calling the allocator function with M_WAIT does on the
>   other BSDs (for the mbuf code, anyway).  Furthermore, I think that the
>   other BSDs still actually 'share' the wait and dontwait flags with the
>   between the malloc() and mbuf allocator subsystems (somewhat for
>   historical reasons on which I can elaborate if you think that it's
>   necessary).
>
>   Clearly, we've already got not only API differences but even more
>   importantly semantics differences with the other BSDs in this area.
>   Fighting to keep the old code for 'compatibility' reasons is therefore
>   kind of pointless.
>

Not when you consider the huge amount of externally maintained kernel
code and the time required to adjust that code to sync up with changes
like this.

Personally, I think the value that looks like a flag, is mostly treated
like a flag, but you can't test like a flag is just asking for foot
shooting.  I think we should depreciate it with verbage for 5.0 and do
something more sane for 6.0.  I think 'more sane' is mostly a bike shed
but obviously something other than what we currently have.  I'll let
others comment on that.

Even though I knew it was not a flag I still got it wrong twice in uma,
btw.  So it is on my list of things that would be nice to do once we
branch 5.1 off of head.

Cheers,
Jeff


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




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