Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Mar 2003 22:02:59 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Alfred Perlstein <bright@mu.org>, <src-committers@FreeBSD.org>, <cvs-src@FreeBSD.org>, <cvs-all@FreeBSD.org>, <bde@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/kern vfs_default.c
Message-ID:  <20030304214414.A37482-100000@gamplex.bde.org>
In-Reply-To: <20030303203530.D72102-100000@mail.chesapeake.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Mar 2003, Jeff Roberson wrote:

> On Mon, 3 Mar 2003, Alfred Perlstein wrote:
>
> > * Jeff Roberson <jroberson@chesapeake.net> [030303 16:39] wrote:
> > > On Mon, 3 Mar 2003, Alfred Perlstein wrote:
> > > > >   Log:
> > > > >    - Correct the wchan in vop_stdfsync()
> > > > >
> > > > >   This is almost what bde asked for.  There is some desire to have per fs wchans
> > > > >   still but that is difficult giving the current arrangement of the code.
> > >
> > > char wchanbuf[7] = "  sync";
> > > wchanbuf[0] = vp->v_type[0];
> > > wchanbuf[1] = vp->v_type[1];

I'd prefer more of "fsync" in the name (fsync != sync).  ffs_fsync()
abbreviates "fsync" to "fsn" and doesn't abbreviate its own name, giving
the rather cryptic sleep message of "ffsfsn".

I don't want this to take long at runtime.  The above is probably OK,
but snprintf() wouldn't be.  Use a character array of size 8 so that it
can be initialized with word-wide writes on normal machines and check that
gcc generates only 1 or 2 word-wide writes to initialize it.  Unfortunately
the 3+3 split prevents the v_type assignment being compiled to a single
(16 or 32 but) assignment.

> > Although I provided that intial suggestion I'm actually opposed to
> > non-const strings being passed into tsleep.  The reaon being, if
> > someone gets a process wedged, it should be trivial to grep for the
> > wchan that it's stuck in.  Adding something like this, while pretty
> > actually would make it harder to debug things later.

Do you mean literal constant strings?  I tend to agree, but ...

> > While this one exception wouldn't be too bad I'm afraid it will lead
> > to (un)clever abuses later.

... almost everything is not a literal constant already.  Examples include
- strings passed down to sleeps in locking functions.
- __func__ instead of literal function names in panics and KASSERTs.
- ANSI string concatenation used to obfuscate literal strings.

> Any comments bde?  This seems like a bit of a judgement call to me.  I'm
> not sure which I prefer.

See above.

Bruce


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?20030304214414.A37482-100000>