Re: svn commit: r232894 - head/contrib/llvm/tools/clang/lib/Basic

2012-03-12 Thread Alexander Best
On Mon Mar 12 12, Dimitry Andric wrote:
> Author: dim
> Date: Mon Mar 12 21:07:22 2012
> New Revision: 232894
> URL: http://svn.freebsd.org/changeset/base/232894
> 
> Log:
>   Pull in r145194 from upstream clang trunk:
>   
> Make our handling of MMX x SSE closer to what gcc does:
>   
> * Enabling sse enables mmx.
> * Disabling (-mno-mmx) mmx, doesn't disable sse (we got this right 
> already).
> * The order in not important. -msse -mno-mmx is the same as -mno-mmx 
> -msse.

are you sure that sys/conf/kern.mk doesn't need updating after this commit? if
now setting -mno-mmx doesn't imply -mno-sse, i think the i386 and amd64
sections in kern.mk needs to be updated (along with the comments).

cheers.
alex

>   
>   Some configure scripts depend on this.
>   
>   PR: i386/165968
>   MFC after:  3 days
> 
> Modified:
>   head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> 
> Modified: head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> ==
> --- head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp   Mon Mar 12 
> 20:59:18 2012(r232893)
> +++ head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp   Mon Mar 12 
> 21:07:22 2012(r232894)
> @@ -1583,23 +1583,26 @@ bool X86TargetInfo::setFeatureEnabled(ll
>(Name != "sse4" && Name != "sse4.2" && Name != "sse4.1"))
>  return false;
>  
> +  // FIXME: this should probably use a switch with fall through.
> +
>if (Enabled) {
>  if (Name == "mmx")
>Features["mmx"] = true;
>  else if (Name == "sse")
> -  Features["sse"] = true;
> +  Features["mmx"] = Features["sse"] = true;
>  else if (Name == "sse2")
> -  Features["sse"] = Features["sse2"] = true;
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = true;
>  else if (Name == "sse3")
> -  Features["sse"] = Features["sse2"] = Features["sse3"] = true;
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
> +true;
>  else if (Name == "ssse3")
> -  Features["sse"] = Features["sse2"] = Features["sse3"] =
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
>  Features["ssse3"] = true;
>  else if (Name == "sse4" || Name == "sse4.2")
> -  Features["sse"] = Features["sse2"] = Features["sse3"] =
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
>  Features["ssse3"] = Features["sse41"] = Features["sse42"] = true;
>  else if (Name == "sse4.1")
> -  Features["sse"] = Features["sse2"] = Features["sse3"] =
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
>  Features["ssse3"] = Features["sse41"] = true;
>  else if (Name == "3dnow")
>Features["mmx"] = Features["3dnow"] = true;
> @@ -1608,10 +1611,11 @@ bool X86TargetInfo::setFeatureEnabled(ll
>  else if (Name == "aes")
>Features["aes"] = true;
>  else if (Name == "avx")
> -  Features["avx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
> -Features["ssse3"] = Features["sse41"] = Features["sse42"] = true;
> +  Features["mmx"] = Features["sse"] = Features["sse2"] = 
> Features["sse3"] =
> +Features["ssse3"] = Features["sse41"] = Features["sse42"] =
> +Features["avx"] = true;
>  else if (Name == "sse4a")
> -  Features["sse4a"] = true;
> +  Features["mmx"] = Features["sse4a"] = true;
>} else {
>  if (Name == "mmx")
>Features["mmx"] = Features["3dnow"] = Features["3dnowa"] = false;
> @@ -3779,13 +3783,32 @@ TargetInfo *TargetInfo::CreateTargetInfo
>Target->getDefaultFeatures(Features);
>  
>// Apply the user specified deltas.
> +  // First the enables.
>for (std::vector::const_iterator it = Opts.Features.begin(),
>   ie = Opts.Features.end(); it != ie; ++it) {
>  const char *Name = it->c_str();
>  
> +if (Name[0] != '+')
> +  continue;
> +
> +// Apply the feature via the target.
> +if (!Target->setFeatureEnabled(Features, Name + 1, true)) {
> +  Diags.Report(diag::err_target_invalid_feature) << Name;
> +  return 0;
> +}
> +  }
> +
> +  // Then the disables.
> +  for (std::vector::const_iterator it = Opts.Features.begin(),
> + ie = Opts.Features.end(); it != ie; ++it) {
> +const char *Name = it->c_str();
> +
> +if (Name[0] == '+')
> +  continue;
> +
>  // Apply the feature via the target.
> -if ((Name[0] != '-' && Name[0] != '+') ||
> -!Target->setFeatureEnabled(Features, Name + 1, (Name[0] == '+'))) {
> +if (Name[0] != '-' ||
> +!Target->setFeatureEnabled(Features, Name + 1, false)) {
>Diags.Report(diag::err_target_invalid_feature) << Name;
>return 0;
>  }
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To uns

Re: svn commit: r232183 - head/sys/kern

2012-02-28 Thread Alexander Best
On Sun Feb 26 12, Jilles Tjoelker wrote:
> Author: jilles
> Date: Sun Feb 26 15:14:29 2012
> New Revision: 232183
> URL: http://svn.freebsd.org/changeset/base/232183
> 
> Log:
>   Fix fchmod() and fchown() on fifos.
>   
>   The new fifo implementation in r232055 broke fchmod() and fchown() on fifos.
>   Postfix needs this.

clang seems to have a problem with this commit:

usr/subversion-src/sys/kern/sys_pipe.c:1556:10: error: promoted type 'int' of 
K&R function parameter is not compatible with the parameter type 'mode_t' (aka 
'unsigned short') declared in a previous prototype [-Werror]
mode_t mode;
   ^
/usr/subversion-src/sys/kern/sys_pipe.c:155:19: note: previous declaration is 
here
static fo_chmod_t   pipe_chmod;
^
1 error generated.
*** Error code 1

cheers.
alex

>   
>   Submitted by:   gianni
>   Reported by:dougb
> 
> Modified:
>   head/sys/kern/sys_pipe.c
> 
> Modified: head/sys/kern/sys_pipe.c
> ==
> --- head/sys/kern/sys_pipe.c  Sun Feb 26 14:27:34 2012(r232182)
> +++ head/sys/kern/sys_pipe.c  Sun Feb 26 15:14:29 2012(r232183)
> @@ -152,6 +152,8 @@ static fo_poll_t  pipe_poll;
>  static fo_kqfilter_t pipe_kqfilter;
>  static fo_stat_t pipe_stat;
>  static fo_close_tpipe_close;
> +static fo_chmod_tpipe_chmod;
> +static fo_chown_tpipe_chown;
>  
>  struct fileops pipeops = {
>   .fo_read = pipe_read,
> @@ -162,8 +164,8 @@ struct fileops pipeops = {
>   .fo_kqfilter = pipe_kqfilter,
>   .fo_stat = pipe_stat,
>   .fo_close = pipe_close,
> - .fo_chmod = invfo_chmod,
> - .fo_chown = invfo_chown,
> + .fo_chmod = pipe_chmod,
> + .fo_chown = pipe_chown,
>   .fo_flags = DFLAG_PASSABLE
>  };
>  
> @@ -1548,6 +1550,43 @@ pipe_close(fp, td)
>   return (0);
>  }
>  
> +static int
> +pipe_chmod(fp, mode, active_cred, td)
> + struct file *fp;
> + mode_t mode;
> + struct ucred *active_cred;
> + struct thread *td;
> +{
> + struct pipe *cpipe;
> + int error;
> +
> + cpipe = fp->f_data;
> + if (cpipe->pipe_state & PIPE_NAMED)
> + error = vn_chmod(fp, mode, active_cred, td);
> + else
> + error = invfo_chmod(fp, mode, active_cred, td);
> + return (error);
> +}
> +
> +static int
> +pipe_chown(fp, uid, gid, active_cred, td)
> + struct file *fp;
> + uid_t uid;
> + gid_t gid;
> + struct ucred *active_cred;
> + struct thread *td;
> +{
> + struct pipe *cpipe;
> + int error;
> +
> + cpipe = fp->f_data;
> + if (cpipe->pipe_state & PIPE_NAMED)
> + error = vn_chown(fp, uid, gid, active_cred, td);
> + else
> + error = invfo_chown(fp, uid, gid, active_cred, td);
> + return (error);
> +}
> +
>  static void
>  pipe_free_kmem(cpipe)
>   struct pipe *cpipe;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r232074 - head/sys/cam/ctl

2012-02-26 Thread Alexander Best
On Sat Feb 25 12, Bruce Evans wrote:
> On Fri, 24 Feb 2012, Alexander Best wrote:
> 
> >On Fri Feb 24 12, Dimitry Andric wrote:
> >>On 2012-02-24 10:38, Alexander Best wrote:
> >>>which will turn all -Wformat-invalid-specifier and -Wformat-extra-args 
> >>>errors
> >>>into warnings (because clang tot doesn't support -fformat-extensions)?
> >>
> >>It would be better to push our format extensions upstream, I think.
> >>Though the option should probably be renamed to something else, e.g.
> >>-ffreebsd-extensions, or such.
> 
> It is only for format extensions.  The idea is that a C compiler that
> supports warning about unsupported printf formats must warn about
> uses of format extensions (no matter whose they are) unless instructed
> not to do so.  It seems excessive to have separate flags
> -fbsd-format-extensions -ffreebsd-format-extensions
> -fotherbsd-format-extensions -fgnu-format-extensions
> -flinux-format-extensions ..., so I used a single flag.  If
> -fbsd-format-extensions existed, then it would have only %b as an
> extension.
> 
> Anyway, clang already supports -fformat-extensions.  The following
> compiles with this, but fails messily without it:
> 
> % #include 
> % 
> % void
> % foo(void)
> % {
> % printf("0x%b\n", 1, "\1foo");
> % }
> 
> gcc (FreeBSD-gcc) complains about %#b, but clang doesn't.  I don't know
> if %#b is valid, but it should be.
> 
> >i'm still confused regarding the actual politics regarding this change.
> >everytime this comes up i get a different answer. the last one was that 
> >since
> >the special printf format is only used for kernel code, the 
> >-fformat-extensions
> >code within clang base shouldn't be pushed upstream.
> 
> Is it only the FreeBSD version of clang that has it?  Does FreeBSD has any
> other significant local changes?  The flag should be push upstream, but
> there are likely to always be OS-specific details.  For example, if %#b
> is indeed invalid and someone fixes the kernel to support it, you don't
> want to have to wait for the upstream sources to be synchronized before
> using %#b.

yes. only the clang version that ships with the freebsd src has support for
-fformat-extensions, however i couldn't find any referrence to it in the
clang(1) manual page. so it seems the support was only hacked into the clang
source and the manual page wasn't updated.

getting these changes pushed upstream would be nice. it's very likely that
the clang folks will rename -fformat-extensions to something else, but it
shouldn't be a big problem handling the different flag names in some *.mk
file.

i don't know, if the freebsd of clang has any other major differences compared
to the vendor version. maybe the freebsd-clang wiki page has some details about
this matter (or will direct you to people who know the answer).

cheers.
alex

> 
> Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r232074 - head/sys/cam/ctl

2012-02-24 Thread Alexander Best
On Fri Feb 24 12, Dimitry Andric wrote:
> On 2012-02-24 10:38, Alexander Best wrote:
> > is the clang version in base able to do complete universe builds for i386 
> > and
> > amd64 without the need for NO_WERROR= and WERROR= now?
> 
> "universe" means all arches, and all kernel configs, so no.  The status
> for head with clang is as follows:

i meant with TARGETS=i386 amd64 set. i think this will only do a universe build
for those arches.

> 
> - buildworld with default options, e.g. no WITH_XXX or WITHOUT_XXX
>   settings, will complete without any (fatal) warnings.
> - buildkernel of the default GENERIC config still has one warning left,
>   in sys/dev/mps/mps_sas.c.  It should be simple to fix, but I'm
>   checking it with Ken first.
> - The LINT kernel configs probably have many warnings left.  I haven't
>   tested those extensively.
> 
> As soon as world & kernel compile without warnings, I'd like to have a
> tinderbox that continually builds with clang.  So head won't be
> regressing any more. :)

yeah good idea. :)

> 
> 
> > ps: are there any plans to add support for compiling kernel+userland with 
> > clang
> > tot? maybe this can be accomplished by doing something like
> > 
> > echo "WITH_CLANG_TOT=yes" >> /etc/src.conf
> 
> I'm not working on this at the moment.  Pawel Worach (CC'd) has a
> buildbot setup that builds FreeBSD daily with clang ToT.  Apparently
> just a few patches are needed.
> 
> 
> > which will turn all -Wformat-invalid-specifier and -Wformat-extra-args 
> > errors
> > into warnings (because clang tot doesn't support -fformat-extensions)?
> 
> It would be better to push our format extensions upstream, I think.
> Though the option should probably be renamed to something else, e.g.
> -ffreebsd-extensions, or such.

i'm still confused regarding the actual politics regarding this change.
everytime this comes up i get a different answer. the last one was that since
the special printf format is only used for kernel code, the -fformat-extensions
code within clang base shouldn't be pushed upstream.

personally i like the idea of pushing it upstream and renaming it to
-ffreebsd-extensions. that would make it easier to import new clang versions
and it would be a lot easier to build freebsd with clang tot.

maybe pushing the -fformat-extensions code upstream could happen before freebsd
10.0 gets released.

thanks for your answer.

cheers.
alex
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r232074 - head/sys/cam/ctl

2012-02-24 Thread Alexander Best
On Thu Feb 23 12, Dimitry Andric wrote:
> Author: dim
> Date: Thu Feb 23 21:34:14 2012
> New Revision: 232074
> URL: http://svn.freebsd.org/changeset/base/232074
> 
> Log:
>   Use a better way to silence unneeded internal declaration warnings in
>   several sys/cam/ctl files.

is the clang version in base able to do complete universe builds for i386 and
amd64 without the need for NO_WERROR= and WERROR= now?

cheers.
alex

ps: are there any plans to add support for compiling kernel+userland with clang
tot? maybe this can be accomplished by doing something like

echo "WITH_CLANG_TOT=yes" >> /etc/src.conf

which will turn all -Wformat-invalid-specifier and -Wformat-extra-args errors
into warnings (because clang tot doesn't support -fformat-extensions)?


>   
>   Suggested by:   ed
>   Reviewed by:ken
>   MFC after:  1 week
> 
> Modified:
>   head/sys/cam/ctl/ctl_private.h
> 
> Modified: head/sys/cam/ctl/ctl_private.h
> ==
> --- head/sys/cam/ctl/ctl_private.hThu Feb 23 21:32:32 2012
> (r232073)
> +++ head/sys/cam/ctl/ctl_private.hThu Feb 23 21:34:14 2012
> (r232074)
> @@ -297,7 +297,7 @@ struct ctl_page_index {
>  #define  CTL_PAGE_DEFAULT0x02
>  #define  CTL_PAGE_SAVED  0x03
>  
> -static struct ctl_page_index page_index_template[] = {
> +static const struct ctl_page_index page_index_template[] = {
>   {SMS_FORMAT_DEVICE_PAGE, 0, sizeof(struct scsi_format_page), NULL,
>CTL_PAGE_FLAG_DISK_ONLY, NULL, NULL},
>   {SMS_RIGID_DISK_PAGE, 0, sizeof(struct scsi_rigid_disk_page), NULL,
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r231999 - head/sys/conf

2012-02-23 Thread Alexander Best
On Wed Feb 22 12, Doug Barton wrote:
> On 02/22/2012 07:05, Josh Paetzel wrote:
> > -# CPU.  This behaviour is enabled by default, so this option can be used
> 
> That's not a typo, it's an alternate spelling, which we usually don't
> "correct" (same with initialisation). I'm not asking for the change to
> be backed out, just letting you know for future reference.

i think the commit should be reverted. freebsd is an international project
and by turning comments that were made by people using british english spelling
into american english spelling, this commit implies that freebsd prefers a
certain spelling. expecially, if the comments came from someone who lives in a
native english speaking country, changing the perfectly valid spelling into
american english might be offensive.

just my 0.02 $ though.

cheers.
alex

> 
> 
> Doug
> 
> -- 
> 
>   It's always a long day; 86400 doesn't fit into a short.
> 
>   Breadth of IT experience, and depth of knowledge in the DNS.
>   Yours for the right price.  :)  http://SupersetSolutions.com/
> 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r229908 - head/usr.bin/brandelf

2012-01-10 Thread Alexander Best
On Wed Jan 11 12, Alexander Best wrote:
> On Tue Jan 10 12, Dimitry Andric wrote:
> > On 2012-01-10 09:21, Pawel Jakub Dawidek wrote:
> > >On Tue, Jan 10, 2012 at 02:58:29AM +, Eitan Adler wrote:
> > >>Author: eadler (ports committer)
> > >>Date: Tue Jan 10 02:58:29 2012
> > >>New Revision: 229908
> > >>URL: http://svn.freebsd.org/changeset/base/229908
> > >>
> > >>Log:
> > >>   Fix warning when compiling with gcc46:
> > >>   error: variable 'verbose' set but not use
> > >
> > >Maybe we should remove -v from the manual page as well or document as 
> > >no-op?
> > >I'd still leave it in the code though, so there is no POLA violation.
> > 
> > It has been a no-op since the beginning of brandelf, and I have really
> > no idea what the original author intended the verbose output to be. :)
> > 
> > It is probably best to document it as a no-op now, to reduce possible
> > confusion.
> 
> shouldn't brandelf be replaced with the version from the elftoolchain project?
> any news when the first import is going to happen?

also you might want to report your changes to the elftoolchain project, because
otherwise your commit will be reverted when the import happens.

cheers.
alex

> 
> cheers.
> alex
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r229908 - head/usr.bin/brandelf

2012-01-10 Thread Alexander Best
On Tue Jan 10 12, Dimitry Andric wrote:
> On 2012-01-10 09:21, Pawel Jakub Dawidek wrote:
> >On Tue, Jan 10, 2012 at 02:58:29AM +, Eitan Adler wrote:
> >>Author: eadler (ports committer)
> >>Date: Tue Jan 10 02:58:29 2012
> >>New Revision: 229908
> >>URL: http://svn.freebsd.org/changeset/base/229908
> >>
> >>Log:
> >>   Fix warning when compiling with gcc46:
> >> error: variable 'verbose' set but not use
> >
> >Maybe we should remove -v from the manual page as well or document as 
> >no-op?
> >I'd still leave it in the code though, so there is no POLA violation.
> 
> It has been a no-op since the beginning of brandelf, and I have really
> no idea what the original author intended the verbose output to be. :)
> 
> It is probably best to document it as a no-op now, to reduce possible
> confusion.

shouldn't brandelf be replaced with the version from the elftoolchain project?
any news when the first import is going to happen?

cheers.
alex
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228822 - head/sys/conf

2011-12-22 Thread Alexander Best
On Fri Dec 23 11, Alexander Best wrote:
> On Fri Dec 23 11, Dimitry Andric wrote:
> > Author: dim
> > Date: Fri Dec 23 00:23:37 2011
> > New Revision: 228822
> > URL: http://svn.freebsd.org/changeset/base/228822
> > 
> > Log:
> >   When building the kernel with clang, it produces several warnings which
> >   might be useful in some cases, but which are not severe enough to error
> >   out the whole kernel build.  Display them anyway, so there is at least
> >   some incentive to fix them eventually.
> >   
> >   Start with -Wtautological-compare warnings.  These usually occur when
> >   people check if unsigned quantities are negative, or similar cases.  To
> >   clean these up would be painful, and might give problems if the base
> >   type which is compared against changes to signed later on.
> 
> ... or is signed on one arch, but unsigned on another. ;)
> 
> any reason you add -Wno-error-tautological-compare to CWARNFLAGS seperately
> and not in the upper CWARNFLAGS?= definition? the way you implemented it here
> makes it impossible to specify custom CWARNFLAGS, where users might want to
> keep -Wtautological-compare as an error and not turn it into a warning.
> 
> i already sent you the following patch, which takes a different approach
> towards the issue you're trying to solve.
> 
> of course it's debatable, whether -Wno-error-tautological-compare should be
> mandatory, or not. -fno-strict-aliasing e.g. is a flag which also gets 
> appended
> (only to COPTFLAGS) even when users set custom COPTFLAGS
> 
> cheers.
> alex
> 
> >   
> >   MFC after:1 week
> > 
> > Modified:
> >   head/sys/conf/kern.mk
> > 
> > Modified: head/sys/conf/kern.mk
> > ==
> > --- head/sys/conf/kern.mk   Fri Dec 23 00:19:17 2011(r228821)
> > +++ head/sys/conf/kern.mk   Fri Dec 23 00:23:37 2011(r228822)
> > @@ -19,6 +19,10 @@ NO_WCONSTANT_CONVERSION= -Wno-constant-c
> >  NO_WARRAY_BOUNDS=  -Wno-array-bounds
> >  NO_WSHIFT_COUNT_NEGATIVE=  -Wno-shift-count-negative
> >  NO_WSHIFT_COUNT_OVERFLOW=  -Wno-shift-count-overflow
> > +# Several other warnings which might be useful in some cases, but not 
> > severe
> > +# enough to error out the whole kernel build.  Display them anyway, so 
> > there is
> > +# some incentive to fix them eventually.
> > +CWARNFLAGS+=   -Wno-error-tautological-compare
> >  .endif
> >  
> >  #

> Index: conf/kern.mk
> ===
> --- conf/kern.mk  (revision 228556)
> +++ conf/kern.mk  (working copy)
> @@ -1,12 +1,24 @@
>  # $FreeBSD$
>  
>  #
> +# Clang implies -Wtautological-compare when -Wall was specified.  Since this
> +# will produce errors for valid code, we need to disable 
> -Wtautological-compare.
> +# GCC doesn't recognize this warning, nor does it have a similar warning 
> flag.
> +# However specifying -Wextra implies -Wtautological-compare semantics.
> +#
> +.if ${CC:T:Mclang} == "clang"
> +NO_TAUTCOMP= -Wno-tautological-compare

s/-Wno-tautological-compare/-Wno-error-tautological-compare/

sorry.

> +.else
> +NO_TAUTCOMP=
> +.endif
> +
> +#
>  # Warning flags for compiling the kernel and components of the kernel:
>  #
>  CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
>   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
>   -Wundef -Wno-pointer-sign -fformat-extensions \
> - -Wmissing-include-dirs -fdiagnostics-show-option
> + -Wmissing-include-dirs -fdiagnostics-show-option ${NO_TAUTCOMP}
>  #
>  # The following flags are next up for working on:
>  #-Wextra

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228822 - head/sys/conf

2011-12-22 Thread Alexander Best
On Fri Dec 23 11, Dimitry Andric wrote:
> Author: dim
> Date: Fri Dec 23 00:23:37 2011
> New Revision: 228822
> URL: http://svn.freebsd.org/changeset/base/228822
> 
> Log:
>   When building the kernel with clang, it produces several warnings which
>   might be useful in some cases, but which are not severe enough to error
>   out the whole kernel build.  Display them anyway, so there is at least
>   some incentive to fix them eventually.
>   
>   Start with -Wtautological-compare warnings.  These usually occur when
>   people check if unsigned quantities are negative, or similar cases.  To
>   clean these up would be painful, and might give problems if the base
>   type which is compared against changes to signed later on.

... or is signed on one arch, but unsigned on another. ;)

any reason you add -Wno-error-tautological-compare to CWARNFLAGS seperately
and not in the upper CWARNFLAGS?= definition? the way you implemented it here
makes it impossible to specify custom CWARNFLAGS, where users might want to
keep -Wtautological-compare as an error and not turn it into a warning.

i already sent you the following patch, which takes a different approach
towards the issue you're trying to solve.

of course it's debatable, whether -Wno-error-tautological-compare should be
mandatory, or not. -fno-strict-aliasing e.g. is a flag which also gets appended
(only to COPTFLAGS) even when users set custom COPTFLAGS

cheers.
alex

>   
>   MFC after:  1 week
> 
> Modified:
>   head/sys/conf/kern.mk
> 
> Modified: head/sys/conf/kern.mk
> ==
> --- head/sys/conf/kern.mk Fri Dec 23 00:19:17 2011(r228821)
> +++ head/sys/conf/kern.mk Fri Dec 23 00:23:37 2011(r228822)
> @@ -19,6 +19,10 @@ NO_WCONSTANT_CONVERSION=   -Wno-constant-c
>  NO_WARRAY_BOUNDS=-Wno-array-bounds
>  NO_WSHIFT_COUNT_NEGATIVE=-Wno-shift-count-negative
>  NO_WSHIFT_COUNT_OVERFLOW=-Wno-shift-count-overflow
> +# Several other warnings which might be useful in some cases, but not severe
> +# enough to error out the whole kernel build.  Display them anyway, so there 
> is
> +# some incentive to fix them eventually.
> +CWARNFLAGS+= -Wno-error-tautological-compare
>  .endif
>  
>  #
Index: conf/kern.mk
===
--- conf/kern.mk(revision 228556)
+++ conf/kern.mk(working copy)
@@ -1,12 +1,24 @@
 # $FreeBSD$
 
 #
+# Clang implies -Wtautological-compare when -Wall was specified.  Since this
+# will produce errors for valid code, we need to disable 
-Wtautological-compare.
+# GCC doesn't recognize this warning, nor does it have a similar warning flag.
+# However specifying -Wextra implies -Wtautological-compare semantics.
+#
+.if ${CC:T:Mclang} == "clang"
+NO_TAUTCOMP=   -Wno-tautological-compare
+.else
+NO_TAUTCOMP=
+.endif
+
+#
 # Warning flags for compiling the kernel and components of the kernel:
 #
 CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
-Wundef -Wno-pointer-sign -fformat-extensions \
-   -Wmissing-include-dirs -fdiagnostics-show-option
+   -Wmissing-include-dirs -fdiagnostics-show-option ${NO_TAUTCOMP}
 #
 # The following flags are next up for working on:
 #  -Wextra
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228785 - in head/sys/dev/ath/ath_hal: ar5210 ar5211

2011-12-22 Thread Alexander Best
On Thu Dec 22 11, John Baldwin wrote:
> On Wednesday, December 21, 2011 6:27:54 pm Alexander Best wrote:
> > On Wed Dec 21 11, John Baldwin wrote:
> > > On Wednesday, December 21, 2011 4:52:04 pm Adrian Chadd wrote:
> > > > Erm, why did you do this without first getting clearance from someone
> > > > who has the hardware to test it?
> > > > 
> > > > Just because it looks obviously wrong to you, doesn't at all mean that
> > > > it's "wrong". It's quite possible that the driver _requires_ those
> > > > bits to be written to the hardware as 0.
> > > > 
> > > > 
> > > > I'd appreciate it if would please revert this and other ath/hal
> > > > changes until I've had time to research them and test them out.
> > > 
> > > I agree it should be reviewed, but if you are seriously depending on
> > > the fact that the shifted values are beyond the edge of the word boundary
> > > and so the result "wraps" to zero, then I'd question the sanity of your 
> > > code.
> > 
> > i disagree.
> 
> You don't think changes should be reviewed (that's what I said above, I did
> not necessarily say it should be reverted)?  That's way out in left field if
> that is what you really think.

no of course not. let's handle it this way:

keep the commits and adrian@ and everybody else can test dim@'s
changes. if the commits broke anything, they should be reverted.

the next time dim@ is about to touch non trivial code or code that is being
maintained by a certain developer, he should post his patches to some
mailinglist (-wireless@ in this case) and cc that particular developer
(adrian@ in this case).

no hard feelings. ;)

cheers.
alex

> 
> As for reverting the changes, I think they are small enough that is probably
> a bit overboard unless someone else reports an actual problem with them.
> (Specifically, I don't think the bar is high enough in this case to warrant a
> reversion.)  However, I think that for future changes, Dimitry should get
> these sort of changes reviewed before committing them.
> 
> -- 
> John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228785 - in head/sys/dev/ath/ath_hal: ar5210 ar5211

2011-12-22 Thread Alexander Best
On Thu Dec 22 11, Pawel Jakub Dawidek wrote:
> On Wed, Dec 21, 2011 at 11:27:54PM +0000, Alexander Best wrote:
> > the commits should stay. after all this is HEAD. this way all developers
> > running HEAD and with the appropriate ath hardware will test the changes. if
> > dim@ really broke something, people will notice.
> > 
> > the changes should *not* be MFC'ed. but if no one complains until 
> > 10.0-RELEASE,
> > it's very unlikely he broke something.
> > 
> > plus...does it make a different, if you test HEAD with the changes present 
> > or
> > test HEAD with the changes integrated via patches?
> > 
> > one way or the other you can test the changes and *if* something broke, the
> > commits can be reverted.
> 
> Is this a joke? Having HEAD as stable as possible is very important.
> That's the only way to actually expect people (including developers
> (including myself!)) to run HEAD on their laptops and less important
> servers. Those people get upset as any other user if their systems stop
> working, because untested changes are being committed.
> 
> This is not to pick on Dimitry, but on those who actually believe that
> it is ok to commit untested changes to HEAD. IT IS NOT. Maybe you are
> just confused, because the place you are looking for seems to be
> junkyard, but not HEAD, NEVER HEAD!
> 
> BTW. This is a lesson we learned from 5-CURRENT. It was so unstable that
> nobody wanted to run it, and so unstable it was even hard to test
> changes on it. In turn it was becoming even more unstable, because
> people kept committing more untested code.
> 
> Please, do never, ever encourage evil like that or I'll turn on mean Pawel:)

sure i understand your concerns and i completely agree that HEAD is not a
playground for experimental changes.

however dim@'s changes don't seem that disruptive. plus: reverting them and
letting adrian@ test the patches on his own poses a cathedral-policy, whereas
letting everybody who is running HEAD test them, seems more of a bazar-way. ;)

cheers.
alex

> 
> -- 
> Pawel Jakub Dawidek   http://www.wheelsystems.com
> FreeBSD committer http://www.FreeBSD.org
> Am I Evil? Yes, I Am! http://yomoli.com


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228785 - in head/sys/dev/ath/ath_hal: ar5210 ar5211

2011-12-21 Thread Alexander Best
On Wed Dec 21 11, John Baldwin wrote:
> On Wednesday, December 21, 2011 4:52:04 pm Adrian Chadd wrote:
> > Erm, why did you do this without first getting clearance from someone
> > who has the hardware to test it?
> > 
> > Just because it looks obviously wrong to you, doesn't at all mean that
> > it's "wrong". It's quite possible that the driver _requires_ those
> > bits to be written to the hardware as 0.
> > 
> > 
> > I'd appreciate it if would please revert this and other ath/hal
> > changes until I've had time to research them and test them out.
> 
> I agree it should be reviewed, but if you are seriously depending on
> the fact that the shifted values are beyond the edge of the word boundary
> and so the result "wraps" to zero, then I'd question the sanity of your code.

i disagree.

the commits should stay. after all this is HEAD. this way all developers
running HEAD and with the appropriate ath hardware will test the changes. if
dim@ really broke something, people will notice.

the changes should *not* be MFC'ed. but if no one complains until 10.0-RELEASE,
it's very unlikely he broke something.

plus...does it make a different, if you test HEAD with the changes present or
test HEAD with the changes integrated via patches?

one way or the other you can test the changes and *if* something broke, the
commits can be reverted.

cheers.
alex

> 
> -- 
> John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228621 - in head/sys: dev/an dev/ath dev/bwi dev/bwn dev/if_ndis dev/ipw dev/iwi dev/iwn dev/malo dev/mwl dev/ral dev/usb/wlan dev/wi dev/wpi net80211

2011-12-17 Thread Alexander Best
On Sat Dec 17 11, Bernhard Schmidt wrote:
> Author: bschmidt
> Date: Sat Dec 17 10:23:17 2011
> New Revision: 228621
> URL: http://svn.freebsd.org/changeset/base/228621
> 
> Log:
>   Fix some net80211 enum nits:
>   - ic_vap_create() uses an ieee80211_opmode argument
>   - ieee80211_rate2media() takes an ieee80211_phymode argument
>   - ieee80211_plcp2rate() takes an ieee80211_phytype argument
>   - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
> compiler warnings
>   
>   Submitted by:   arundel@

actually i merely submitted a problem report via kern/162475. ;) i didn't write 
a
single patch. so all the credit goes to bernhard. :)

> 
> Modified:
>   head/sys/dev/an/if_an.c
>   head/sys/dev/ath/if_ath.c
>   head/sys/dev/bwi/if_bwi.c
>   head/sys/dev/bwn/if_bwn.c
>   head/sys/dev/if_ndis/if_ndis.c
>   head/sys/dev/ipw/if_ipw.c
>   head/sys/dev/iwi/if_iwi.c
>   head/sys/dev/iwn/if_iwn.c
>   head/sys/dev/malo/if_malo.c
>   head/sys/dev/mwl/if_mwl.c
>   head/sys/dev/ral/rt2560.c
>   head/sys/dev/ral/rt2661.c
>   head/sys/dev/usb/wlan/if_rum.c
>   head/sys/dev/usb/wlan/if_run.c
>   head/sys/dev/usb/wlan/if_uath.c
>   head/sys/dev/usb/wlan/if_upgt.c
>   head/sys/dev/usb/wlan/if_ural.c
>   head/sys/dev/usb/wlan/if_urtw.c
>   head/sys/dev/usb/wlan/if_zyd.c
>   head/sys/dev/wi/if_wi.c
>   head/sys/dev/wpi/if_wpi.c
>   head/sys/net80211/ieee80211.c
>   head/sys/net80211/ieee80211_ht.c
>   head/sys/net80211/ieee80211_ioctl.c
>   head/sys/net80211/ieee80211_var.h
> 
> Modified: head/sys/dev/an/if_an.c
> ==
> --- head/sys/dev/an/if_an.c   Sat Dec 17 06:57:35 2011(r228620)
> +++ head/sys/dev/an/if_an.c   Sat Dec 17 10:23:17 2011(r228621)
> @@ -797,7 +797,7 @@ an_attach(struct an_softc *sc, int flags
>   ADD(IFM_AUTO, IFM_IEEE80211_ADHOC);
>   for (i = 0; i < nrate; i++) {
>   r = sc->an_caps.an_rates[i];
> - mword = ieee80211_rate2media(NULL, r, IEEE80211_T_DS);
> + mword = ieee80211_rate2media(NULL, r, IEEE80211_MODE_AUTO);
>   if (mword == 0)
>   continue;
>   printf("%s%d%sMbps", (i != 0 ? " " : ""),
> @@ -3299,7 +3299,7 @@ an_media_status(struct ifnet *ifp, struc
>   if (sc->an_config.an_opmode == AN_OPMODE_IBSS_ADHOC)
>   imr->ifm_active |= IFM_IEEE80211_ADHOC;
>   imr->ifm_active |= ieee80211_rate2media(NULL,
> - status.an_current_tx_rate, IEEE80211_T_DS);
> + status.an_current_tx_rate, IEEE80211_MODE_AUTO);
>   imr->ifm_status = IFM_AVALID;
>   if (status.an_opmode & AN_STATUS_OPMODE_ASSOCIATED)
>   imr->ifm_status |= IFM_ACTIVE;
> 
> Modified: head/sys/dev/ath/if_ath.c
> ==
> --- head/sys/dev/ath/if_ath.c Sat Dec 17 06:57:35 2011(r228620)
> +++ head/sys/dev/ath/if_ath.c Sat Dec 17 10:23:17 2011(r228621)
> @@ -128,9 +128,9 @@ __FBSDID("$FreeBSD$");
>  CTASSERT(ATH_BCBUF <= 8);
>  
>  static struct ieee80211vap *ath_vap_create(struct ieee80211com *,
> - const char name[IFNAMSIZ], int unit, int opmode,
> - int flags, const uint8_t bssid[IEEE80211_ADDR_LEN],
> - const uint8_t mac[IEEE80211_ADDR_LEN]);
> + const char [IFNAMSIZ], int, enum ieee80211_opmode, int,
> + const uint8_t [IEEE80211_ADDR_LEN],
> + const uint8_t [IEEE80211_ADDR_LEN]);
>  static void  ath_vap_delete(struct ieee80211vap *);
>  static void  ath_init(void *);
>  static void  ath_stop_locked(struct ifnet *);
> @@ -885,16 +885,17 @@ assign_bslot(struct ath_softc *sc)
>  }
>  
>  static struct ieee80211vap *
> -ath_vap_create(struct ieee80211com *ic,
> - const char name[IFNAMSIZ], int unit, int opmode, int flags,
> - const uint8_t bssid[IEEE80211_ADDR_LEN],
> - const uint8_t mac0[IEEE80211_ADDR_LEN])
> +ath_vap_create(struct ieee80211com *ic, const char name[IFNAMSIZ], int unit,
> +enum ieee80211_opmode opmode, int flags,
> +const uint8_t bssid[IEEE80211_ADDR_LEN],
> +const uint8_t mac0[IEEE80211_ADDR_LEN])
>  {
>   struct ath_softc *sc = ic->ic_ifp->if_softc;
>   struct ath_vap *avp;
>   struct ieee80211vap *vap;
>   uint8_t mac[IEEE80211_ADDR_LEN];
> - int ic_opmode, needbeacon, error;
> + int needbeacon, error;
> + enum ieee80211_opmode ic_opmode;
>  
>   avp = (struct ath_vap *) malloc(sizeof(struct ath_vap),
>   M_80211_VAP, M_WAITOK | M_ZERO);
> 
> Modified: head/sys/dev/bwi/if_bwi.c
> ==
> --- head/sys/dev/bwi/if_bwi.c Sat Dec 17 06:57:35 2011(r228620)
> +++ head/sys/dev/bwi/if_bwi.c Sat Dec 17 10:23:17 2011(r228621)
> @@ -96,9 +96,9 @@ struct bwi_myaddr_bssid {
>  } __packed;
>  
>  static struct ieee80211vap *bwi_vap_create(struct iee

Re: svn commit: r228552 - head/lib/libipsec

2011-12-15 Thread Alexander Best
On Thu Dec 15 11, Dimitry Andric wrote:
> Author: dim
> Date: Thu Dec 15 23:22:24 2011
> New Revision: 228552
> URL: http://svn.freebsd.org/changeset/base/228552
> 
> Log:
>   Define YY_NO_INPUT in lib/libipsec/policy_token.l, so lex's input()
>   function does not get defined needlessly.

could such a minimal change also fix the following cases:

>>> stage 2.3: build tools
--
cd /usr/obj/usr/subversion-src/sys/ARUNDEL;  
MAKESRCPATH=/usr/subversion-src/sys/dev/aic7xxx/aicasm  make SSP_CFLAGS= 
-DNO_CPU_CFLAGS -DNO_CTF  -f /usr/subversion-src/sys/dev/aic7xxx/aicasm/Makefile
Warning: Object directory not changed from original 
/usr/obj/usr/subversion-src/sys/ARUNDEL
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c /usr/subversion-src/sys/dev/aic7xxx/aicasm/aicasm.c
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c /usr/subversion-src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c aicasm_gram.c
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c aicasm_macro_gram.c
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c aicasm_scan.c
/usr/subversion-src/sys/dev/aic7xxx/aicasm/aicasm_scan.l:843:12: warning: 
function 'input' is not needed and will not be emitted 
[-Wunneeded-internal-declaration]
static int input(void)
   ^
1 warning generated.
lex -t  -Pmm /usr/subversion-src/sys/dev/aic7xxx/aicasm/aicasm_macro_scan.l > 
aicasm_macro_scan.c
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign -c aicasm_macro_scan.c
/usr/subversion-src/sys/dev/aic7xxx/aicasm/aicasm_macro_scan.l:545:12: warning: 
function 'input' is not needed and will not be emitted 
[-Wunneeded-internal-declaration]
static int input(void)
   ^
1 warning generated.
clang -O2 -pipe -nostdinc -I/usr/include -I. 
-I/usr/subversion-src/sys/dev/aic7xxx/aicasm -DSTRIP_FBSDID -std=gnu99 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wno-pointer-sign  -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o 
aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
clang: warning: argument unused during compilation: '-nostdinc'
clang: warning: argument unused during compilation: '-std=gnu99'

?

cheers.
alex

>   
>   MFC after:  1 week
> 
> Modified:
>   head/lib/libipsec/policy_token.l
> 
> Modified: head/lib/libipsec/policy_token.l
> ==
> --- head/lib/libipsec/policy_token.l  Thu Dec 15 23:13:57 2011
> (r228551)
> +++ head/lib/libipsec/policy_token.l  Thu Dec 15 23:22:24 2011
> (r228552)
> @@ -48,6 +48,7 @@
>  
>  #include "y.tab.h"
>  #define yylval __libipsecyylval  /* XXX */
> +#define YY_NO_INPUT
>  
>  int yylex(void);
>  %}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228148 - head/sys/conf

2011-12-01 Thread Alexander Best
On Wed Nov 30 11, Garrett Cooper wrote:
> On Wed, Nov 30, 2011 at 4:59 PM, Alexander Best  wrote:
> > On Tue Nov 29 11, John Baldwin wrote:
> >> Author: jhb
> >> Date: Tue Nov 29 21:28:48 2011
> >> New Revision: 228148
> >> URL: http://svn.freebsd.org/changeset/base/228148
> >>
> >> Log:
> >>   Remove a bit of debugging that accidentally crept in earlier.
> >>
> >> Modified:
> >>   head/sys/conf/newvers.sh
> >>
> >> Modified: head/sys/conf/newvers.sh
> >> ==
> >> --- head/sys/conf/newvers.sh  Tue Nov 29 20:06:27 2011        (r228147)
> >> +++ head/sys/conf/newvers.sh  Tue Nov 29 21:28:48 2011        (r228148)
> >> @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin;
> >>  done
> >>
> >>  if [ -n "$svnversion" ] ; then
> >> -     echo "$svnversion"
> >>       svn=`cd ${SYSDIR} && $svnversion`
> >
> > any chance we could replace $svnversion with something like the following:
> >
> > 'svn info|grep ^Revision|sed 's/^Revision: //'' ?
> >
> > this is much faster and the only downside seems to be the missing {MSP} at 
> > the
> > end.
> >
> > running a standard hdd, svnversion takes almost half a minute, while the
> > command above finishes in < 0.1 seconds.
> 
> We already hashed over that in the last discussion. svnversion was
> picked because it iterates over the entire tree and you know for an
> absolute fact that it's running versions X-Y-Z, instead of the version
> of the Makefile being X.

sorry. wasn't aware of that. thanks for the info.

cheers.
alex

> Thanks,
> -Garrett
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228148 - head/sys/conf

2011-11-30 Thread Alexander Best
On Tue Nov 29 11, John Baldwin wrote:
> Author: jhb
> Date: Tue Nov 29 21:28:48 2011
> New Revision: 228148
> URL: http://svn.freebsd.org/changeset/base/228148
> 
> Log:
>   Remove a bit of debugging that accidentally crept in earlier.
> 
> Modified:
>   head/sys/conf/newvers.sh
> 
> Modified: head/sys/conf/newvers.sh
> ==
> --- head/sys/conf/newvers.sh  Tue Nov 29 20:06:27 2011(r228147)
> +++ head/sys/conf/newvers.sh  Tue Nov 29 21:28:48 2011(r228148)
> @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin;
>  done
>  
>  if [ -n "$svnversion" ] ; then
> - echo "$svnversion"
>   svn=`cd ${SYSDIR} && $svnversion`

any chance we could replace $svnversion with something like the following:

'svn info|grep ^Revision|sed 's/^Revision: //'' ?

this is much faster and the only downside seems to be the missing {MSP} at the
end.

running a standard hdd, svnversion takes almost half a minute, while the
command above finishes in < 0.1 seconds.

cheers.
alex

>   case "$svn" in
>   [0-9]*) svn=" r${svn}" ;;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r228157 - head/usr.bin/make

2011-11-30 Thread Alexander Best
On Wed Nov 30 11, Max Khon wrote:
> Author: fjoe
> Date: Wed Nov 30 18:07:38 2011
> New Revision: 228157
> URL: http://svn.freebsd.org/changeset/base/228157
> 
> Log:
>   - Fix segmentation fault when running "+command" when run with -jX -n due
>   to Compat_RunCommand() being called with `cmd' that is not on the 
> node->commands
>   list
>   - Make ellipsis ("..." command) handling consistent: check for "..." command
>   in job make after variables expansion to match compat make behavior
>   - Fix empty command handling (after variables expansion and @+- modifiers
>   are processed): now empty commands are ignored in compat make and are not
>   printed in job make case
>   - Bump MAKE_VERSION to 5-2011-11-30-0

it would also be nice, if at some point, somebody could dive into the code to
see why 'make buildkernel' will let clang produce coloured output, but
'make -j(N>1) buildkernel' doesn't (and why adding a -B switch to that command
fixes it).

cheers.
alex

> 
> Modified:
>   head/usr.bin/make/Makefile
>   head/usr.bin/make/job.c
> 
> Modified: head/usr.bin/make/Makefile
> ==
> --- head/usr.bin/make/MakefileWed Nov 30 17:39:00 2011
> (r228156)
> +++ head/usr.bin/make/MakefileWed Nov 30 18:07:38 2011
> (r228157)
> @@ -10,7 +10,9 @@ SRCS=   arch.c buf.c cond.c dir.c for.c ha
>  
>  NO_SHARED?=  YES
>  
> -CFLAGS+=-DMAKE_VERSION=\"5200408120\"
> +# Version has the RMMDDX format, where R is from RELENG_
> +CFLAGS+=-DMAKE_VERSION=\"520300\"
> +
>  # There is no obvious performance improvement currently.
>  # CFLAGS+=-DUSE_KQUEUE
>  
> 
> Modified: head/usr.bin/make/job.c
> ==
> --- head/usr.bin/make/job.c   Wed Nov 30 17:39:00 2011(r228156)
> +++ head/usr.bin/make/job.c   Wed Nov 30 18:07:38 2011(r228157)
> @@ -381,7 +381,7 @@ static int JobStart(GNode *, int, Job *)
>  static void JobDoOutput(Job *, Boolean);
>  static void JobInterrupt(int, int);
>  static void JobRestartJobs(void);
> -static int Compat_RunCommand(char *, struct GNode *);
> +static int Compat_RunCommand(LstNode *, struct GNode *);
>  
>  static GNode *curTarg = NULL;
>  static GNode *ENDNode;
> @@ -647,7 +647,7 @@ JobPassSig(int signo)
>   *   numCommands is incremented if the command is actually printed.
>   */
>  static int
> -JobPrintCommand(char *cmd, Job *job)
> +JobPrintCommand(LstNode *cmdNode, Job *job)
>  {
>   Boolean noSpecials; /* true if we shouldn't worry about
>* inserting special commands into
> @@ -658,40 +658,30 @@ JobPrintCommand(char *cmd, Job *job)
>* off before printing the command
>* and need to turn it back on */
>   const char *cmdTemplate;/* Template to use when printing the command */
> - char*cmdStart;  /* Start of expanded command */
> - LstNode *cmdNode;   /* Node for replacing the command */
> + char*cmd;   /* Expanded command */
>  
>   noSpecials = (noExecute && !(job->node->type & OP_MAKE));
>  
> - if (strcmp(cmd, "...") == 0) {
> - job->node->type |= OP_SAVE_CMDS;
> - if ((job->flags & JOB_IGNDOTS) == 0) {
> - job->tailCmds =
> - Lst_Succ(Lst_Member(&job->node->commands, cmd));
> - return (1);
> - }
> - return (0);
> - }
> -
>  #define  DBPRINTF(fmt, arg)  \
>   DEBUGF(JOB, (fmt, arg));\
>   fprintf(job->cmdFILE, fmt, arg);\
>   fflush(job->cmdFILE);
>  
> - numCommands += 1;
> -
>   /*
>* For debugging, we replace each command with the result of expanding
>* the variables in the command.
>*/
> - cmdNode = Lst_Member(&job->node->commands, cmd);
> -
> - cmd = Buf_Peel(Var_Subst(cmd, job->node, FALSE));
> - cmdStart = cmd;
> -
> - Lst_Replace(cmdNode, cmdStart);
> -
> - cmdTemplate = "%s\n";
> + cmd = Buf_Peel(Var_Subst(Lst_Datum(cmdNode), job->node, FALSE));
> + if (strcmp(cmd, "...") == 0) {
> + free(cmd);
> + job->node->type |= OP_SAVE_CMDS;
> + if ((job->flags & JOB_IGNDOTS) == 0) {
> + job->tailCmds = Lst_Succ(cmdNode);
> + return (1);
> + }
> + return (0);
> + }
> + Lst_Replace(cmdNode, cmd);
>  
>   /*
>* Check for leading @', -' or +'s to control echoing, error checking,
> @@ -715,7 +705,7 @@ JobPrintCommand(char *cmd, Job *job)
>* but this one needs to be - use compat mode
>* just for it.
>*/
> - Compat_RunCommand(cmd, job->node);
> +  

Re: svn commit: r228031 - head/sys/netinet

2011-11-27 Thread Alexander Best
On Sun Nov 27 11, Michael Tuexen wrote:
> Author: tuexen
> Date: Sun Nov 27 17:51:13 2011
> New Revision: 228031
> URL: http://svn.freebsd.org/changeset/base/228031
> 
> Log:
>   Fix a warning reported by arundel@.
>   Fix a bug where the parameter length of a supported address types
>   parameter is set to a wrong value if the kernel is built with
>   with either INET or INET6, but not both.
>   
>   MFC after: 3 days.
> 
> Modified:
>   head/sys/netinet/sctp_header.h
>   head/sys/netinet/sctp_output.c
> 
> Modified: head/sys/netinet/sctp_header.h
> ==
> --- head/sys/netinet/sctp_header.hSun Nov 27 17:05:26 2011
> (r228030)
> +++ head/sys/netinet/sctp_header.hSun Nov 27 17:51:13 2011
> (r228031)
> @@ -81,8 +81,7 @@ struct sctp_host_name_param {
>  /* supported address type */
>  struct sctp_supported_addr_param {
>   struct sctp_paramhdr ph;/* type=SCTP_SUPPORTED_ADDRTYPE */
> - uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address

since SCTP_ARRAY_MIN_LEN is only used in one other place, i think we can remove
it entirely (see the attached patch).

cheers.
alex

> -  * types */
> + uint16_t addr_type[2];  /* array of supported address types */
>  } SCTP_PACKED;
>  
>  /* ECN parameter */
> 
> Modified: head/sys/netinet/sctp_output.c
> ==
> --- head/sys/netinet/sctp_output.cSun Nov 27 17:05:26 2011
> (r228030)
> +++ head/sys/netinet/sctp_output.cSun Nov 27 17:51:13 2011
> (r228031)
> @@ -4680,24 +4680,24 @@ sctp_send_initiate(struct sctp_inpcb *in
>  #ifdef INET6
>  #ifdef INET
>   /* we support 2 types: IPv4/IPv6 */
> - sup_addr->ph.param_length = htons(sizeof(*sup_addr) + sizeof(uint16_t));
> + sup_addr->ph.param_length = htons(sizeof(struct sctp_paramhdr) + 2 * 
> sizeof(uint16_t));
>   sup_addr->addr_type[0] = htons(SCTP_IPV4_ADDRESS);
>   sup_addr->addr_type[1] = htons(SCTP_IPV6_ADDRESS);
>  #else
>   /* we support 1 type: IPv6 */
> - sup_addr->ph.param_length = htons(sizeof(*sup_addr) + sizeof(uint8_t));
> + sup_addr->ph.param_length = htons(sizeof(struct sctp_paramhdr) + 
> sizeof(uint16_t));
>   sup_addr->addr_type[0] = htons(SCTP_IPV6_ADDRESS);
>   sup_addr->addr_type[1] = htons(0);  /* this is the padding */
>  #endif
>  #else
>   /* we support 1 type: IPv4 */
> - sup_addr->ph.param_length = htons(sizeof(*sup_addr) + sizeof(uint8_t));
> + sup_addr->ph.param_length = htons(sizeof(struct sctp_paramhdr) + 
> sizeof(uint16_t));
>   sup_addr->addr_type[0] = htons(SCTP_IPV4_ADDRESS);
>   sup_addr->addr_type[1] = htons(0);  /* this is the padding */
>  #endif
> - SCTP_BUF_LEN(m) += sizeof(*sup_addr) + sizeof(uint16_t);
> + SCTP_BUF_LEN(m) += sizeof(struct sctp_supported_addr_param);
>   /* adaptation layer indication parameter */
> - ali = (struct sctp_adaptation_layer_indication *)((caddr_t)sup_addr + 
> sizeof(*sup_addr) + sizeof(uint16_t));
> + ali = (struct sctp_adaptation_layer_indication *)((caddr_t)sup_addr + 
> sizeof(struct sctp_supported_addr_param));
>   ali->ph.param_type = htons(SCTP_ULP_ADAPTATION);
>   ali->ph.param_length = htons(sizeof(*ali));
>   ali->indication = ntohl(inp->sctp_ep.adaptation_layer_indicator);
Index: sys/netinet/sctp_header.h
===
--- sys/netinet/sctp_header.h   (revision 228040)
+++ sys/netinet/sctp_header.h   (working copy)
@@ -66,11 +66,10 @@
uint32_t time;  /* time in ms to extend cookie */
 }  SCTP_PACKED;
 
-#define SCTP_ARRAY_MIN_LEN 1
 /* Host Name Address */
 struct sctp_host_name_param {
struct sctp_paramhdr ph;/* type=SCTP_HOSTNAME_ADDRESS */
-   char name[SCTP_ARRAY_MIN_LEN];  /* host name */
+   char name[1];   /* host name */
 }SCTP_PACKED;
 
 /*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r227840 - head/bin/ps

2011-11-22 Thread Alexander Best
On Tue Nov 22 11, Mikolaj Golub wrote:
> Author: trociny
> Date: Tue Nov 22 21:14:46 2011
> New Revision: 227840
> URL: http://svn.freebsd.org/changeset/base/227840
> 
> Log:
>   No need in procfs(5).
>   
>   MFC after:  2 weeks
> 
> Modified:
>   head/bin/ps/ps.1
>   head/bin/ps/ps.c
> 
> Modified: head/bin/ps/ps.1
> ==
> --- head/bin/ps/ps.1  Tue Nov 22 21:12:28 2011(r227839)
> +++ head/bin/ps/ps.1  Tue Nov 22 21:14:46 2011(r227840)
> @@ -29,7 +29,7 @@
>  .\" @(#)ps.1 8.3 (Berkeley) 4/18/94
>  .\" $FreeBSD$
>  .\"
> -.Dd October 30, 2011
> +.Dd November 22, 2011
>  .Dt PS 1
>  .Os
>  .Sh NAME
> @@ -686,9 +686,6 @@ attempts to automatically determine the 
>  .Bl -tag -width ".Pa /boot/kernel/kernel" -compact
>  .It Pa /boot/kernel/kernel
>  default system namelist
> -.It Pa /proc
> -the mount point of
> -.Xr procfs 5

are these references to procfs still necessary in the ps(1) man page?

1)
"
 The process file system (see procfs(5)) should be mounted when ps is exe-
 cuted, otherwise not all information will be available.
"

and 2)

"
SEE ALSO
 kill(1), pgrep(1), pkill(1), procstat(1), w(1), kvm(3), strftime(3),
 mac(4), procfs(5), pstat(8), sysctl(8), mutex(9)
"

?

cheers.
alex


>  .El
>  .Sh SEE ALSO
>  .Xr kill 1 ,
> 
> Modified: head/bin/ps/ps.c
> ==
> --- head/bin/ps/ps.c  Tue Nov 22 21:12:28 2011(r227839)
> +++ head/bin/ps/ps.c  Tue Nov 22 21:14:46 2011(r227840)
> @@ -130,7 +130,6 @@ struct listinfo {
>   } l;
>  };
>  
> -static intcheck_procfs(void);
>  static intaddelem_gid(struct listinfo *, const char *);
>  static intaddelem_pid(struct listinfo *, const char *);
>  static intaddelem_tty(struct listinfo *, const char *);
> @@ -411,14 +410,6 @@ main(int argc, char *argv[])
>   argv += optind;
>  
>   /*
> -  * If the user specified ps -e then they want a copy of the process
> -  * environment kvm_getenvv(3) attempts to open /proc//mem.
> -  * Check to make sure that procfs is mounted on /proc, otherwise
> -  * print a warning informing the user that output will be incomplete.
> -  */
> - if (needenv == 1 && check_procfs() == 0)
> - warnx("Process environment requires procfs(5)");
> - /*
>* If there arguments after processing all the options, attempt
>* to treat them as a list of process ids.
>*/
> @@ -1360,18 +1351,6 @@ kludge_oldps_options(const char *optlist
>   return (newopts);
>  }
>  
> -static int
> -check_procfs(void)
> -{
> - struct statfs mnt;
> -
> - if (statfs("/proc", &mnt) < 0)
> - return (0);
> - if (strcmp(mnt.f_fstypename, "procfs") != 0)
> - return (0);
> - return (1);
> -}
> -
>  static void
>  usage(void)
>  {
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r227769 - head

2011-11-20 Thread Alexander Best
On Sun Nov 20 11, Glen Barber wrote:
> Author: gjb (doc committer)
> Date: Sun Nov 20 19:05:32 2011
> New Revision: 227769
> URL: http://svn.freebsd.org/changeset/base/227769
> 
> Log:
>   Add a note to src/Makefile that explains that 'rm' runs twice because the
>   second invocation only needs to operate on files with the immutable flag

thanks for taking care of this one. :)

are we sure we're only dealing with the immutable flag? since chflags is being
invoked as 'chflags -R 0' and not 'chflags -R noschg', wouldn't it be better to
refer to "file flags" in general and not only to the "immutable flag"?

cheers.
alex

>   set.
>   
>   Submitted by:   arundel (via private email) (original version)
>   Discussed on:   -toolchain@
>   MFC after:  3 days
> 
> Modified:
>   head/Makefile
> 
> Modified: head/Makefile
> ==
> --- head/Makefile Sun Nov 20 18:01:45 2011(r227768)
> +++ head/Makefile Sun Nov 20 19:05:32 2011(r227769)
> @@ -185,7 +185,10 @@ buildworld: upgrade_checks
>  # files with chflags set, so this unsets them and tries the 'rm' a
>  # second time.  There are situations where this target will be cleaning
>  # some directories via more than one method, but that duplication is
> -# needed to correctly handle all the possible situations.
> +# needed to correctly handle all the possible situations.  Removing all
> +# files without the immutable flag set in the first 'rm' instance saves
> +# time, because 'chflags' will need to operate on fewer files (with the
> +# immutable flag set) afterwards.
>  #
>  BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
>  cleanworld:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r227164 - head/usr.bin/du

2011-11-06 Thread Alexander Best
On Sun Nov  6 11, Ed Schouten wrote:
> Hi Alexander,
> 
> * Alexander Best , 2006 23:30:
> > +The
> > +.Fl a, d
> > +and
> > +.Fl s
> > +options are mutually exclusive.
> > +.Pp
> > +The
> > +.Fl H, L
> > +and
> > +.Fl P
> > +options are mutually exclusive.
> 
> This can already be derived from the SYNOPSIS, right?

partially:


"du [-A] [-H | -L | -P] [-a | -s | -d depth | -t threshold] [-c] [-l]
[-h | -k | -m | -B blocksize] [-n] [-x] [-I mask] [file ...]"

1) [-H | -L | -P] is correct
2) [-a | -s | -d depth | -t threshold] is not correct. the -t option can be
   used together with the -a, -s and -d options.
3) [-h | -k | -m | -B blocksize] is not correct. the -B option can be used
   together with the -h, -k and -m options.
   also style(9) describes "|" as "either-or" operator. for the -h, -k and -m
   options this isn't true. they can very well be used in a single command, but
   the last option backs out all the previous ones.

i think the following would be better:

"du [-Achklmnx] [-H | -L | -P] [-a | -s | -d depth] [-B blocksize]
[-I mask] [-t threshold] [file ...]"

and the paragraph

"The -h, -k and -m options all override each other; the last one specified
 determines the block count used."

cheers.
alex

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r227164 - head/usr.bin/du

2011-11-06 Thread Alexander Best
On Sun Nov  6 11, Ed Schouten wrote:
> Hi Alexander,
> 
> * Alexander Best , 2006 21:46:
> > this diff was flying around in my /usr/src, which makes some code a bit more
> > readable. maybe this is something worth having in HEAD?
> 
> Looks good. It seems we can also get rid of the `listall' variable here.
> The rest of the code also uses the `*flag' variables, so there's no
> reason why we can't just use `aflag'. Does this patch look good to you?

loking good. :)

i also found this man page update.

cheers.
alex

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/




diff --git a/usr.bin/du/du.1 b/usr.bin/du/du.1
index ef8b5ac..f85cdf3 100644
--- a/usr.bin/du/du.1
+++ b/usr.bin/du/du.1
@@ -28,7 +28,7 @@
 .\"@(#)du.18.2 (Berkeley) 4/1/94
 .\" $FreeBSD$
 .\"
-.Dd November 6, 2008
+.Dd November 6, 2011
 .Dt DU 1
 .Os
 .Sh NAME
@@ -65,7 +65,9 @@ Calculate block counts in
 .Ar blocksize
 byte blocks.
 This is different from the
-.Fl k, m
+.Fl k
+and
+.Fl m
 options or setting
 .Ev BLOCKSIZE
 and gives an estimate of how much space the examined file hierarchy would
@@ -154,6 +156,25 @@ or
 .Fl L
 options are specified, storage used by any symbolic links which are
 followed is not counted or displayed.
+.Pp
+The
+.Fl a, d
+and
+.Fl s
+options are mutually exclusive.
+.Pp
+The
+.Fl H, L
+and
+.Fl P
+options are mutually exclusive.
+.Pp
+The
+.Fl h, k
+and
+.Fl m
+options all override each other; the last one specified determines
+the block count used.
 .Sh ENVIRONMENT
 .Bl -tag -width BLOCKSIZE
 .It Ev BLOCKSIZE
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r227164 - head/usr.bin/du

2011-11-06 Thread Alexander Best
On Sun Nov  6 11, Ed Schouten wrote:
> Author: ed
> Date: Sun Nov  6 08:15:17 2011
> New Revision: 227164
> URL: http://svn.freebsd.org/changeset/base/227164
> 
> Log:
>   Add missing static keywords to du(1)

this diff was flying around in my /usr/src, which makes some code a bit more
readable. maybe this is something worth having in HEAD?

cheers.
alex

> 
> Modified:
>   head/usr.bin/du/du.c
> 
> Modified: head/usr.bin/du/du.c
> ==
> --- head/usr.bin/du/du.c  Sun Nov  6 08:14:57 2011(r227163)
> +++ head/usr.bin/du/du.c  Sun Nov  6 08:15:17 2011(r227164)
> @@ -61,7 +61,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  
> -SLIST_HEAD(ignhead, ignentry) ignores;
> +static SLIST_HEAD(ignhead, ignentry) ignores;
>  struct ignentry {
>   char*mask;
>   SLIST_ENTRY(ignentry)   next;
diff --git a/usr.bin/du/du.c b/usr.bin/du/du.c
index cdaa70d..4089e04 100644
--- a/usr.bin/du/du.c
+++ b/usr.bin/du/du.c
@@ -231,15 +231,14 @@ main(int argc, char *argv[])
 
listall = 0;
 
-   if (aflag) {
-   if (sflag || dflag)
-   usage();
+   if (aflag + dflag + sflag > 1)
+   usage();
+
+   if (aflag)
listall = 1;
-   } else if (sflag) {
-   if (dflag)
-   usage();
+
+   if (sflag)
depth = 0;
-   }
 
if (!*argv) {
argv = save;

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r226860 - head/etc

2011-10-27 Thread Alexander Best
On Thu Oct 27 11, Gavin Atkinson wrote:
> Author: gavin
> Date: Thu Oct 27 20:35:21 2011
> New Revision: 226860
> URL: http://svn.freebsd.org/changeset/base/226860
> 
> Log:
>   Update the example rules in devfs.conf to reflect the changes since ATA_CAM.
>   While here, add another example rule, as many applications these days
>   expect to find /dev/dvd instead.

http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028406.html

;)

>   
>   MFC after:  3 days
> 
> Modified:
>   head/etc/devfs.conf
> 
> Modified: head/etc/devfs.conf
> ==
> --- head/etc/devfs.conf   Thu Oct 27 20:32:57 2011(r226859)
> +++ head/etc/devfs.conf   Thu Oct 27 20:35:21 2011(r226860)
> @@ -35,7 +35,8 @@
>  #linkttyv0   vga
>  
>  # Commonly used by many ports
> -#linkacd0cdrom
> +#linkcd0 cdrom
> +#linkcd0 dvd
>  
>  # Allow a user in the wheel group to query the smb0 device
>  #permsmb00660
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r226665 - head/sys/conf

2011-10-26 Thread Alexander Best
On Thu Oct 27 11, Bruce Evans wrote:
> On Wed, 26 Oct 2011, Alexander Best wrote:
> 
> >On Sun Oct 23 11, Robert Millan wrote:
> >>Log:
> >>  Conditionalize a pair of FreeBSD GCC extensions so that its CFLAGS are 
> >>  only
> >>  used with FreeBSD GCC.
> >
> >any reason -f* flags were added to CWARNFLAGS in the first place? they 
> >aren't
> >really warnings, are they, so adding them to CFLAGS makes more sense imo.
> 
> -fformat-extensions is added to CWARNFLAGS because it is a modifier
> to -Wformat.  It was originally (in bsd.kern.mk 1.10) placed immediately
> after -Wformat in CWARNFLAGS, and was added in the same commit as
> -Wformat (since -Wformat could not be added before -fformat-extensions
> was developed to allow it to be added without breaking kernel builds).
> This is partially explained in the commit message.  This was obfuscated
> (in bsd.kern.mk 1.14) by removing -Wformat.  1.13 had made -Wformat
> redundant by adding -Wall.  This is not explained in the commit message.
> 
> >diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> >index a0a595f..91560e0 100644
> >--- a/sys/conf/kern.mk
> >+++ b/sys/conf/kern.mk
> >@@ -3,10 +3,9 @@
> >#
> ># Warning flags for compiling the kernel and components of the kernel:
> >#
> >-CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs 
> >-Wstrict-prototypes \
> >-   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
> >-   -Wundef -Wno-pointer-sign -fformat-extensions \
> >-   -Wmissing-include-dirs -fdiagnostics-show-option
> >+CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs 
> >-Wstrict-prototypes\
> >+   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual\
> >+   -Wundef -Wno-pointer-sign -Wmissing-include-dirs
> 
> Neither of these should be moved, except within CWARNFLAGS.
> 
> For -fformat-extensions, see above.
> 
> -fdiagnostics-show option is even more closely related with warning flags
> and even better documented in its commit message, as you should know since
> you submitted it :-).  Actually, the commit message seems to tie it
> more closely with warning flags than it actually is -- it says that
> "it will report which -W* flag was responsible for triggering a certain
> warning", while gcc(1) says that it is for reporting of general diagnostics.
> 
> -Wformat and -fformat-extensions were originally at the end of CWARNFLAGS.
> -fformat-extensions wasn't moved to be with -Wall when that was added.
> Keeping it at the end is reasonable.  But it shouldn't be in the middle
> of random -W flags like it now is.  All of the -W options are unfortunately
> unsorted by adding them to the end of the unsorted list.  Some old versions
> even added -std=c99 to the end.  Since -std has nothing to do with warning
> flags, that was nonsense and has been fixed.
> 
> -fdiagnostics-show-option controls all the warning flags, so it would be
> better placed at the beginning.

thanks for the detailed explanation. how does the following patch look like,
which basically sorts the CWARNINGSFLAGS alphatically and semantically:

diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index a0a595f..b45be2a 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -1,12 +1,15 @@
 # $FreeBSD$
 
 #
-# Warning flags for compiling the kernel and components of the kernel:
+# Warning flags for compiling the kernel and components of the kernel.
+# Additionally enable FreeBSD kernel-specific printf format specifiers
+# and instruct gcc to enable some diagnostics, which make it easier to
+# pinpoint tinderbox failures.
 #
-CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
-   -Wundef -Wno-pointer-sign -fformat-extensions \
-   -Wmissing-include-dirs -fdiagnostics-show-option
+CWARNFLAGS?=   -fdiagnostics-show-option -Wall -Wcast-qual -Winline\
+   -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs\
+   -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef\
+   -Wno-pointer-sign -fformat-extensions
 #
 # The following flags are next up for working on:
 #  -Wextra
@@ -83,7 +86,7 @@ CFLAGS+=  -mno-sse
 .else
 CFLAGS+=   -mno-aes -mno-avx
 .endif
-CFLAGS+=   -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float \
+CFLAGS+=   -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float\
-fno-asynchronous-unwind-tables
 INLINE_LIMIT?= 8000
 .endif

a flag i am unsure about is "-Wno-pointer-sign". one could argue that it should
come right after "-Wpointer-arith", since we use it to back out a certain
w

Re: svn commit: r226665 - head/sys/conf

2011-10-26 Thread Alexander Best
On Sun Oct 23 11, Robert Millan wrote:
> Author: rmh
> Date: Sun Oct 23 16:27:03 2011
> New Revision: 226665
> URL: http://svn.freebsd.org/changeset/base/226665
> 
> Log:
>   Conditionalize a pair of FreeBSD GCC extensions so that its CFLAGS are only
>   used with FreeBSD GCC.

any reason -f* flags were added to CWARNFLAGS in the first place? they aren't
really warnings, are they, so adding them to CFLAGS makes more sense imo.

how about:

diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index a0a595f..91560e0 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -3,10 +3,9 @@
 #
 # Warning flags for compiling the kernel and components of the kernel:
 #
-CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
-   -Wundef -Wno-pointer-sign -fformat-extensions \
-   -Wmissing-include-dirs -fdiagnostics-show-option
+CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes\
+   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual\
+   -Wundef -Wno-pointer-sign -Wmissing-include-dirs
 #
 # The following flags are next up for working on:
 #  -Wextra
@@ -83,7 +82,7 @@ CFLAGS+=  -mno-sse
 .else
 CFLAGS+=   -mno-aes -mno-avx
 .endif
-CFLAGS+=   -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float \
+CFLAGS+=   -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float\
-fno-asynchronous-unwind-tables
 INLINE_LIMIT?= 8000
 .endif
@@ -120,11 +119,19 @@ INLINE_LIMIT?=8000
 CFLAGS+=   -ffreestanding
 
 #
+# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc to
+# enable some diagnostics, which make it easier to pinpoint tinderbox failures.
+# Clang already has these diagnostics enabled by default.
+#
+CFLAGS+=   -fformat-extensions -fdiagnostics-show-option
+
+#
 # GCC SSP support
 #

this also gets rid of some cases where double spaces occur during compilation.
that's just eye candy though.

cheers.
alex

>   
>   Approved by:kib (mentor)
> 
> Modified:
>   head/sys/conf/kern.mk
> 
> Modified: head/sys/conf/kern.mk
> ==
> --- head/sys/conf/kern.mk Sun Oct 23 16:04:07 2011(r226664)
> +++ head/sys/conf/kern.mk Sun Oct 23 16:27:03 2011(r226665)
> @@ -1,11 +1,21 @@
>  # $FreeBSD$
>  
> +.if ${CC:T:Mclang} != "clang"
> +FREEBSD_GCC!=${CC} --version | grep FreeBSD || true
> +.endif
> +
>  #
>  # Warning flags for compiling the kernel and components of the kernel:
>  #
> +.if ${FREEBSD_GCC}
> +# FreeBSD extensions, not available in upstream GCC
> +format_extensions=   -fformat-extensions
> +no_align_long_strings=   -mno-align-long-strings
> +.endif
> +
>  CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
>   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
> - -Wundef -Wno-pointer-sign -fformat-extensions \
> + -Wundef -Wno-pointer-sign ${format_extensions} \
>   -Wmissing-include-dirs -fdiagnostics-show-option
>  #
>  # The following flags are next up for working on:
> @@ -32,7 +42,7 @@ CWARNFLAGS?=-Wall -Wredundant-decls -Wn
>  #
>  .if ${MACHINE_CPUARCH} == "i386"
>  .if ${CC:T:Mclang} != "clang"
> -CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
> +CFLAGS+= ${no_align_long_strings} -mpreferred-stack-boundary=2 -mno-sse
>  .else
>  CFLAGS+= -mno-aes -mno-avx
>  .endif
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-26 Thread Alexander Best
On Sun Oct  9 11, Ed Schouten wrote:
> * Alexander Best , 20111009 03:11:
> > is this what you had in mind?
> 
> Yes, exactly. :-)

here's an updated patch, which also includes a man page addition. please
anybody feel free to commit.

cheers.
alex

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


Index: bin/ps/ps.1
===
--- bin/ps/ps.1 (revision 226769)
+++ bin/ps/ps.1 (working copy)
@@ -29,7 +29,7 @@
 .\" @(#)ps.1   8.3 (Berkeley) 4/18/94
 .\" $FreeBSD$
 .\"
-.Dd October 1, 2011
+.Dd October 26, 2011
 .Dt PS 1
 .Os
 .Sh NAME
@@ -437,6 +437,10 @@
 .Ql -
 if the process can no longer reach that
 controlling terminal (i.e., it has been revoked).
+A
+.Ql -
+without a preceding two letter abbreviation or pseudo-terminal device number
+indicates a process which never had a controlling terminal.
 The full pathname of the controlling terminal is available via the
 .Cm tty
 keyword.
Index: bin/ps/print.c
===
--- bin/ps/print.c  (revision 226769)
+++ bin/ps/print.c  (working copy)
@@ -362,7 +362,7 @@
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV)
-   str = strdup("??");
+   str = strdup("-");
else
asprintf(&str, "%#jx", (uintmax_t)dev);
 
@@ -379,7 +379,7 @@
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV || (ttname = devname(dev, S_IFCHR)) == NULL)
-   str = strdup("?? ");
+   str = strdup("- ");
else {
if (strncmp(ttname, "tty", 3) == 0 ||
strncmp(ttname, "cua", 3) == 0)
@@ -403,7 +403,7 @@
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV || (ttname = devname(dev, S_IFCHR)) == NULL)
-   ttname = "??";
+   ttname = "-";
 
return (strdup(ttname));
 }
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r226519 - head/gnu/usr.bin/cc/cc_tools

2011-10-18 Thread Alexander Best
On Tue Oct 18 11, Dimitry Andric wrote:
> Author: dim
> Date: Tue Oct 18 17:38:25 2011
> New Revision: 226519
> URL: http://svn.freebsd.org/changeset/base/226519
> 
> Log:
>   Update gcc's __FreeBSD__ and __FreeBSD_cc_version macros for FreeBSD 10.

should these also be updated to 9? maybe before it gets released?

cheers.
alex

> 
> Modified:
>   head/gnu/usr.bin/cc/cc_tools/freebsd-native.h
> 
> Modified: head/gnu/usr.bin/cc/cc_tools/freebsd-native.h
> ==
> --- head/gnu/usr.bin/cc/cc_tools/freebsd-native.h Tue Oct 18 17:37:18 
> 2011(r226518)
> +++ head/gnu/usr.bin/cc/cc_tools/freebsd-native.h Tue Oct 18 17:38:25 
> 2011(r226519)
> @@ -7,8 +7,8 @@
>  #define FREEBSD_NATIVE 1
>  
>  /* Fake out gcc/config/freebsd.h.  */
> -#define  FBSD_MAJOR  8
> -#define  FBSD_CC_VER 81  /* form like __FreeBSD_version 
> */
> +#define  FBSD_MAJOR  10
> +#define  FBSD_CC_VER 101 /* form like __FreeBSD_version 
> */
>  
>  #undef SYSTEM_INCLUDE_DIR/* We don't need one for now. */
>  #undef TOOL_INCLUDE_DIR  /* We don't need one for now. */
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r226266 - head/sbin/tunefs

2011-10-11 Thread Alexander Best
On Tue Oct 11 11, Kirk McKusick wrote:
> Author: mckusick
> Date: Tue Oct 11 19:03:57 2011
> New Revision: 226266
> URL: http://svn.freebsd.org/changeset/base/226266
> 
> Log:
>   After creating a filesystem using newfs -j the time stamps are all
>   zero and thus report as having been made in January 1970. Apart
>   from looking a bit silly, it also triggers alarms from scripts
>   that detect weird time stamps. This update sets all 4 (or 3, in
>   the case of UFS1) time stamps to the current time when enabling
>   journaling during newfs or later when enabling it with tunefs.

on an already existing UFS2 fs with SU+SUJ enabled, will a `touch .sujournal`
also set those 4 time stamps to sensible values, or will this somehow break
the journal?

cheers.
alex

>   
>   Reported by: Hans Ottevanger 
>   MFC after:   1 week
> 
> Modified:
>   head/sbin/tunefs/tunefs.c
> 
> Modified: head/sbin/tunefs/tunefs.c
> ==
> --- head/sbin/tunefs/tunefs.c Tue Oct 11 18:46:41 2011(r226265)
> +++ head/sbin/tunefs/tunefs.c Tue Oct 11 19:03:57 2011(r226266)
> @@ -64,6 +64,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /* the optimization warning string template */
> @@ -923,6 +924,7 @@ journal_alloc(int64_t size)
>   ino_t ino;
>   int blks;
>   int mode;
> + time_t utime;
>   int i;
>  
>   cgp = &disk.d_cg;
> @@ -983,18 +985,26 @@ journal_alloc(int64_t size)
>*/
>   dp2 = ip;
>   dp1 = ip;
> + time(&utime);
>   if (sblock.fs_magic == FS_UFS1_MAGIC) {
>   bzero(dp1, sizeof(*dp1));
>   dp1->di_size = size;
>   dp1->di_mode = IFREG | IREAD;
>   dp1->di_nlink = 1;
>   dp1->di_flags = SF_IMMUTABLE | SF_NOUNLINK | UF_NODUMP;
> + dp1->di_atime = utime;
> + dp1->di_mtime = utime;
> + dp1->di_ctime = utime;
>   } else {
>   bzero(dp2, sizeof(*dp2));
>   dp2->di_size = size;
>   dp2->di_mode = IFREG | IREAD;
>   dp2->di_nlink = 1;
>   dp2->di_flags = SF_IMMUTABLE | SF_NOUNLINK | UF_NODUMP;
> + dp2->di_atime = utime;
> + dp2->di_mtime = utime;
> + dp2->di_ctime = utime;
> + dp2->di_birthtime = utime;
>   }
>   for (i = 0; i < NDADDR && resid; i++, resid--) {
>   blk = journal_balloc();
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-09 Thread Alexander Best
On Sun Oct  9 11, Ed Schouten wrote:
> * Alexander Best , 20111009 03:11:
> > is this what you had in mind?
> 
> Yes, exactly. :-)

here you are. ;)

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


diff --git a/bin/ps/print.c b/bin/ps/print.c
index 45c7823..021415f 100644
--- a/bin/ps/print.c
+++ b/bin/ps/print.c
@@ -362,7 +362,7 @@ tdev(KINFO *k, VARENT *ve)
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV)
-   str = strdup("??");
+   str = strdup("-");
else
asprintf(&str, "%#jx", (uintmax_t)dev);
 
@@ -379,7 +379,7 @@ tname(KINFO *k, VARENT *ve)
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV || (ttname = devname(dev, S_IFCHR)) == NULL)
-   str = strdup("?? ");
+   str = strdup("- ");
else {
if (strncmp(ttname, "tty", 3) == 0 ||
strncmp(ttname, "cua", 3) == 0)
@@ -403,7 +403,7 @@ longtname(KINFO *k, VARENT *ve)
v = ve->var;
dev = k->ki_p->ki_tdev;
if (dev == NODEV || (ttname = devname(dev, S_IFCHR)) == NULL)
-   ttname = "??";
+   ttname = "-";
 
return (strdup(ttname));
 }
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r225868 - head/bin/ps

2011-10-08 Thread Alexander Best
On Sat Oct  1 11, Ed Schouten wrote:
> * Alexander Best , 20110929 14:14:
> > i think i wrote you about the two spaces between the "TT" and "TIME" field
> > some time ago. you said that the "TT" entry can contain a postfix "-". can
> > you describe a situation, where this can occur? i've never seen the "TT" 
> > field
> > contain an entry larger than 2 chars.
> 
> Also, it would be better if we replaced the "??" string with "-". When
> we print "??", it actually means: this process has no controlling
> terminal, not that we don't know which TTY it is.

i've adjusted ps(1) and now the output looks like this:

otaku% ps -xOtty,tdev   
  PID TTY   TDEV TT  STAT TIME COMMAND
 1427 --  -  Is   15:02,64 /usr/local/bin/musicpd 
/usr/local/etc/musicpd.conf
 1692 --  -  Is0:00,15 ssh-agent
 1740 --  -  Ss0:00,69 /usr/local/bin/dbus-daemon --fork 
--print-pid 5 --print-address 7 --session
 1744 --  -  Is   10:02,33 /usr/local/bin/sakura
 1746 --  -  S 3:24,25 /usr/local/libexec/gam_server
45117 --  -  Ss3:29,84 /usr/local/bin/pidgin
55734 --  -  Is   17:03,48 /usr/local/bin/python2.7 
/usr/local/bin/sonata
63888 --  -  Is3:21,53 chromium-browser:  (chrome)
63889 --  -  I 0:05,26 chromium-browser:  (chrome)
63890 --  -  I 0:00,43 chrome: --type=zygote (chrome)
63891 --  -  S 0:50,87 chrome: --type=zygote (chrome)
63892 --  -  I 0:21,03 chrome: --type=zygote (chrome)
63893 --  -  I 0:06,14 chrome: --type=zygote (chrome)
63894 --  -  S 0:21,96 chrome: --type=zygote (chrome)
63904 --  -  I 0:08,63 chrome: --type=zygote (chrome)
63905 --  -  I 0:03,64 chrome: --type=zygote (chrome)
63907 --  -  S 0:38,14 chrome: --type=zygote (chrome)
63908 --  -  S 0:33,20 chrome: --type=zygote (chrome)
63909 --  -  S 0:14,13 chrome: --type=zygote (chrome)
63910 --  -  S 0:14,96 chrome: --type=zygote (chrome)
63911 --  -  S 0:21,98 chrome: --type=zygote (chrome)
63913 --  -  I 0:06,10 chrome: --type=zygote (chrome)
63914 --  -  I 0:05,95 chrome: --type=zygote (chrome)
63915 --  -  I 0:03,11 chrome: --type=zygote (chrome)
63916 --  -  S 0:20,96 chrome: --type=zygote (chrome)
63917 --  -  I 0:09,19 chrome: --type=zygote (chrome)
64191 --  -  Z 0:07,58 
64270 --  -  I 0:31,20 chrome: --type=zygote (chrome)
64271 --  -  I 0:12,39 chrome: --type=zygote (chrome)
64326 --  -  I 0:08,61 chrome: --type=zygote (chrome)
64327 --  -  I 0:03,11 chrome: --type=zygote (chrome)
64341 --  -  I 0:05,40 chrome: --type=zygote (chrome)
64361 --  -  I 0:12,72 chrome: --type=zygote (chrome)
64664 --  -  Z 0:00,60 
65411 --  -  S 0:00,01 /usr/local/bin/pidgin
 1664 ttyv0 0x2f v0  IW0:00,00 -zsh (zsh)
 1712 ttyv0 0x2f v0  IW+   0:00,00 /bin/sh /usr/local/bin/startx
 1730 ttyv0 0x2f v0  IW+   0:00,00 xinit /home/arundel/.xinitrc -- 
/home/arundel/.xserverrc :0 -auth /home/arundel/.serverauth.1712
 1734 ttyv0 0x2f v0  IW0:00,00 sh /home/arundel/.xinitrc
 1735 ttyv0 0x2f v0  S39:35,89 /usr/local/bin/awesome
 1739 ttyv0 0x2f v0  I 0:00,00 dbus-launch --autolaunch 
1210d605f192e5e97cd9d23a00043997 --binary-syntax --close-stderr
55738 pts/0 0x6b  0  IWs   0:00,00 /usr/local/bin/zsh
62073 pts/0 0x6b  0  I+0:02,11 ssh hub
64131 pts/5 0x6c  5  Is+   0:00,09 /usr/local/bin/zsh
64134 pts/6 0x96  6  Is+   0:00,50 /usr/local/bin/zsh
63523 pts/1 0x99  1  Is+   0:00,10 /usr/local/bin/zsh
63586 pts/2 0x9a  2  Is0:00,05 /usr/local/bin/zsh
64254 pts/2 0x9a  2  I+0:00,37 ssh hub
63656 pts/3 0x9c  3  Is0:00,22 /usr/local/bin/zsh
64267 pts/3 0x9c  3  I+0:00,63 ssh freefall
64382 pts/7 0x9d  7  Ss0:00,16 /usr/local/bin/zsh
65413 pts/7 0x9d  7  R+0:00,00 ps -xOtty,tdev
64384 pts/8 0x9e  8  Is0:00,13 /usr/local/bin/zsh
64470 pts/8 0x9e  8  I 0:00,12 zsh
64642 pts/8 0x9e  8  I+0:00,09 edit machine.c
64484 pts/9 0x9f  9  Is+   0:00,24 /usr/local/bin/zsh

is this what you had in mind?

cheers.
alex

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-05 Thread Alexander Best
On Wed Oct  5 11, David O'Brien wrote:
> On Sat, Oct 01, 2011 at 12:43:23PM +, Alexander Best wrote:
> > we could then add an envar $PS, so users can set PS=-k to restore the
> 
> Should be spelled "PS_OPTIONS" please.  Many of us likely have
> "export PS=_" in order to have dot files that support multiple OS's.
> 
> This is also in-line with FreeBSD's existing "MALLOC_OPTIONS",
> "DIFF_OPTIONS", "GREP_OPTIONS", "GCC_OPTIONS", etc...

thanks for the hint. *if* it is being decided that ps(1) should get its own
envar, i'll make sure "PS_OPTIONS" gets chosen as the identifier. ;)

cheers.
alex

> 
> -- 
> -- David  (obr...@freebsd.org)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225927 - head/bin/ps

2011-10-04 Thread Alexander Best
On Mon Oct  3 11, Alexander Best wrote:
> On Sun Oct  2 11, Glen Barber wrote:
> > Author: gjb (doc committer)
> > Date: Sun Oct  2 16:05:19 2011
> > New Revision: 225927
> > URL: http://svn.freebsd.org/changeset/base/225927
> > 
> > Log:
> >   Correct a typo that was introduced in 225912
> >   
> >   Submitted by: Valentin Nechayev (netch % netch!kiev!ua), 
> > arundel
> >   MFC after:1 week
> >   With-MFC: 225908
> > 
> > Modified:
> >   head/bin/ps/ps.1
> 
> i've been reviewing the ps(1) man page some more and found several other
> issues. in addition to those, i think some of the recent changes could be
> improved, too.
> 
> it would be nice to hear what people think regarding these changes.

i'll try tidying up the man page a bit more and will then submit a PR. the
patch is quite extensive, so i guess filing this as PR is a better idea.

cheers.
alex

> 
> cheers.
> alex
> 
> > 
> > Modified: head/bin/ps/ps.1
> > ==
> > --- head/bin/ps/ps.1Sun Oct  2 14:10:25 2011(r225926)
> > +++ head/bin/ps/ps.1Sun Oct  2 16:05:19 2011(r225927)
> > @@ -431,7 +431,7 @@ The process is being traced or debugged.
> >  An abbreviation for the pathname of the controlling terminal, if any.
> >  The abbreviation consists of the three letters following
> >  .Pa /dev/tty ,
> > -or, for psuedo-terminals, the corresponding entry in
> > +or, for pseudo-terminals, the corresponding entry in
> >  .Pa /dev/pts .
> >  This is followed by a
> >  .Ql -

> diff --git a/bin/ps/ps.1 b/bin/ps/ps.1
> index 2c04c21..965abcb 100644
> --- a/bin/ps/ps.1
> +++ b/bin/ps/ps.1
> @@ -29,7 +29,7 @@
>  .\" @(#)ps.1 8.3 (Berkeley) 4/18/94
>  .\" $FreeBSD$
>  .\"
> -.Dd October 1, 2011
> +.Dd October 3, 2011
>  .Dt PS 1
>  .Os
>  .Sh NAME
> @@ -98,6 +98,16 @@ The default output format includes, for each process, the 
> process' ID,
>  controlling terminal, state, CPU time (including both user and system time)
>  and associated command.
>  .Pp
> +The
> +.Fl G , O , o , p , t
> +and
> +.Fl U
> +options accept, in addition to a single argument, a list of arguments
> +which must be space or comma seperated.
> +Also these options can be used more than once in a single
> +.Nm
> +command.
> +.Pp
>  The process file system (see
>  .Xr procfs 5 )
>  should be mounted when
> @@ -184,11 +194,15 @@ Add the information associated with the space or comma 
> separated list
>  of keywords specified, after the process ID,
>  in the default information
>  display.
> -Keywords may be appended with an equals
> +The last keyword in the list may be appended with an equals
>  .Pq Ql =
> -sign and a string.
> +sign and a string that spans the rest of the argument, and can contain
> +space and comma characters.
>  This causes the printed header to use the specified string instead of
>  the standard header.
> +To specify header texts for multiple keywords, more than one
> +.Fl O
> +option must be used.
>  .It Fl o
>  Display information associated with the space or comma separated
>  list of keywords specified.
> @@ -198,10 +212,9 @@ sign and a string that spans the rest of the argument, 
> and can contain
>  space and comma characters.
>  This causes the printed header to use the specified string instead of
>  the standard header.
> -Multiple keywords may also be given in the form of more than one
> +To specify header texts for multiple keywords, more than one
>  .Fl o
> -option.
> -So the header texts for multiple keywords can be changed.
> +option must be used.
>  If all keywords have empty header texts, no header line is written.
>  .It Fl p
>  Display information about processes which match the specified process IDs.
> @@ -217,7 +230,9 @@ with the standard input.
>  .It Fl t
>  Display information about processes attached to the specified terminal
>  devices.
> -Full pathnames, as well as abbreviations (see explanation of the
> +Full pathnames, relative pathnames to
> +.Pa /dev ,
> +as well as abbreviations (see explanation of the
>  .Cm tt
>  keyword) can be specified.
>  .It Fl U
> @@ -428,16 +443,16 @@ The process is swapped out.
>  The process is being traced or debugged.
>  .El
>  .It Cm tt
> -An abbreviation for the pathname of the controlling terminal, if any.
> -The abbreviation consists of the three letters following
> +An abbreviation for the device name of the controlling terminal, if any.
> +The abbreviation consists of the two

Re: svn commit: r225927 - head/bin/ps

2011-10-03 Thread Alexander Best
On Sun Oct  2 11, Glen Barber wrote:
> Author: gjb (doc committer)
> Date: Sun Oct  2 16:05:19 2011
> New Revision: 225927
> URL: http://svn.freebsd.org/changeset/base/225927
> 
> Log:
>   Correct a typo that was introduced in 225912
>   
>   Submitted by:   Valentin Nechayev (netch % netch!kiev!ua), 
> arundel
>   MFC after:  1 week
>   With-MFC:   225908
> 
> Modified:
>   head/bin/ps/ps.1

i've been reviewing the ps(1) man page some more and found several other
issues. in addition to those, i think some of the recent changes could be
improved, too.

it would be nice to hear what people think regarding these changes.

cheers.
alex

> 
> Modified: head/bin/ps/ps.1
> ==
> --- head/bin/ps/ps.1  Sun Oct  2 14:10:25 2011(r225926)
> +++ head/bin/ps/ps.1  Sun Oct  2 16:05:19 2011(r225927)
> @@ -431,7 +431,7 @@ The process is being traced or debugged.
>  An abbreviation for the pathname of the controlling terminal, if any.
>  The abbreviation consists of the three letters following
>  .Pa /dev/tty ,
> -or, for psuedo-terminals, the corresponding entry in
> +or, for pseudo-terminals, the corresponding entry in
>  .Pa /dev/pts .
>  This is followed by a
>  .Ql -
diff --git a/bin/ps/ps.1 b/bin/ps/ps.1
index 2c04c21..965abcb 100644
--- a/bin/ps/ps.1
+++ b/bin/ps/ps.1
@@ -29,7 +29,7 @@
 .\" @(#)ps.1   8.3 (Berkeley) 4/18/94
 .\" $FreeBSD$
 .\"
-.Dd October 1, 2011
+.Dd October 3, 2011
 .Dt PS 1
 .Os
 .Sh NAME
@@ -98,6 +98,16 @@ The default output format includes, for each process, the 
process' ID,
 controlling terminal, state, CPU time (including both user and system time)
 and associated command.
 .Pp
+The
+.Fl G , O , o , p , t
+and
+.Fl U
+options accept, in addition to a single argument, a list of arguments
+which must be space or comma seperated.
+Also these options can be used more than once in a single
+.Nm
+command.
+.Pp
 The process file system (see
 .Xr procfs 5 )
 should be mounted when
@@ -184,11 +194,15 @@ Add the information associated with the space or comma 
separated list
 of keywords specified, after the process ID,
 in the default information
 display.
-Keywords may be appended with an equals
+The last keyword in the list may be appended with an equals
 .Pq Ql =
-sign and a string.
+sign and a string that spans the rest of the argument, and can contain
+space and comma characters.
 This causes the printed header to use the specified string instead of
 the standard header.
+To specify header texts for multiple keywords, more than one
+.Fl O
+option must be used.
 .It Fl o
 Display information associated with the space or comma separated
 list of keywords specified.
@@ -198,10 +212,9 @@ sign and a string that spans the rest of the argument, and 
can contain
 space and comma characters.
 This causes the printed header to use the specified string instead of
 the standard header.
-Multiple keywords may also be given in the form of more than one
+To specify header texts for multiple keywords, more than one
 .Fl o
-option.
-So the header texts for multiple keywords can be changed.
+option must be used.
 If all keywords have empty header texts, no header line is written.
 .It Fl p
 Display information about processes which match the specified process IDs.
@@ -217,7 +230,9 @@ with the standard input.
 .It Fl t
 Display information about processes attached to the specified terminal
 devices.
-Full pathnames, as well as abbreviations (see explanation of the
+Full pathnames, relative pathnames to
+.Pa /dev ,
+as well as abbreviations (see explanation of the
 .Cm tt
 keyword) can be specified.
 .It Fl U
@@ -428,16 +443,16 @@ The process is swapped out.
 The process is being traced or debugged.
 .El
 .It Cm tt
-An abbreviation for the pathname of the controlling terminal, if any.
-The abbreviation consists of the three letters following
+An abbreviation for the device name of the controlling terminal, if any.
+The abbreviation consists of the two letters following
 .Pa /dev/tty ,
-or, for pseudo-terminals, the corresponding entry in
+or, for pseudo-terminals, the corresponding device number in
 .Pa /dev/pts .
 This is followed by a
 .Ql -
 if the process can no longer reach that
 controlling terminal (i.e., it has been revoked).
-The full pathname of the controlling terminal is available via the
+The full device name of the controlling terminal is available via the
 .Cm tty
 keyword.
 .It Cm wchan
@@ -636,9 +651,12 @@ control terminal session ID
 .It Cm tsiz
 text size (in Kbytes)
 .It Cm tt
-control terminal name (two letter abbreviation)
+abbreviated two letter control terminal name or
+device number for pseudo-terminals
 .It Cm tty
-full name of control terminal
+full name of control terminal or
+.Pa pts/ Ns Ao Ar tt Ac
+for pseudo-terminals
 .It Cm ucomm
 name to be used for accounting
 .It Cm uid
___
svn-src-all@freebsd.org mailing list

Re: svn commit: r225868 - head/bin/ps

2011-10-01 Thread Alexander Best
On Sun Oct  2 11, Ed Schouten wrote:
> * Alexander Best , 20111001 23:10:
> > i'd like to propose the following patch. any objections?
> 
> Looks good!

here's an updated patch, which fixes another few issues imo:

http://lists.freebsd.org/pipermail/freebsd-doc/2011-October/018910.html

cheers.
alex

> 
> Thanks,
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-01 Thread Alexander Best
On Sat Oct  1 11, Alexander Best wrote:
> On Sat Oct  1 11, Jilles Tjoelker wrote:
> > On Sat, Oct 01, 2011 at 05:14:01PM +, Alexander Best wrote:
> > > On Sat Oct  1 11, Ed Schouten wrote:
> > > > Also, it would be better if we replaced the "??" string with "-". When
> > > > we print "??", it actually means: this process has no controlling
> > > > terminal, not that we don't know which TTY it is.
> > 
> > > good point. also i was thinking: if a process had a controlling
> > > terminal, but that terminal has been revoked, are users really
> > > interested to know what the name of that revoked terminal was? can't
> > > we just use "-"? is it important to know whether a process never had a
> > > controlling terminal, or had one at some point, but not anymore?
> > 
> > I think this is potentially useful, because it shows that the process
> > did not explicitly detach from the terminal (such as via setsid(2)).
> > 
> > Particularly if the terminal is real (not a pseudo-terminal), its name
> > may be useful in recognition.
> > 
> > When asking for processes attached to a specific terminal with ps's t
> > option, ps will also show processes that used to be attached ("-"),
> > possibly allowing users to keep track of processes better.
> > 
> > It appears that even if a terminal is "revoked" in this way, it still
> > prevents reuse of the pts number.
> 
> that's a very good explanation. :) so yeah...let's keep it the way it is.
> 
> > 
> > > also the ps(1) man page claims that a process running on console has a 
> > > "TT"
> > > entry of "con". i've never seen such an entry. is this still correct?
> > 
> > This may indeed be no longer the case, although it was never common to
> > see "con". With syscons in multi-user mode, you cannot log in on
> > /dev/console, only on /dev/ttyv*. With syscons in single-user mode,
> > ps(1) says "v0" or "ttyv0" but tty(1) says /dev/console.
> > 
> > > and the last point i'd like to make: looking at 'ps alx' on freebsd
> > > 7.x makes it easy to distinguish between ttys and pts'es, because they
> > > are names ttyvX and ttypX. looking at the same output under HEAD, all
> > > pts terminal descriptors have moved to /dev/pts/X. so they will not
> > > show up as pX, but merely as X.
> > 
> > > can't we tell ps to prefix anything coming from /dev/pts with a "p"?
> > 
> > > in this output:
> > 
> > >  1001 1780 1778   1  16  0   15956   3136 pauseIs00:00,02 
> > > /usr/local/bin/zsh
> > 
> > > users are supposed to know that the "0" stands for /dev/pts/0. imho
> > 
> > >  1001 1780 1778   1  16  0   15956   3136 pauseIs   p00:00,02 
> > > /usr/local/bin/zsh
> > 
> > > would be much better here (like under freebsd 7.x).
> > 
> > I rather like the new output. Pseudo-terminals are by far the most
> > common kind of terminal and there may be many of them, so it makes sense
> > not to have a prefix. The t option in ps also accepts these short names,
> > like 'ps lt0'. All other terminal names start with a letter.
> > 
> > In FreeBSD 7, the first 256 pseudo-terminals are named
> > /dev/tty[pqrsPQRS][0-9a-v]. A few more letters can be used to provide a
> > few more pseudo-terminals but even then two characters suffice.
> > 
> > The TTY keyword shows the full pathname relative to /dev.
> 
> i think we should adjust the following paragraph
> 
> " tt   An abbreviation for the pathname of the controlling terminal,
>if any.  The abbreviation consists of the three letters follow-
>ing /dev/tty, or, for the console, ``con''.  This is followed
>by a `-' if the process can no longer reach that controlling
>terminal (i.e., it has been revoked).
> "
> 
> to something like this then
> 
> " tt   An abbreviation for the pathname of the controlling terminal,
>if any.  The abbreviation consists of the three letters follow-
>ing /dev/tty, or, for pseudo-terminals, the entry in /dev/pts.
>This is followed by a `-' if the process can no longer reach
>that controlling terminal (i.e., it has been revoked).
>The full pathname of the controlling terminal is available via
>   

Re: svn commit: r225868 - head/bin/ps

2011-10-01 Thread Alexander Best
On Sat Oct  1 11, Jilles Tjoelker wrote:
> On Sat, Oct 01, 2011 at 05:14:01PM +0000, Alexander Best wrote:
> > On Sat Oct  1 11, Ed Schouten wrote:
> > > Also, it would be better if we replaced the "??" string with "-". When
> > > we print "??", it actually means: this process has no controlling
> > > terminal, not that we don't know which TTY it is.
> 
> > good point. also i was thinking: if a process had a controlling
> > terminal, but that terminal has been revoked, are users really
> > interested to know what the name of that revoked terminal was? can't
> > we just use "-"? is it important to know whether a process never had a
> > controlling terminal, or had one at some point, but not anymore?
> 
> I think this is potentially useful, because it shows that the process
> did not explicitly detach from the terminal (such as via setsid(2)).
> 
> Particularly if the terminal is real (not a pseudo-terminal), its name
> may be useful in recognition.
> 
> When asking for processes attached to a specific terminal with ps's t
> option, ps will also show processes that used to be attached ("-"),
> possibly allowing users to keep track of processes better.
> 
> It appears that even if a terminal is "revoked" in this way, it still
> prevents reuse of the pts number.

that's a very good explanation. :) so yeah...let's keep it the way it is.

> 
> > also the ps(1) man page claims that a process running on console has a "TT"
> > entry of "con". i've never seen such an entry. is this still correct?
> 
> This may indeed be no longer the case, although it was never common to
> see "con". With syscons in multi-user mode, you cannot log in on
> /dev/console, only on /dev/ttyv*. With syscons in single-user mode,
> ps(1) says "v0" or "ttyv0" but tty(1) says /dev/console.
> 
> > and the last point i'd like to make: looking at 'ps alx' on freebsd
> > 7.x makes it easy to distinguish between ttys and pts'es, because they
> > are names ttyvX and ttypX. looking at the same output under HEAD, all
> > pts terminal descriptors have moved to /dev/pts/X. so they will not
> > show up as pX, but merely as X.
> 
> > can't we tell ps to prefix anything coming from /dev/pts with a "p"?
> 
> > in this output:
> 
> >  1001 1780 1778   1  16  0   15956   3136 pauseIs00:00,02 
> > /usr/local/bin/zsh
> 
> > users are supposed to know that the "0" stands for /dev/pts/0. imho
> 
> >  1001 1780 1778   1  16  0   15956   3136 pauseIs   p00:00,02 
> > /usr/local/bin/zsh
> 
> > would be much better here (like under freebsd 7.x).
> 
> I rather like the new output. Pseudo-terminals are by far the most
> common kind of terminal and there may be many of them, so it makes sense
> not to have a prefix. The t option in ps also accepts these short names,
> like 'ps lt0'. All other terminal names start with a letter.
> 
> In FreeBSD 7, the first 256 pseudo-terminals are named
> /dev/tty[pqrsPQRS][0-9a-v]. A few more letters can be used to provide a
> few more pseudo-terminals but even then two characters suffice.
> 
> The TTY keyword shows the full pathname relative to /dev.

i think we should adjust the following paragraph

" tt   An abbreviation for the pathname of the controlling terminal,
   if any.  The abbreviation consists of the three letters follow-
   ing /dev/tty, or, for the console, ``con''.  This is followed
   by a `-' if the process can no longer reach that controlling
   terminal (i.e., it has been revoked).
"

to something like this then

" tt   An abbreviation for the pathname of the controlling terminal,
   if any.  The abbreviation consists of the three letters follow-
   ing /dev/tty, or, for pseudo-terminals, the entry in /dev/pts.
   This is followed by a `-' if the process can no longer reach
   that controlling terminal (i.e., it has been revoked).
   The full pathname of the controlling terminal is available via
   the tty keyword.
"

cheers.
alex

ps: i am also wondering, why -o and -O aren't mutually exclusive. this would
make more sense to me.

> 
> -- 
> Jilles Tjoelker
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-01 Thread Alexander Best
On Sat Oct  1 11, Ed Schouten wrote:
> * Alexander Best , 20110929 14:14:
> > i think i wrote you about the two spaces between the "TT" and "TIME" field
> > some time ago. you said that the "TT" entry can contain a postfix "-". can
> > you describe a situation, where this can occur? i've never seen the "TT" 
> > field
> > contain an entry larger than 2 chars.
> 
> Also, it would be better if we replaced the "??" string with "-". When
> we print "??", it actually means: this process has no controlling
> terminal, not that we don't know which TTY it is.

good point. also i was thinking: if a process had a controlling terminal, but
that terminal has been revoked, are users really interested to know what the
name of that revoked terminal was? can't we just use "-"? is it important to
know whether a process never had a controlling terminal, or had one at some
point, but not anymore?

also the ps(1) man page claims that a process running on console has a "TT"
entry of "con". i've never seen such an entry. is this still correct?

and the last point i'd like to make: looking at 'ps alx' on freebsd 7.x makes
it easy to distinguish between ttys and pts'es, because they are names ttyvX
and ttypX. looking at the same output under HEAD, all pts terminal descriptors
have moved to /dev/pts/X. so they will not show up as pX, but merely as X.

can't we tell ps to prefix anything coming from /dev/pts with a "p"?

in this output:

 1001 1780 1778   1  16  0   15956   3136 pauseIs00:00,02 
/usr/local/bin/zsh

users are supposed to know that the "0" stands for /dev/pts/0. imho

 1001 1780 1778   1  16  0   15956   3136 pauseIs   p00:00,02 
/usr/local/bin/zsh

would be much better here (like under freebsd 7.x).

cheers.
alex

> 
> -- 
>  Ed Schouten 
>  WWW: http://80386.nl/


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-10-01 Thread Alexander Best
On Fri Sep 30 11, Edward Tomasz Napiera?a wrote:
> Wiadomo?? napisana przez Alexander Best w dniu 29 wrz 2011, o godz. 20:57:
> > On Thu Sep 29 11, Edward Tomasz Napiera?a wrote:
> >> Wiadomo?? napisana przez Alexander Best w dniu 29 wrz 2011, o godz. 14:14:
> >>> On Thu Sep 29 11, Edward Tomasz Napierala wrote:
> >>>> Author: trasz
> >>>> Date: Thu Sep 29 06:31:42 2011
> >>>> New Revision: 225868
> >>>> URL: http://svn.freebsd.org/changeset/base/225868
> >>>> 
> >>>> Log:
> >>>> Make ps(1) automatically size its column widths.
> >>> 
> >>> cool to see this committed. :)
> >>> 
> >>> i think i wrote you about the two spaces between the "TT" and "TIME" field
> >>> some time ago. you said that the "TT" entry can contain a postfix "-". can
> >>> you describe a situation, where this can occur? i've never seen the "TT" 
> >>> field
> >>> contain an entry larger than 2 chars.
> >> 
> >> Login via ssh, run "nohup sleep 1000 &", then logout.
> > 
> > maybe it would also be possible to introduce unit symbols for the "vsz" and
> > "rss" fields. they are getting really huge on systems with a long uptime
> > (*cough* mem leaks) and kilobyte granularity isn't really that great when
> > those fields are nearing 1GB.
> 
> I thought about it, but the "-h" option is already taken.

maybe making unit symbols the default behavior and introducing a -k flag, which
toggles between the unit symbol mode and the traditional kilobyte mode?

we could then add an envar $PS, so users can set PS=-k to restore the historic
ps(1) behavior. a note to the BUGS section could then be added, similar to the
note in top(1)'s BUGS section regarding the -I flag, which explains that
ps(1)es semantics were changed, but can be restored via PS=-k.

cheers.
alex

> 
> --
> If you cut off my head, what would I say?  Me and my head, or me and my body?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225827 - head/sys/kern head/usr.bin/compress head/usr.bin/gzip releng/7.3 releng/7.3/sys/conf releng/7.3/sys/kern releng/7.3/usr.bin/compress releng/7.3/usr.bin/gzip releng/7.4 releng

2011-09-30 Thread Alexander Best
On Fri Sep 30 11, Bjoern A. Zeeb wrote:
> 
> On Sep 30, 2011, at 8:16 AM, Alexander Best wrote:
> 
> > On Wed Sep 28 11, Bjoern A. Zeeb wrote:
> >> Author: bz
> >> Date: Wed Sep 28 08:47:17 2011
> >> New Revision: 225827
> >> URL: http://svn.freebsd.org/changeset/base/225827
> >> 
> >> Log:
> >>  Fix handling of corrupt compress(1)ed data. [11:04]
> > 
> 
> That's the wrong line to cite;-)   You mean 11:05.

oops. sorry.

> 
> > a thread on freebsd-questions@ indicates that the changes to uipc_usrreq.c
> > broke support for flash.
> > 
> > the thread's subject line is "FreeBSD 9-Beta3 and FlashPlayer".
> 
> And so does an email to security@, etc. already.  Colin is aware of the fact
> and looking into the changes needed.  We obviously all missed that part.
> As far as I understood him there's a mix of "linux is different" and
> "the linuxolator was always buggy there and we luckily caught that now" 
> involved.
> 
> Assume it will be handled some way properly.

thanks for the info. good to know people are working on it. :)

cheers.
alex

> 
> /bz
> 
> -- 
> Bjoern A. Zeeb You have to have visions!
>  Stop bit received. Insert coin for new address family.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225827 - head/sys/kern head/usr.bin/compress head/usr.bin/gzip releng/7.3 releng/7.3/sys/conf releng/7.3/sys/kern releng/7.3/usr.bin/compress releng/7.3/usr.bin/gzip releng/7.4 releng

2011-09-30 Thread Alexander Best
On Wed Sep 28 11, Bjoern A. Zeeb wrote:
> Author: bz
> Date: Wed Sep 28 08:47:17 2011
> New Revision: 225827
> URL: http://svn.freebsd.org/changeset/base/225827
> 
> Log:
>   Fix handling of corrupt compress(1)ed data. [11:04]

a thread on freebsd-questions@ indicates that the changes to uipc_usrreq.c
broke support for flash.

the thread's subject line is "FreeBSD 9-Beta3 and FlashPlayer".

cheers.
alex

>   
>   Add missing length checks on unix socket addresses. [11:05]
>   
>   Approved by:so (cperciva)
>   Approved by:re (kensmith)
>   Security:   FreeBSD-SA-11:04.compress
>   Security:   CVE-2011-2895 [11:04]
>   Security:   FreeBSD-SA-11:05.unix
> 
> Modified:
>   head/sys/kern/uipc_usrreq.c
>   head/usr.bin/compress/zopen.c
>   head/usr.bin/gzip/zuncompress.c
> 
> Changes in other areas also in this revision:
> Modified:
>   releng/7.3/UPDATING
>   releng/7.3/sys/conf/newvers.sh
>   releng/7.3/sys/kern/uipc_usrreq.c
>   releng/7.3/usr.bin/compress/zopen.c
>   releng/7.3/usr.bin/gzip/zuncompress.c
>   releng/7.4/UPDATING
>   releng/7.4/sys/conf/newvers.sh
>   releng/7.4/sys/kern/uipc_usrreq.c
>   releng/7.4/usr.bin/compress/zopen.c
>   releng/7.4/usr.bin/gzip/zuncompress.c
>   releng/8.1/UPDATING
>   releng/8.1/sys/conf/newvers.sh
>   releng/8.1/sys/kern/uipc_usrreq.c
>   releng/8.1/usr.bin/compress/zopen.c
>   releng/8.1/usr.bin/gzip/zuncompress.c
>   releng/8.2/UPDATING
>   releng/8.2/sys/conf/newvers.sh
>   releng/8.2/sys/kern/uipc_usrreq.c
>   releng/8.2/usr.bin/compress/zopen.c
>   releng/8.2/usr.bin/gzip/zuncompress.c
>   stable/7/sys/kern/uipc_usrreq.c
>   stable/7/usr.bin/compress/zopen.c
>   stable/7/usr.bin/gzip/zuncompress.c
>   stable/8/sys/kern/uipc_usrreq.c
>   stable/8/usr.bin/compress/zopen.c
>   stable/8/usr.bin/gzip/zuncompress.c
>   stable/9/sys/kern/uipc_usrreq.c
>   stable/9/usr.bin/compress/zopen.c
>   stable/9/usr.bin/gzip/zuncompress.c
> 
> Modified: head/sys/kern/uipc_usrreq.c
> ==
> --- head/sys/kern/uipc_usrreq.c   Wed Sep 28 08:19:45 2011
> (r225826)
> +++ head/sys/kern/uipc_usrreq.c   Wed Sep 28 08:47:17 2011
> (r225827)
> @@ -462,6 +462,8 @@ uipc_bind(struct socket *so, struct sock
>   unp = sotounpcb(so);
>   KASSERT(unp != NULL, ("uipc_bind: unp == NULL"));
>  
> + if (soun->sun_len > sizeof(struct sockaddr_un))
> + return (EINVAL);
>   namelen = soun->sun_len - offsetof(struct sockaddr_un, sun_path);
>   if (namelen <= 0)
>   return (EINVAL);
> @@ -1252,6 +1254,8 @@ unp_connect(struct socket *so, struct so
>   unp = sotounpcb(so);
>   KASSERT(unp != NULL, ("unp_connect: unp == NULL"));
>  
> + if (nam->sa_len > sizeof(struct sockaddr_un))
> + return (EINVAL);
>   len = nam->sa_len - offsetof(struct sockaddr_un, sun_path);
>   if (len <= 0)
>   return (EINVAL);
> 
> Modified: head/usr.bin/compress/zopen.c
> ==
> --- head/usr.bin/compress/zopen.c Wed Sep 28 08:19:45 2011
> (r225826)
> +++ head/usr.bin/compress/zopen.c Wed Sep 28 08:47:17 2011
> (r225827)
> @@ -486,7 +486,7 @@ zread(void *cookie, char *rbp, int num)
>   block_compress = maxbits & BLOCK_MASK;
>   maxbits &= BIT_MASK;
>   maxmaxcode = 1L << maxbits;
> - if (maxbits > BITS) {
> + if (maxbits > BITS || maxbits < 12) {
>   errno = EFTYPE;
>   return (-1);
>   }
> @@ -513,17 +513,28 @@ zread(void *cookie, char *rbp, int num)
>   for (code = 255; code >= 0; code--)
>   tab_prefixof(code) = 0;
>   clear_flg = 1;
> - free_ent = FIRST - 1;
> - if ((code = getcode(zs)) == -1) /* O, untimely death! */
> - break;
> + free_ent = FIRST;
> + oldcode = -1;
> + continue;
>   }
>   incode = code;
>  
> - /* Special case for KwKwK string. */
> + /* Special case for kWkWk string. */
>   if (code >= free_ent) {
> + if (code > free_ent || oldcode == -1) {
> + /* Bad stream. */
> + errno = EINVAL;
> + return (-1);
> + }
>   *stackp++ = finchar;
>   code = oldcode;
>   }
> + /*
> +  * The above condition ensures that code < free_ent.
> +  * The construction of tab_prefixof in turn guarantees that
> +  * each iteration decreases code and therefore stack usage is
> +  * bound by 1 << BITS - 256.
> +  */
>  
>   /* Generate output characters in reverse order. */
>   wh

Re: svn commit: r225868 - head/bin/ps

2011-09-29 Thread Alexander Best
On Thu Sep 29 11, Edward Tomasz Napiera?a wrote:
> Wiadomo?? napisana przez Alexander Best w dniu 29 wrz 2011, o godz. 14:14:
> > On Thu Sep 29 11, Edward Tomasz Napierala wrote:
> >> Author: trasz
> >> Date: Thu Sep 29 06:31:42 2011
> >> New Revision: 225868
> >> URL: http://svn.freebsd.org/changeset/base/225868
> >> 
> >> Log:
> >>  Make ps(1) automatically size its column widths.
> > 
> > cool to see this committed. :)
> > 
> > i think i wrote you about the two spaces between the "TT" and "TIME" field
> > some time ago. you said that the "TT" entry can contain a postfix "-". can
> > you describe a situation, where this can occur? i've never seen the "TT" 
> > field
> > contain an entry larger than 2 chars.
> 
> Login via ssh, run "nohup sleep 1000 &", then logout.

maybe it would also be possible to introduce unit symbols for the "vsz" and
"rss" fields. they are getting really huge on systems with a long uptime
(*cough* mem leaks) and kilobyte granularity isn't really that great when
those fields are nearing 1GB.

cheers.
alex

> 
> --
> If you cut off my head, what would I say?  Me and my head, or me and my body?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-09-29 Thread Alexander Best
On Thu Sep 29 11, Edward Tomasz Napiera?a wrote:
> Wiadomo?? napisana przez Alexander Best w dniu 29 wrz 2011, o godz. 14:14:
> > On Thu Sep 29 11, Edward Tomasz Napierala wrote:
> >> Author: trasz
> >> Date: Thu Sep 29 06:31:42 2011
> >> New Revision: 225868
> >> URL: http://svn.freebsd.org/changeset/base/225868
> >> 
> >> Log:
> >>  Make ps(1) automatically size its column widths.
> > 
> > cool to see this committed. :)
> > 
> > i think i wrote you about the two spaces between the "TT" and "TIME" field
> > some time ago. you said that the "TT" entry can contain a postfix "-". can
> > you describe a situation, where this can occur? i've never seen the "TT" 
> > field
> > contain an entry larger than 2 chars.
> 
> Login via ssh, run "nohup sleep 1000 &", then logout.

ahh thanks. maybe, since ps needs to iterate through the whole output at first
anyway, it can check if a "TT" entry is postfixed with "-", and if it isn't get
rid of the trailing space.

cheers.
alex

> 
> --
> If you cut off my head, what would I say?  Me and my head, or me and my body?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225868 - head/bin/ps

2011-09-29 Thread Alexander Best
On Thu Sep 29 11, Edward Tomasz Napierala wrote:
> Author: trasz
> Date: Thu Sep 29 06:31:42 2011
> New Revision: 225868
> URL: http://svn.freebsd.org/changeset/base/225868
> 
> Log:
>   Make ps(1) automatically size its column widths.

cool to see this committed. :)

i think i wrote you about the two spaces between the "TT" and "TIME" field
some time ago. you said that the "TT" entry can contain a postfix "-". can
you describe a situation, where this can occur? i've never seen the "TT" field
contain an entry larger than 2 chars.

cheers.
alex

> 
> Modified:
>   head/bin/ps/extern.h
>   head/bin/ps/keyword.c
>   head/bin/ps/print.c
>   head/bin/ps/ps.c
>   head/bin/ps/ps.h
> 
> Modified: head/bin/ps/extern.h
> ==
> --- head/bin/ps/extern.h  Thu Sep 29 06:00:26 2011(r225867)
> +++ head/bin/ps/extern.h  Thu Sep 29 06:31:42 2011(r225868)
> @@ -39,63 +39,52 @@ extern fixpt_t ccpu;
>  extern int cflag, eval, fscale, nlistread, rawcpu;
>  extern unsigned long mempages;
>  extern time_t now;
> -extern int showthreads, sumrusage, termwidth, totwidth;
> +extern int showthreads, sumrusage, termwidth;
>  extern STAILQ_HEAD(velisthead, varent) varlist;
>  
>  __BEGIN_DECLS
> -void  arguments(KINFO *, VARENT *);
> -void  command(KINFO *, VARENT *);
> -void  cputime(KINFO *, VARENT *);
> +char  *arguments(KINFO *, VARENT *);
> +char  *command(KINFO *, VARENT *);
> +char  *cputime(KINFO *, VARENT *);
>  int   donlist(void);
> -void  elapsed(KINFO *, VARENT *);
> -void  elapseds(KINFO *, VARENT *);
> -void  emulname(KINFO *, VARENT *);
> +char  *elapsed(KINFO *, VARENT *);
> +char  *elapseds(KINFO *, VARENT *);
> +char  *emulname(KINFO *, VARENT *);
>  VARENT   *find_varentry(VAR *);
>  const char *fmt_argv(char **, char *, size_t);
>  doublegetpcpu(const KINFO *);
> -void  kvar(KINFO *, VARENT *);
> -void  label(KINFO *, VARENT *);
> -void  loginclass(KINFO *, VARENT *);
> -void  logname(KINFO *, VARENT *);
> -void  longtname(KINFO *, VARENT *);
> -void  lstarted(KINFO *, VARENT *);
> -void  maxrss(KINFO *, VARENT *);
> -void  lockname(KINFO *, VARENT *);
> -void  mwchan(KINFO *, VARENT *);
> -void  nwchan(KINFO *, VARENT *);
> -void  pagein(KINFO *, VARENT *);
> +char  *kvar(KINFO *, VARENT *);
> +char  *label(KINFO *, VARENT *);
> +char  *loginclass(KINFO *, VARENT *);
> +char  *logname(KINFO *, VARENT *);
> +char  *longtname(KINFO *, VARENT *);
> +char  *lstarted(KINFO *, VARENT *);
> +char  *maxrss(KINFO *, VARENT *);
> +char  *lockname(KINFO *, VARENT *);
> +char  *mwchan(KINFO *, VARENT *);
> +char  *nwchan(KINFO *, VARENT *);
> +char  *pagein(KINFO *, VARENT *);
>  void  parsefmt(const char *, int);
> -void  pcpu(KINFO *, VARENT *);
> -void  pmem(KINFO *, VARENT *);
> -void  pri(KINFO *, VARENT *);
> +char  *pcpu(KINFO *, VARENT *);
> +char  *pmem(KINFO *, VARENT *);
> +char  *pri(KINFO *, VARENT *);
>  void  printheader(void);
> -void  priorityr(KINFO *, VARENT *);
> -void  egroupname(KINFO *, VARENT *);
> -void  rgroupname(KINFO *, VARENT *);
> -void  runame(KINFO *, VARENT *);
> -void  rvar(KINFO *, VARENT *);
> -int   s_comm(KINFO *);
> -int   s_cputime(KINFO *);
> -int   s_label(KINFO *);
> -int   s_loginclass(KINFO *);
> -int   s_logname(KINFO *);
> -int   s_egroupname(KINFO *);
> -int   s_rgroupname(KINFO *);
> -int   s_runame(KINFO *);
> -int   s_systime(KINFO *);
> -int   s_uname(KINFO *);
> -int   s_usertime(KINFO *);
> +char  *priorityr(KINFO *, VARENT *);
> +char  *egroupname(KINFO *, VARENT *);
> +char  *rgroupname(KINFO *, VARENT *);
> +char  *runame(KINFO *, VARENT *);
> +char  *rvar(KINFO *, VARENT *);
>  void  showkey(void);
> -void  started(KINFO *, VARENT *);
> -void  state(KINFO *, VARENT *);
> -void  systime(KINFO *, VARENT *);
> -void  tdev(KINFO *, VARENT *);
> -void  tdnam(KINFO *, VARENT *);
> -void  tname(KINFO *, VARENT *);
> -void  ucomm(KINFO *, VARENT *);
> -void  uname(KINFO *, VARENT *);
> -void  upr(KINFO *, VARENT *);
> -void  usertime(KINFO *, VARENT *);
> -void  vsize(KINFO *, VARENT *);
> -void  wchan(KINFO *, VARENT *);
> +char  *started(KINFO *, VARENT *);
> +char  *state(KINFO *, VARENT *);
> +char  *systime(KINFO *, VARENT *);
> +char  *tdev(KINFO *, VARENT *);
> +char  *tdnam(KINFO *, VARENT *);
> +char  *tname(KINFO *, VARENT *);
> +char  *ucomm(KINFO *, VARENT *);
> +char  *uname(KINFO *, VARENT *);
> +char  *upr(KINFO *, VARENT *);
> +char  *usertime(KINFO *, VARENT *);
> +char  *vsize(KINFO *, VARENT *);
> +char  *wchan(KINFO *, VARENT *);
>  __END_DECLS
> 
> Modified: head/bin/ps/keyword.c
> ==
> --- head/bin/ps/keyword.c Thu Sep 29 06:00:26 2011(r225867)
> +++ head/bin/ps/keyword.c Thu Sep 29 06:31:42 2011(r225868)
> @@ -57,178 +57,116 @@ static int  vcmp(const void *, const voi
>  #define  KOFF(x) offsetof(struct kinfo_proc, x)
>  #define  R

Re: svn commit: r225847 - in head: bin/ls bin/ps lib/libc/gen sbin/fsdb usr.bin/find usr.bin/fstat usr.sbin/pstat

2011-09-28 Thread Alexander Best
On Wed Sep 28 11, Ed Schouten wrote:
> Author: ed
> Date: Wed Sep 28 18:53:36 2011
> New Revision: 225847
> URL: http://svn.freebsd.org/changeset/base/225847
> 
> Log:
>   Get rid of major/minor number distinction.
>   
>   As of FreeBSD 6, devices can only be opened through devfs. These device
>   nodes don't have major and minor numbers anymore. The st_rdev field in
>   struct stat is simply based a copy of st_ino.
>   
>   Simply display device numbers as hexadecimal, using "%#jx". This is
>   allowed by POSIX, since it explicitly states things like the following
>   (example taken from ls(1)):
>   
>   "If the file is a character special or block special file, the
>   size of the file may be replaced with implementation-defined
>   information associated with the device in question."
>   
>   This makes the output of these commands more compact. For example, ls(1)
>   now uses approximately four columns less. While there, simplify the
>   column length calculation from ls(1) by calling snprintf() with a NULL
>   buffer.

very cool. maybe before the release of freebsd 10.0 we could get edward's
ps(1) auto-size-column-width patch committed. this shrinks the ps(1) output
some more:

http://people.freebsd.org/~trasz/ps-9.diff

:)

cheers.
alex

>   
>   Don't be afraid; if needed one can still obtain individual major/minor
>   numbers using stat(1).
> 
> Modified:
>   head/bin/ls/ls.1
>   head/bin/ls/ls.c
>   head/bin/ls/ls.h
>   head/bin/ls/print.c
>   head/bin/ps/print.c
>   head/lib/libc/gen/devname.c
>   head/sbin/fsdb/fsdbutil.c
>   head/usr.bin/find/find.1
>   head/usr.bin/find/ls.c
>   head/usr.bin/fstat/fstat.1
>   head/usr.bin/fstat/fstat.c
>   head/usr.sbin/pstat/pstat.c
> 
> Modified: head/bin/ls/ls.1
> ==
> --- head/bin/ls/ls.1  Wed Sep 28 18:49:37 2011(r225846)
> +++ head/bin/ls/ls.1  Wed Sep 28 18:53:36 2011(r225847)
> @@ -32,7 +32,7 @@
>  .\" @(#)ls.1 8.7 (Berkeley) 7/29/94
>  .\" $FreeBSD$
>  .\"
> -.Dd April 4, 2008
> +.Dd September 28, 2011
>  .Dt LS 1
>  .Os
>  .Sh NAME
> @@ -357,8 +357,7 @@ option is given,
>  the numeric ID's are displayed.
>  .Pp
>  If the file is a character special or block special file,
> -the major and minor device numbers for the file are displayed
> -in the size field.
> +the device number for the file is displayed in the size field.
>  If the file is a symbolic link the pathname of the
>  linked-to file is preceded by
>  .Dq Li -> .
> 
> Modified: head/bin/ls/ls.c
> ==
> --- head/bin/ls/ls.c  Wed Sep 28 18:49:37 2011(r225846)
> +++ head/bin/ls/ls.c  Wed Sep 28 18:53:36 2011(r225847)
> @@ -563,7 +563,7 @@ display(const FTSENT *p, FTSENT *list, i
>   long maxblock;
>   u_long btotal, labelstrlen, maxinode, maxlen, maxnlink;
>   u_long maxlabelstr;
> - u_int devstrlen;
> + u_int sizelen;
>   int maxflags;
>   gid_t maxgroup;
>   uid_t maxuser;
> @@ -572,7 +572,6 @@ display(const FTSENT *p, FTSENT *list, i
>   int entries, needstats;
>   const char *user, *group;
>   char *flags, *labelstr = NULL;
> - char buf[STRBUF_SIZEOF(u_quad_t) + 1];
>   char ngroup[STRBUF_SIZEOF(uid_t) + 1];
>   char nuser[STRBUF_SIZEOF(gid_t) + 1];
>  
> @@ -656,7 +655,8 @@ display(const FTSENT *p, FTSENT *list, i
>   MAKENINES(maxsize);
>   free(jinitmax);
>   }
> - devstrlen = 0;
> + d.s_size = 0;
> + sizelen = 0;
>   flags = NULL;
>   for (cur = list, entries = 0; cur; cur = cur->fts_link) {
>   if (cur->fts_info == FTS_ERR || cur->fts_info == FTS_NS) {
> @@ -796,14 +796,12 @@ label_out:
>   np->group = &np->data[ulen + 1];
>   (void)strcpy(np->group, group);
>  
> - if ((S_ISCHR(sp->st_mode) ||
> - S_ISBLK(sp->st_mode)) &&
> - devstrlen < DEVSTR_HEX_LEN) {
> - if (minor(sp->st_rdev) > 255 ||
> - minor(sp->st_rdev) < 0)
> - devstrlen = DEVSTR_HEX_LEN;
> - else
> - devstrlen = DEVSTR_LEN;
> + if (S_ISCHR(sp->st_mode) ||
> + S_ISBLK(sp->st_mode)) {
> + sizelen = snprintf(NULL, 0,
> + "%#jx", (uintmax_t)sp->st_rdev);
> + if (d.s_size < sizelen)
> + d.s_size = sizelen;
>   }
>  
>   if (f_flags) {
> @@ -837,23 +835,16 @@ label_out:
>   d.maxlen = maxlen;
>   if 

Re: svn commit: r225815 - head/usr.bin/fetch

2011-09-27 Thread Alexander Best
On Tue Sep 27 11, Dag-Erling Smorgrav wrote:
> Author: des
> Date: Tue Sep 27 19:02:44 2011
> New Revision: 225815
> URL: http://svn.freebsd.org/changeset/base/225815
> 
> Log:
>   Document the fact that passive mode is now the default.
>   Update copyright dates and strip my middle name.
> 
> Modified:
>   head/usr.bin/fetch/fetch.1
>   head/usr.bin/fetch/fetch.c
> 
> Modified: head/usr.bin/fetch/fetch.1
> ==
> --- head/usr.bin/fetch/fetch.1Tue Sep 27 18:57:26 2011
> (r225814)
> +++ head/usr.bin/fetch/fetch.1Tue Sep 27 19:02:44 2011
> (r225815)
> @@ -1,5 +1,5 @@
>  .\"-
> -.\" Copyright (c) 2000-2004 Dag-Erling Co?dan Sm?rgrav
> +.\" Copyright (c) 2000-2011 Dag-Erling Sm?rgrav

your name isn't being displayed correctly here.

>  .\" All rights reserved.
>  .\" Portions Copyright (c) 1999 Massachusetts Institute of Technology; used
>  .\" by permission.
> @@ -29,7 +29,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd December 14, 2008
> +.Dd September 27, 2011
>  .Dt FETCH 1
>  .Os
>  .Sh NAME
> @@ -165,11 +165,13 @@ directory, with name(s) selected as in t
>  .It Fl P
>  .It Fl p
>  Use passive FTP.
> -This is useful if you are behind a firewall which blocks incoming
> -connections.
> -Try this flag if
> -.Nm
> -seems to hang when retrieving FTP URLs.
> +These flags have no effect, since passive FTP is the default, but are
> +provided for compatibility with earlier versions where active FTP was
> +the default.
> +To force active mode, set the
> +.Ev FTP_PASSIVE_MODE
> +environment variable to
> +.Ql NO .
>  .It Fl q
>  Quiet mode.
>  .It Fl R
> 
> Modified: head/usr.bin/fetch/fetch.c
> ==
> --- head/usr.bin/fetch/fetch.cTue Sep 27 18:57:26 2011
> (r225814)
> +++ head/usr.bin/fetch/fetch.cTue Sep 27 19:02:44 2011
> (r225815)
> @@ -1,5 +1,5 @@
>  /*-
> - * Copyright (c) 2000-2004 Dag-Erling Coïdan Smørgrav
> + * Copyright (c) 2000-2011 Dag-Erling Smørgrav

here your name gets displayed correctly.

>   * All rights reserved.
>   *
>   * Redistribution and use in source and binary forms, with or without

the output of `locale` on my local machine is:

LANG=en_GB.ISO8859-15
LC_CTYPE=de_DE.ISO8859-15
LC_COLLATE="en_GB.ISO8859-15"
LC_TIME=de_DE.ISO8859-15
LC_NUMERIC=de_DE.ISO8859-15
LC_MONETARY=de_DE.ISO8859-15
LC_MESSAGES="en_GB.ISO8859-15"
LC_ALL=

cheers.
alex
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r225530 - in head/sys/boot/i386: gptboot gptzfsboot zfsboot

2011-09-14 Thread Alexander Best
On Tue Sep 13 11, Andriy Gapon wrote:
> Author: avg
> Date: Tue Sep 13 14:03:55 2011
> New Revision: 225530
> URL: http://svn.freebsd.org/changeset/base/225530
> 
> Log:
>   gpt/zfs boot blocks: reduce optimizing CFLAGS to -O1
>   
>   gpt and zfs boot blocks are not nearly as size-constrained as boot2
>   from which they inherited their current optimization and anti-optimization
>   options.  As such the current options do not provide any benefit, but
>   make debugging of the code much harder.
>   Also, it has been demonstrated that combination of -mrtd and
>   -fno-unit-at-a-time may result in mis-compilation of the boot code
>   with the current base gcc.
>   
>   Additionally, intermediate assembly file filtering is removed for
>   zfsboot.
>   
>   The new boot blocks are all compile- and boot- tested using qemu.
>   gptzfsboot is tested with real hardware.
>   
>   Reported by:Peter Jeremy  [miscompilation]
>   Discussed with: bde, jhb
>   Tested by:  Sebastian Chmielewski  [gptzfsboot]
>   Approved by:re (kib)
>   MFC after:  3 weeks

i also found the following patches sitting in my /usr/src dir. they should get
rid of some -mno-* flags, which are already implied by other flags.

please see r221879 for a more detailed explanation.

cheers.
alex

> 
> Modified:
>   head/sys/boot/i386/gptboot/Makefile
>   head/sys/boot/i386/gptzfsboot/Makefile
>   head/sys/boot/i386/zfsboot/Makefile
> 
> Modified: head/sys/boot/i386/gptboot/Makefile
> ==
> --- head/sys/boot/i386/gptboot/Makefile   Tue Sep 13 14:01:35 2011
> (r225529)
> +++ head/sys/boot/i386/gptboot/Makefile   Tue Sep 13 14:03:55 2011
> (r225530)
> @@ -20,12 +20,7 @@ GPTBOOT_UFS?=  UFS1_AND_UFS2
>  #GPTBOOT_UFS?=   UFS1_ONLY
>  
>  CFLAGS=  -DBOOTPROG=\"gptboot\" \
> - -Os \
> - -fno-guess-branch-probability \
> - -fomit-frame-pointer \
> - -fno-unit-at-a-time \
> - -mno-align-long-strings \
> - -mrtd \
> + -O1 \
>   -DGPT \
>   -D${GPTBOOT_UFS} \
>   -DSIOPRT=${BOOT_COMCONSOLE_PORT} \
> 
> Modified: head/sys/boot/i386/gptzfsboot/Makefile
> ==
> --- head/sys/boot/i386/gptzfsboot/MakefileTue Sep 13 14:01:35 2011
> (r225529)
> +++ head/sys/boot/i386/gptzfsboot/MakefileTue Sep 13 14:03:55 2011
> (r225530)
> @@ -17,12 +17,7 @@ ORG1=  0x7c00
>  ORG2=0x0
>  
>  CFLAGS=  -DBOOTPROG=\"gptzfsboot\" \
> - -Os \
> - -fno-guess-branch-probability \
> - -fomit-frame-pointer \
> - -fno-unit-at-a-time \
> - -mno-align-long-strings \
> - -mrtd \
> + -O1 \
>   -DGPT -DBOOT2 \
>   -DSIOPRT=${BOOT_COMCONSOLE_PORT} \
>   -DSIOFMT=${B2SIOFMT} \
> 
> Modified: head/sys/boot/i386/zfsboot/Makefile
> ==
> --- head/sys/boot/i386/zfsboot/Makefile   Tue Sep 13 14:01:35 2011
> (r225529)
> +++ head/sys/boot/i386/zfsboot/Makefile   Tue Sep 13 14:03:55 2011
> (r225530)
> @@ -15,12 +15,7 @@ ORG1=  0x7c00
>  ORG2=0x2000
>  
>  CFLAGS=  -DBOOTPROG=\"zfsboot\" \
> - -Os \
> - -fno-guess-branch-probability \
> - -fomit-frame-pointer \
> - -fno-unit-at-a-time \
> - -mno-align-long-strings \
> - -mrtd \
> + -O1 \
>   -DBOOT2 \
>   -DSIOPRT=${BOOT_COMCONSOLE_PORT} \
>   -DSIOFMT=${B2SIOFMT} \
> @@ -85,20 +80,10 @@ zfsboot.bin: zfsboot.out
>  zfsboot.out: ${BTXCRT} zfsboot.o sio.o drv.o cons.o util.o
>   ${LD} ${LDFLAGS} -Ttext ${ORG2} -o ${.TARGET} ${.ALLSRC} ${LIBSTAND}
>  
> -zfsboot.o: zfsboot.s
> -.if ${CC:T:Mclang} == "clang"
> - ${CC} ${ACFLAGS} -c zfsboot.s
> -.endif
> -
>  SRCS=zfsboot.c
>  
> -zfsboot.s: zfsboot.c ${.CURDIR}/../../zfs/zfsimpl.c
> - ${CC} ${CFLAGS} -S -o zfsboot.s.tmp ${.CURDIR}/zfsboot.c
> - sed -e '/align/d' -e '/nop/d' < zfsboot.s.tmp > zfsboot.s
> - rm -f zfsboot.s.tmp
> -
>  .if ${MACHINE_CPUARCH} == "amd64"
> -beforedepend zfsboot.s: machine
> +beforedepend zfsboot.o: machine
>  CLEANFILES+= machine
>  machine:
>   ln -sf ${.CURDIR}/../../../i386/include machine
diff --git a/sys/boot/ficl/Makefile b/sys/boot/ficl/Makefile
index e441573..7769bd2 100644
--- a/sys/boot/ficl/Makefile
+++ b/sys/boot/ficl/Makefile
@@ -8,8 +8,13 @@ SRCS=  ${BASE_SRCS} sysdep.c softcore.c
 CLEANFILES=softcore.c testmain testmain.o
 CFLAGS+=   -ffreestanding
 .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
-CFLAGS+=   -mpreferred-stack-boundary=2
-CFLAGS+=   -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
+# See sys/conf/kern.mk for -m* implications
+.if ${CC:T:Mclang} != "clang"
+CFLAGS+=   -mpreferred-stack-boundary=2 -mno-sse
+.else
+CFLAGS+=   -mno-aes -mno-avx
+.endif
+CFLAGS+=   -mno-mmx -msoft-float
 .end

Re: svn commit: r224721 - head/sys/sys

2011-08-15 Thread Alexander Best
On Mon Aug 15 11, Alexander Best wrote:
> On Mon Aug 15 11, Bruce Evans wrote:
> > On Wed, 10 Aug 2011, Alexander Best wrote:
> > 
> > >On Wed Aug 10 11, Bruce Evans wrote:
> > >>On Wed, 10 Aug 2011, Alexander Best wrote:
> > >>>any reason {TIMEVAL,TIMESPEC}_TO_{TIMESPEC,TIMEVAL}()s code is being
> > >>>executed
> > >>>in a
> > >>>
> > >>>do { ... } while (0)
> > >>>
> > >>>conditional loop?
> > >>
> > >>Just the usual syntactical trick for making large macros that look
> > >>like function calls almost usable like function calls.  Without the
> > >...
> > >thanks a lot for the in depth information. :) any reason, back in the 
> > >days, it
> > >was decided that the functionality of converting a timespec to a timeval 
> > >and
> > >vice versa should be implemented as a macro and not a function?
> > 
> > Macros avoid some namespace pollution problems, and all the old kernel
> > timeval manipulation interfaces are either extern functions or macros,
> > partly because inline functions didn't exist when these interfaces were
> > designed.  But the TIME* macros still have gratuitously different styles:
> > 1) they are spelled in upper case (which is "correct" since they are unsafe
> >macros, but this is not done for the other timeval macros which are 
> >almost
> >all unsafe)
> > 2) FreeBSD moved their definitions from  (where 4.4BSD-Lite
> >put them) to .  This is not incorrect (since 
> >is an old header that should only declare timeval interfaces (POSIX
> >put timespec interfaces in ).  However, the move became out of
> >date before it was done (in 2001) because  had already
> >grown several other timespec interfaces which were not moved.  But these
> >were kernel-only, so they didn't cause namespace problems.  Now
> > has grown several more user timespec interfaces.
> 
> thanks for the explanation. :)

sorry. this was supposed to go to bde@ alone and not the lists.

> 
> > 
> > Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r224721 - head/sys/sys

2011-08-15 Thread Alexander Best
On Mon Aug 15 11, Bruce Evans wrote:
> On Wed, 10 Aug 2011, Alexander Best wrote:
> 
> >On Wed Aug 10 11, Bruce Evans wrote:
> >>On Wed, 10 Aug 2011, Alexander Best wrote:
> >>>any reason {TIMEVAL,TIMESPEC}_TO_{TIMESPEC,TIMEVAL}()s code is being
> >>>executed
> >>>in a
> >>>
> >>>do { ... } while (0)
> >>>
> >>>conditional loop?
> >>
> >>Just the usual syntactical trick for making large macros that look
> >>like function calls almost usable like function calls.  Without the
> >...
> >thanks a lot for the in depth information. :) any reason, back in the 
> >days, it
> >was decided that the functionality of converting a timespec to a timeval 
> >and
> >vice versa should be implemented as a macro and not a function?
> 
> Macros avoid some namespace pollution problems, and all the old kernel
> timeval manipulation interfaces are either extern functions or macros,
> partly because inline functions didn't exist when these interfaces were
> designed.  But the TIME* macros still have gratuitously different styles:
> 1) they are spelled in upper case (which is "correct" since they are unsafe
>macros, but this is not done for the other timeval macros which are 
>almost
>all unsafe)
> 2) FreeBSD moved their definitions from  (where 4.4BSD-Lite
>put them) to .  This is not incorrect (since 
>is an old header that should only declare timeval interfaces (POSIX
>put timespec interfaces in ).  However, the move became out of
>date before it was done (in 2001) because  had already
>grown several other timespec interfaces which were not moved.  But these
>were kernel-only, so they didn't cause namespace problems.  Now
> has grown several more user timespec interfaces.

thanks for the explanation. :)

> 
> Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r213507 - head/usr.bin/man

2011-08-14 Thread Alexander Best
On Sun Aug 14 11, Test Rat wrote:
> Gordon Tetlow  writes:
> 
> > Author: gordon
> > Date: Thu Oct  7 06:34:47 2010
> > New Revision: 213507
> > URL: http://svn.freebsd.org/changeset/base/213507
> >
> > Log:
> >   Add the ability to display specific manual pages if passed on the
> >   commandline. This mirrors the old (undocumented) GNU man functionality.
> >   Also document this feature in the implementation notes section of
> >   the manpage.
> >
> >   Submitted by: arundel
> >   Approved by:  wes (mentor implicit)
> 
> Why the limitation? It's rather painful to prefix manpages with $PWD
> on command line. And a useful case of displaying generated on-the-fly
> manpages is missed, too, irrespective of GNU man.

at the time my issue was that something like

'man /usr/src/share/man/man1/intro.1'

didn't work and gordon fixed that to restore gnu man behavior. i never really
tried or needed something like in your example to be honest. ;)

but if it makes peoples lives easier and doesn't cause any collisions with
gnu man behaviour, then i'm in. ;)

cheers.
alex

> 
>   $ man dup.2
>   $ texi2pod.pl ffmpeg.texi | pod2man | man
> 
> %%
> Index: usr.bin/man/man.sh
> ===
> --- usr.bin/man/man.sh(revision 224842)
> +++ usr.bin/man/man.sh(working copy)
> @@ -403,10 +403,9 @@
>  man_find_and_display() {
>   local found_page locpath p path sect
>  
> - # Check to see if it's a file. But only if it has a '/' in
> - # the filename.
> - case "$1" in
> - */*)if [ -f "$1" -a -r "$1" ]; then
> + # Check to see if it's a troff file.
> + case $(file --brief --mime-type "$1") in
> + text/troff) if [ -f "$1" -a -r "$1" ]; then
>   decho "Found a usable page, displaying that"
>   unset use_cat
>   manpage="$1"
> @@ -898,12 +897,16 @@
>  
>  do_man() {
>   man_parse_args "$@"
> - if [ -z "$pages" ]; then
> + if [ -z "$pages" -a -t 0 ]; then
>   echo 'What manual page do you want?' >&2
>   exit 1
>   fi
>   man_setup
>  
> + if [ ! -t 0 ]; then
> + man_display_page
> + fi
> +
>   for page in $pages; do
>   decho "Searching for $page"
>   man_find_and_display "$page"
> Index: usr.bin/man/man.1
> ===
> --- usr.bin/man/man.1 (revision 224842)
> +++ usr.bin/man/man.1 (working copy)
> @@ -232,9 +232,7 @@
>  The
>  .Nm
>  utility also supports displaying a specific manual page if passed a path
> -to the file as long as it contains a
> -.Ql /
> -character.
> +to the file as long as it's a troff file.
>  .Sh ENVIRONMENT
>  The following environment variables affect the execution of
>  .Nm :
> %%
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r224842 - head/sys/kern

2011-08-14 Thread Alexander Best
On Sun Aug 14 11, Niclas Zeising wrote:
> On 2011-08-13 18:03, Robert Watson wrote:
> > Author: rwatson
> > Date: Sat Aug 13 16:03:40 2011
> > New Revision: 224842
> > URL: http://svn.freebsd.org/changeset/base/224842
> > 
> > Log:
> >   When falloc() was broken into separate falloc_noinstall() and finstall(),
> >   a bug was introduced in kern_openat() such that the error from the vnode
> >   open operation was overwritten before it was passed as an argument to
> >   dupfdopen().  This broke operations on /dev/{stdin,stdout,stderr}.  Fix
> >   by preserving the original error number across finstall() so that it is
> >   still available.
> >   
> >   Approved by:  re (kib)
> >   Reported by:  cognet
> > 
> > Modified:
> >   head/sys/kern/vfs_syscalls.c
> > 
> 
> It might be worth mentioning this in UPDATING or similar, since a kernel
> built with clang (I haven't tried gcc) during this window will make it
> impossible to do a buildworld without first rebuilding the kernel with
> this fix. It also seems to break at least portsnap, and possibly other
> tools as well.

+1. please also mention the KPI change to fget()! so many people have had
issues, where 3rd party drivers - mostly the nvidia binary driver - got broken.

cheers.
alex

> 
> Regards!
> -- 
> Niclas Zeising
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r224721 - head/sys/sys

2011-08-10 Thread Alexander Best
On Wed Aug 10 11, Bruce Evans wrote:
> On Wed, 10 Aug 2011, Alexander Best wrote:
> 
> >On Tue Aug  9 11, Bruce Evans wrote:
> >>...
> >>What is wrong with the existing APIs TIMEVAL_TO_TIMESPEC() and
> >>TIMESPEC_TO_TIMEVAL(), which are used for these conversions by almost
> >>everything now?  Well, quite a bit is wrong with them, starting with
> >>...
> >
> >any reason {TIMEVAL,TIMESPEC}_TO_{TIMESPEC,TIMEVAL}()s code is being 
> >executed
> >in a
> >
> >do { ... } while (0)
> >
> >conditional loop?
> 
> Just the usual syntactical trick for making large macros that look
> like function calls almost usable like function calls.  Without the
> do-while trick, code like
> 
>   if (foo)
>   TIMEVAL_TO_TIMESPEC(&tv, &ts);
> 
> would be fragile at best.  With an else clause added to it, it would expand
> to either
> 
>   if (foo)
>   first_statement_of_macro;
>   second_statement_of_macro; ;
>   else
>   ...
> 
> which is obviously broken (3 statements between the 'if' and the 'else'
> give a syntax error).  We partially fix this by putting outer braces in
> the macro:
> 
>   if (foo)
>   /*
>* Here I attempt to duplicate the ugly indentation,
>* that tends to be preserved on expansion, which is
>* given by style bugs in the macro definition.  See
>* sys/queue.h for similar definitions without these
>* style bugs.
>*/
>   {
>   first_statement_of_macro;
>   second_statement_of_macro;
>   } ;
>   else
>   ...
> 
> This might work without the else clause, but with the else clause it
> is still a syntax error, since there are still too many statements
> between the 'if' and the 'else' -- we want to add the semicolon after
> the macro invocation, since the macro invocation looks like a function
> call, but this semicolon gives an extra statement and thus defeats the
> reduction to a single statement in the macro be using braces.
> 
> With the trick, and without the style bugs, the above expands to:
> 
>   if (foo)
>   do {
>   first_statement_of_macro;
>   second_statement_of_macro;
>   } while (0) ;
>   else
>   ...
> 
> Now there is only 1 statement between the 'if' and the 'else', since we
> trickily made the macro a non-statement that works after adding a semicolon
> to it -- the semicolon completes the statement, and the do-while is a
> trick that works (I don't know of any other).
> 
> >both macros are also defined in crypto/openssh/defines.h and
> >don't seem to need that extra one-time-loop.
> 
> Macros that are only used locally can be sloppier, but shouldn't be.

thanks a lot for the in depth information. :) any reason, back in the days, it
was decided that the functionality of converting a timespec to a timeval and
vice versa should be implemented as a macro and not a function?

cheers.
alex

> 
> Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r224721 - head/sys/sys

2011-08-10 Thread Alexander Best
On Tue Aug  9 11, Bruce Evans wrote:
> On Mon, 8 Aug 2011, Jonathan Anderson wrote:
> 
> >Log:
> > Create timeval2timespec() and timespec2timeval().
> >
> > These functions will be used by process descriptors to convert process
> > creation time into process descriptor [acm]time.
> 
> These were intentionally left out.
> 
> What is wrong with the existing APIs TIMEVAL_TO_TIMESPEC() and
> TIMESPEC_TO_TIMEVAL(), which are used for these conversions by almost
> everything now?  Well, quite a bit is wrong with them, starting with
> the loudness of their names, but not including a twee spelling of "to"
> in their names.  The main bugs in them is that they give undocumented
> APIs and namespace pollution in userland and undocumented APIs in the
> kernel.

any reason {TIMEVAL,TIMESPEC}_TO_{TIMESPEC,TIMEVAL}()s code is being executed
in a

do { ... } while (0)

conditional loop? both macros are also defined in crypto/openssh/defines.h and
don't seem to need that extra one-time-loop.

cheers.
alex

> 
> > Approved by: re (kib), mentor (rwatson)
> > Suggested by: jhb
> 
> Should know better.
> 
> >Modified: head/sys/sys/time.h
> >==
> >--- head/sys/sys/time.h  Mon Aug  8 19:03:26 2011(r224720)
> >+++ head/sys/sys/time.h  Mon Aug  8 20:36:52 2011(r224721)
> >@@ -195,6 +195,24 @@ timeval2bintime(const struct timeval *tv
> > ((tvp)->tv_usec cmp (uvp)->tv_usec) :   \
> > ((tvp)->tv_sec cmp (uvp)->tv_sec))
> >
> >+/* Conversion between timespec and timeval. */
> >+
> >+static __inline void
> >+timeval2timespec(const struct timeval *tv, struct timespec *ts)
> >+{
> >+
> >+ts->tv_sec = tv->tv_sec;
> >+ts->tv_nsec = 1000 * tv->tv_usec;
> >+}
> >+
> >+static __inline void
> >+timespec2timeval(const struct timespec *ts, struct timeval *tv)
> >+{
> >+
> >+tv->tv_sec = ts->tv_sec;
> >+tv->tv_usec = ts->tv_nsec / 1000;
> >+}
> >+
> >/* timevaladd and timevalsub are not inlined */
> >
> >#endif /* _KERNEL */
> 
> These are in the _KERNEL section, so they don't pollute userland.
> Otherwise, the pollution would consist of 2 function names, 2 parameter
> names and possibly 1 struct member names (I think tv_sec and tv_usec
> are reserved in , but perhaps timespecs and tv_nsec are
> not, since  is mainly for old timeval interfaces.  This
> is another reason why the implementation of timespec conversions belongs
> in  where they already are and not in ).
> 
> Style bugs in these include:
> - use of inline functions instead of macros.  Macros are used for all the
>   other APIs in this section.  Using macros would limit the namespace
>   pollution.  E.g., it keeps parameter names out of other namespaces.
> - not using Hungrarian notation for pointers.  Names of pointers are spelled
>   with a trailing p in all other APIs in this section.
> 
> sys/time.h has mounds of older implementation bugs.  The bintime section
> is especially bad.  The following is mostly about buigs in the non-_KERNEL
> sections.
> 
> 1) Userland pollution in  starts with everything in
>.
> 2) Then there is everything in .  The only pollution is
>the undocumented TIMEPSEC conversion macros mentioned above (these
>are conditional on __BSD_VISIBLE).
> 4) Then there is struct timezone and its members.
> 5) Then there is DST_* for using tz_dsttime.
> 6) Then there is mounds of pollution from struct bintime and its APIs.
>This is conditional on __BSD_VISIBLE.  Most of the bintime APIs are
>undocumented.  (zgrep -r bintime in /usr/share/man gives many hits,
>while zgrep -r TIMESPEC in /usr/share/man gives zero hits, but most
>of the hits for bintime are in peripheral man pages and bintime(9);
>bintime(9) only documents the highest level of bintime APIs, leaving
>all of the arithmetic and conversion APIs undocumented.)
> 
>Inlines instead of macros are used to implement most of the bintime
>APIs.  This gives the following undocumented pollution:
>- bintime struct tag name 'bintime'
>- bintime struct member names 'sec' and 'frac'.  These are especially
>  bad since they are missing a prefix.
>- all the API names
>- all the parameter names: bt, x, bt2, ts, tv.  Of course, these are
>  also missing Hungrarian notation.
>- all the local variable names: u.
> 7) Then there is mounds of documented pollution for the NetBSD/OpenBSD
>compatibility APIs.  These are not under __BSD_VISIBLE, so they are
>pure pollution.  These were obsolete before they were born, since they
>are only for timevals.  The kernel has always had equivalent interfaces,
>but they were intentionally left out of userland.  Then they came back 
>:-(.
>But they are documented, and they implemented using macros so they are
>missing the namespace pollution for parameter and local variable names,
>and their parameter names are spelled in Hungrarian notations, so 

Re: svn commit: r223877 - in head: include/rpc lib/libc/xdr

2011-07-09 Thread Alexander Best
On Sat Jul  9 11, Kevin Lo wrote:
> Author: kevlo
> Date: Sat Jul  9 07:43:56 2011
> New Revision: 223877
> URL: http://svn.freebsd.org/changeset/base/223877
> 
> Log:
>   - Add xdr_sizeof(3) to libc
>   - Document xdr_sizeof(3); from NetBSD
>   
>   Discussed with: kib
> 
> Modified:
>   head/include/rpc/xdr.h
>   head/lib/libc/xdr/Makefile.inc
>   head/lib/libc/xdr/Symbol.map
>   head/lib/libc/xdr/xdr.3
>   head/lib/libc/xdr/xdr_sizeof.c
> 
> Modified: head/include/rpc/xdr.h
> ==
> --- head/include/rpc/xdr.hFri Jul  8 20:41:12 2011(r223876)
> +++ head/include/rpc/xdr.hSat Jul  9 07:43:56 2011(r223877)
> @@ -285,43 +285,46 @@ struct xdr_discrim {
>   * These are the "generic" xdr routines.
>   */
>  __BEGIN_DECLS
> -extern bool_txdr_void(void);
> -extern bool_txdr_int(XDR *, int *);
> -extern bool_txdr_u_int(XDR *, u_int *);
> -extern bool_txdr_long(XDR *, long *);
> -extern bool_txdr_u_long(XDR *, u_long *);
> -extern bool_txdr_short(XDR *, short *);
> -extern bool_txdr_u_short(XDR *, u_short *);
> -extern bool_txdr_int16_t(XDR *, int16_t *);
> -extern bool_txdr_u_int16_t(XDR *, u_int16_t *);
> -extern bool_txdr_uint16_t(XDR *, u_int16_t *);
> -extern bool_txdr_int32_t(XDR *, int32_t *);
> -extern bool_txdr_u_int32_t(XDR *, u_int32_t *);
> -extern bool_txdr_uint32_t(XDR *, u_int32_t *);
> -extern bool_txdr_int64_t(XDR *, int64_t *);
> -extern bool_txdr_u_int64_t(XDR *, u_int64_t *);
> -extern bool_txdr_uint64_t(XDR *, u_int64_t *);
> -extern bool_txdr_bool(XDR *, bool_t *);
> -extern bool_txdr_enum(XDR *, enum_t *);
> -extern bool_txdr_array(XDR *, char **, u_int *, u_int, u_int, 
> xdrproc_t);
> -extern bool_txdr_bytes(XDR *, char **, u_int *, u_int);
> -extern bool_txdr_opaque(XDR *, char *, u_int);
> -extern bool_txdr_string(XDR *, char **, u_int);
> -extern bool_txdr_union(XDR *, enum_t *, char *, const struct 
> xdr_discrim *, xdrproc_t);
> -extern bool_txdr_char(XDR *, char *);
> -extern bool_txdr_u_char(XDR *, u_char *);
> -extern bool_txdr_vector(XDR *, char *, u_int, u_int, xdrproc_t);
> -extern bool_txdr_float(XDR *, float *);
> -extern bool_txdr_double(XDR *, double *);
> -extern bool_txdr_quadruple(XDR *, long double *);
> -extern bool_txdr_reference(XDR *, char **, u_int, xdrproc_t);
> -extern bool_txdr_pointer(XDR *, char **, u_int, xdrproc_t);
> -extern bool_txdr_wrapstring(XDR *, char **);
> -extern void  xdr_free(xdrproc_t, void *);
> -extern bool_txdr_hyper(XDR *, quad_t *);
> -extern bool_txdr_u_hyper(XDR *, u_quad_t *);
> -extern bool_txdr_longlong_t(XDR *, quad_t *);
> -extern bool_txdr_u_longlong_t(XDR *, u_quad_t *);
> +extern bool_txdr_void(void);
> +extern bool_txdr_int(XDR *, int *);
> +extern bool_txdr_u_int(XDR *, u_int *);
> +extern bool_txdr_long(XDR *, long *);
> +extern bool_txdr_u_long(XDR *, u_long *);
> +extern bool_txdr_short(XDR *, short *);
> +extern bool_txdr_u_short(XDR *, u_short *);
> +extern bool_txdr_int16_t(XDR *, int16_t *);
> +extern bool_txdr_u_int16_t(XDR *, u_int16_t *);
> +extern bool_txdr_uint16_t(XDR *, u_int16_t *);
> +extern bool_txdr_int32_t(XDR *, int32_t *);
> +extern bool_txdr_u_int32_t(XDR *, u_int32_t *);
> +extern bool_txdr_uint32_t(XDR *, u_int32_t *);
> +extern bool_txdr_int64_t(XDR *, int64_t *);
> +extern bool_txdr_u_int64_t(XDR *, u_int64_t *);
> +extern bool_txdr_uint64_t(XDR *, u_int64_t *);
> +extern bool_txdr_bool(XDR *, bool_t *);
> +extern bool_txdr_enum(XDR *, enum_t *);
> +extern bool_txdr_array(XDR *, char **, u_int *, u_int, u_int,
> + xdrproc_t);
> +extern bool_txdr_bytes(XDR *, char **, u_int *, u_int);
> +extern bool_txdr_opaque(XDR *, char *, u_int);
> +extern bool_txdr_string(XDR *, char **, u_int);
> +extern bool_txdr_union(XDR *, enum_t *, char *,
> + const struct xdr_discrim *, xdrproc_t);
> +extern bool_txdr_char(XDR *, char *);
> +extern bool_txdr_u_char(XDR *, u_char *);
> +extern bool_txdr_vector(XDR *, char *, u_int, u_int, 
> xdrproc_t);
> +extern bool_txdr_float(XDR *, float *);
> +extern bool_txdr_double(XDR *, double *);
> +extern bool_txdr_quadruple(XDR *, long double *);
> +extern bool_txdr_reference(XDR *, 

Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf

2011-07-02 Thread Alexander Best
On Sat Jul  2 11, Ulrich Spörlein wrote:
> On Sat, 11.06.2011 at 13:55:15 -0700, Doug Barton wrote:
> > On 6/11/2011 1:02 PM, Warner Losh wrote:
> > >
> > > On Jun 11, 2011, at 12:17 PM, Doug Barton wrote:
> > >
> > >> On 6/11/2011 6:07 AM, Robert Watson wrote:
> > >>> To me, this seems like the wrong direction.  Over the last decade, we've
> > >>> been trying to move away from conditional compilation of features to
> > >>> having them be loadable as modules.
> > >>
> > >> FWIW, I agree. I'm wondering though, is there still a performance 
> > >> penalty for modules? My understanding in the past was that there is, 
> > >> although for most use cases it's in the statistical noise. Is that still 
> > >> true?
> > >
> > > At run time, I believe that's true.  At load time, lots of modules can 
> > > take a few seconds longer.
> > 
> > I have 3 or 4 modules loaded via loader.conf at boot time. They take at 
> > least 2 seconds each. IMO loading everything via loader.conf would slow 
> > the boot so much as to be a non-starter.
> > 
> > OTOH, I could imagine an rc.d script that depends on mountcritlocal that 
> > could load a list of modules. Unless I'm missing something that would be 
> > several times faster.
> 
> I suspect this is your BIOS' fault. I load 22 modules via loader.conf
> and the loader takes 2, at most 3, seconds to load them all (next to the
> kernel). This is true for all machines that I own/owned.

actually i recenly switched from using kernel modules to one big kernel entity,
simply because i had the same problem. each module was taking ~ 3-5 seconds to
load. make that 10 modules and you have additional loading time of almost half
a minute. now that i'm using one big kernel entity i was able to reduce the
loading time to ~ 4 seconds plus an extra 3 seconds for nvidia.ko.

i could upload two videos demonstrating the huge differences between both
schemes on my computer, if somebody is interested in it.

cheers.
alex

> 
> As you can guess, I'm very much in favour of moving modules from GENERIC
> to loader.conf ...
> 
> Uli
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r223493 - in head/usr.bin: ktrace ncplogin systat tftp vmstat

2011-06-24 Thread Alexander Best
On Fri Jun 24 11, Roman Divacky wrote:
> On Fri, Jun 24, 2011 at 07:18:44AM +, Kevin Lo wrote:
> > Author: kevlo
> > Date: Fri Jun 24 07:18:44 2011
> > New Revision: 223493
> > URL: http://svn.freebsd.org/changeset/base/223493
> > 
> > Log:
> >   Remove duplicated header files
> 
> You may be interested in this tool:
> 
> http://code.google.com/p/include-what-you-use/

did they add C support since the last time i tested it? back then it only
worked with CPP code, iirc. it was possible to thorw it at C code, but it
returned pretty useless results.

cheers.
alex
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r223342 - head/contrib/top

2011-06-22 Thread Alexander Best
On Mon Jun 20 11, Xin LI wrote:
> Author: delphij
> Date: Mon Jun 20 16:48:00 2011
> New Revision: 223342
> URL: http://svn.freebsd.org/changeset/base/223342
> 
> Log:
>   Revert r214857 pursudant to 9.0-RELEASE cycle.

why does top(1) have so much problems with finding the applicable number of
available columns? ps(1) works great regarding this matter. for me it works
without the need for the -w or -ww switch under the console and under X and
always makes perfect use of the available columns.

i've never been able to make `top -a` display complete commands, although
there defenately are enough columns available.

cheers.
alex

>   
>   Requested by:   jh
> 
> Modified:
>   head/contrib/top/display.c
>   head/contrib/top/top.h
> 
> Modified: head/contrib/top/display.c
> ==
> --- head/contrib/top/display.cMon Jun 20 16:42:20 2011
> (r223341)
> +++ head/contrib/top/display.cMon Jun 20 16:48:00 2011
> (r223342)
> @@ -698,7 +698,7 @@ char *text;
>   int width;
>  
>   s = NULL;
> - width = screen_width;
> + width = display_width;
>   header_length = strlen(text);
>   if (header_length >= width) {
>   s = malloc((width + 1) * sizeof(char));
> @@ -706,14 +706,6 @@ char *text;
>   return (NULL);
>   strncpy(s, text, width);
>   s[width] = '\0';
> - } else {
> - s = malloc((width + 1) * sizeof(char));
> - if (s == NULL)
> - return (NULL);
> - strncpy(s, text, width);
> - while (screen_width > header_length)
> - s[header_length++] = ' ';
> - s[width] = '\0';
>   }
>   return (s);
>  }
> @@ -738,7 +730,7 @@ char *text;
>  if (header_status == ON)
>  {
>   putchar('\n');
> - standout(text, stdout);
> + fputs(text, stdout);
>   lastline++;
>  }
>  else if (header_status == ERASE)
> 
> Modified: head/contrib/top/top.h
> ==
> --- head/contrib/top/top.hMon Jun 20 16:42:20 2011(r223341)
> +++ head/contrib/top/top.hMon Jun 20 16:48:00 2011(r223342)
> @@ -14,7 +14,7 @@
>  extern int Header_lines; /* 7 */
>  
>  /* Maximum number of columns allowed for display */
> -#define MAX_COLS 512
> +#define MAX_COLS 128
>  
>  /* Log base 2 of 1024 is 10 (2^10 == 1024) */
>  #define LOG1024  10
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r223197 - head/usr.sbin/fdread

2011-06-17 Thread Alexander Best
On Fri Jun 17 11, Joerg Wunsch wrote:
> Author: joerg
> Date: Fri Jun 17 18:56:51 2011
> New Revision: 223197
> URL: http://svn.freebsd.org/changeset/base/223197

any thoughts about switching the default from WITH_FLOPPY to WITHOUT_FLOPPY? i
don't think too many people are using floppy disks nowadays.

cheers.
alex

> 
> Log:
>   Open the floppy disk device with O_RDONLY rather than O_RDWR.  After
>   all, this is the fd*read* command, and thus should be able to read
>   even write-protected disks.
>   
>   MFC after:  1 week
> 
> Modified:
>   head/usr.sbin/fdread/fdread.c
> 
> Modified: head/usr.sbin/fdread/fdread.c
> ==
> --- head/usr.sbin/fdread/fdread.c Fri Jun 17 18:49:59 2011
> (r223196)
> +++ head/usr.sbin/fdread/fdread.c Fri Jun 17 18:56:51 2011
> (r223197)
> @@ -149,7 +149,7 @@ main(int argc, char **argv)
>   err(EX_OSERR, "cannot create output file %s", fname);
>   }
>  
> - if ((fd = open(_devname, O_RDWR)) == -1)
> + if ((fd = open(_devname, O_RDONLY)) == -1)
>   err(EX_OSERR, "cannot open device %s", _devname);
>  
>   return (numids? doreadid(fd, numids, trackno): doread(fd, of, 
> _devname));

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r221853 - in head/sys: dev/md dev/null sys vm

2011-06-03 Thread Alexander Best
On Tue May 31 11, Bruce Evans wrote:
> On Mon, 30 May 2011 m...@freebsd.org wrote:
> 
> >On Mon, May 30, 2011 at 8:25 AM, Bruce Evans  wrote:
> >>On Sat, 28 May 2011 m...@freebsd.org wrote:
> >>>...
> >>>Meanwhile you could try setting ZERO_REGION_SIZE to PAGE_SIZE and I
> >>>think that will restore things to the original performance.
> >>
> >>Using /dev/zero always thrashes caches by the amount  >>size> +  (unless the arch uses nontemporal memory
> >>accesses for uiomove, which none do AFAIK).  So a large source buffer
> >>is always just a pessimization.  A large target buffer size is also a
> >>pessimization, but for the target buffer a fairly large size is needed
> >>to amortize the large syscall costs.  In this PR, the target buffer
> >>size is 64K.  ZERO_REGION_SIZE is 64K on i386 and 2M on amd64.  64K+64K
> >>on i386 is good for thrashing the L1 cache.
> >
> >That depends -- is the cache virtually or physically addressed?  The
> >zero_region only has 4k (PAGE_SIZE) of unique physical addresses.  So
> >most of the cache thrashing is due to the user-space buffer, if the
> >cache is physically addressed.
> 
> Oops.  I now remember thinking that the much larger source buffer would be
> OK since it only uses 1 physical page.  But it is apparently virtually
> addressed.
> 
> >It will only have a
> >>noticeable impact on a current L2 cache in competition with other
> >>threads.  It is hard to fit everything in the L1 cache even with
> >>non-bloated buffer sizes and 1 thread (16 for the source (I)cache, 0
> >>for the source (D)cache and 4K for the target cache might work).  On
> >>amd64, 2M+2M is good for thrashing most L2 caches.  In this PR, the
> >>thrashing is limited by the target buffer size to about 64K+64K, up
> >>from 4K+64K, and it is marginal whether the extra thrashing from the
> >>larger source buffer makes much difference.
> >>
> >>The old zbuf source buffer size of PAGE_SIZE was already too large.
> >
> >Wouldn't this depend on how far down from the use of the buffer the
> >actual copy happens?  Another advantage to a large virtual buffer is
> >that it reduces the number of times the copy loop in uiomove has to
> >return up to the device layer that initiated the copy.  This is all
> >pretty fast, but again assuming a physical cache fewer trips is
> >better.
> 
> Yes, I had forgotten that I have to keep going back to the uiomove()
> level for each iteration.  That's a lot of overhead although not nearly
> as much as going back to the user level.  If this is actually important
> to optimize, then I might add a repeat count to uiomove() and copyout()
> (actually a different function for the latter).
> 
> linux-2.6.10 uses a mmapped /dev/zero and has had this since Y2K
> according to its comment.  Sigh.  You will never beat that by copying,
> but I think mmapping /dev/zero is only much more optimal for silly
> benchmarks.
> 
> linux-2.6.10 also has a seekable /dev/zero.  Seeks don't really work,
> but some of them "succeed" and keep the offset at 0 .  ISTR remember
> a FreeBSD PR about the file offset for /dev/zero not "working" because
> it is garbage instead of 0.  It is clearly a Linuxism to depend on it
> being nonzero.  IIRC, the file offset for device files is at best
> implementation-defined in POSIX.

i think you refer to [1]. i posted a patch as followup to that PR, but later
noticed that it is completely wrong. there was also a discussion on @hackers i
opened up with the subject line "seeking into /dev/{null,zero}". however not
much came out of it. POSIX doesn't have anything to say about seeking in
connection with /dev/{null,zero}. it only states that:

"The behavior of lseek() on devices which are incapable of seeking is 
implementation-defined.
The value of the file offset associated with such a device is undefined."

so basically we can decide for ourselves, whether /dev/{null,zero} shall be
capable or incapable of seeking.

i really think this issue should be solved once and for all and then also
mentioned in the zero(4) and null(4) man pages. so the question is:

how do we want /dev/zero and /dev/null to behave when seeking into the devices?

right now HEAD features the following semantics:

reading from /dev/null != seeking
writing to /dev/null != seeking
reading from /dev/zero == seeking
writing to /dev/zero != seeking

please don't get me wrong: i'm NOT saying the current semantics are wrong. the
issue in question is: the semantics need to be agreed upon and then documented
once and for all in the zero(4) and null(4) man pages, so people don't trip
over this questions every couple of years over and over again.

cheers.
alex

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/152485

> 
> Bruce


-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r222530 - in head: contrib/top usr.bin/top

2011-06-02 Thread Alexander Best
On Thu Jun  2 11, John Baldwin wrote:
> On Thursday, June 02, 2011 12:42:36 pm Alexander Best wrote:
> > On Tue May 31 11, John Baldwin wrote:
> > > Author: jhb
> > > Date: Tue May 31 15:11:23 2011
> > > New Revision: 222530
> > > URL: http://svn.freebsd.org/changeset/base/222530
> > > 
> > > Log:
> > >   Add a new option to toggle the display of the system idle process 
> > > (per-CPU
> > >   idle threads).  The process is displayed by default (subject to whether 
> > > or
> > >   not system processes are displayed) to preserve existing behavior.  The
> > >   system idle process can be hidden via the '-z' command line argument or 
> > > the
> > >   'z' key while top is running.  When it is hidden, top more closely 
> > > matches
> > >   the behavior of FreeBSD <= 4.x where idle time was not accounted to any
> > >   process.
> > 
> > does it make sense to have the -z flag and "z" key available, when the -S
> > flag or the "S" key was not specified?
> 
> I view them as independent just as 'i' and 'S' are.  I'm not sure it's worth
> trying to make it fancier as none of the other keys are dependent on another
> mode.

that's a good point. i hope this commit will survive the new vendor import of
top, once it happens. :)

cheers.
alex

> 
> -- 
> John Baldwin

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r222530 - in head: contrib/top usr.bin/top

2011-06-02 Thread Alexander Best
On Tue May 31 11, John Baldwin wrote:
> Author: jhb
> Date: Tue May 31 15:11:23 2011
> New Revision: 222530
> URL: http://svn.freebsd.org/changeset/base/222530
> 
> Log:
>   Add a new option to toggle the display of the system idle process (per-CPU
>   idle threads).  The process is displayed by default (subject to whether or
>   not system processes are displayed) to preserve existing behavior.  The
>   system idle process can be hidden via the '-z' command line argument or the
>   'z' key while top is running.  When it is hidden, top more closely matches
>   the behavior of FreeBSD <= 4.x where idle time was not accounted to any
>   process.

does it make sense to have the -z flag and "z" key available, when the -S
flag or the "S" key was not specified?

cheers.
alex

>   
>   MFC after:  2 weeks
> 
> Modified:
>   head/contrib/top/commands.c
>   head/contrib/top/machine.h
>   head/contrib/top/top.X
>   head/contrib/top/top.c
>   head/usr.bin/top/machine.c
> 
> Modified: head/contrib/top/commands.c
> ==
> --- head/contrib/top/commands.c   Tue May 31 15:05:29 2011
> (r222529)
> +++ head/contrib/top/commands.c   Tue May 31 15:11:23 2011
> (r222530)
> @@ -94,6 +94,7 @@ S   - toggle the displaying of syste
>  a   - toggle the displaying of process titles\n\
>  t   - toggle the display of this process\n\
>  u   - display processes for only one user (+ selects all users)\n\
> +z   - toggle the displaying of the system idle process\n\
>  \n\
>  \n", stdout);
>  }
> 
> Modified: head/contrib/top/machine.h
> ==
> --- head/contrib/top/machine.hTue May 31 15:05:29 2011
> (r222529)
> +++ head/contrib/top/machine.hTue May 31 15:11:23 2011
> (r222530)
> @@ -65,6 +65,7 @@ struct process_select
>  int uid; /* only this uid (unless uid == -1) */
>  int wcpu;/* show weighted cpu */
>  int jail;/* show jail ID */
> +int kidle;   /* show per-CPU idle threads */
>  char *command;   /* only this command (unless == NULL) */
>  };
>  
> 
> Modified: head/contrib/top/top.X
> ==
> --- head/contrib/top/top.XTue May 31 15:05:29 2011(r222529)
> +++ head/contrib/top/top.XTue May 31 15:11:23 2011(r222530)
> @@ -10,7 +10,7 @@ top \- display and update information ab
>  .SH SYNOPSIS
>  .B top
>  [
> -.B \-abCHIijnPqStuv
> +.B \-abCHIijnPqStuvz
>  ] [
>  .BI \-d count
>  ] [
> @@ -142,6 +142,9 @@ Write version number information to stde
>  No other processing takes place when this option is used.  To see current
>  revision information while top is running, use the help command \*(lq?\*(rq.
>  .TP
> +.B \-z
> +Do not display the system idle process.
> +.TP
>  .BI \-d count
>  Show only
>  .I count
> @@ -303,6 +306,9 @@ ID.
>  Toggle the display of the
>  .I top
>  process.
> +.TP
> +.B z
> +Toggle the display of the system idle process.
>  .SH "THE DISPLAY"
>  The actual display varies depending on the specific variant of Unix
>  that the machine is running.  This description may not exactly match
> 
> Modified: head/contrib/top/top.c
> ==
> --- head/contrib/top/top.cTue May 31 15:05:29 2011(r222529)
> +++ head/contrib/top/top.cTue May 31 15:11:23 2011(r222530)
> @@ -196,9 +196,9 @@ char *argv[];
>  fd_set readfds;
>  
>  #ifdef ORDER
> -static char command_chars[] = "\f qh?en#sdkriIutHmSCajo";
> +static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo";
>  #else
> -static char command_chars[] = "\f qh?en#sdkriIutHmSCaj";
> +static char command_chars[] = "\f qh?en#sdkriIutHmSCajz";
>  #endif
>  /* these defines enumerate the "strchr"s of the commands in command_chars */
>  #define CMD_redraw   0
> @@ -224,8 +224,9 @@ char *argv[];
>  #define  CMD_wcputog 19
>  #define  CMD_showargs20
>  #define  CMD_jidtog  21
> +#define CMD_kidletog 22
>  #ifdef ORDER
> -#define CMD_order   22
> +#define CMD_order   23
>  #endif
>  
>  /* set the buffer for stdout */
> @@ -258,6 +259,7 @@ char *argv[];
>  ps.thread  = No;
>  ps.wcpu= 1;
>  ps.jail= No;
> +ps.kidle   = Yes;
>  ps.command = NULL;
>  
>  /* get preset options from the environment */
> @@ -283,7 +285,7 @@ char *argv[];
>   optind = 1;
>   }
>  
> - while ((i = getopt(ac, av, "CSIHPabijnquvs:d:U:m:o:t")) != EOF)
> + while ((i = getopt(ac, av, "CSIHPabijnquvzs:d:U:m:o:t")) != EOF)
>   {
>   switch(i)
>   {
> @@ -412,10 +414,14 @@ char *argv[];
>   pcpu_stats = Yes;
>   break;
>  
> +   case 'z':
> + ps.kidle = !ps.kidle;
> +

Re: svn commit: r222423 - head/sbin/newfs

2011-05-31 Thread Alexander Best
On Sat May 28 11, Niclas Zeising wrote:
> On 2011-05-28 17:14, Kirk McKusick wrote:
> > Author: mckusick
> > Date: Sat May 28 15:14:50 2011
> > New Revision: 222423
> > URL: http://svn.freebsd.org/changeset/base/222423
> > 
> > Log:
> >   Update the manual page to reflect the new 32K/4K defaults.
> >   
> >   Reminded by: Ivan Voras
> > 
> > Modified:
> >   head/sbin/newfs/newfs.8
> > 
> 
> See docs/157354 as well.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=157354

i believe tuning(7) might also benefit from updating it to reflect the new
defaults.

cheers.
alex

> 
> Regards!
> -- 
> Niclas

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r221541 - head/tools/build/options

2011-05-06 Thread Alexander Best
On Fri May  6 11, Ruslan Ermilov wrote:
> Author: ru
> Date: Fri May  6 19:14:06 2011
> New Revision: 221541
> URL: http://svn.freebsd.org/changeset/base/221541
> 
> Log:
>   MK_GPIO changed its default; reflect.

could you also have a look at WITHOUT_SSP? the description says that it only
affects world, but looking at sys/conf/kern.mk, it also triggers the
-fstack-protector flag for the kernel. so it has an effect both on world AND
kernel, if i understood things correctly.

cheers.
alex

> 
> Added:
>   head/tools/build/options/WITHOUT_GPIO
>  - copied, changed from r221204, head/tools/build/options/WITH_GPIO
> Deleted:
>   head/tools/build/options/WITH_GPIO
> 
> Copied and modified: head/tools/build/options/WITHOUT_GPIO (from r221204, 
> head/tools/build/options/WITH_GPIO)
> ==
> --- head/tools/build/options/WITH_GPIOFri Apr 29 10:33:54 2011
> (r221204, copy source)
> +++ head/tools/build/options/WITHOUT_GPIO Fri May  6 19:14:06 2011
> (r221541)
> @@ -1,2 +1,4 @@
>  .\" $FreeBSD$
> -Set to build gpioctl(8) as part of the base system.
> +Set to not build
> +.Xr gpioctl 8
> +as part of the base system.

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r221348 - head/sys/boot/i386/boot2

2011-05-02 Thread Alexander Best
On Mon May  2 11, Dimitry Andric wrote:
> Author: dim
> Date: Mon May  2 21:13:08 2011
> New Revision: 221348
> URL: http://svn.freebsd.org/changeset/base/221348
> 
> Log:
>   Clang r130700 can now compile sys/boot/i386/boot2 with room to spare.

congratulations! everybody hanging out in #freebsd-clang knows how hard all of
you guys have been working on this and persuading the llvm devs to look into
the issues.

alex

> 
> Modified:
>   head/sys/boot/i386/boot2/Makefile
> 
> Modified: head/sys/boot/i386/boot2/Makefile
> ==
> --- head/sys/boot/i386/boot2/Makefile Mon May  2 21:10:13 2011
> (r221347)
> +++ head/sys/boot/i386/boot2/Makefile Mon May  2 21:13:08 2011
> (r221348)
> @@ -2,9 +2,6 @@
>  
>  .include 
>  
> -# XXX: clang can compile the boot code just fine, but boot2 gets too big
> -CC:=${CC:C/^(.*\/)?clang$/gcc/1}
> -
>  FILES=   boot boot1 boot2
>  
>  NM?= nm
> @@ -45,6 +42,12 @@ CFLAGS=-Os \
>   -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings \
>   -Winline --param max-inline-insns-single=100
>  
> +.if ${CC:T:Mclang} == "clang"
> +CFLAGS+= -mllvm -stack-alignment=8 -mllvm -inline-threshold=3
> +# XXX: clang integrated-as doesn't grok .codeNN directives yet
> +CFLAGS+= ${.IMPSRC:T:Mboot1.S:C/^.+$/-no-integrated-as/}
> +.endif
> +
>  LDFLAGS=-static -N --gc-sections
>  
>  # Pick up ../Makefile.inc early.

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r221320 - head/sys/conf

2011-05-02 Thread Alexander Best
On Mon May  2 11, Bruce Cran wrote:
> Author: brucec
> Date: Mon May  2 10:35:27 2011
> New Revision: 221320
> URL: http://svn.freebsd.org/changeset/base/221320
> 
> Log:
>   Add -Wmissing-include-dirs to CWARNFLAGS, so tinderbox will punish those
>   developers committing new code with broken include directories.

Bruce already committed r220712 in order to make the current tree work with
-Wmissing-include-dirs. So hopefully tinderbox will not complain for any ARCH.

Please also note that currently -Wmissing-include-dirs is a noop in clang. Once
it gets implemented we will hopefully benefit from it via the vendor import.

Thanks again Bruce for taking care! :)

>   Fix a few whitespace issues.
>   Improve a couple of comments.
>   -W is now deprecated and is referred to as -Wextra (see gcc(1)).
>   
>   Submitted by:   arundel
> 
> Modified:
>   head/sys/conf/kern.mk
> 
> Modified: head/sys/conf/kern.mk
> ==
> --- head/sys/conf/kern.mk Mon May  2 09:47:13 2011(r221319)
> +++ head/sys/conf/kern.mk Mon May  2 10:35:27 2011(r221320)
> @@ -3,24 +3,25 @@
>  #
>  # Warning flags for compiling the kernel and components of the kernel.
>  #
> -# Note that the newly added -Wcast-qual is responsible for generating 
> +# Note that the newly added -Wcast-qual is responsible for generating
>  # most of the remaining warnings.  Warnings introduced with -Wall will
>  # also pop up, but are easier to fix.
>  CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
>   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
> - -Wundef -Wno-pointer-sign -fformat-extensions
> + -Wundef -Wno-pointer-sign -fformat-extensions \
> + -Wmissing-include-dirs
>  #
>  # The following flags are next up for working on:
> -#-W
> +#-Wextra
>  
>  #
> -# On the i386, do not align the stack to 16-byte boundaries.  Otherwise GCC
> -# 2.95 adds code to the entry and exit point of every function to align the
> +# On i386, do not align the stack to 16-byte boundaries.  Otherwise GCC 2.95
> +# and above adds code to the entry and exit point of every function to align 
> the
>  # stack to 16-byte boundaries -- thus wasting approximately 12 bytes of stack
> -# per function call.  While the 16-byte alignment may benefit micro 
> benchmarks, 
> +# per function call.  While the 16-byte alignment may benefit micro 
> benchmarks,
>  # it is probably an overall loss as it makes the code bigger (less efficient
>  # use of code cache tag lines) and uses more stack (less efficient use of 
> data
> -# cache tag lines).  Explicitly prohibit the use of SSE and other SIMD
> +# cache tag lines).  Explicitly prohibit the use of FPU, SSE and other SIMD
>  # operations inside the kernel itself.  These operations are exclusively
>  # reserved for user applications.
>  #
> @@ -35,6 +36,7 @@ INLINE_LIMIT?=  8000
>  .if ${MACHINE_CPUARCH} == "arm"
>  INLINE_LIMIT?=   8000
>  .endif
> +
>  #
>  # For IA-64, we use r13 for the kernel globals pointer and we only use
>  # a very small subset of float registers for integer divides.
> @@ -98,7 +100,7 @@ INLINE_LIMIT?= 8000
>  CFLAGS+= -ffreestanding
>  
>  #
> -# GCC SSP support.
> +# GCC SSP support
>  #
>  .if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \
>  ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
> @@ -106,9 +108,8 @@ CFLAGS+=  -fstack-protector
>  .endif
>  
>  #
> -# Enable CTF conversation on request.
> +# Enable CTF conversation on request
>  #
>  .if defined(WITH_CTF)
>  .undef NO_CTF
>  .endif
> -

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220983 - head

2011-04-24 Thread Alexander Best
On Sun Apr 24 11, Alexander Motin wrote:
> Author: mav
> Date: Sun Apr 24 09:23:08 2011
> New Revision: 220983
> URL: http://svn.freebsd.org/changeset/base/220983
> 
> Log:
>   Explicitly note that device numbers are starting from zero.
> 
> Modified:
>   head/UPDATING
> 
> Modified: head/UPDATING
> ==
> --- head/UPDATING Sun Apr 24 08:58:58 2011(r220982)
> +++ head/UPDATING Sun Apr 24 09:23:08 2011(r220983)
> @@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
>   removed and replaced by respective CAM drivers. If you are using
>   ATA device names in /etc/fstab or other places, make sure to update
>   them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
> - where 'Y's are the sequential numbers for each type in order of
> - detection, unless configured otherwise with tunables, see cam(4)).
> + where 'Y's are the sequential numbers starting from zero for each type
> + in order of detection, unless configured otherwise with tunables,
> + see cam(4)).

maybe an extra sentence mentioning the fact that {geom,ufs}-labels and ufsids
are preferred over device nodes nowadays would be a good idea?

cheers.
alex

>  
>   ataraid(4) functionality is now supported by the RAID GEOM class.
>   To use it you can load geom_raid kernel module and use graid(8) tool

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220412 - in head: share/man/man4 sys/cam/ata

2011-04-07 Thread Alexander Best
On Thu Apr  7 11, Garrett Cooper wrote:
> On Thu, Apr 7, 2011 at 12:03 PM, Alexander Best  wrote:
> > On Thu Apr  7 11, Alexander Motin wrote:
> >> Author: mav
> >> Date: Thu Apr  7 08:17:53 2011
> >> New Revision: 220412
> >> URL: http://svn.freebsd.org/changeset/base/220412
> >>
> >> Log:
> >>   Make ada(4) driver to control device write cache, same as ata(4) does.
> >>   Add kern.cam.ada.write_cache sysctl/tunable to control it alike 
> >> hw.ata.wc.
> >
> > how hard would it be to support per device sysctls/tunables? i'd really 
> > like to
> > do:
> >
> > kern.cam.ada.0.write_cache=0 (root fs)
> > kern.cam.ada.1.write_cache=1 (/usr, /var, etc.)
> 
> Does it really make sense to turn on write caching for one drive and
> not the other(s)?

i think so. for "/" i want maximum safebelts. so i'd like to disable the write
cache and mount it with the "sync" option. for /usr/ and all the other mount
points i'd like maximum speed with write caching enabled and mounted with the
"noasync" and "noatime" options.

cheers.
alex

> Thanks,
> -Garrett

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220412 - in head: share/man/man4 sys/cam/ata

2011-04-07 Thread Alexander Best
On Thu Apr  7 11, Alexander Motin wrote:
> Author: mav
> Date: Thu Apr  7 08:17:53 2011
> New Revision: 220412
> URL: http://svn.freebsd.org/changeset/base/220412
> 
> Log:
>   Make ada(4) driver to control device write cache, same as ata(4) does.
>   Add kern.cam.ada.write_cache sysctl/tunable to control it alike hw.ata.wc.

how hard would it be to support per device sysctls/tunables? i'd really like to
do:

kern.cam.ada.0.write_cache=0 (root fs)
kern.cam.ada.1.write_cache=1 (/usr, /var, etc.)

cheers.
alex

> 
> Modified:
>   head/share/man/man4/ada.4
>   head/sys/cam/ata/ata_da.c
> 
> Modified: head/share/man/man4/ada.4
> ==
> --- head/share/man/man4/ada.4 Thu Apr  7 07:34:01 2011(r220411)
> +++ head/share/man/man4/ada.4 Thu Apr  7 08:17:53 2011(r220412)
> @@ -25,7 +25,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd October 24, 2010
> +.Dd April 7, 2011
>  .Dt ADA 4
>  .Os
>  .Sh NAME
> @@ -123,6 +123,11 @@ seconds.
>  This variable determines whether to spin-down disks when shutting down.
>  Set to 1 to enable spin-down, 0 to disable.  
>  The default is currently enabled.
> +.It kern.cam.ada.write_cache
> +.Pp
> +This variable determines whether device write cache should be enabled or not.
> +Set to 1 to enable write cache, 0 to disable, -1 to left it as-is.
> +The default is currently enabled.
>  .El
>  .Sh FILES
>  .Bl -tag -width ".Pa /dev/ada*" -compact
> 
> Modified: head/sys/cam/ata/ata_da.c
> ==
> --- head/sys/cam/ata/ata_da.c Thu Apr  7 07:34:01 2011(r220411)
> +++ head/sys/cam/ata/ata_da.c Thu Apr  7 08:17:53 2011(r220412)
> @@ -66,6 +66,7 @@ __FBSDID("$FreeBSD$");
>  #define ATA_MAX_28BIT_LBA   268435455UL
>  
>  typedef enum {
> + ADA_STATE_WCACHE,
>   ADA_STATE_NORMAL
>  } ada_state;
>  
> @@ -89,6 +90,7 @@ typedef enum {
>  } ada_quirks;
>  
>  typedef enum {
> + ADA_CCB_WCACHE  = 0x01,
>   ADA_CCB_BUFFER_IO   = 0x03,
>   ADA_CCB_WAITING = 0x04,
>   ADA_CCB_DUMP= 0x05,
> @@ -186,6 +188,10 @@ static void  adashutdown(void *arg, int 
>  #define  ADA_DEFAULT_SPINDOWN_SHUTDOWN   1
>  #endif
>  
> +#ifndef  ADA_DEFAULT_WRITE_CACHE
> +#define  ADA_DEFAULT_WRITE_CACHE 1
> +#endif
> +
>  /*
>   * Most platforms map firmware geometry to actual, but some don't.  If
>   * not overridden, default to nothing.
> @@ -198,6 +204,7 @@ static int ada_retry_count = ADA_DEFAULT
>  static int ada_default_timeout = ADA_DEFAULT_TIMEOUT;
>  static int ada_send_ordered = ADA_DEFAULT_SEND_ORDERED;
>  static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOWN_SHUTDOWN;
> +static int ada_write_cache = ADA_DEFAULT_WRITE_CACHE;
>  
>  SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0,
>  "CAM Direct Access Disk driver");
> @@ -213,6 +220,9 @@ TUNABLE_INT("kern.cam.ada.ada_send_order
>  SYSCTL_INT(_kern_cam_ada, OID_AUTO, spindown_shutdown, CTLFLAG_RW,
> &ada_spindown_shutdown, 0, "Spin down upon shutdown");
>  TUNABLE_INT("kern.cam.ada.spindown_shutdown", &ada_spindown_shutdown);
> +SYSCTL_INT(_kern_cam_ada, OID_AUTO, write_cache, CTLFLAG_RW,
> +   &ada_write_cache, 0, "Enable disk write cache");
> +TUNABLE_INT("kern.cam.ada.write_cache", &ada_write_cache);
>  
>  /*
>   * ADA_ORDEREDTAG_INTERVAL determines how often, relative
> @@ -568,6 +578,7 @@ adaasync(void *callback_arg, u_int32_t c
>   struct cam_path *path, void *arg)
>  {
>   struct cam_periph *periph;
> + struct ada_softc *softc;
>  
>   periph = (struct cam_periph *)callback_arg;
>   switch (code) {
> @@ -600,6 +611,28 @@ adaasync(void *callback_arg, u_int32_t c
>   "due to status 0x%x\n", status);
>   break;
>   }
> + case AC_SENT_BDR:
> + case AC_BUS_RESET:
> + {
> + struct ccb_getdev cgd;
> +
> + softc = (struct ada_softc *)periph->softc;
> + cam_periph_async(periph, code, path, arg);
> + if (ada_write_cache < 0)
> + break;
> + if (softc->state != ADA_STATE_NORMAL)
> + break;
> + xpt_setup_ccb(&cgd.ccb_h, path, CAM_PRIORITY_NORMAL);
> + cgd.ccb_h.func_code = XPT_GDEV_TYPE;
> + xpt_action((union ccb *)&cgd);
> + if ((cgd.ident_data.support.command1 & ATA_SUPPORT_WRITECACHE) 
> == 0)
> + break;
> + softc->state = ADA_STATE_WCACHE;
> + cam_periph_acquire(periph);
> + cam_freeze_devq_arg(periph->path,
> + RELSIM_RELEASE_RUNLEVEL, CAM_RL_DEV + 1);
> + xpt_schedule(periph, CAM_PRIORITY_DEV);
> + }
>   default:
>   cam_periph_async(periph, code, path, arg);
>   break;
> @@ -691,7 +724,6 @@ adaregister(struct cam_periph *periph, v
>

Re: svn commit: r220401 - in head: . share/mk tools/build/mk tools/build/options

2011-04-07 Thread Alexander Best
On Wed Apr  6 11, Warner Losh wrote:
> 
> On Apr 6, 2011, at 3:41 PM, Alexander Best wrote:
> 
> > On Wed Apr  6 11, Juli Mallett wrote:
> >> On Wed, Apr 6, 2011 at 14:04, Alexander Best  wrote:
> >>> On Wed Apr  6 11, Ulrich Spoerlein wrote:
> >>>> Author: uqs
> >>>> Date: Wed Apr  6 20:08:23 2011
> >>>> New Revision: 220401
> >>>> URL: http://svn.freebsd.org/changeset/base/220401
> >>>> 
> >>>> Log:
> >>>>   Complete WITHOUT_CXX support. It implies WITHOUT_GROFF and
> >>>>   WITHOUT_CLANG.
> >>> 
> >>> is there no way to build clang/llvm without CXX support?
> >> 
> >> Clang and LLVM are written in C++.  Even if their support for
> >> compiling C++ could be disabled, you'd still need a C++ cross-compiler
> >> to build them, which ought to be disabled by WITHOUT_CXX, right?
> > 
> > good point. is it even possible to build a world *with* C++ support, if the
> > installed world *doesn't* have C++ support? is the C++ part of gcc written 
> > in
> > C? if that's the case it's possible.
> 
> Yes.  We don't need c++ to bootstrap g++ or anything else in the base system. 
>  Once we build the compilers, we can build the c++ that's in the tree.

however that means that FreeBSD can never get rid of gcc. so clang can never
become the main and only base compiler.

> 
> > couldn't we install clang *without* C++ support and then do the following to
> > build it *with* C++ support:
> > 
> > 1) use gcc to build a bootstrap gcc *with* C++ support
> > 2) use the bootstrap gcc to build clang
> 
> I suppose you could do that, but I'm unsure how much that buys you...
> 
> Warner
-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220401 - in head: . share/mk tools/build/mk tools/build/options

2011-04-06 Thread Alexander Best
On Wed Apr  6 11, Juli Mallett wrote:
> On Wed, Apr 6, 2011 at 14:04, Alexander Best  wrote:
> > On Wed Apr  6 11, Ulrich Spoerlein wrote:
> >> Author: uqs
> >> Date: Wed Apr  6 20:08:23 2011
> >> New Revision: 220401
> >> URL: http://svn.freebsd.org/changeset/base/220401
> >>
> >> Log:
> >>   Complete WITHOUT_CXX support. It implies WITHOUT_GROFF and
> >>   WITHOUT_CLANG.
> >
> > is there no way to build clang/llvm without CXX support?
> 
> Clang and LLVM are written in C++.  Even if their support for
> compiling C++ could be disabled, you'd still need a C++ cross-compiler
> to build them, which ought to be disabled by WITHOUT_CXX, right?

good point. is it even possible to build a world *with* C++ support, if the
installed world *doesn't* have C++ support? is the C++ part of gcc written in
C? if that's the case it's possible.

couldn't we install clang *without* C++ support and then do the following to
build it *with* C++ support:

1) use gcc to build a bootstrap gcc *with* C++ support
2) use the bootstrap gcc to build clang

cheers.
alex

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220401 - in head: . share/mk tools/build/mk tools/build/options

2011-04-06 Thread Alexander Best
On Wed Apr  6 11, Ulrich Spoerlein wrote:
> Author: uqs
> Date: Wed Apr  6 20:08:23 2011
> New Revision: 220401
> URL: http://svn.freebsd.org/changeset/base/220401
> 
> Log:
>   Complete WITHOUT_CXX support. It implies WITHOUT_GROFF and
>   WITHOUT_CLANG.

is there no way to build clang/llvm without CXX support?

cheers.
alex

>   
>   Don't build clang bootstrap/build-tools depending on this flag. We also
>   keep gperf, devd and libstdc++ around to prevent foot-shooting and to
>   make this a two-way street.
> 
> Modified:
>   head/Makefile.inc1
>   head/share/mk/bsd.own.mk
>   head/tools/build/mk/OptionalObsoleteFiles.inc
>   head/tools/build/options/WITHOUT_CXX
> 
> Modified: head/Makefile.inc1
> ==
> --- head/Makefile.inc1Wed Apr  6 19:13:04 2011(r220400)
> +++ head/Makefile.inc1Wed Apr  6 20:08:23 2011(r220401)
> @@ -1127,10 +1127,12 @@ _kgzip=   usr.sbin/kgzip
>  .endif
>  .endif
>  
> +.if ${MK_CLANG} != "no"
>  .if ${CC:T:Mclang} == "clang"
>  _clang=  usr.bin/clang
>  _clang_libs= lib/clang
>  .endif
> +.endif
>  
>  cross-tools:
>  .for _tool in \
> 
> Modified: head/share/mk/bsd.own.mk
> ==
> --- head/share/mk/bsd.own.mk  Wed Apr  6 19:13:04 2011(r220400)
> +++ head/share/mk/bsd.own.mk  Wed Apr  6 20:08:23 2011(r220401)
> @@ -500,6 +500,11 @@ MK_OPENSSH:= no
>  MK_KERBEROS:=no
>  .endif
>  
> +.if ${MK_CXX} == "no"
> +MK_CLANG:=   no
> +MK_GROFF:=   no
> +.endif
> +
>  .if ${MK_IPX} == "no"
>  MK_NCP:= no
>  .endif
> 
> Modified: head/tools/build/mk/OptionalObsoleteFiles.inc
> ==
> --- head/tools/build/mk/OptionalObsoleteFiles.inc Wed Apr  6 19:13:04 
> 2011(r220400)
> +++ head/tools/build/mk/OptionalObsoleteFiles.inc Wed Apr  6 20:08:23 
> 2011(r220401)
> @@ -689,9 +689,575 @@ OLD_FILES+=usr/share/man/man5/cvs.5.gz
>  OLD_FILES+=usr/share/man/man8/cvsbug.8.gz
>  .endif
>  
> -#.if ${MK_CXX} == no
> -# to be filled in
> -#.endif
> +# devd(8) and gperf(1) not listed here on purpose
> +.if ${MK_CXX} == no
> +OLD_FILES+=usr/bin/CC
> +OLD_FILES+=usr/bin/c++
> +OLD_FILES+=usr/bin/c++filt
> +OLD_FILES+=usr/bin/g++
> +OLD_FILES+=usr/include/c++/4.2/algorithm
> +OLD_FILES+=usr/include/c++/4.2/backward/algo.h
> +OLD_FILES+=usr/include/c++/4.2/backward/algobase.h
> +OLD_FILES+=usr/include/c++/4.2/backward/alloc.h
> +OLD_FILES+=usr/include/c++/4.2/backward/backward_warning.h
> +OLD_FILES+=usr/include/c++/4.2/backward/bvector.h
> +OLD_FILES+=usr/include/c++/4.2/backward/complex.h
> +OLD_FILES+=usr/include/c++/4.2/backward/defalloc.h
> +OLD_FILES+=usr/include/c++/4.2/backward/deque.h
> +OLD_FILES+=usr/include/c++/4.2/backward/fstream.h
> +OLD_FILES+=usr/include/c++/4.2/backward/function.h
> +OLD_FILES+=usr/include/c++/4.2/backward/hash_map.h
> +OLD_FILES+=usr/include/c++/4.2/backward/hash_set.h
> +OLD_FILES+=usr/include/c++/4.2/backward/hashtable.h
> +OLD_FILES+=usr/include/c++/4.2/backward/heap.h
> +OLD_FILES+=usr/include/c++/4.2/backward/iomanip.h
> +OLD_FILES+=usr/include/c++/4.2/backward/iostream.h
> +OLD_FILES+=usr/include/c++/4.2/backward/istream.h
> +OLD_FILES+=usr/include/c++/4.2/backward/iterator.h
> +OLD_FILES+=usr/include/c++/4.2/backward/list.h
> +OLD_FILES+=usr/include/c++/4.2/backward/map.h
> +OLD_FILES+=usr/include/c++/4.2/backward/multimap.h
> +OLD_FILES+=usr/include/c++/4.2/backward/multiset.h
> +OLD_FILES+=usr/include/c++/4.2/backward/new.h
> +OLD_FILES+=usr/include/c++/4.2/backward/ostream.h
> +OLD_FILES+=usr/include/c++/4.2/backward/pair.h
> +OLD_FILES+=usr/include/c++/4.2/backward/queue.h
> +OLD_FILES+=usr/include/c++/4.2/backward/rope.h
> +OLD_FILES+=usr/include/c++/4.2/backward/set.h
> +OLD_FILES+=usr/include/c++/4.2/backward/slist.h
> +OLD_FILES+=usr/include/c++/4.2/backward/stack.h
> +OLD_FILES+=usr/include/c++/4.2/backward/stream.h
> +OLD_FILES+=usr/include/c++/4.2/backward/streambuf.h
> +OLD_FILES+=usr/include/c++/4.2/backward/strstream
> +OLD_FILES+=usr/include/c++/4.2/backward/tempbuf.h
> +OLD_FILES+=usr/include/c++/4.2/backward/tree.h
> +OLD_FILES+=usr/include/c++/4.2/backward/vector.h
> +OLD_FILES+=usr/include/c++/4.2/bits/allocator.h
> +OLD_FILES+=usr/include/c++/4.2/bits/atomic_word.h
> +OLD_FILES+=usr/include/c++/4.2/bits/basic_file.h
> +OLD_FILES+=usr/include/c++/4.2/bits/basic_ios.h
> +OLD_FILES+=usr/include/c++/4.2/bits/basic_ios.tcc
> +OLD_FILES+=usr/include/c++/4.2/bits/basic_string.h
> +OLD_FILES+=usr/include/c++/4.2/bits/basic_string.tcc
> +OLD_FILES+=usr/include/c++/4.2/bits/boost_concept_check.h
> +OLD_FILES+=usr/include/c++/4.2/bits/c++allocator.h
> +OLD_FILES+=usr/include/c++/4.2/bits/c++config.h
> +OLD_FILES+=usr/include/c++/4.2/bits/c++io.h
> +OLD_FILES+=usr/include/c++/4.2/bits/c++locale.h
> +OLD_FILES+=usr/include/c++/4.2/bit

Re: svn commit: r220238 - in head/sys: amd64/ia32 compat/freebsd32 compat/ia32 ia64/ia32 kern modules sys

2011-04-01 Thread Alexander Best
On Fri Apr  1 11, Konstantin Belousov wrote:
> Author: kib
> Date: Fri Apr  1 11:16:29 2011
> New Revision: 220238
> URL: http://svn.freebsd.org/changeset/base/220238
> 
> Log:
>   Add support for executing the FreeBSD 1/i386 a.out binaries on amd64.
>   
>   In particular:
>   - implement compat shims for old stat(2) variants and ogetdirentries(2);
>   - implement delivery of signals with ancient stack frame layout and
> corresponding sigreturn(2);
>   - implement old getpagesize(2);
>   - provide a user-mode trampoline and LDT call gate for lcall $7,$0;
>   - port a.out image activator and connect it to the build as a module
> on amd64.
>   
>   The changes are hidden under COMPAT_43.

hmm...for i386 there's

# Enable i386 a.out binary support
options COMPAT_AOUT

why not make this feature dependant upon the same option and not COMPAT_43?

...also i noticed sys/amd/conf/NOTES says:

# Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_FREEBSD32)
options COMPAT_LINUX32


...i don't think COMPAT_43 is actually necessary to use COMPAT_FREEBSD32, is
it?

cheers.
alex

>   
>   MFC after:   1 month
> 
> Modified:
>   head/sys/amd64/ia32/ia32_misc.c
>   head/sys/amd64/ia32/ia32_signal.c
>   head/sys/amd64/ia32/ia32_sigtramp.S
>   head/sys/amd64/ia32/ia32_syscall.c
>   head/sys/compat/freebsd32/freebsd32_misc.c
>   head/sys/compat/freebsd32/syscalls.master
>   head/sys/compat/ia32/ia32_genassym.c
>   head/sys/compat/ia32/ia32_signal.h
>   head/sys/compat/ia32/ia32_sysvec.c
>   head/sys/compat/ia32/ia32_util.h
>   head/sys/ia64/ia32/ia32_misc.c
>   head/sys/ia64/ia32/ia32_signal.c
>   head/sys/kern/imgact_aout.c
>   head/sys/kern/vfs_syscalls.c
>   head/sys/modules/Makefile
>   head/sys/sys/syscallsubr.h
> 
> Modified: head/sys/amd64/ia32/ia32_misc.c
> ==
> --- head/sys/amd64/ia32/ia32_misc.c   Fri Apr  1 06:28:21 2011
> (r220237)
> +++ head/sys/amd64/ia32/ia32_misc.c   Fri Apr  1 11:16:29 2011
> (r220238)
> @@ -69,3 +69,14 @@ freebsd32_sysarch(struct thread *td, str
>   return (sysarch(td, &uap1));
>   }
>  }
> +
> +#ifdef COMPAT_43
> +int
> +ofreebsd32_getpagesize(struct thread *td,
> +struct ofreebsd32_getpagesize_args *uap)
> +{
> +
> + td->td_retval[0] = IA32_PAGE_SIZE;
> + return (0);
> +}
> +#endif
> 
> Modified: head/sys/amd64/ia32/ia32_signal.c
> ==
> --- head/sys/amd64/ia32/ia32_signal.c Fri Apr  1 06:28:21 2011
> (r220237)
> +++ head/sys/amd64/ia32/ia32_signal.c Fri Apr  1 11:16:29 2011
> (r220238)
> @@ -300,6 +300,109 @@ freebsd32_swapcontext(struct thread *td,
>   * frame pointer, it returns to the user
>   * specified pc, psl.
>   */
> +
> +#ifdef COMPAT_43
> +static void
> +ia32_osendsig(sig_t catcher, ksiginfo_t *ksi, sigset_t *mask)
> +{
> + struct ia32_sigframe3 sf, *fp;
> + struct proc *p;
> + struct thread *td;
> + struct sigacts *psp;
> + struct trapframe *regs;
> + int sig;
> + int oonstack;
> +
> + td = curthread;
> + p = td->td_proc;
> + PROC_LOCK_ASSERT(p, MA_OWNED);
> + sig = ksi->ksi_signo;
> + psp = p->p_sigacts;
> + mtx_assert(&psp->ps_mtx, MA_OWNED);
> + regs = td->td_frame;
> + oonstack = sigonstack(regs->tf_rsp);
> +
> + /* Allocate space for the signal handler context. */
> + if ((td->td_pflags & TDP_ALTSTACK) && !oonstack &&
> + SIGISMEMBER(psp->ps_sigonstack, sig)) {
> + fp = (struct ia32_sigframe3 *)(td->td_sigstk.ss_sp +
> + td->td_sigstk.ss_size - sizeof(sf));
> + td->td_sigstk.ss_flags |= SS_ONSTACK;
> + } else
> + fp = (struct ia32_sigframe3 *)regs->tf_rsp - 1;
> +
> + /* Translate the signal if appropriate. */
> + if (p->p_sysent->sv_sigtbl && sig <= p->p_sysent->sv_sigsize)
> + sig = p->p_sysent->sv_sigtbl[_SIG_IDX(sig)];
> +
> + /* Build the argument list for the signal handler. */
> + sf.sf_signum = sig;
> + sf.sf_scp = (register_t)&fp->sf_siginfo.si_sc;
> + if (SIGISMEMBER(psp->ps_siginfo, sig)) {
> + /* Signal handler installed with SA_SIGINFO. */
> + sf.sf_arg2 = (register_t)&fp->sf_siginfo;
> + sf.sf_siginfo.si_signo = sig;
> + sf.sf_siginfo.si_code = ksi->ksi_code;
> + sf.sf_ah = (uintptr_t)catcher;
> + } else {
> + /* Old FreeBSD-style arguments. */
> + sf.sf_arg2 = ksi->ksi_code;
> + sf.sf_addr = (register_t)ksi->ksi_addr;
> + sf.sf_ah = (uintptr_t)catcher;
> + }
> + mtx_unlock(&psp->ps_mtx);
> + PROC_UNLOCK(p);
> +
> + /* Save most if not all of trap frame. */
> + sf.sf_siginfo.si_sc.sc_eax = regs->tf_rax;
> + sf.sf_siginfo.si_sc.sc_ebx = regs->tf_rbx;
> + sf.sf_siginfo.si_sc.sc_ecx = regs->tf_rcx;
> + sf.sf_s

Re: svn commit: r220082 - head/release

2011-03-27 Thread Alexander Best
On Sun Mar 27 11, Nathan Whitehorn wrote:
> Author: nwhitehorn
> Date: Sun Mar 27 23:46:52 2011
> New Revision: 220082
> URL: http://svn.freebsd.org/changeset/base/220082
> 
> Log:
>   Copy all generated ISO images into the release area.

s/cp -pRP/cp -a/ ?

> 
> Modified:
>   head/release/generate-release.sh
> 
> Modified: head/release/generate-release.sh
> ==
> --- head/release/generate-release.sh  Sun Mar 27 23:46:12 2011
> (r220081)
> +++ head/release/generate-release.sh  Sun Mar 27 23:46:52 2011
> (r220082)
> @@ -62,5 +62,5 @@ fi
>  chroot $2 /bin/sh -c "cd /usr/src && make $MAKE_FLAGS buildworld 
> buildkernel" || exit 1
>  chroot $2 /bin/sh -c "cd /usr/src/release && make release" || exit 1
>  mkdir $2/R
> -cp -pRP $2/usr/obj/usr/src/release/release.iso 
> $2/usr/obj/usr/src/release/memstick $2/usr/obj/usr/src/release/ftp $2/R
> +cp -pRP $2/usr/obj/usr/src/release/*.iso $2/usr/obj/usr/src/release/memstick 
> $2/usr/obj/usr/src/release/ftp $2/R
>  

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r220015 - head/usr.sbin/newsyslog

2011-03-25 Thread Alexander Best
On Sat Mar 26 11, Doug Barton wrote:
> Author: dougb
> Date: Sat Mar 26 00:34:35 2011
> New Revision: 220015
> URL: http://svn.freebsd.org/changeset/base/220015
> 
> Log:
>   Add an example for the use of the  entry to help others
>   who are as slow as I am.

shouldn't that be march 25th? ;)

>   
>   Discussed with: gordon
> 
> Modified:
>   head/usr.sbin/newsyslog/newsyslog.conf.5
> 
> Modified: head/usr.sbin/newsyslog/newsyslog.conf.5
> ==
> --- head/usr.sbin/newsyslog/newsyslog.conf.5  Fri Mar 25 22:31:28 2011
> (r220014)
> +++ head/usr.sbin/newsyslog/newsyslog.conf.5  Sat Mar 26 00:34:35 2011
> (r220015)
> @@ -21,7 +21,7 @@
>  .\" the suitability of this software for any purpose.  It is
>  .\" provided "as is" without express or implied warranty.
>  .\"
> -.Dd January 31, 2011
> +.Dd February 25, 2011
>  .Dt NEWSYSLOG.CONF 5
>  .Os
>  .Sh NAME
> @@ -349,6 +349,11 @@ If this field is not present, then a
>  .Dv SIGHUP
>  signal will be sent.
>  .El
> +.Sh EXAMPLES
> +The following is an example of the
> +.Dq Aq Li include
> +entry:
> +.Dl " /etc/newsyslog-local.conf"
>  .Sh SEE ALSO
>  .Xr bzip2 1 ,
>  .Xr gzip 1 ,

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219972 - head/bin/ps

2011-03-24 Thread Alexander Best
On Thu Mar 24 11, Edward Tomasz Napierala wrote:
> Author: trasz
> Date: Thu Mar 24 20:15:42 2011
> New Revision: 219972
> URL: http://svn.freebsd.org/changeset/base/219972
> 
> Log:
>   Add proper width calculation for time fields (time, cputime and usertime).
>   This fixes the ugly overflow in "ps aux" output for "[idle]".

nice. maybe you could also take a look at these cases:

1) ps -wlu is not honouring -w
2) ps -lud is not honouring -d
3) ps(1) doesn't mention that -X is the default

cheers.
alex

> 
> Modified:
>   head/bin/ps/extern.h
>   head/bin/ps/keyword.c
>   head/bin/ps/print.c
> 
> Modified: head/bin/ps/extern.h
> ==
> --- head/bin/ps/extern.h  Thu Mar 24 19:50:34 2011(r219971)
> +++ head/bin/ps/extern.h  Thu Mar 24 20:15:42 2011(r219972)
> @@ -74,12 +74,15 @@ void   rgroupname(KINFO *, VARENT *);
>  void  runame(KINFO *, VARENT *);
>  void  rvar(KINFO *, VARENT *);
>  int   s_comm(KINFO *);
> +int   s_cputime(KINFO *);
>  int   s_label(KINFO *);
>  int   s_loginclass(KINFO *);
>  int   s_logname(KINFO *);
>  int   s_rgroupname(KINFO *);
>  int   s_runame(KINFO *);
> +int   s_systime(KINFO *);
>  int   s_uname(KINFO *);
> +int   s_usertime(KINFO *);
>  void  showkey(void);
>  void  started(KINFO *, VARENT *);
>  void  state(KINFO *, VARENT *);
> 
> Modified: head/bin/ps/keyword.c
> ==
> --- head/bin/ps/keyword.c Thu Mar 24 19:50:34 2011(r219971)
> +++ head/bin/ps/keyword.c Thu Mar 24 20:15:42 2011(r219972)
> @@ -189,12 +189,14 @@ static VAR var[] = {
>   UINT, UIDFMT, 0},
>   {"svuid", "SVUID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_svuid),
>   UINT, UIDFMT, 0},
> - {"systime", "SYSTIME", NULL, USER, systime, NULL, 9, 0, CHAR, NULL, 0},
> + {"systime", "SYSTIME", NULL, USER|DSIZ, systime, s_systime, 15, 0, CHAR,
> + NULL, 0},
>   {"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2,
>   KOFF(ki_tdaddr), KPTR, "lx", 0},
>   {"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0},
>   {"tdnam", "TDNAM", NULL, LJUST, tdnam, NULL, COMMLEN, 0, CHAR, NULL, 0},
> - {"time", "TIME", NULL, USER, cputime, NULL, 9, 0, CHAR, NULL, 0},
> + {"time", "TIME", NULL, USER|DSIZ, cputime, s_cputime, 15, 0, CHAR,
> + NULL, 0},
>   {"tpgid", "TPGID", NULL, 0, kvar, NULL, 4, KOFF(ki_tpgid), UINT,
>   PIDFMT, 0},
>   {"tsid", "TSID", NULL, 0, kvar, NULL, PIDLEN, KOFF(ki_tsid), UINT,
> @@ -211,8 +213,8 @@ static VAR var[] = {
>   KOFF(ki_paddr), KPTR, "lx", 0},
>   {"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR,
>   NULL, 0},
> - {"usertime", "USERTIME", NULL, USER, usertime, NULL, 9, 0, CHAR, NULL,
> - 0},
> + {"usertime", "USERTIME", NULL, USER|DSIZ, usertime, s_usertime, 15, 0,
> + CHAR, NULL, 0},
>   {"usrpri", "", "upr", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
>   {"vsize", "", "vsz", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
>   {"vsz", "VSZ", NULL, 0, vsize, NULL, 6, 0, CHAR, NULL, 0},
> 
> Modified: head/bin/ps/print.c
> ==
> --- head/bin/ps/print.c   Thu Mar 24 19:50:34 2011(r219971)
> +++ head/bin/ps/print.c   Thu Mar 24 20:15:42 2011(r219972)
> @@ -570,11 +570,20 @@ printtime(KINFO *k, VARENT *ve, long sec
>   secs += psecs / 100;
>   psecs = psecs % 100;
>   }
> - (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld",
> + (void)snprintf(obuff, sizeof(obuff), "%ld:%02ld%c%02ld",
>   secs / 60, secs % 60, decimal_point, psecs);
>   (void)printf("%*s", v->width, obuff);
>  }
>  
> +static int
> +sizetime(long secs)
> +{
> +
> + if (secs < 60)
> + return (7);
> + return (log10(secs / 60) + 7);
> +}
> +
>  void
>  cputime(KINFO *k, VARENT *ve)
>  {
> @@ -930,6 +939,17 @@ s_comm(KINFO *k)
>  }
>  
>  int
> +s_cputime(KINFO *k)
> +{
> + long secs;
> +
> + secs = k->ki_p->ki_runtime / 100;
> + if (sumrusage)
> + secs += k->ki_p->ki_childtime.tv_sec;
> + return (sizetime(secs));
> +}
> +
> +int
>  s_label(KINFO *k)
>  {
>   char *string = NULL;
> @@ -975,3 +995,25 @@ s_logname(KINFO *k)
>  
>   return (strlen(s));
>  }
> +
> +int
> +s_systime(KINFO *k)
> +{
> + long secs;
> +
> + secs = k->ki_p->ki_rusage.ru_stime.tv_sec;
> + if (sumrusage)
> + secs += k->ki_p->ki_childstime.tv_sec;
> + return (sizetime(secs));
> +}
> +
> +int
> +s_usertime(KINFO *k)
> +{
> + long secs;
> +
> + secs = k->ki_p->ki_rusage.ru_utime.tv_sec;
> + if (sumrusage)
> + secs += k->ki_p->ki_childutime.tv_sec;
> + return (sizetime(secs));
> +}

-- 
a13x

Re: svn commit: r219939 - head/lib/libutil

2011-03-24 Thread Alexander Best
On Wed Mar 23 11, Xin LI wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> On 03/23/11 17:29, Alexander Best wrote:
> > On Wed Mar 23 11, Xin LI wrote:
> >> Author: delphij
> >> Date: Wed Mar 23 22:08:01 2011
> >> New Revision: 219939
> >> URL: http://svn.freebsd.org/changeset/base/219939
> >>
> >> Log:
> >>   humanize_number(3) multiply the input number by 100, which could cause an
> >>   integer overflow when the input is very large (for example, 100 Pi would
> >>   become about 10 Ei which exceeded signed int64_t).
> > 
> > i think we should also change the humanize_number(3) manual page 
> > accordingly.
> > here's a rough draft (date not bumped, yet).
> 
> I think matching the variables within source code would not be necessary
> - -- I think it's much more clear to the reader of the manual page when
> the parameter called "number" and not "quotient" when the function is
> called "humanize_number".
> 
> I am not sure about the CAVEATS part though, to me, it's kinda obvious
> since a parameter of signed int64_t can represent only a maximum number
> of INT64_MAX and a minimum number of INT64_MIN, and I think we don't
> document these explicitly for other manual pages.  Personally I am
> inclined not to document this as limitation at all but would not object
> doing so.

those are very good arguments. you have me convinced. let's keep the manual the
way it is. more so i think both your assumptions are very well suited to become
a style(9) entry.

i've also thought about the difference between the base 2 and base 10 values.
according to the official docs we should refer to base 2 values as Ki, Mi, etc.
however i don't hink this is implementable, since too much code would need to
be changed. the actual problem i see is that from the output of df(1) e.g. one
cannot know if base 2 or base 10 is implied.

cheers.
alex

> 
> Cheers,
> - -- 
> Xin LI   http://www.delphij.net/
> FreeBSD - The Power to Serve!Live free or die
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (FreeBSD)
> 
> iQEcBAEBCAAGBQJNip8CAAoJEATO+BI/yjfBz3YH/3YDlfvf8Bty6NeBnk3CyxjE
> skeaowGWIG5/gQ73zXfc1KTBEr5CobNLZWxuvGnXGCfMdATypRQR+5yQt366tQNK
> oDvd60tMofztH6rtrBt9b/td2mIoQAfX9Mc0X9ri69LgkExXVQBxqAcxkYxVadGm
> r+nAkhZjpaHdz20eDXbQg7wDXd3iGEBYx1wagMIBLtVeJL0GFKABXIHiZfbcBU9S
> tZNlXpeF3SXqOIql9KEeJ9+Zq8neU2sE7J1y3Jph4j8kkN39CABzNNKUHH7KLl7/
> mD9mPKxILulDMkropntEU3G7uE2Y1Ax9o7PcjMbd509/bpzZK2SP4t28VSQg1/8=
> =ODAn
> -END PGP SIGNATURE-

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219939 - head/lib/libutil

2011-03-23 Thread Alexander Best
On Wed Mar 23 11, Xin LI wrote:
> Author: delphij
> Date: Wed Mar 23 22:08:01 2011
> New Revision: 219939
> URL: http://svn.freebsd.org/changeset/base/219939
> 
> Log:
>   humanize_number(3) multiply the input number by 100, which could cause an
>   integer overflow when the input is very large (for example, 100 Pi would
>   become about 10 Ei which exceeded signed int64_t).

i think we should also change the humanize_number(3) manual page accordingly.
here's a rough draft (date not bumped, yet).

>   
>   Solve this issue by splitting the division into two parts and avoid the
>   multiplication.
>   
>   PR: bin/146205
>   Reviewed by:arundel
>   MFC after:  1 month
> 
> Modified:
>   head/lib/libutil/humanize_number.c
> 
> Modified: head/lib/libutil/humanize_number.c
> ==
> --- head/lib/libutil/humanize_number.cWed Mar 23 22:06:09 2011
> (r219938)
> +++ head/lib/libutil/humanize_number.cWed Mar 23 22:08:01 2011
> (r219939)
> @@ -43,11 +43,11 @@ __FBSDID("$FreeBSD$");
>  #include 
>  
>  int
> -humanize_number(char *buf, size_t len, int64_t bytes,
> +humanize_number(char *buf, size_t len, int64_t quotient,
>  const char *suffix, int scale, int flags)
>  {
>   const char *prefixes, *sep;
> - int b, i, r, maxscale, s1, s2, sign;
> + int i, r, remainder, maxscale, s1, s2, sign;
>   int64_t divisor, max;
>   size_t  baselen;
>  
> @@ -55,6 +55,8 @@ humanize_number(char *buf, size_t len, i
>   assert(suffix != NULL);
>   assert(scale >= 0);
>  
> + remainder = 0;
> +
>   if (flags & HN_DIVISOR_1000) {
>   /* SI for decimal multiplies */
>   divisor = 1000;
> @@ -86,13 +88,12 @@ humanize_number(char *buf, size_t len, i
>  
>   if (len > 0)
>   buf[0] = '\0';
> - if (bytes < 0) {
> + if (quotient < 0) {
>   sign = -1;
> - bytes *= -100;
> + quotient = -quotient;
>   baselen = 3;/* sign, digit, prefix */
>   } else {
>   sign = 1;
> - bytes *= 100;
>   baselen = 2;/* digit, prefix */
>   }
>   if (flags & HN_NOSPACE)
> @@ -109,7 +110,7 @@ humanize_number(char *buf, size_t len, i
>  
>   if (scale & (HN_AUTOSCALE | HN_GETSCALE)) {
>   /* See if there is additional columns can be used. */
> - for (max = 100, i = len - baselen; i-- > 0;)
> + for (max = 1, i = len - baselen; i-- > 0;)
>   max *= 10;
>  
>   /*
> @@ -117,30 +118,37 @@ humanize_number(char *buf, size_t len, i
>* If there will be an overflow by the rounding below,
>* divide once more.
>*/
> - for (i = 0; bytes >= max - 50 && i < maxscale; i++)
> - bytes /= divisor;
> + for (i = 0;
> + (quotient >= max || (quotient == max - 1 && remainder >= 
> 950)) &&
> + i < maxscale; i++) {
> + remainder = quotient % divisor;
> + quotient /= divisor;
> + }
>  
>   if (scale & HN_GETSCALE)
>   return (i);
> - } else
> - for (i = 0; i < scale && i < maxscale; i++)
> - bytes /= divisor;
> + } else {
> + for (i = 0; i < scale && i < maxscale; i++) {
> + remainder = quotient % divisor;
> + quotient /= divisor;
> + }
> + }
>  
>   /* If a value <= 9.9 after rounding and ... */
> - if (bytes < 995 && i > 0 && flags & HN_DECIMAL) {
> + if (quotient <= 9 && remainder < 950 && i > 0 && flags & HN_DECIMAL) {
>   /* baselen + \0 + .N */
>   if (len < baselen + 1 + 2)
>   return (-1);
> - b = ((int)bytes + 5) / 10;
> - s1 = b / 10;
> - s2 = b % 10;
> + s1 = (int)quotient + ((remainder + 50) / 1000);
> + s2 = ((remainder + 50) / 100) % 10;
>   r = snprintf(buf, len, "%d%s%d%s%s%s",
>   sign * s1, localeconv()->decimal_point, s2,
>   sep, SCALE2PREFIX(i), suffix);
>   } else
>   r = snprintf(buf, len, "%" PRId64 "%s%s%s",
> - sign * ((bytes + 50) / 100),
> + sign * (quotient + (remainder + 50) / 1000),
>   sep, SCALE2PREFIX(i), suffix);
>  
>   return (r);
>  }
> +

-- 
a13x
diff --git a/lib/libutil/humanize_number.3 b/lib/libutil/humanize_number.3
index 82925ba..8741e23 100644
--- a/lib/libutil/humanize_number.3
+++ b/lib/libutil/humanize_number.3
@@ -40,14 +40,14 @@
 .In libutil.h
 .Ft int
 .Fo humanize_number
-.Fa "char *buf" "size_t len" "int64_t number" "const char *suffix"
+.Fa "char *buf" "size_t len" "int64_t quotient" "const char *suff

Re: svn commit: r219702 - head/sys/boot/i386/common

2011-03-16 Thread Alexander Best
On Wed Mar 16 11, Andrey V. Elsukov wrote:
> Author: ae
> Date: Wed Mar 16 20:04:56 2011
> New Revision: 219702
> URL: http://svn.freebsd.org/changeset/base/219702
> 
> Log:
>   Set control flags in putc(). This should fix zfsboot hangs in drvread().

i was looking at xputc() and putchar() and was wondering why these are two
seperate functions? their funcionality can very easily be merged into a single
one.

cheers.
alex

>   
>   PR: kern/153552
>   Reviewed by:jhb
>   MFC after:  1 week
> 
> Modified:
>   head/sys/boot/i386/common/cons.c
> 
> Modified: head/sys/boot/i386/common/cons.c
> ==
> --- head/sys/boot/i386/common/cons.c  Wed Mar 16 17:09:51 2011
> (r219701)
> +++ head/sys/boot/i386/common/cons.c  Wed Mar 16 20:04:56 2011
> (r219702)
> @@ -37,6 +37,7 @@ void
>  putc(int c)
>  {
>  
> + v86.ctl = V86_FLAGS;
>   v86.addr = 0x10;
>   v86.eax = 0xe00 | (c & 0xff);
>   v86.ebx = 0x7;

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219680 - in head/bin: ln rm test

2011-03-15 Thread Alexander Best
On Tue Mar 15 11, Jilles Tjoelker wrote:
> Author: jilles
> Date: Tue Mar 15 22:22:11 2011
> New Revision: 219680
> URL: http://svn.freebsd.org/changeset/base/219680
> 
> Log:
>   bin: Prefer strrchr() to rindex().

shouldn't the rindex(3) manual contain a note regarding it's depricated nature
and the fact that strchr(3) is preferred?

cheers.
alex

>   
>   This removes the last index/rindex usage from /bin.
> 
> Modified:
>   head/bin/ln/ln.c
>   head/bin/rm/rm.c
>   head/bin/test/test.c
> 
> Modified: head/bin/ln/ln.c
> ==
> --- head/bin/ln/ln.c  Tue Mar 15 21:45:10 2011(r219679)
> +++ head/bin/ln/ln.c  Tue Mar 15 22:22:11 2011(r219680)
> @@ -80,7 +80,7 @@ main(int argc, char *argv[])
>* "link", for which the functionality provided is greatly
>* simplified.
>*/
> - if ((p = rindex(argv[0], '/')) == NULL)
> + if ((p = strrchr(argv[0], '/')) == NULL)
>   p = argv[0];
>   else
>   ++p;
> 
> Modified: head/bin/rm/rm.c
> ==
> --- head/bin/rm/rm.c  Tue Mar 15 21:45:10 2011(r219679)
> +++ head/bin/rm/rm.c  Tue Mar 15 22:22:11 2011(r219680)
> @@ -90,7 +90,7 @@ main(int argc, char *argv[])
>* "unlink", for which the functionality provided is greatly
>* simplified.
>*/
> - if ((p = rindex(argv[0], '/')) == NULL)
> + if ((p = strrchr(argv[0], '/')) == NULL)
>   p = argv[0];
>   else
>   ++p;
> 
> Modified: head/bin/test/test.c
> ==
> --- head/bin/test/test.c  Tue Mar 15 21:45:10 2011(r219679)
> +++ head/bin/test/test.c  Tue Mar 15 22:22:11 2011(r219680)
> @@ -194,7 +194,7 @@ main(int argc, char **argv)
>   int res;
>   char*p;
>  
> - if ((p = rindex(argv[0], '/')) == NULL)
> + if ((p = strrchr(argv[0], '/')) == NULL)
>   p = argv[0];
>   else
>   p++;

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219483 - head/sys/boot/i386/gptboot

2011-03-12 Thread Alexander Best
On Fri Mar 11 11, John Baldwin wrote:
> Author: jhb
> Date: Fri Mar 11 13:11:15 2011
> New Revision: 219483
> URL: http://svn.freebsd.org/changeset/base/219483
> 
> Log:
>   Remove all object files during 'make clean'.

thanks. :)

>   
>   PR: kern/154888
>   Submitted by:   arundel
>   MFC after:  1 week
> 
> Modified:
>   head/sys/boot/i386/gptboot/Makefile
> 
> Modified: head/sys/boot/i386/gptboot/Makefile
> ==
> --- head/sys/boot/i386/gptboot/Makefile   Fri Mar 11 12:12:35 2011
> (r219482)
> +++ head/sys/boot/i386/gptboot/Makefile   Fri Mar 11 13:11:15 2011
> (r219483)
> @@ -65,7 +65,8 @@ gptldr.bin: gptldr.out
>  gptldr.out: gptldr.o
>   ${LD} ${LDFLAGS} -e start -Ttext ${ORG1} -o ${.TARGET} gptldr.o
>  
> -CLEANFILES+= gptboot.bin gptboot.out gptboot.o sio.o ufsread.o
> +CLEANFILES+= gptboot.bin gptboot.out gptboot.o sio.o gpt.o crc32.o drv.o \
> + cons.o util.o
>  
>  gptboot.bin: gptboot.out
>   objcopy -S -O binary gptboot.out ${.TARGET}

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219376 - in head/share: examples/etc mk

2011-03-07 Thread Alexander Best
On Mon Mar  7 11, Martin Matuska wrote:
> Author: mm
> Date: Mon Mar  7 14:58:23 2011
> New Revision: 219376
> URL: http://svn.freebsd.org/changeset/base/219376
> 
> Log:
>   Add AMD Geode CPU type to bsd.cpu.mk and examples/etc/make.conf
>   For CPUTYPE=core2 use -march=core2

maybe you might also want to add a note to UPDATING. apparently there are
still people (see freebsd-current@) who have CPUTYPE?=core2 in their make.conf
and rely on fbsd overwritting it to nocona. trying to build a kernel with this
commit will no longer do that and thus gcc complains about core2.

the best strategie might be:
1) set CPUTYPE?=native
2) build world
3) build kernel; install kernel
4) install world
5) set CPUTYPE?=core2 again

cheers.
alex

>   
>   PR: gnu/155308
>   MFC after:  2 weeks
> 
> Modified:
>   head/share/examples/etc/make.conf
>   head/share/mk/bsd.cpu.mk
> 
> Modified: head/share/examples/etc/make.conf
> ==
> --- head/share/examples/etc/make.conf Mon Mar  7 14:54:45 2011
> (r219375)
> +++ head/share/examples/etc/make.conf Mon Mar  7 14:58:23 2011
> (r219376)
> @@ -32,7 +32,7 @@
>  #   Intel x86 architecture:
>  #   (AMD CPUs)   opteron-sse3 opteron athlon64-sse3 athlon64 athlon-mp
>  #athlon-xp athlon-4 athlon-tbird athlon k8-sse3 k8
> -#k6-3 k6-2 k6 k5
> +#geode k6-3 k6-2 k6 k5
>  #   (Intel CPUs) core2 core nocona pentium4m pentium4 prescott
>  #pentium3m pentium3 pentium-m pentium2
>  #pentiumpro pentium-mmx pentium i486 i386
> 
> Modified: head/share/mk/bsd.cpu.mk
> ==
> --- head/share/mk/bsd.cpu.mk  Mon Mar  7 14:54:45 2011(r219375)
> +++ head/share/mk/bsd.cpu.mk  Mon Mar  7 14:58:23 2011(r219376)
> @@ -59,7 +59,7 @@ CPUTYPE = athlon-mp
>  CPUTYPE = athlon
>  .  endif
>  . elif ${MACHINE_CPUARCH} == "amd64"
> -.  if ${CPUTYPE} == "prescott" || ${CPUTYPE} == "core2"
> +.  if ${CPUTYPE} == "prescott"
>  CPUTYPE = nocona
>  .  endif
>  . elif ${MACHINE_ARCH} == "sparc64"
> @@ -170,7 +170,7 @@ MACHINE_CPU = athlon-xp athlon k7 3dnow 
>  MACHINE_CPU = athlon-xp athlon k7 3dnow sse mmx k6 k5 i586 i486 i386
>  .  elif ${CPUTYPE} == "athlon" || ${CPUTYPE} == "athlon-tbird"
>  MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
> -.  elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2"
> +.  elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "geode"
>  MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
>  .  elif ${CPUTYPE} == "k6"
>  MACHINE_CPU = mmx k6 k5 i586 i486 i386
> @@ -206,7 +206,7 @@ MACHINE_CPU = i386
>  MACHINE_CPU = k8 3dnow sse3
>  .  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == 
> "k8"
>  MACHINE_CPU = k8 3dnow
> -.  elif ${CPUTYPE} == "nocona"
> +.  elif ${CPUTYPE} == "nocona" || ${CPUTYPE} == "core2"
>  MACHINE_CPU = sse3
>  .  endif
>  MACHINE_CPU += amd64 sse2 sse mmx

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r219376 - in head/share: examples/etc mk

2011-03-07 Thread Alexander Best
On Mon Mar  7 11, Martin Matuska wrote:
> Author: mm
> Date: Mon Mar  7 14:58:23 2011
> New Revision: 219376
> URL: http://svn.freebsd.org/changeset/base/219376
> 
> Log:
>   Add AMD Geode CPU type to bsd.cpu.mk and examples/etc/make.conf
>   For CPUTYPE=core2 use -march=core2

very cool. never thought core2 support would be coming. :) any plans for
-march=native? for me it works, but apparently there are some users which
claim native doesn't always chose the correct -m{tune,arch} setting [1].

maybe something like

.if ${CPUTYPE} == "native"
.error "bla bla don't do that"
.endif

would be a nice idea. however the PR was with a geode cpu, so this might in
fact has been fixed in this (or recent gcc) commit. any chance you could test

touch hello.c && gcc -march=native -### hello.c

on a system with a geode cpu and see, if -m{tune,arch}=geode gets chosen?

cheers.
alex

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/146716

>   
>   PR: gnu/155308
>   MFC after:  2 weeks
> 
> Modified:
>   head/share/examples/etc/make.conf
>   head/share/mk/bsd.cpu.mk
> 
> Modified: head/share/examples/etc/make.conf
> ==
> --- head/share/examples/etc/make.conf Mon Mar  7 14:54:45 2011
> (r219375)
> +++ head/share/examples/etc/make.conf Mon Mar  7 14:58:23 2011
> (r219376)
> @@ -32,7 +32,7 @@
>  #   Intel x86 architecture:
>  #   (AMD CPUs)   opteron-sse3 opteron athlon64-sse3 athlon64 athlon-mp
>  #athlon-xp athlon-4 athlon-tbird athlon k8-sse3 k8
> -#k6-3 k6-2 k6 k5
> +#geode k6-3 k6-2 k6 k5
>  #   (Intel CPUs) core2 core nocona pentium4m pentium4 prescott
>  #pentium3m pentium3 pentium-m pentium2
>  #pentiumpro pentium-mmx pentium i486 i386
> 
> Modified: head/share/mk/bsd.cpu.mk
> ==
> --- head/share/mk/bsd.cpu.mk  Mon Mar  7 14:54:45 2011(r219375)
> +++ head/share/mk/bsd.cpu.mk  Mon Mar  7 14:58:23 2011(r219376)
> @@ -59,7 +59,7 @@ CPUTYPE = athlon-mp
>  CPUTYPE = athlon
>  .  endif
>  . elif ${MACHINE_CPUARCH} == "amd64"
> -.  if ${CPUTYPE} == "prescott" || ${CPUTYPE} == "core2"
> +.  if ${CPUTYPE} == "prescott"
>  CPUTYPE = nocona
>  .  endif
>  . elif ${MACHINE_ARCH} == "sparc64"
> @@ -170,7 +170,7 @@ MACHINE_CPU = athlon-xp athlon k7 3dnow 
>  MACHINE_CPU = athlon-xp athlon k7 3dnow sse mmx k6 k5 i586 i486 i386
>  .  elif ${CPUTYPE} == "athlon" || ${CPUTYPE} == "athlon-tbird"
>  MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
> -.  elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2"
> +.  elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "geode"
>  MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
>  .  elif ${CPUTYPE} == "k6"
>  MACHINE_CPU = mmx k6 k5 i586 i486 i386
> @@ -206,7 +206,7 @@ MACHINE_CPU = i386
>  MACHINE_CPU = k8 3dnow sse3
>  .  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == 
> "k8"
>  MACHINE_CPU = k8 3dnow
> -.  elif ${CPUTYPE} == "nocona"
> +.  elif ${CPUTYPE} == "nocona" || ${CPUTYPE} == "core2"
>  MACHINE_CPU = sse3
>  .  endif
>  MACHINE_CPU += amd64 sse2 sse mmx

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218967 - head/sys/kern

2011-02-23 Thread Alexander Best
On Thu Feb 24 11, Bruce Evans wrote:
> On Wed, 23 Feb 2011, Alexander Best wrote:
> 
> >On Wed Feb 23 11, Kostik Belousov wrote:
> >>On Wed, Feb 23, 2011 at 12:56:25PM +, John Baldwin wrote:
> >>>...
> >>>Log:
> >>>  Fix off-by-one error in check against max_threads_per_proc.
> >>>
> >>>  Submitted by:arundel
> >>>  MFC after:   1 week
> >>>
> >>>Modified:
> >>>  head/sys/kern/kern_thr.c
> >>>
> >>>Modified: head/sys/kern/kern_thr.c
> >>>==
> >>>--- head/sys/kern/kern_thr.c   Wed Feb 23 10:28:37 2011 (r218966)
> >>>+++ head/sys/kern/kern_thr.c   Wed Feb 23 12:56:25 2011 (r218967)
> >>>@@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontex
> >>>   p = td->td_proc;
> >>>
> >>>   /* Have race condition but it is cheap. */
> >>>-  if (p->p_numthreads >= max_threads_per_proc) {
> >>>+  if (p->p_numthreads > max_threads_per_proc) {
> >>>   ++max_threads_hits;
> >>>   return (EPROCLIM);
> >>>   }
> >>
> >>I do not think there was off by one error. The create_thread() function
> >>is called to create new thread, and before the process thread counter
> >>is incremented in thread_link(). The old test tried to not allow more
> >>then max_threads_per_proc threads in a process, now it allows to
> >>create max_threads_per_proc.
> 
> Actually, now it allows to create 1 more than max_threads_per_proc threads
> in a process.
> 
> >doesn't the semantics of the term "maximum" imply that it's own value is 
> >also
> >valid?
> 
> Yes.  Not 1 more.

the misconception on my side was that i thought a process had an initial thread
count of zero. however since a process itself counts as a single thread and has
a thread id, it's now obvious to me that with max_threads_per_proc=15000 a
process should only be allowed to spawn 14999 new threads.

thanks for clearing things up for the n3wb. ;)

cheers.
alex

> 
> >if a sign says maximum weight 2000kg, does that mean that a weight of 
> >2000kg is
> >invalid and the highest valid weight is 1999,999..kg?
> 
> No.  This means that if weights are always in units of kg, and are 
> represented
> by indexes starting at index 0, then the highest valid index is 1999.  But
> if the index is a count of the number of kg's, then the highest valud index
> is 2000.
> 
> p->p_numthreads presumably matches its name, so it is a count of a number
> of threads and not a thread number.
> 
> Bruce

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218967 - head/sys/kern

2011-02-23 Thread Alexander Best
On Wed Feb 23 11, Hans Petter Selasky wrote:
> On Wednesday 23 February 2011 14:57:34 Alexander Best wrote:
> > On Wed Feb 23 11, Kostik Belousov wrote:
> > > On Wed, Feb 23, 2011 at 12:56:25PM +, John Baldwin wrote:
> > > > Author: jhb
> > > > Date: Wed Feb 23 12:56:25 2011
> > > > New Revision: 218967
> > > > URL: http://svn.freebsd.org/changeset/base/218967
> > > > 
> > > > Log:
> > > >   Fix off-by-one error in check against max_threads_per_proc.
> > > >   
> > > >   Submitted by: arundel
> > > >   MFC after:1 week
> > > > 
> > > > Modified:
> > > >   head/sys/kern/kern_thr.c
> > > > 
> > > > Modified: head/sys/kern/kern_thr.c
> > > > ===
> > > > === --- head/sys/kern/kern_thr.cWed Feb 23 10:28:37 2011
> (r218966)
> > > > +++ head/sys/kern/kern_thr.cWed Feb 23 12:56:25 2011
> > > > (r218967) @@
> > > > -153,7 +153,7 @@ create_thread(struct thread *td, mcontex
> > > > 
> > > > p = td->td_proc;
> > > > 
> > > > /* Have race condition but it is cheap. */
> > > > 
> > > > -   if (p->p_numthreads >= max_threads_per_proc) {
> > > > +   if (p->p_numthreads > max_threads_per_proc) {
> > > > 
> > > > ++max_threads_hits;
> > > > return (EPROCLIM);
> > > > 
> > > > }
> > > 
> > > I do not think there was off by one error. The create_thread() function
> > > is called to create new thread, and before the process thread counter
> > > is incremented in thread_link(). The old test tried to not allow more
> > > then max_threads_per_proc threads in a process, now it allows to
> > > create max_threads_per_proc.
> > 
> > doesn't the semantics of the term "maximum" imply that it's own value is
> > also valid?
> > 
> > if a sign says maximum weight 2000kg, does that mean that a weight of
> > 2000kg is invalid and the highest valid weight is 1999,999..kg?
> 
> Hi,
> 
> The sign should have used terms like EQ and GTE and LTE and a granularity.  
> Obviously not all people writing important numerical information are 
> programmers ;-)

*hehehe* well they don't (at least in this country):

http://upload.wikimedia.org/wikipedia/commons/9/94/Zeichen_262.svg

this sign includes the maximum of 5500kg and thus implies GT.

cheers.
alex

> 
> --HPS

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218967 - head/sys/kern

2011-02-23 Thread Alexander Best
On Wed Feb 23 11, Kostik Belousov wrote:
> On Wed, Feb 23, 2011 at 01:57:34PM +0000, Alexander Best wrote:
> > On Wed Feb 23 11, Kostik Belousov wrote:
> > > On Wed, Feb 23, 2011 at 12:56:25PM +, John Baldwin wrote:
> > > > Author: jhb
> > > > Date: Wed Feb 23 12:56:25 2011
> > > > New Revision: 218967
> > > > URL: http://svn.freebsd.org/changeset/base/218967
> > > > 
> > > > Log:
> > > >   Fix off-by-one error in check against max_threads_per_proc.
> > > >   
> > > >   Submitted by: arundel
> > > >   MFC after:1 week
> > > > 
> > > > Modified:
> > > >   head/sys/kern/kern_thr.c
> > > > 
> > > > Modified: head/sys/kern/kern_thr.c
> > > > ==
> > > > --- head/sys/kern/kern_thr.cWed Feb 23 10:28:37 2011
> > > > (r218966)
> > > > +++ head/sys/kern/kern_thr.cWed Feb 23 12:56:25 2011
> > > > (r218967)
> > > > @@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontex
> > > > p = td->td_proc;
> > > >  
> > > > /* Have race condition but it is cheap. */
> > > > -   if (p->p_numthreads >= max_threads_per_proc) {
> > > > +   if (p->p_numthreads > max_threads_per_proc) {
> > > > ++max_threads_hits;
> > > > return (EPROCLIM);
> > > > }
> > > 
> > > I do not think there was off by one error. The create_thread() function
> > > is called to create new thread, and before the process thread counter
> > > is incremented in thread_link(). The old test tried to not allow more
> > > then max_threads_per_proc threads in a process, now it allows to
> > > create max_threads_per_proc.
> > 
> > doesn't the semantics of the term "maximum" imply that it's own value is 
> > also
> > valid?
> > 
> > if a sign says maximum weight 2000kg, does that mean that a weight of 
> > 2000kg is
> > invalid and the highest valid weight is 1999,999..kg?
> > 
> > cheers.
> > alex
> > 
> > > 
> > > My guess is that the reference to mentioned pthread_vfork_test failed
> > > because reporter set kern.threads.max_threads_per_proc to 100. The
> > > test actually tries to create 101 threads, 1 main + 100 new.
> > 
> > so the main process counts as 1 thread and for each pthread_create
> > invokation the thread number gets bumped up?
> >
> > so with a process doing a single pthread_create() that would imply
> > this process is having a thread count of 2?
> 
> Exactly. The main thread is the same as all others (almost).

thanks for the hint. i wasn't aware of that. however now proctsta -akk also
displaying a thread id for a process with no additional threads makes a lot
more sense. ;)

so in theory:
kern.threads.max_threads_per_proc=0 and kern.threads.max_threads_per_proc=1
both forbid a process to trigger any new threads.

cheers.
alex

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218967 - head/sys/kern

2011-02-23 Thread Alexander Best
On Wed Feb 23 11, Kostik Belousov wrote:
> On Wed, Feb 23, 2011 at 12:56:25PM +, John Baldwin wrote:
> > Author: jhb
> > Date: Wed Feb 23 12:56:25 2011
> > New Revision: 218967
> > URL: http://svn.freebsd.org/changeset/base/218967
> > 
> > Log:
> >   Fix off-by-one error in check against max_threads_per_proc.
> >   
> >   Submitted by: arundel
> >   MFC after:1 week
> > 
> > Modified:
> >   head/sys/kern/kern_thr.c
> > 
> > Modified: head/sys/kern/kern_thr.c
> > ==
> > --- head/sys/kern/kern_thr.cWed Feb 23 10:28:37 2011
> > (r218966)
> > +++ head/sys/kern/kern_thr.cWed Feb 23 12:56:25 2011
> > (r218967)
> > @@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontex
> > p = td->td_proc;
> >  
> > /* Have race condition but it is cheap. */
> > -   if (p->p_numthreads >= max_threads_per_proc) {
> > +   if (p->p_numthreads > max_threads_per_proc) {
> > ++max_threads_hits;
> > return (EPROCLIM);
> > }
> 
> I do not think there was off by one error. The create_thread() function
> is called to create new thread, and before the process thread counter
> is incremented in thread_link(). The old test tried to not allow more
> then max_threads_per_proc threads in a process, now it allows to
> create max_threads_per_proc.

doesn't the semantics of the term "maximum" imply that it's own value is also
valid?

if a sign says maximum weight 2000kg, does that mean that a weight of 2000kg is
invalid and the highest valid weight is 1999,999..kg?

cheers.
alex

> 
> My guess is that the reference to mentioned pthread_vfork_test failed
> because reporter set kern.threads.max_threads_per_proc to 100. The
> test actually tries to create 101 threads, 1 main + 100 new.

so the main process counts as 1 thread and for each pthread_create invokation
the thread number gets bumped up?

so with a process doing a single pthread_create() that would imply this process
is having a thread count of 2?

cheers.
alex

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218967 - head/sys/kern

2011-02-23 Thread Alexander Best
On Wed Feb 23 11, John Baldwin wrote:
> Author: jhb
> Date: Wed Feb 23 12:56:25 2011
> New Revision: 218967
> URL: http://svn.freebsd.org/changeset/base/218967
> 
> Log:
>   Fix off-by-one error in check against max_threads_per_proc.

thanks a lot. :)

>   
>   Submitted by:   arundel
>   MFC after:  1 week
> 
> Modified:
>   head/sys/kern/kern_thr.c
> 
> Modified: head/sys/kern/kern_thr.c
> ==
> --- head/sys/kern/kern_thr.c  Wed Feb 23 10:28:37 2011(r218966)
> +++ head/sys/kern/kern_thr.c  Wed Feb 23 12:56:25 2011(r218967)
> @@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontex
>   p = td->td_proc;
>  
>   /* Have race condition but it is cheap. */
> - if (p->p_numthreads >= max_threads_per_proc) {
> + if (p->p_numthreads > max_threads_per_proc) {
>   ++max_threads_hits;
>   return (EPROCLIM);
>   }

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218940 - in head: tools usr.bin/xinstall

2011-02-22 Thread Alexander Best
On Tue Feb 22 11, Ulrich Spoerlein wrote:
> Author: uqs
> Date: Tue Feb 22 08:07:17 2011
> New Revision: 218940
> URL: http://svn.freebsd.org/changeset/base/218940
> 
> Log:
>   Teach tools/install.sh the -d directory mode.
>   
>   Sync up with flags understood by install(1) [1], and make install(1)'s
>   usage output not hide the clearly documented -M flag.

thanks a lot. i'd also like to mention that a first draft of this patch was
hacked up by Eygene Ryabinkin. so credits to him too. :)

>   
>   PR: misc/154739 [1]
>   Submitted by:   arundel
> 
> Modified:
>   head/tools/install.sh
>   head/usr.bin/xinstall/xinstall.c
> 
> Modified: head/tools/install.sh
> ==
> --- head/tools/install.sh Tue Feb 22 07:49:51 2011(r218939)
> +++ head/tools/install.sh Tue Feb 22 08:07:17 2011(r218940)
> @@ -29,14 +29,30 @@
>  # $FreeBSD$
>  
>  # parse install's options and ignore them completely.
> +dirmode=""
>  while [ $# -gt 0 ]; do
>  case $1 in
> --[bCcMpSs]) shift;;
> +-d) dirmode="YES"; shift;;
> +-[bCcMpSsv]) shift;;
>  -[Bfgmo]) shift; shift;;
>  -[Bfgmo]*) shift;;
>  *) break;
>  esac
>  done
>  
> +if [ "$#" -eq 0 ]; then
> + echo "$0: no files/dirs specified" >&2
> + exit 1
> +fi
> +
> +if [ -z "$dirmode" ] && [ "$#" -lt 2 ]; then
> + echo "$0: no target specified" >&2
> + exit 1
> +fi
> +
>  # the remaining arguments are assumed to be files/dirs only.
> -exec install -p $*
> +if [ -z "$dirmode" ]; then
> + exec install -p "$@"
> +else
> + exec install -d "$@"
> +fi
> 
> Modified: head/usr.bin/xinstall/xinstall.c
> ==
> --- head/usr.bin/xinstall/xinstall.c  Tue Feb 22 07:49:51 2011
> (r218939)
> +++ head/usr.bin/xinstall/xinstall.c  Tue Feb 22 08:07:17 2011
> (r218940)
> @@ -769,9 +769,9 @@ static void
>  usage(void)
>  {
>   (void)fprintf(stderr,
> -"usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]\n"
> +"usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]\n"
>  "   [-o owner] file1 file2\n"
> -"   install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]\n"
> +"   install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]\n"
>  "   [-o owner] file1 ... fileN directory\n"
>  "   install -d [-v] [-g group] [-m mode] [-o owner] directory ...\n");
>   exit(EX_USAGE);

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218896 - in head/share: examples/etc mk

2011-02-20 Thread Alexander Best
On Sun Feb 20 11, Martin Matuska wrote:
> Author: mm
> Date: Sun Feb 20 22:32:21 2011
> New Revision: 218896
> URL: http://svn.freebsd.org/changeset/base/218896
> 
> Log:
>   Add opteron-sse3, athlon64-sse3 and k8-sse3 cpu types to bsd.cpu.mk.
>   - add "sse3" to MACHINE_CPU for the new cpu types
>   - for i386, default to CPUTYPE=prescott for the new cpu types

any thoughts regarding these clang specific changes? i think it will be nice to
pass newer CPUTYPEs to clang, yet this will break gnu/lib/libobjc and
sys/boot/{i386,pc98}/boot2, which always get built with gcc.

cheers.
alex

>   
>   PR: gnu/154906
>   Discussed with: kib, kan, dim
>   MFC after:  2 weeks
> 
> Modified:
>   head/share/examples/etc/make.conf
>   head/share/mk/bsd.cpu.mk
> 
> Modified: head/share/examples/etc/make.conf
> ==
> --- head/share/examples/etc/make.conf Sun Feb 20 22:25:23 2011
> (r218895)
> +++ head/share/examples/etc/make.conf Sun Feb 20 22:32:21 2011
> (r218896)
> @@ -30,8 +30,9 @@
>  # NO_CPU_CFLAGS variable below.
>  # Currently the following CPU types are recognized:
>  #   Intel x86 architecture:
> -#   (AMD CPUs)   opteron athlon64 athlon-mp athlon-xp athlon-4
> -#athlon-tbird athlon k8 k6-3 k6-2 k6 k5
> +#   (AMD CPUs)   opteron-sse3 opteron athlon64-sse3 athlon64 athlon-mp
> +#athlon-xp athlon-4 athlon-tbird athlon k8-sse3 k8
> +#k6-3 k6-2 k6 k5
>  #   (Intel CPUs) core2 core nocona pentium4m pentium4 prescott
>  #pentium3m pentium3 pentium-m pentium2
>  #pentiumpro pentium-mmx pentium i486 i386
> 
> Modified: head/share/mk/bsd.cpu.mk
> ==
> --- head/share/mk/bsd.cpu.mk  Sun Feb 20 22:25:23 2011(r218895)
> +++ head/share/mk/bsd.cpu.mk  Sun Feb 20 22:32:21 2011(r218896)
> @@ -49,6 +49,9 @@ CPUTYPE = pentiumpro
>  CPUTYPE = pentium-mmx
>  .  elif ${CPUTYPE} == "i586"
>  CPUTYPE = pentium
> +.  elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" || \
> + ${CPUTYPE} == "k8-sse3"
> +CPUTYPE = prescott
>  .  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || \
>   ${CPUTYPE} == "k8"
>  CPUTYPE = athlon-mp
> @@ -158,7 +161,9 @@ _CPUCFLAGS = -mcpu=ultrasparc3
>  # presence of a CPU feature.
>  
>  . if ${MACHINE_CPUARCH} == "i386"
> -.  if ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64"
> +.  if ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3"
> +MACHINE_CPU = athlon-xp athlon k7 3dnow sse3 sse2 sse mmx k6 k5 i586 i486 
> i386
> +.  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64"
>  MACHINE_CPU = athlon-xp athlon k7 3dnow sse2 sse mmx k6 k5 i586 i486 i386
>  .  elif ${CPUTYPE} == "athlon-mp" || ${CPUTYPE} == "athlon-xp" || \
>  ${CPUTYPE} == "athlon-4"
> @@ -197,7 +202,9 @@ MACHINE_CPU = i486 i386
>  MACHINE_CPU = i386
>  .  endif
>  . elif ${MACHINE_CPUARCH} == "amd64"
> -.  if ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == 
> "k8"
> +.  if ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" || 
> ${CPUTYPE} == "k8-sse3"
> +MACHINE_CPU = k8 3dnow sse3
> +.  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == 
> "k8"
>  MACHINE_CPU = k8 3dnow
>  .  elif ${CPUTYPE} == "nocona"
>  MACHINE_CPU = sse3

-- 
a13x
Index: share/mk/sys.mk
===
--- share/mk/sys.mk (revision 218896)
+++ share/mk/sys.mk (working copy)
@@ -355,6 +355,13 @@
 .include "${__MAKE_CONF}"
 .endif
 
+.if !defined(_WITHOUT_SRCCONF)
+SRCCONF?=/etc/src.conf
+.if exists(${SRCCONF})
+.include "${SRCCONF}"
+.endif
+.endif
+
 .if defined(__MAKE_SHELL) && !empty(__MAKE_SHELL)
 SHELL= ${__MAKE_SHELL}
 .SHELL: path=${__MAKE_SHELL}
Index: share/mk/bsd.cpu.mk
===
--- share/mk/bsd.cpu.mk (revision 218896)
+++ share/mk/bsd.cpu.mk (working copy)
@@ -33,10 +33,14 @@
 CPUTYPE = prescott
 .  elif ${CPUTYPE} == "p4"
 CPUTYPE = pentium4
+.  elif ${CPUTYPE} == "p4m" && ${CC:T:Mclang} == "clang"
+CPUTYPE = pentium4
 .  elif ${CPUTYPE} == "p4m"
 CPUTYPE = pentium4m
 .  elif ${CPUTYPE} == "p3"
 CPUTYPE = pentium3
+.  elif ${CPUTYPE} == "p3m" && ${CC:T:Mclang} == "clang"
+CPUTYPE = pentium3
 .  elif ${CPUTYPE} == "p3m"
 CPUTYPE = pentium3m
 .  elif ${CPUTYPE} == "p-m"
@@ -59,8 +63,10 @@
 CPUTYPE = athlon
 .  endif
 . elif ${MACHINE_CPUARCH} == "amd64"
-.  if ${CPUTYPE} == "prescott" || ${CPUTYPE} == "core2"
+.  if ${CPUTYPE} == "prescott"
 CPUTYPE = nocona
+.  elif ${CPUTYPE} == "core2" && ${CC:T:Mclang} != "clang"
+CPUTYPE = nocona
 .  endif
 . elif ${MACHINE_ARCH} == "sparc64"
 .  if ${CPUTYPE} == "us"
@@ -206,7 +212,7 @@
 MACHINE_CPU = k8 3dnow sse3
 .  elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == 
"k8

Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Warner Losh wrote:
> Author: imp
> Date: Wed Feb 16 18:05:10 2011
> New Revision: 218745
> URL: http://svn.freebsd.org/changeset/base/218745
> 
> Log:
>   Remove reading of symbols from a.out loaded files.  Since we are tight
>   on space for clang and a.out support is only needed for /boot/loader,
>   they are excess bytes that serve no useful purpose other than to
>   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
>   support over support for these old kernels and remove this code.  We
>   gain about 100 bytes of space this way.

sorry for my crappy previous attempt to reduce boot2's size. obviously
the *.S files aren't the problem, because even with clang we're using GAS.
so working on boot2.c is the only way of reducing the size.

i've managed to do so (even with another 4 bytes to spare) with the attached
patch.

i did

otaku% grep -r bi_basemem *
sys/boot/i386/boot2/boot2.c:bootinfo.bi_basemem = 0;/* XXX will be 
filled by loader or kernel */
sys/boot/i386/boot2/machine/bootinfo.h: u_int32_t   bi_basemem;
sys/boot/i386/gptboot/gptboot.c:bootinfo.bi_basemem = 0;/* XXX 
will be filled by loader or kernel */
sys/boot/i386/libi386/bootinfo32.c:bi.bi_basemem = bios_basemem / 1024;
sys/boot/i386/loader/main.c:initial_bootinfo->bi_basemem = bios_basemem / 
1024;
sys/boot/i386/zfsboot/zfsboot.c:bootinfo.bi_basemem = bios_basemem / 1024;
sys/boot/pc98/boot2/boot2.c:bootinfo.bi_basemem = 0;/* XXX will be 
filled by loader or kernel */
sys/boot/pc98/loader/main.c:initial_bootinfo->bi_basemem = bios_basemem / 
1024;
sys/i386/include/bootinfo.h:u_int32_t   bi_basemem;
sys/mips/include/bootinfo.h:u_int32_t   bi_basemem;

which led me to the conclusion that bootinfo.bi_basemem doesn't need to
initialised, because it will always be set by the loader (as the XXX comment
says).

turning ioctrl from uint8_t to int also saves a few bytes for whatever reason).
removing x doesn't save any bytes, but gets rid of a warning (as noted in one
of my messages).

cheers.
alex

...and sorry for the previous noise. :(

>   
>   Reviewed by:rdivacky@
> 
> Modified:
>   head/sys/boot/i386/boot2/boot2.c
> 
> Modified: head/sys/boot/i386/boot2/boot2.c
> ==
> --- head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 17:50:21 2011
> (r218744)
> +++ head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 18:05:10 2011
> (r218745)
> @@ -347,23 +347,6 @@ load(void)
>   p += roundup2(hdr.ex.a_text, PAGE_SIZE);
>   if (xfsread(ino, p, hdr.ex.a_data))
>   return;
> - p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE);
> - bootinfo.bi_symtab = VTOP(p);
> - *(uint32_t*)p = hdr.ex.a_syms;
> - p += sizeof(hdr.ex.a_syms);
> - if (hdr.ex.a_syms) {
> - if (xfsread(ino, p, hdr.ex.a_syms))
> - return;
> - p += hdr.ex.a_syms;
> - if (xfsread(ino, p, sizeof(int)))
> - return;
> - x = *(uint32_t *)p;
> - p += sizeof(int);
> - x -= sizeof(int);
> - if (xfsread(ino, p, x))
> - return;
> - p += x;
> - }
>  } else {
>   fs_off = hdr.eh.e_phoff;
>   for (j = i = 0; i < hdr.eh.e_phnum && j < 2; i++) {
> @@ -395,8 +378,8 @@ load(void)
>   }
>   }
>   addr = hdr.eh.e_entry & 0xff;
> + bootinfo.bi_esymtab = VTOP(p);
>  }
> -bootinfo.bi_esymtab = VTOP(p);
>  bootinfo.bi_kernelname = VTOP(kname);
>  bootinfo.bi_bios_dev = dsk.drive;
>  __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),

-- 
a13x
diff --git a/sys/boot/i386/boot2/boot2.c b/sys/boot/i386/boot2/boot2.c
index 3849725..d572700 100644
--- a/sys/boot/i386/boot2/boot2.c
+++ b/sys/boot/i386/boot2/boot2.c
@@ -135,7 +135,7 @@ static char kname[1024];
 static uint16_t opts;
 static int comspeed = SIOSPD;
 static struct bootinfo bootinfo;
-static uint8_t ioctrl = IO_KEYBOARD;
+static int ioctrl = IO_KEYBOARD;
 
 void exit(int);
 static void load(void);
@@ -245,7 +245,7 @@ main(void)
 dsk.slice = *(uint8_t *)PTOV(ARGS + 1) + 1;
 bootinfo.bi_version = BOOTINFO_VERSION;
 bootinfo.bi_size = sizeof(bootinfo);
-bootinfo.bi_basemem = 0;   /* XXX will be filled by loader or kernel */
+/* bootinfo.bi_basemem = 0;XXX will be filled by loader or kernel 
*/
 bootinfo.bi_extmem = memsize();
 bootinfo.bi_memsizes_valid++;
 
@@ -319,7 +319,7 @@ load(void)
 static Elf32_Shdr es[2];
 caddr_t p;
 ino_t ino;
-uint32_t addr, x;
+uint32_t addr;
 int i, j;
 uint8_t fmt;
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Alexander Best wrote:
> On Wed Feb 16 11, Alexander Best wrote:
> > On Wed Feb 16 11, Alexander Best wrote:
> > > On Wed Feb 16 11, Warner Losh wrote:
> > > > Author: imp
> > > > Date: Wed Feb 16 18:05:10 2011
> > > > New Revision: 218745
> > > > URL: http://svn.freebsd.org/changeset/base/218745
> > > > 
> > > > Log:
> > > >   Remove reading of symbols from a.out loaded files.  Since we are tight
> > > >   on space for clang and a.out support is only needed for /boot/loader,
> > > >   they are excess bytes that serve no useful purpose other than to
> > > >   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
> > > >   support over support for these old kernels and remove this code.  We
> > > >   gain about 100 bytes of space this way.

sorry false alarm. :(

> > > 
> > > i think without this code uint32_t x serves no purpose any longer:
> > > 
> > > /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:322:20: warning: unused 
> > > variable 'x' [-Wunused-variable]
> > > uint32_t addr, x;
> > >^
> > 
> > also due to
> > 
> > /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:631:8: warning: cast from 
> > 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases 
> > required alignment from 1 to 4 [-Wcast-align]
> > t1 = *(uint32_t *)PTOV(0x46c);
> >   ^~~
> > 
> > i think t0 and t1 can be turned into uint8_t's and PTOV(0x46c); can be 
> > casted
> > to (uint8_t *), instead of (uint32_t *).

this will actually increase the size.

> 
> with this additional change the code fits when compiled with clang:
> 
> diff --git a/sys/boot/i386/boot2/sio.S b/sys/boot/i386/boot2/sio.S
> index 7b8e9eb..d745129 100644
> --- a/sys/boot/i386/boot2/sio.S
> +++ b/sys/boot/i386/boot2/sio.S
> @@ -29,11 +29,11 @@
>  sio_init:  movw $SIO_PRT+0x3,%dx   # Data format reg
> movb $SIO_FMT|0x80,%al  # Set format
> outb %al,(%dx)  #  and DLAB
> -   pushl %edx  # Save
> +   pushb %dl   # Save
> subb $0x3,%dl   # Divisor latch reg
> movl 0x8(%esp),%eax # Set
> outw %ax,(%dx)  #  BPS
> -   popl %edx   # Restore
> +   popb %dl# Restore
> movb $SIO_FMT,%al   # Clear
> outb %al,(%dx)  #  DLAB
> incl %edx   # Modem control reg

cannot push a single byte onto the stack on i386 32 bit.

...back to the drawing board.

> 
> ...since we're only modifying %dl in subb $0x3,%dl, we don't need to push/pop
> a 32 bit value, but only 8 bits.
> 
> cheers.
> alex
> 
> > 
> > cheers.
> > alex
> > 
> > > 
> > > cheers.
> > > alex
> > > 
> > > >   
> > > >   Reviewed by:  rdivacky@
> > > > 
> > > > Modified:
> > > >   head/sys/boot/i386/boot2/boot2.c
> > > > 
> > > > Modified: head/sys/boot/i386/boot2/boot2.c
> > > > ==
> > > > --- head/sys/boot/i386/boot2/boot2.cWed Feb 16 17:50:21 2011
> > > > (r218744)
> > > > +++ head/sys/boot/i386/boot2/boot2.cWed Feb 16 18:05:10 2011
> > > > (r218745)
> > > > @@ -347,23 +347,6 @@ load(void)
> > > > p += roundup2(hdr.ex.a_text, PAGE_SIZE);
> > > > if (xfsread(ino, p, hdr.ex.a_data))
> > > > return;
> > > > -   p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE);
> > > > -   bootinfo.bi_symtab = VTOP(p);
> > > > -   *(uint32_t*)p = hdr.ex.a_syms;
> > > > -   p += sizeof(hdr.ex.a_syms);
> > > > -   if (hdr.ex.a_syms) {
> > > > -   if (xfsread(ino, p, hdr.ex.a_syms))
> > > > -   return;
> > > > -   p += hdr.ex.a_syms;
> > > > -   if (xfsread(ino, p, sizeof(int)))
> > > > -   return;
> > > > -   x = *(uint32_t *)p;
> > > > -   p += sizeof(int);
> > > > -   x -= sizeof(int);
>

Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Ronald Klop wrote:
> On Wed, 16 Feb 2011 23:41:26 +0100, Alexander Best   
> wrote:
> 
> >On Wed Feb 16 11, Alexander Best wrote:
> >>On Wed Feb 16 11, Alexander Best wrote:
> >>> On Wed Feb 16 11, Warner Losh wrote:
> >>> > Author: imp
> >>> > Date: Wed Feb 16 18:05:10 2011
> >>> > New Revision: 218745
> >>> > URL: http://svn.freebsd.org/changeset/base/218745
> >>> >
> >>> > Log:
> >>> >   Remove reading of symbols from a.out loaded files.  Since we are  
> >>tight
> >>> >   on space for clang and a.out support is only needed for  
> >>/boot/loader,
> >>> >   they are excess bytes that serve no useful purpose other than to
> >>> >   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
> >>> >   support over support for these old kernels and remove this code.   
> >>We
> >>> >   gain about 100 bytes of space this way.
> >>>
> >>> i think without this code uint32_t x serves no purpose any longer:
> >>>
> >>> /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:322:20: warning:  
> >>unused variable 'x' [-Wunused-variable]
> >>> uint32_t addr, x;
> >>>^
> >>
> >>also due to
> >>
> >>/usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:631:8: warning: cast  
> >>from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *')  
> >>increases required alignment from 1 to 4 [-Wcast-align]
> >>t1 = *(uint32_t *)PTOV(0x46c);
> >>  ^~~
> >>
> >>i think t0 and t1 can be turned into uint8_t's and PTOV(0x46c); can be  
> >>casted
> >>to (uint8_t *), instead of (uint32_t *).
> >
> >with this additional change the code fits when compiled with clang:
> >
> >diff --git a/sys/boot/i386/boot2/sio.S b/sys/boot/i386/boot2/sio.S
> >index 7b8e9eb..d745129 100644
> >--- a/sys/boot/i386/boot2/sio.S
> >+++ b/sys/boot/i386/boot2/sio.S
> >@@ -29,11 +29,11 @@
> > sio_init:  movw $SIO_PRT+0x3,%dx   # Data format reg
> >movb $SIO_FMT|0x80,%al  # Set format
> >outb %al,(%dx)  #  and DLAB
> >-   pushl %edx  # Save
> >+   pushb %dl   # Save
> >subb $0x3,%dl   # Divisor latch reg
> >movl 0x8(%esp),%eax # Set
> >outw %ax,(%dx)  #  BPS
> >-   popl %edx   # Restore
> >+   popb %dl# Restore
> >movb $SIO_FMT,%al   # Clear
> >outb %al,(%dx)  #  DLAB
> >incl %edx   # Modem control reg
> >
> >...since we're only modifying %dl in subb $0x3,%dl, we don't need to  
> >push/pop
> >a 32 bit value, but only 8 bits.
> 
> 
> You guys are kings. :-) I heard they don't even teach assembly anymore at  
> a lot of universities.

*lol* assembly (especially i386) isn't that complicated. but you're right:
they don't teach it at university that much. usually you only get to hear
about it in classes which focus on the principals of the CPU, RAM, cache, etc.

the reason for that is quite simple: assembly languages don't get used that
much anymore. in the past they were used a lot to optimise speed, but since
computers have gotten so fast that's not needed anymore.

even for embedded platforms assembly isn't used very often. one of the reason
is also that it's incredibly hard to maintain. comprehending foreign code
(written by another programmer) is really really hard work.

so +1 for having fewer assembly code nowadays. we now have enough cpu power
and hardware ressources in general to having the luxury of letting the
computer do all the abstractions from human thinking to how computers work.

cheers.
alex

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >
> >cheers.
> >alex
> >
> >>
> >>cheers.
> >>alex
> >>
> >>>
> >>> cheers.
> >>> alex
> >>>
> >>> >
> >>> >   Reviewed by:  rdivacky@
> >>> >
> >>> > Modified:
> >>> >   head/sys/boot/i386/boot2/boot2.c
> >>> >
> &g

Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Alexander Best wrote:
> On Wed Feb 16 11, Alexander Best wrote:
> > On Wed Feb 16 11, Warner Losh wrote:
> > > Author: imp
> > > Date: Wed Feb 16 18:05:10 2011
> > > New Revision: 218745
> > > URL: http://svn.freebsd.org/changeset/base/218745
> > > 
> > > Log:
> > >   Remove reading of symbols from a.out loaded files.  Since we are tight
> > >   on space for clang and a.out support is only needed for /boot/loader,
> > >   they are excess bytes that serve no useful purpose other than to
> > >   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
> > >   support over support for these old kernels and remove this code.  We
> > >   gain about 100 bytes of space this way.
> > 
> > i think without this code uint32_t x serves no purpose any longer:
> > 
> > /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:322:20: warning: unused 
> > variable 'x' [-Wunused-variable]
> > uint32_t addr, x;
> >^
> 
> also due to
> 
> /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:631:8: warning: cast from 
> 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases 
> required alignment from 1 to 4 [-Wcast-align]
> t1 = *(uint32_t *)PTOV(0x46c);
>   ^~~
> 
> i think t0 and t1 can be turned into uint8_t's and PTOV(0x46c); can be casted
> to (uint8_t *), instead of (uint32_t *).

with this additional change the code fits when compiled with clang:

diff --git a/sys/boot/i386/boot2/sio.S b/sys/boot/i386/boot2/sio.S
index 7b8e9eb..d745129 100644
--- a/sys/boot/i386/boot2/sio.S
+++ b/sys/boot/i386/boot2/sio.S
@@ -29,11 +29,11 @@
 sio_init:  movw $SIO_PRT+0x3,%dx   # Data format reg
movb $SIO_FMT|0x80,%al  # Set format
outb %al,(%dx)  #  and DLAB
-   pushl %edx  # Save
+   pushb %dl   # Save
subb $0x3,%dl   # Divisor latch reg
movl 0x8(%esp),%eax # Set
outw %ax,(%dx)  #  BPS
-   popl %edx   # Restore
+   popb %dl# Restore
movb $SIO_FMT,%al   # Clear
outb %al,(%dx)  #  DLAB
incl %edx   # Modem control reg

...since we're only modifying %dl in subb $0x3,%dl, we don't need to push/pop
a 32 bit value, but only 8 bits.

cheers.
alex

> 
> cheers.
> alex
> 
> > 
> > cheers.
> > alex
> > 
> > >   
> > >   Reviewed by:rdivacky@
> > > 
> > > Modified:
> > >   head/sys/boot/i386/boot2/boot2.c
> > > 
> > > Modified: head/sys/boot/i386/boot2/boot2.c
> > > ==
> > > --- head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 17:50:21 2011
> > > (r218744)
> > > +++ head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 18:05:10 2011
> > > (r218745)
> > > @@ -347,23 +347,6 @@ load(void)
> > >   p += roundup2(hdr.ex.a_text, PAGE_SIZE);
> > >   if (xfsread(ino, p, hdr.ex.a_data))
> > >   return;
> > > - p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE);
> > > - bootinfo.bi_symtab = VTOP(p);
> > > - *(uint32_t*)p = hdr.ex.a_syms;
> > > - p += sizeof(hdr.ex.a_syms);
> > > - if (hdr.ex.a_syms) {
> > > - if (xfsread(ino, p, hdr.ex.a_syms))
> > > - return;
> > > - p += hdr.ex.a_syms;
> > > - if (xfsread(ino, p, sizeof(int)))
> > > - return;
> > > - x = *(uint32_t *)p;
> > > - p += sizeof(int);
> > > - x -= sizeof(int);
> > > - if (xfsread(ino, p, x))
> > > - return;
> > > - p += x;
> > > - }
> > >  } else {
> > >   fs_off = hdr.eh.e_phoff;
> > >   for (j = i = 0; i < hdr.eh.e_phnum && j < 2; i++) {
> > > @@ -395,8 +378,8 @@ load(void)
> > >   }
> > >   }
> > >   addr = hdr.eh.e_entry & 0xff;
> > > + bootinfo.bi_esymtab = VTOP(p);
> > >  }
> > > -bootinfo.bi_esymtab = VTOP(p);
> > >  bootinfo.bi_kernelname = VTOP(kname);
> > >  bootinfo.bi_bios_dev = dsk.drive;
> > >  __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),
> > 
> > -- 
> > a13x
> 
> -- 
> a13x

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Alexander Best wrote:
> On Wed Feb 16 11, Warner Losh wrote:
> > Author: imp
> > Date: Wed Feb 16 18:05:10 2011
> > New Revision: 218745
> > URL: http://svn.freebsd.org/changeset/base/218745
> > 
> > Log:
> >   Remove reading of symbols from a.out loaded files.  Since we are tight
> >   on space for clang and a.out support is only needed for /boot/loader,
> >   they are excess bytes that serve no useful purpose other than to
> >   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
> >   support over support for these old kernels and remove this code.  We
> >   gain about 100 bytes of space this way.
> 
> i think without this code uint32_t x serves no purpose any longer:
> 
> /usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:322:20: warning: unused 
> variable 'x' [-Wunused-variable]
> uint32_t addr, x;
>^

also due to

/usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:631:8: warning: cast from 
'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases 
required alignment from 1 to 4 [-Wcast-align]
t1 = *(uint32_t *)PTOV(0x46c);
  ^~~

i think t0 and t1 can be turned into uint8_t's and PTOV(0x46c); can be casted
to (uint8_t *), instead of (uint32_t *).

cheers.
alex

> 
> cheers.
> alex
> 
> >   
> >   Reviewed by:  rdivacky@
> > 
> > Modified:
> >   head/sys/boot/i386/boot2/boot2.c
> > 
> > Modified: head/sys/boot/i386/boot2/boot2.c
> > ==
> > --- head/sys/boot/i386/boot2/boot2.cWed Feb 16 17:50:21 2011
> > (r218744)
> > +++ head/sys/boot/i386/boot2/boot2.cWed Feb 16 18:05:10 2011
> > (r218745)
> > @@ -347,23 +347,6 @@ load(void)
> > p += roundup2(hdr.ex.a_text, PAGE_SIZE);
> > if (xfsread(ino, p, hdr.ex.a_data))
> > return;
> > -   p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE);
> > -   bootinfo.bi_symtab = VTOP(p);
> > -   *(uint32_t*)p = hdr.ex.a_syms;
> > -   p += sizeof(hdr.ex.a_syms);
> > -   if (hdr.ex.a_syms) {
> > -   if (xfsread(ino, p, hdr.ex.a_syms))
> > -   return;
> > -   p += hdr.ex.a_syms;
> > -   if (xfsread(ino, p, sizeof(int)))
> > -   return;
> > -   x = *(uint32_t *)p;
> > -   p += sizeof(int);
> > -   x -= sizeof(int);
> > -   if (xfsread(ino, p, x))
> > -   return;
> > -   p += x;
> > -   }
> >  } else {
> > fs_off = hdr.eh.e_phoff;
> > for (j = i = 0; i < hdr.eh.e_phnum && j < 2; i++) {
> > @@ -395,8 +378,8 @@ load(void)
> > }
> > }
> > addr = hdr.eh.e_entry & 0xff;
> > +   bootinfo.bi_esymtab = VTOP(p);
> >  }
> > -bootinfo.bi_esymtab = VTOP(p);
> >  bootinfo.bi_kernelname = VTOP(kname);
> >  bootinfo.bi_bios_dev = dsk.drive;
> >  __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),
> 
> -- 
> a13x

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218745 - head/sys/boot/i386/boot2

2011-02-16 Thread Alexander Best
On Wed Feb 16 11, Warner Losh wrote:
> Author: imp
> Date: Wed Feb 16 18:05:10 2011
> New Revision: 218745
> URL: http://svn.freebsd.org/changeset/base/218745
> 
> Log:
>   Remove reading of symbols from a.out loaded files.  Since we are tight
>   on space for clang and a.out support is only needed for /boot/loader,
>   they are excess bytes that serve no useful purpose other than to
>   support really old kernels (FreeBSD < 3.2 or so).  Prefer clang
>   support over support for these old kernels and remove this code.  We
>   gain about 100 bytes of space this way.

i think without this code uint32_t x serves no purpose any longer:

/usr/git-freebsd-head/sys/boot/i386/boot2/boot2.c:322:20: warning: unused 
variable 'x' [-Wunused-variable]
uint32_t addr, x;
   ^

cheers.
alex

>   
>   Reviewed by:rdivacky@
> 
> Modified:
>   head/sys/boot/i386/boot2/boot2.c
> 
> Modified: head/sys/boot/i386/boot2/boot2.c
> ==
> --- head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 17:50:21 2011
> (r218744)
> +++ head/sys/boot/i386/boot2/boot2.c  Wed Feb 16 18:05:10 2011
> (r218745)
> @@ -347,23 +347,6 @@ load(void)
>   p += roundup2(hdr.ex.a_text, PAGE_SIZE);
>   if (xfsread(ino, p, hdr.ex.a_data))
>   return;
> - p += hdr.ex.a_data + roundup2(hdr.ex.a_bss, PAGE_SIZE);
> - bootinfo.bi_symtab = VTOP(p);
> - *(uint32_t*)p = hdr.ex.a_syms;
> - p += sizeof(hdr.ex.a_syms);
> - if (hdr.ex.a_syms) {
> - if (xfsread(ino, p, hdr.ex.a_syms))
> - return;
> - p += hdr.ex.a_syms;
> - if (xfsread(ino, p, sizeof(int)))
> - return;
> - x = *(uint32_t *)p;
> - p += sizeof(int);
> - x -= sizeof(int);
> - if (xfsread(ino, p, x))
> - return;
> - p += x;
> - }
>  } else {
>   fs_off = hdr.eh.e_phoff;
>   for (j = i = 0; i < hdr.eh.e_phnum && j < 2; i++) {
> @@ -395,8 +378,8 @@ load(void)
>   }
>   }
>   addr = hdr.eh.e_entry & 0xff;
> + bootinfo.bi_esymtab = VTOP(p);
>  }
> -bootinfo.bi_esymtab = VTOP(p);
>  bootinfo.bi_kernelname = VTOP(kname);
>  bootinfo.bi_bios_dev = dsk.drive;
>  __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218652 - head/sbin/mdconfig

2011-02-13 Thread Alexander Best
On Sun Feb 13 11, Bruce Cran wrote:
> Author: brucec
> Date: Sun Feb 13 18:30:17 2011
> New Revision: 218652
> URL: http://svn.freebsd.org/changeset/base/218652
> 
> Log:
>   Only print the unit number when invoked with the -n flag.

wow. i completely forget about this one. ;) thanks for taking care of it. :)

>   
>   PR: bin/144300
>   Submitted by:   arundel
>   MFC after:  3 days
> 
> Modified:
>   head/sbin/mdconfig/mdconfig.c
> 
> Modified: head/sbin/mdconfig/mdconfig.c
> ==
> --- head/sbin/mdconfig/mdconfig.c Sun Feb 13 18:21:41 2011
> (r218651)
> +++ head/sbin/mdconfig/mdconfig.c Sun Feb 13 18:30:17 2011
> (r218652)
> @@ -373,7 +373,7 @@ md_list(char *units, int opt)
>   found = 1;
>   }
>   gc = &pp->lg_config;
> - printf("%s", pp->lg_name);
> + printf("%s", nflag ? pp->lg_name + 2 : pp->lg_name);
>   if (opt & OPT_VERBOSE || opt & OPT_UNIT) {
>   type = geom_config_get(gc, "type");
>   if (strcmp(type, "vnode") == 0)

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218303 - in head/lib/libc: amd64/string i386/string

2011-02-04 Thread Alexander Best
On Fri Feb  4 11, Konstantin Belousov wrote:
> Author: kib
> Date: Fri Feb  4 21:04:00 2011
> New Revision: 218303
> URL: http://svn.freebsd.org/changeset/base/218303
> 
> Log:
>   Remove duplicate .note.GNU-stack section declaration. bcopy already
>   made the neccessary provisions.

...and some more in
lib/msun/amd64/s_llrint.S
lib/msun/amd64/s_llrintf.S

due to the inclusion of s_lrintf.S

>   
>   Reported by:arundel
> 
> Modified:
>   head/lib/libc/amd64/string/memmove.S
>   head/lib/libc/i386/string/memcpy.S
>   head/lib/libc/i386/string/memmove.S
> 
> Modified: head/lib/libc/amd64/string/memmove.S
> ==
> --- head/lib/libc/amd64/string/memmove.S  Fri Feb  4 20:59:45 2011
> (r218302)
> +++ head/lib/libc/amd64/string/memmove.S  Fri Feb  4 21:04:00 2011
> (r218303)
> @@ -3,5 +3,3 @@
>  
>  #define MEMMOVE
>  #include "bcopy.S"
> -
> - .section .note.GNU-stack,"",%progbist
> 
> Modified: head/lib/libc/i386/string/memcpy.S
> ==
> --- head/lib/libc/i386/string/memcpy.SFri Feb  4 20:59:45 2011
> (r218302)
> +++ head/lib/libc/i386/string/memcpy.SFri Feb  4 21:04:00 2011
> (r218303)
> @@ -3,5 +3,3 @@ __FBSDID("$FreeBSD$");
>  
>  #define MEMCOPY
>  #include "bcopy.S"
> -
> - .section .note.GNU-stack,"",%progbits
> 
> Modified: head/lib/libc/i386/string/memmove.S
> ==
> --- head/lib/libc/i386/string/memmove.S   Fri Feb  4 20:59:45 2011
> (r218302)
> +++ head/lib/libc/i386/string/memmove.S   Fri Feb  4 21:04:00 2011
> (r218303)
> @@ -3,5 +3,3 @@ __FBSDID("$FreeBSD$");
>  
>  #define MEMMOVE
>  #include "bcopy.S"
> -
> - .section .note.GNU-stack,"",%progbits

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218290 - head/sys/conf

2011-02-04 Thread Alexander Best
On Fri Feb  4 11, John Baldwin wrote:
> Author: jhb
> Date: Fri Feb  4 18:36:09 2011
> New Revision: 218290
> URL: http://svn.freebsd.org/changeset/base/218290
> 
> Log:
>   Correct include path.

thanks a bunch. :)

>   
>   Submitted by:   arundel
>   MFC after:  1 week
> 
> Modified:
>   head/sys/conf/files
> 
> Modified: head/sys/conf/files
> ==
> --- head/sys/conf/files   Fri Feb  4 17:49:55 2011(r218289)
> +++ head/sys/conf/files   Fri Feb  4 18:36:09 2011(r218290)
> @@ -960,7 +960,7 @@ dev/e1000/e1000_82543.c   optional em | i
>  dev/e1000/e1000_82571.c  optional em | igb \
>   compile-with "${NORMAL_C} -I$S/dev/e1000"
>  dev/e1000/e1000_82575.c  optional em | igb \
> -  compile-with "${NORMAL_C} -I$S/dev/igb"
> + compile-with "${NORMAL_C} -I$S/dev/e1000"
>  dev/e1000/e1000_ich8lan.coptional em | igb \
>   compile-with "${NORMAL_C} -I$S/dev/e1000"
>  dev/e1000/e1000_api.coptional em | igb \

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r218171 - head/contrib/top

2011-02-01 Thread Alexander Best
On Tue Feb  1 11, John Baldwin wrote:
> Author: jhb
> Date: Tue Feb  1 15:48:27 2011
> New Revision: 218171
> URL: http://svn.freebsd.org/changeset/base/218171
> 
> Log:
>   Output an appropriate amount of padding to line up per-CPU state columns
>   rather than using a terminal sequence to move the cursor when drawing the
>   initial screen.

thanks. :)

>   
>   Requested by:   arundel
>   MFC after:  3 days
> 
> Modified:
>   head/contrib/top/display.c
> 
> Modified: head/contrib/top/display.c
> ==
> --- head/contrib/top/display.cTue Feb  1 15:26:30 2011
> (r218170)
> +++ head/contrib/top/display.cTue Feb  1 15:48:27 2011
> (r218171)
> @@ -447,12 +447,14 @@ for (cpu = 0; cpu < num_cpus; cpu++) {
>  /* print tag and bump lastline */
>  if (num_cpus == 1)
>   printf("\nCPU: ");
> -else
> - printf("\nCPU %d: ", cpu);
> +else {
> + value = printf("\nCPU %d: ", cpu);
> + while (value++ <= cpustates_column)
> + printf(" ");
> +}
>  lastline++;
>  
>  /* now walk thru the names and print the line */
> -Move_to(cpustates_column, y_cpustates + cpu);
>  while ((thisname = *names++) != NULL)
>  {
>   if (*thisname != '\0')
> @@ -532,7 +534,7 @@ z_cpustates()
>  register char **names;
>  register char *thisname;
>  register int *lp;
> -int cpu;
> +int cpu, value;
>  
>  for (cpu = 0; cpu < num_cpus; cpu++) {
>  names = cpustate_names;
> @@ -540,11 +542,13 @@ for (cpu = 0; cpu < num_cpus; cpu++) {
>  /* show tag and bump lastline */
>  if (num_cpus == 1)
>   printf("\nCPU: ");
> -else
> - printf("\nCPU %d: ", cpu);
> +else {
> + value = printf("\nCPU %d: ", cpu);
> + while (value++ <= cpustates_column)
> + printf(" ");
> +}
>  lastline++;
>  
> -Move_to(cpustates_column, y_cpustates + cpu);
>  while ((thisname = *names++) != NULL)
>  {
>   if (*thisname != '\0')

-- 
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


  1   2   >