Re: svn commit: r366748 - head/sys/fs/pseudofs

[Edward Napierala]

On Fri, 16 Oct 2020 at 11:47, Konstantin Belousov  wrote:
>
> On Fri, Oct 16, 2020 at 09:58:11AM +, Edward Tomasz Napierala wrote:
> > Author: trasz
> > Date: Fri Oct 16 09:58:10 2020
> > New Revision: 366748
> > URL: https://svnweb.freebsd.org/changeset/base/366748
> >
> > Log:
> >   Bump pseudofs size limit from 128kB to 1MB.  The old limit could result
> >   in process' memory maps being truncated.
> New limit could as well.

True.  With r367139 we'll at least emit a warning when that happens.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r357203 - head/sys/compat/linux

[Edward Napierala]

On Tue, 28 Jan 2020 at 18:55, Gleb Smirnoff  wrote:
>
> On Tue, Jan 28, 2020 at 01:57:25PM +, Edward Tomasz Napierala wrote:
> E> Author: trasz
> E> Date: Tue Jan 28 13:57:24 2020
> E> New Revision: 357203
> E> URL: https://svnweb.freebsd.org/changeset/base/357203
> E>
> E> Log:
> E>   Add TCP_CORK support to linux(4).  This fixes one of the things Nginx
> E>   trips over.
> E>
> E>   MFC after: 2 weeks
> E>   Sponsored by:  The FreeBSD Foundation
> E>   Differential Revision: https://reviews.freebsd.org/D23171
>
> Again, out of curiosity: what is any good reason to run linux nginx
> binary on FreeBSD? To lose all the nice features of FreeBSD kernel
> that nginx supports?

Docker, obviously.

Seriously though - Nginx, or whatever other application you can see in my
commit messages, is not the goal itself; it's more of a test case, so I can
easily reproduce/retest it in the future, should I need to.  The goal is fixing
TCP_CORK, for whatever Linux app that needs it.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r355818 - in head: share/man/man4 sys/amd64/linux sys/amd64/linux32 sys/arm64/linux sys/compat/linux sys/i386/linux

[Edward Napierala]

On Mon, 16 Dec 2019 at 20:59, Enji Cooper  wrote:
>
>
> > On Dec 16, 2019, at 12:07, Edward Tomasz Napierala  
> > wrote:
> >
> > Author: trasz
> > Date: Mon Dec 16 20:07:04 2019
> > New Revision: 355818
> > URL: https://svnweb.freebsd.org/changeset/base/355818
> >
> > Log:
> >  Add compat.linux.emul_path, so it can be set to something other
> >  than "/compat/linux".  Useful when you have several compat directories
> >  with different Linux versions and you don't want to clash with files
> >  installed by linux-c7 packages.
>
> Hi Edward!
> Great feature :).. i was wondering if it made sense to implement this 
> sysctl as a per-jail setting so one jail could have one setting and another 
> have another setting? Arguably, one could just leave the default, but it’s a 
> just thought I had when reading your commit message.

Thanks!  Yes, eventually this could be turned into a per-jail
parameter.  In most cases it just doesn't matter within a jail, though
- for Linux jails you probably want to have a usual Linux root
filesystem, without /compat/linux; thus, linuxulator path translation
will be a nop.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r353283 - in head: lib lib/libstats share/man/man3 share/mk sys/amd64/conf sys/conf sys/kern sys/sys tools/build/options

[Edward Napierala]

On Mon, 7 Oct 2019 at 22:39, John Baldwin  wrote:
>
> On 10/7/19 12:05 PM, Edward Tomasz Napierala wrote:
> > Author: trasz
> > Date: Mon Oct  7 19:05:05 2019
> > New Revision: 353283
> > URL: https://svnweb.freebsd.org/changeset/base/353283
> >
> > Log:
> >   Introduce stats(3), a flexible statistics gathering API.
> >
> >   This provides a framework to define a template describing
> >   a set of "variables of interest" and the intended way for
> >   the framework to maintain them (for example the maximum, sum,
> >   t-digest, or a combination thereof).  Afterwards the user
> >   code feeds in the raw data, and the framework maintains
> >   these variables inside a user-provided, opaque stats blobs.
> >   The framework also provides a way to selectively extract the
> >   stats from the blobs.  The stats(3) framework can be used in
> >   both userspace and the kernel.
> >
> >   See the stats(3) manual page for details.
> >
> >   This will be used by the upcoming TCP statistics gathering code,
> >   https://reviews.freebsd.org/D20655.
> >
> >   The stats(3) framework is disabled by default for now, except
> >   in the NOTES kernel (for QA); it is expected to be enabled
> >   in amd64 GENERIC after a cool down period.
>
> Why sys/amd64/conf/NOTES instead of sys/conf/NOTES?  The userland
> library seems to be enabled for all architectures rather than only
> amd64?

Good point.  My original thinking was to only enable it by default on
amd64, since, well, it's "server-y stuff", but now I think of it, it doesn't
make sense.

> > Modified: head/share/man/man3/arb.3
> > ==
> > --- head/share/man/man3/arb.3 Mon Oct  7 18:55:40 2019(r353282)
> > +++ head/share/man/man3/arb.3 Mon Oct  7 19:05:05 2019(r353283)
> > @@ -30,7 +30,7 @@
> >  .\"
> >  .\" $FreeBSD$
> >  .\"
> > -.Dd September 28, 2019
> > +.Dd October 2, 2019
> >  .Dt ARB 3
> >  .Os
> >  .Sh NAME
> > @@ -94,7 +94,8 @@
> >  .Nm ARB_INIT ,
> >  .Nm ARB_INSERT ,
> >  .Nm ARB_REMOVE ,
> > -.Nm ARB_REINSERT
> > +.Nm ARB_REINSERT ,
> > +.Nm ARB_RESET_TREE
> >  .Nd "array-based red-black trees"
> >  .Sh SYNOPSIS
> >  .In sys/arb.h
>
> Are these changes related?  Perhaps it would have been nice to commit this
> change separately with its own description before the stats(3) commit if so.

Which is exactly what I was intending to do, sigh.  But yes, this chunk
is specific to stats(3); in fact up until the last Phab revision it's been done
directly in kern_stats.c.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r346571 - in head: share/examples/tests/tests/tap share/man/man4 share/man/man5 share/zoneinfo/tests usr.bin/calendar/calendars usr.bin/du/tests usr.bin/getconf/tests usr.bin/procstat/

[Edward Napierala]

On Mon, 22 Apr 2019 at 20:01, Rodney W. Grimes
 wrote:
>
> > Author: ngie
> > Date: Mon Apr 22 17:52:46 2019
> > New Revision: 346571
> > URL: https://svnweb.freebsd.org/changeset/base/346571
> >
> > Log:
> >   Update the spelling of my name
> >
> >   Previous spellings of my name (NGie, Ngie) weren't my legal spelling. Use 
> > Enji
> >   instead for clarity.
> >
> >   While here, remove "All Rights Reserved" from copyrights I "own".

[..]

> > Modified: head/share/man/man4/cfiscsi.4
> > ==
> > --- head/share/man/man4/cfiscsi.4 Mon Apr 22 17:48:10 2019
> > (r346570)
> > +++ head/share/man/man4/cfiscsi.4 Mon Apr 22 17:52:46 2019
> > (r346571)
> > @@ -1,7 +1,6 @@
> >  .\" Copyright (c) 2013 Edward Tomasz Napierala
> >  .\" Copyright (c) 2015-2017 Alexander Motin 
> > -.\" Copyright (c) 2017 Ngie Cooper 
> > -.\" All rights reserved.
> > +.\" Copyright (c) 2017 Enji Cooper 
>
> We should investiage the history of this All rights reserved,
> I suspect it actually originally belongs to traz and possibly
> mav, and not explicity you due to prior habbits.  If you have
> already done that investigation (ie, you added the line) ignore
> my comment.  If however you simply added a copyright between
> the line and some other copyright please restore this line
> to its prior state.

FWIW, I'm perfectly fine with this.


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

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

[Edward Napierala]

On Fri, 12 Apr 2019 at 16:20, Konstantin Belousov  wrote:
>
> On Fri, Apr 12, 2019 at 03:28:26PM +0100, Edward Napierala wrote:
> > On Thu, 11 Apr 2019 at 17:26, Conrad Meyer  wrote:
> > >
> > > Hi Edward,
> > >
> > > I have a question about this change below.
> > >
> > > On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala
> > >  wrote:
> > > >
> > > > Author: trasz
> > > > Date: Thu Apr 11 11:21:45 2019
> > > > New Revision: 346120
> > > > URL: https://svnweb.freebsd.org/changeset/base/346120
> > > >
> > > > Log:
> > > >   Use shared vnode locks for the ELF interpreter.
> >
> > [..]
> >
> > > On the one hand, perhaps VOP_IS_TEXT() is rarely false for common
> > > interpreters anyway.  On the other hand, there is sort of a
> > > renaissance of static linking happening.  So maybe the thought is,
> > > !VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more
> > > rare, so why bother writing additional code for it?
> >
> > Konstantin already answered to most of the points, but regarding
> > this one: that's exactly the case.  In a typical case, the number of times
> > this code path will be executed is zero.  I'd expect one - when running
> > dynamically linked ELF binary for the first time - but for some reason in
> > that case lookup() returns with the exclusive vnode lock already held.
>
> This is strange.  Which filesystem do you use ?

UFS.


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

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

[Edward Napierala]

On Thu, 11 Apr 2019 at 17:26, Conrad Meyer  wrote:
>
> Hi Edward,
>
> I have a question about this change below.
>
> On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala
>  wrote:
> >
> > Author: trasz
> > Date: Thu Apr 11 11:21:45 2019
> > New Revision: 346120
> > URL: https://svnweb.freebsd.org/changeset/base/346120
> >
> > Log:
> >   Use shared vnode locks for the ELF interpreter.

[..]

> On the one hand, perhaps VOP_IS_TEXT() is rarely false for common
> interpreters anyway.  On the other hand, there is sort of a
> renaissance of static linking happening.  So maybe the thought is,
> !VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more
> rare, so why bother writing additional code for it?

Konstantin already answered to most of the points, but regarding
this one: that's exactly the case.  In a typical case, the number of times
this code path will be executed is zero.  I'd expect one - when running
dynamically linked ELF binary for the first time - but for some reason in
that case lookup() returns with the exclusive vnode lock already held.


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

Re: svn commit: r345549 - head/sys/dev/smartpqi

[Edward Napierala]

On Tue, 26 Mar 2019 at 15:47, Edward Tomasz Napierala  wrote:
>
> Author: trasz
> Date: Tue Mar 26 15:47:13 2019
> New Revision: 345549
> URL: https://svnweb.freebsd.org/changeset/base/345549
>
> Log:
>   Make smartpqi(4) behave better when running out of memory, by returning
>   CAM_RESRC_UNAVAIL instead of CAM_REQUEUE_REQ.  This makes CAM delay a bit
>   before retrying, so that the retries actually get a chance to succeed.
>
>   Reviewed by:  sbruno

Reviewed by: imp, sbruno

Sorry for missing this earlier.


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

Re: svn commit: r350331 - in head: sbin/camcontrol sys/cam/ata sys/cam/scsi sys/sys

[Edward Napierala]

On Thu, 25 Jul 2019 at 19:48, Alexander Motin  wrote:
>
> Author: mav
> Date: Thu Jul 25 18:48:31 2019
> New Revision: 350331
> URL: https://svnweb.freebsd.org/changeset/base/350331
>
> Log:
>   Make `camcontrol sanitize` support also ATA devices.
>
>   ATA sanitize is functionally identical to SCSI, just uses different
>   initiation commands and status reporting mechanism.
>
>   While there, make kernel better handle sanitize commands and statuses.
>
>   MFC after:2 weeks
>   Sponsored by: iXsystems, Inc.

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

Re: svn commit: r346571 - in head: share/examples/tests/tests/tap share/man/man4 share/man/man5 share/zoneinfo/tests usr.bin/calendar/calendars usr.bin/du/tests usr.bin/getconf/tests usr.bin/procstat/

[Edward Napierala]

On Mon, 22 Apr 2019 at 20:01, Rodney W. Grimes
 wrote:
>
> > Author: ngie
> > Date: Mon Apr 22 17:52:46 2019
> > New Revision: 346571
> > URL: https://svnweb.freebsd.org/changeset/base/346571
> >
> > Log:
> >   Update the spelling of my name
> >
> >   Previous spellings of my name (NGie, Ngie) weren't my legal spelling. Use 
> > Enji
> >   instead for clarity.
> >
> >   While here, remove "All Rights Reserved" from copyrights I "own".

[..]

> > Modified: head/share/man/man4/cfiscsi.4
> > ==
> > --- head/share/man/man4/cfiscsi.4 Mon Apr 22 17:48:10 2019
> > (r346570)
> > +++ head/share/man/man4/cfiscsi.4 Mon Apr 22 17:52:46 2019
> > (r346571)
> > @@ -1,7 +1,6 @@
> >  .\" Copyright (c) 2013 Edward Tomasz Napierala
> >  .\" Copyright (c) 2015-2017 Alexander Motin 
> > -.\" Copyright (c) 2017 Ngie Cooper 
> > -.\" All rights reserved.
> > +.\" Copyright (c) 2017 Enji Cooper 
>
> We should investiage the history of this All rights reserved,
> I suspect it actually originally belongs to traz and possibly
> mav, and not explicity you due to prior habbits.  If you have
> already done that investigation (ie, you added the line) ignore
> my comment.  If however you simply added a copyright between
> the line and some other copyright please restore this line
> to its prior state.

FWIW, I'm perfectly fine with this.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Edward Napierala]

On Fri, 12 Apr 2019 at 16:20, Konstantin Belousov  wrote:
>
> On Fri, Apr 12, 2019 at 03:28:26PM +0100, Edward Napierala wrote:
> > On Thu, 11 Apr 2019 at 17:26, Conrad Meyer  wrote:
> > >
> > > Hi Edward,
> > >
> > > I have a question about this change below.
> > >
> > > On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala
> > >  wrote:
> > > >
> > > > Author: trasz
> > > > Date: Thu Apr 11 11:21:45 2019
> > > > New Revision: 346120
> > > > URL: https://svnweb.freebsd.org/changeset/base/346120
> > > >
> > > > Log:
> > > >   Use shared vnode locks for the ELF interpreter.
> >
> > [..]
> >
> > > On the one hand, perhaps VOP_IS_TEXT() is rarely false for common
> > > interpreters anyway.  On the other hand, there is sort of a
> > > renaissance of static linking happening.  So maybe the thought is,
> > > !VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more
> > > rare, so why bother writing additional code for it?
> >
> > Konstantin already answered to most of the points, but regarding
> > this one: that's exactly the case.  In a typical case, the number of times
> > this code path will be executed is zero.  I'd expect one - when running
> > dynamically linked ELF binary for the first time - but for some reason in
> > that case lookup() returns with the exclusive vnode lock already held.
>
> This is strange.  Which filesystem do you use ?

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

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

[Edward Napierala]

On Thu, 11 Apr 2019 at 17:26, Conrad Meyer  wrote:
>
> Hi Edward,
>
> I have a question about this change below.
>
> On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala
>  wrote:
> >
> > Author: trasz
> > Date: Thu Apr 11 11:21:45 2019
> > New Revision: 346120
> > URL: https://svnweb.freebsd.org/changeset/base/346120
> >
> > Log:
> >   Use shared vnode locks for the ELF interpreter.

[..]

> On the one hand, perhaps VOP_IS_TEXT() is rarely false for common
> interpreters anyway.  On the other hand, there is sort of a
> renaissance of static linking happening.  So maybe the thought is,
> !VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more
> rare, so why bother writing additional code for it?

Konstantin already answered to most of the points, but regarding
this one: that's exactly the case.  In a typical case, the number of times
this code path will be executed is zero.  I'd expect one - when running
dynamically linked ELF binary for the first time - but for some reason in
that case lookup() returns with the exclusive vnode lock already held.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345549 - head/sys/dev/smartpqi

[Edward Napierala]

On Tue, 26 Mar 2019 at 15:47, Edward Tomasz Napierala  wrote:
>
> Author: trasz
> Date: Tue Mar 26 15:47:13 2019
> New Revision: 345549
> URL: https://svnweb.freebsd.org/changeset/base/345549
>
> Log:
>   Make smartpqi(4) behave better when running out of memory, by returning
>   CAM_RESRC_UNAVAIL instead of CAM_REQUEUE_REQ.  This makes CAM delay a bit
>   before retrying, so that the retries actually get a chance to succeed.
>
>   Reviewed by:  sbruno

Reviewed by: imp, sbruno

Sorry for missing this earlier.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver

[Edward Napierala]

pon., 4 mar 2019 o 15:17 Cy Schubert  napisał(a):
>
> On March 4, 2019 6:30:21 AM PST, Konstantin Belousov  
> wrote:
> >On Mon, Mar 04, 2019 at 01:31:37PM +, Edward Napierala wrote:
> >> pon., 4 mar 2019 o 13:20 Konstantin Belousov 
> >napisał(a):
> >> > > + p = curthread;
> >> > Why do you name it 'p', which is typical for process, and not 'td',
> >you are
> >> > changing most of the code anyway.
> >>
> >> To keep the diff size smaller.  You're right, this touches a lot of
> >stuff,
> >> but most of those added lines are temporary anyway - they will be
> >> removed later, when the td is pushed down even more.
> >But if you create code churn, doing it only half way is worse.
> >
> >>
> >> > Also I am curious why. It is certainly fine to remove td when it is
> >used
> >> > as a formal placeholder argument only. But when the first action in
> >the
> >> > function is evaluation of curthread() it becomes less obvious.
> >>
> >> Again, many/most of those are temporary.  I'm trying to push td down
> >> in small steps, "layer by layer", so it's easy to review.
> >>
> >> > curthread() become very cheap on modern amd64, I am not so sure
> >about
> >> > older machines or non-x86 cases.
> >>
> >> The main reason is readability.  Right now there's no easy way to
> >tell whether
> >> a function can be passed any td, or if it must be curthread.
> >I must admit that this is the weirdnest argument against 'td' that I
> >ever
> >heard.  I saw more or less reasonable argumentation
> >- that using less arguments make one more register for argument passing
> >  (amd64 has 6 input arg regs),
> >- that less arguments make smaller call code.
> >But trust me, in all cases where function can take td != curthread, it
> >is
> >either obvious or well-known for anybody who works with that code.
> >
> >Before you start doing a lot of small changes (AKA continous churn)
> >please formulate your goals and get some public feedback.  My immediate
> >question that I want answered before you ever start touching the code,
> >is what you plan to do with
> >   sys_syscall(struct thread *td, uap)
>
> Agreed on all points. At the very least this group of commits should be 
> reviewed on phabricator.

It has been, even though they are pretty much mechanical changes.

> Can we back all these commits out until there is a proper review, please?

The review from the NFS maintainer is not enough?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver

[Edward Napierala]

pon., 4 mar 2019 o 14:30 Konstantin Belousov  napisał(a):
>
> On Mon, Mar 04, 2019 at 01:31:37PM +, Edward Napierala wrote:
> > pon., 4 mar 2019 o 13:20 Konstantin Belousov  
> > napisał(a):
> > > > + p = curthread;
> > > Why do you name it 'p', which is typical for process, and not 'td', you 
> > > are
> > > changing most of the code anyway.
> >
> > To keep the diff size smaller.  You're right, this touches a lot of stuff,
> > but most of those added lines are temporary anyway - they will be
> > removed later, when the td is pushed down even more.
> But if you create code churn, doing it only half way is worse.

But this way I create less churn - if I renamed it to 'td', then first
I'd change
the calls to other functions to take 'td' instead of 'p', and then I'd remove
this argument altogether in subsequent commit.  This would make diffs
larger for no good reason.

> > > Also I am curious why. It is certainly fine to remove td when it is used
> > > as a formal placeholder argument only. But when the first action in the
> > > function is evaluation of curthread() it becomes less obvious.
> >
> > Again, many/most of those are temporary.  I'm trying to push td down
> > in small steps, "layer by layer", so it's easy to review.
> >
> > > curthread() become very cheap on modern amd64, I am not so sure about
> > > older machines or non-x86 cases.
> >
> > The main reason is readability.  Right now there's no easy way to tell 
> > whether
> > a function can be passed any td, or if it must be curthread.
> I must admit that this is the weirdnest argument against 'td' that I ever
> heard.  I saw more or less reasonable argumentation
> - that using less arguments make one more register for argument passing
>   (amd64 has 6 input arg regs),
> - that less arguments make smaller call code.
> But trust me, in all cases where function can take td != curthread, it is
> either obvious or well-known for anybody who works with that code.

Ah, ok.  So, yes, you are right that from a high level point of view
it's a poor argument.  But at this point I'm not trying to change stuff
throughout the kernel; just the NFS server.  And the reason for doing
this is to make it obvious that the 'td' argument it passes to VOPs and
other kernel APIs is always equal to curthread.  Doing it layer by layer
makes it easy to review.

> Before you start doing a lot of small changes (AKA continous churn)
> please formulate your goals and get some public feedback.

I'll do that; I won't go changing kernel APIs like that.  But I'd like to
untangle things that complicate the picture, and the NFS server code
is one of them.

>  My immediate
> question that I want answered before you ever start touching the code,
> is what you plan to do with
> sys_syscall(struct thread *td, uap)

Probably nothing; those things pretty much always actually use the thread
pointer.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver

[Edward Napierala]

pon., 4 mar 2019 o 13:20 Konstantin Belousov  napisał(a):
>
> On Mon, Mar 04, 2019 at 01:02:36PM +, Edward Tomasz Napierala wrote:
> > Author: trasz
> > Date: Mon Mar  4 13:02:36 2019
> > New Revision: 344758
> > URL: https://svnweb.freebsd.org/changeset/base/344758
> >
> > Log:
> >   Push down td in nfsrvd_dorpc() - make it use curthread instead
> >   of it being explicitly passed as an argument. No functional changes.
> >
> >   The big picture here is that I want to get rid of the 'td' argument
> >   being passed everywhere, and this is the first piece that affects
> >   the NFS server.
> >
> >   Reviewed by:rmacklem
> >   MFC after:  2 weeks
> >   Sponsored by:   DARPA, AFRL
> >   Differential Revision:  https://reviews.freebsd.org/D19417
> >
> > Modified:
> >   head/sys/fs/nfs/nfs_var.h
> >   head/sys/fs/nfsserver/nfs_nfsdkrpc.c
> >   head/sys/fs/nfsserver/nfs_nfsdsocket.c
> >
> > Modified: head/sys/fs/nfs/nfs_var.h
> > ==
> > --- head/sys/fs/nfs/nfs_var.h Mon Mar  4 11:33:49 2019(r344757)
> > +++ head/sys/fs/nfs/nfs_var.h Mon Mar  4 13:02:36 2019(r344758)
> > @@ -283,8 +283,7 @@ int nfsrvd_notsupp(struct nfsrv_descript *, int,
> >
> >  /* nfs_nfsdsocket.c */
> >  void nfsrvd_rephead(struct nfsrv_descript *);
> > -void nfsrvd_dorpc(struct nfsrv_descript *, int, u_char *, int, u_int32_t,
> > -NFSPROC_T *);
> > +void nfsrvd_dorpc(struct nfsrv_descript *, int, u_char *, int, u_int32_t);
> >
> >  /* nfs_nfsdcache.c */
> >  void nfsrvd_initcache(void);
> >
> > Modified: head/sys/fs/nfsserver/nfs_nfsdkrpc.c
> > ==
> > --- head/sys/fs/nfsserver/nfs_nfsdkrpc.c  Mon Mar  4 11:33:49 2019  
> >   (r344757)
> > +++ head/sys/fs/nfsserver/nfs_nfsdkrpc.c  Mon Mar  4 13:02:36 2019  
> >   (r344758)
> > @@ -323,7 +323,6 @@ static int
> >  nfs_proc(struct nfsrv_descript *nd, u_int32_t xid, SVCXPRT *xprt,
> >  struct nfsrvcache **rpp)
> >  {
> > - struct thread *td = curthread;
> >   int cacherep = RC_DOIT, isdgram, taglen = -1;
> >   struct mbuf *m;
> >   u_char tag[NFSV4_SMALLSTR + 1], *tagstr = NULL;
> > @@ -384,7 +383,7 @@ nfs_proc(struct nfsrv_descript *nd, u_int32_t xid, SVC
> >   if (cacherep == RC_DOIT) {
> >   if ((nd->nd_flag & ND_NFSV41) != 0)
> >   nd->nd_xprt = xprt;
> > - nfsrvd_dorpc(nd, isdgram, tagstr, taglen, minorvers, td);
> > + nfsrvd_dorpc(nd, isdgram, tagstr, taglen, minorvers);
> >   if ((nd->nd_flag & ND_NFSV41) != 0) {
> >   if (nd->nd_repstat != NFSERR_REPLYFROMCACHE &&
> >   (nd->nd_flag & ND_SAVEREPLY) != 0) {
> >
> > Modified: head/sys/fs/nfsserver/nfs_nfsdsocket.c
> > ==
> > --- head/sys/fs/nfsserver/nfs_nfsdsocket.cMon Mar  4 11:33:49 2019  
> >   (r344757)
> > +++ head/sys/fs/nfsserver/nfs_nfsdsocket.cMon Mar  4 13:02:36 2019  
> >   (r344758)
> > @@ -367,7 +367,7 @@ int nfsrv_writerpc[NFS_NPROCS] = { 0, 0, 1, 0, 0, 0, 0
> >
> >  /* local functions */
> >  static void nfsrvd_compound(struct nfsrv_descript *nd, int isdgram,
> > -u_char *tag, int taglen, u_int32_t minorvers, NFSPROC_T *p);
> > +u_char *tag, int taglen, u_int32_t minorvers);
> >
> >
> >  /*
> > @@ -475,14 +475,17 @@ nfsrvd_statend(int op, uint64_t bytes, struct bintime
> >   */
> >  APPLESTATIC void
> >  nfsrvd_dorpc(struct nfsrv_descript *nd, int isdgram, u_char *tag, int 
> > taglen,
> > -u_int32_t minorvers, NFSPROC_T *p)
> > +u_int32_t minorvers)
> >  {
> >   int error = 0, lktype;
> >   vnode_t vp;
> >   mount_t mp = NULL;
> >   struct nfsrvfh fh;
> >   struct nfsexstuff nes;
> > + struct thread *p;
> >
> > + p = curthread;
> > +
> >   /*
> >* Get a locked vnode for the first file handle
> >*/
> > @@ -557,7 +560,7 @@ nfsrvd_dorpc(struct nfsrv_descript *nd, int isdgram, u
> >* The group is indicated by the value in nfs_retfh[].
> >*/
> >   if (nd->nd_flag & ND_NFSV4) {
> > - nfsrvd_compound(nd, isdgram, tag, taglen, minorvers, p);
> > + nfsrvd_compound(nd, isdgram, tag, taglen, minorvers);
> >   } else {
> >   struct bintime start_time;
> >
> > @@ -620,7 +623,7 @@ out:
> >   */
> >  static void
> >  nfsrvd_compound(struct nfsrv_descript *nd, int isdgram, u_char *tag,
> > -int taglen, u_int32_t minorvers, NFSPROC_T *p)
> > +int taglen, u_int32_t minorvers)
> >  {
> >   int i, lktype, op, op0 = 0, statsinprog = 0;
> >   u_int32_t *tl;
> > @@ -635,6 +638,9 @@ nfsrvd_compound(struct nfsrv_descript *nd, int isdgram
> >   fsid_t cur_fsid, save_fsid;
> >   static u_int64_t compref = 0;
> >   struct bintime start_time;
> > + struct thread *p;
> > 

Re: svn commit: r344021 - head/share/man/man7

[Edward Napierala]

niedz., 17 lut 2019 o 16:05 Enji Cooper  napisał(a):
>
>
> > On Feb 17, 2019, at 04:17, Jan Beich  wrote:
> >
> > Edward Tomasz Napierala  writes:
> >
> >> ... while the
> >> +.Em quarterly
> >
> > .Em looks unnecessary as "the" is enough. /quarterly is a package set
> > (or repository), not an actual name of the branch.
> >
> > - /head -> /latest
> > - /branches/*Q* -> /quarterly
> > - /tags/RELEASE_* -> /release_*

Jan, do you mean to drop just this single .Em, drop .Ems in all places
it's being
used for "quarterly", or drop it for both "quarterly" and "head"?

> >> +subdirectory, eg:
> >
> > Did you mean "subdirectory e.g.," ?
> >
> > https://english.stackexchange.com/questions/16172/should-i-always-use-a-comma-after-e-g-or-i-e
>
> It’s actually “subdirectory, e.g.,”. igor will correct the usage :).

It would, if only I've spelled it correctly, as "e.g." and not "eg".

I'm not sure about this case, though, because it's followed by a colon.
Should it become "subdirectory, e.g.,", and then the URL, without the colon?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

sob., 26 sty 2019 o 01:38 Rodney W. Grimes
 napisał(a):
>
> > On 0125T1705, Rodney W. Grimes wrote:
> > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala  
> > > > > wrote:
> > >
> > > Chop with the big axe most of this as I need to clarify a miss statement.
> > > ...
> > > > > The change we're discussing doesn't affect upgrades at all - it's only
> > > > > for new installs.
> > > >
> > > > mergemaster, iirc, will merge in changes to etc files after an upgrade.
> > > > So this would effect anybody that goes through an upgrade and performs 
> > > > mergemaster.
> > >
> > > Correct, and to my knowledge there is no way to stop that effect.
> >
> > Won't happen in this case, this doesn't apply to files in /etc
> > at all; it only applies to the default /root/.shrc and /root/.profile
> > that get installed on fresh systems.
>
> mergemaster is the wrong term here, freebsd-update is
> going to want to merge this change.

Are you sure freebsd-update also updates root's private configuration
files?  I've never used it, but this seems somewhat surprising.

> > > > >  And it doesn't affect root by default, you
> > > > > need to change their shell from csh(1) to sh(1).
> > > >
> > > > By your own commit messages admission, this is for the toor account, so 
> > > > it does affect a user (and as you were keen to point out, users with 
> > > > the default shell).
> > >
> > > Further it effects root any time root types "sh" or "/bin/sh"
> > > and intentially invokes sh interactive for some reason,
> > > something I do more often than I care to admit simply
> > > cause I know what I want to do is much easier in that
> > > shell.
> >
> > It doesn't.  For sh(1) to read ~/.shrc (/root/.shrc in this case)
> > you need to have ENV set; the default /root/.profile only sets
> > it when sh(1) is your login shell.
> I do not see any conditional logic in /root/.profile,
> what your mis stating is that /root/.profile is not
> run for a login shell, so ENV would not be set unless
> something else caused /root/.profile to be read, aka
> source ~/.profile

Correction: /root/.profile is not-run for non-login shell, so ENV
wouldn't be set.  Yeah, that's what I've meant.

> >   Which means, this doesn't
> > change the behaviour when you casually run "sh" or "/bin/sh"
> > as root; sh needs to be set up as login shell for this to take
> > effect.
>
> Again I do not see any conditional logic in /root/.profile
> that would make that true.  A su - toor would be effected.

As opposed to 'su - root' or plain '/bin/sh', right.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

On 0125T1647, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 1:13 AM, Edward Napierala  wrote:
> > 
> > On 0125T1530, Devin Teske wrote:
> >> 
> >> 
> >>> On Jan 25, 2019, at 12:28 AM, Edward Napierala  wrote:
> >>> 
> >>> On 0125T1441, Devin Teske wrote:
> >>>> 
> >>>> 
> >>>>> On Jan 25, 2019, at 1:37 PM, Edward Napierala  wrote:
> >>>>> 
> >>>>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> >>>>>  >>>>> <mailto:free...@pdx.rh.cn85.dnsmgr.net>> napisał(a):
> >>>>>> 
> >>>>>>> Author: trasz
> >>>>>>> Date: Fri Jan 25 17:09:26 2019
> >>>>>>> New Revision: 343440
> >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/343440
> >>>>>>> 
> >>>>>>> Log:
> >>>>>>> Comment out the default sh(1) aliases for root, introduced in r343416.
> >>>>>>> The rest of this stuff is still to be discussed, but I think at this
> >>>>>>> point we have the agreement that the aliases should go.
> >>>>>>> 
> >>>>>>> MFC after:  2 weeks
> >>>>>>> Sponsored by:   DARPA, AFRL
> >>>>>> 
> >>>>>> Please just revert this and the prior commit out, and when
> >>>>>> the path forward is clear commit it.  I would not want any of this
> >>>>>> merged to 12/ or 11/ until the time that it is all settled.
> >>>>> 
> >>>>> Oops, my bad - neither this nor the previous commit is supposed
> >>>>> to be MFC-ed; the "2 weeks" above comes from my default Subversion
> >>>>> config.
> >>>>> 
> >>>>> Regarding the backoff - just a few hours ago you said you don't have
> >>>>> any problem with this, except for aliases and the default ENV.  The
> >>>>> aliases problem has been addressed, and you hadn't yet responded
> >>>>> to my explanations regarding the ENV.  Another committer asked for
> >>>>> backoff, because "sh is not an interactive shell", while in fact sh(1)
> >>>>> is FreeBSD's default interactive shell except for root.  Finally, 
> >>>>> there's
> >>>>> one person who asked for revert, but without giving any reasons
> >>>>> whatsoever.
> >>>>> 
> >>>>> So far nobody had proposed any scenario where this would break
> >>>>> anything, or even affect existing users.  It seems like a typical 
> >>>>> bikeshed
> >>>>> situation.
> >>>> 
> >>>> It is not clear to me after reading r343416 and D18872 what this change 
> >>>> is trying to solve.
> >>> 
> >>> The idea is to make it easy to replace the default root shell - which
> >>> many people consider broken, due to not supporting basic shell syntax - 
> >>> with
> >>> something that actually works.
> >> 
> >> How exactly does changing PS1 or adding 6 aliases fix the "basic shell 
> >> syntax" which you claim to be unsupported?
> >> 
> >> If the number of aliases added to a shell are a measure of its brokenness, 
> >> then bash must be hella broken (I have 43 aliases in my bash_profile).
> > 
> > The aliases are gone.
> 
> Fair enough, albeit the topic was r343416 and D18872.
> 
> 
> >  Human-friendly PS1 is considered a standard feature
> > nowadays.
> 
> I fail to see how ''$ " is unfriendly.

How many people you know use a plain '$' as a shell prompt,
because they like it that way?

> In fact, I am a bit amiss how you don't see "\u@\h:\w \\$ " as being 
> unfriendly to TCL/Expect.
> 
> While it's certainly possible to use "expect -re" and formulate around it, 
> the change itself would break existing scripts.
> 
> 
> 
> >  But the way it fixes things is that it makes it easy to replace
> > csh with a shell which actually groks shell syntax and is reasonably useful
> > out of the box,
> 
> This sounds like you are claiming csh is broken.
> 
> I see where you may be coming from:
> 
> + /bin/sh supports a syntax
> + bash supports nearly all of /bin/sh
> + zsh supports nearly all of /bin/sh
> 
> So [t]csh must seem broken to you because it doesn't fall

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

On 0125T1705, Rodney W. Grimes wrote:
> > > On Jan 25, 2019, at 1:13 AM, Edward Napierala  wrote:
> 
> Chop with the big axe most of this as I need to clarify a miss statement.
> ...
> > > The change we're discussing doesn't affect upgrades at all - it's only
> > > for new installs.
> > 
> > mergemaster, iirc, will merge in changes to etc files after an upgrade.
> > So this would effect anybody that goes through an upgrade and performs 
> > mergemaster.
> 
> Correct, and to my knowledge there is no way to stop that effect.

Won't happen in this case, this doesn't apply to files in /etc
at all; it only applies to the default /root/.shrc and /root/.profile
that get installed on fresh systems.

> > >  And it doesn't affect root by default, you
> > > need to change their shell from csh(1) to sh(1).
> > 
> > By your own commit messages admission, this is for the toor account, so it 
> > does affect a user (and as you were keen to point out, users with the 
> > default shell).
> 
> Further it effects root any time root types "sh" or "/bin/sh"
> and intentially invokes sh interactive for some reason,
> something I do more often than I care to admit simply
> cause I know what I want to do is much easier in that
> shell.

It doesn't.  For sh(1) to read ~/.shrc (/root/.shrc in this case)
you need to have ENV set; the default /root/.profile only sets
it when sh(1) is your login shell.  Which means, this doesn't
change the behaviour when you casually run "sh" or "/bin/sh"
as root; sh needs to be set up as login shell for this to take
effect.

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

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

Excuse my brevity; I'll address the rest after getting some sleep,
but I'd like to clarify one crucial thing.  I think that's actually
_the_ point where I screwed up: I didn't expect people to actually
care for what I considered a cosmetic change, and I didn't realize
the need to explain what this commit does _not_ affect.

(And I've been reminded by rgrimes@ more than once that I should pay
more attention to my commit messages.  Oh well.  Perhaps I'll learn
this time.)

On 0125T1647, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 1:13 AM, Edward Napierala  wrote:

[..]

> >>>> PS1 should have a reasonable default. If that default is not reasonable, 
> >>>> then we should change the C code.
> >>>> 
> >>>> Maybe I see things differently, but I'd rather see PS1 default change so 
> >>>> no profile/shrc change is necessary.
> >>> 
> >>> Thank you, that's actually a valid argument.  I believe that's also what
> >>> bash does.  It would be more intrusive, though, and I kind of don't like
> >>> the idea of hardcoding things that can easily be dealt with with in a more
> >>> "high-level" way.
> >>> 
> >>>> I prefer that sh, in its default configuration, not attempt to read 
> >>>> $HOME/.shrc, for security reasons.
> >>> 
> >>> Can you elaborate?  It already reads $HOME/.profile; how is $HOME/.shrc
> >>> different?
> >> 
> >> If you read "The Cuckoo's Egg" by Clifford Stoll, you'll understand the 
> >> importance of "one place to exploit versus two."
> >> 
> >> (situation)
> >> 
> >> Say you've been running FreeBSD for 20 years (it turned 25 years old last 
> >> year, so this is not only possible, but plausible).
> >> You know all the areas of interest where an attacker could inject code.
> >> You take care to lock down each one.
> >> But come to your surprise ...
> >> 
> >> (hypothetical)
> >> 
> >> 6 months after you upgraded from 11.2 to the latest 12.x, you find that 
> >> you didn't take into account that $HOME/.profile (which you perhaps locked 
> >> down with a "chflags" command) now branches out to a new file which you've 
> >> never taken steps to lock down, keep an eye on, or audit (e.g., by using 
> >> DTrace remote-logging, tripwire, or other means). You only found out 6 
> >> months after the upgrade because someone exploited it. At that point, the 
> >> security event has already occurred.
> >> 
> >> When I worked at "the banks" shit like this was always on our radar. 
> >> Changes like this were often cited for the reason why one bank moved to 
> >> BoKs for security.
> > 
> > The change we're discussing doesn't affect upgrades at all - it's only
> > for new installs.
> 
> mergemaster, iirc, will merge in changes to etc files after an upgrade.
> So this would effect anybody that goes through an upgrade and performs 
> mergemaster.

No, it won't - it doesn't affect files in /etc at all.  It doesn't
affect stuff that's being installed by mergemaster(8), nor stuff
installed by 'make install'.  It only affects the default /root/.profile
and /root/.shrc, as installed by bsdinstall(8) or shipped as VM or SD
card images.

[..]

> >  And it doesn't affect root by default, you
> > need to change their shell from csh(1) to sh(1).
> 
> By your own commit messages admission, this is for the toor account, so it 
> does affect a user (and as you were keen to point out, users with the default 
> shell).

Yes, but it only affects the toor account for new installs, and the account
is locked by default.

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

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

On 0125T1530, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 12:28 AM, Edward Napierala  wrote:
> > 
> > On 0125T1441, Devin Teske wrote:
> >> 
> >> 
> >>> On Jan 25, 2019, at 1:37 PM, Edward Napierala  wrote:
> >>> 
> >>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> >>> mailto:free...@pdx.rh.cn85.dnsmgr.net>> 
> >>> napisał(a):
> >>>> 
> >>>>> Author: trasz
> >>>>> Date: Fri Jan 25 17:09:26 2019
> >>>>> New Revision: 343440
> >>>>> URL: https://svnweb.freebsd.org/changeset/base/343440
> >>>>> 
> >>>>> Log:
> >>>>> Comment out the default sh(1) aliases for root, introduced in r343416.
> >>>>> The rest of this stuff is still to be discussed, but I think at this
> >>>>> point we have the agreement that the aliases should go.
> >>>>> 
> >>>>> MFC after:  2 weeks
> >>>>> Sponsored by:   DARPA, AFRL
> >>>> 
> >>>> Please just revert this and the prior commit out, and when
> >>>> the path forward is clear commit it.  I would not want any of this
> >>>> merged to 12/ or 11/ until the time that it is all settled.
> >>> 
> >>> Oops, my bad - neither this nor the previous commit is supposed
> >>> to be MFC-ed; the "2 weeks" above comes from my default Subversion
> >>> config.
> >>> 
> >>> Regarding the backoff - just a few hours ago you said you don't have
> >>> any problem with this, except for aliases and the default ENV.  The
> >>> aliases problem has been addressed, and you hadn't yet responded
> >>> to my explanations regarding the ENV.  Another committer asked for
> >>> backoff, because "sh is not an interactive shell", while in fact sh(1)
> >>> is FreeBSD's default interactive shell except for root.  Finally, there's
> >>> one person who asked for revert, but without giving any reasons
> >>> whatsoever.
> >>> 
> >>> So far nobody had proposed any scenario where this would break
> >>> anything, or even affect existing users.  It seems like a typical bikeshed
> >>> situation.
> >> 
> >> It is not clear to me after reading r343416 and D18872 what this change is 
> >> trying to solve.
> > 
> > The idea is to make it easy to replace the default root shell - which
> > many people consider broken, due to not supporting basic shell syntax - with
> > something that actually works.
> 
> How exactly does changing PS1 or adding 6 aliases fix the "basic shell 
> syntax" which you claim to be unsupported?
> 
> If the number of aliases added to a shell are a measure of its brokenness, 
> then bash must be hella broken (I have 43 aliases in my bash_profile).

The aliases are gone.  Human-friendly PS1 is considered a standard feature
nowadays.  But the way it fixes things is that it makes it easy to replace
csh with a shell which actually groks shell syntax and is reasonably useful
out of the box, with ~/.shrc you can customize etc.  Think of it as a POLA,
but horizontally, for folks coming from other systems, instead of the usual
one.

> Also, the perhaps anecdotal consideration of brokenness is nearly laughable 
> -- these can largely be lumped into one of three categories:
> 
> a. Considered broken because it doesn't support bashisms
> b. Considered broken because lack of syntactical knowledge
> c. Considered broken because (no reason given)

It's broken because it doesn't accept what people call the shell syntax.
Sure, some folks do realize there used to be something called 'csh',
and people kept using it even into the nineties.  But most users aren't
actually that much into computing history; they expect the system to just
work like they expect.

> Other languages might fit that description as well, and so we should take 
> this anecdote of "many people consider broken" with a grain of salt.
> 
> I personally have written more than 50,000 lines of shell for the FreeBSD 
> base OS -- all utilizing /bin/sh

And that's one of the reasons why I really apprieciate your response.

> >> PS1 should have a reasonable default. If that default is not reasonable, 
> >> then we should change the C code.
> >> 
> >> Maybe I see things differently, but I'd rather see PS1 default change so 
> >> no profile/shrc change is necessary.
> > 
> > Thank you, that's actually a valid argument.  I believe that's also what
> > b

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

On 0125T1441, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 1:37 PM, Edward Napierala  wrote:
> > 
> > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > mailto:free...@pdx.rh.cn85.dnsmgr.net>> 
> > napisał(a):
> >> 
> >>> Author: trasz
> >>> Date: Fri Jan 25 17:09:26 2019
> >>> New Revision: 343440
> >>> URL: https://svnweb.freebsd.org/changeset/base/343440
> >>> 
> >>> Log:
> >>>  Comment out the default sh(1) aliases for root, introduced in r343416.
> >>>  The rest of this stuff is still to be discussed, but I think at this
> >>>  point we have the agreement that the aliases should go.
> >>> 
> >>>  MFC after:  2 weeks
> >>>  Sponsored by:   DARPA, AFRL
> >> 
> >> Please just revert this and the prior commit out, and when
> >> the path forward is clear commit it.  I would not want any of this
> >> merged to 12/ or 11/ until the time that it is all settled.
> > 
> > Oops, my bad - neither this nor the previous commit is supposed
> > to be MFC-ed; the "2 weeks" above comes from my default Subversion
> > config.
> > 
> > Regarding the backoff - just a few hours ago you said you don't have
> > any problem with this, except for aliases and the default ENV.  The
> > aliases problem has been addressed, and you hadn't yet responded
> > to my explanations regarding the ENV.  Another committer asked for
> > backoff, because "sh is not an interactive shell", while in fact sh(1)
> > is FreeBSD's default interactive shell except for root.  Finally, there's
> > one person who asked for revert, but without giving any reasons
> > whatsoever.
> > 
> > So far nobody had proposed any scenario where this would break
> > anything, or even affect existing users.  It seems like a typical bikeshed
> > situation.
> 
> It is not clear to me after reading r343416 and D18872 what this change is 
> trying to solve.

The idea is to make it easy to replace the default root shell - which
many people consider broken, due to not supporting basic shell syntax - with
something that actually works.

> PS1 should have a reasonable default. If that default is not reasonable, then 
> we should change the C code.
> 
> Maybe I see things differently, but I'd rather see PS1 default change so no 
> profile/shrc change is necessary.

Thank you, that's actually a valid argument.  I believe that's also what
bash does.  It would be more intrusive, though, and I kind of don't like
the idea of hardcoding things that can easily be dealt with with in a more
"high-level" way.

> I prefer that sh, in its default configuration, not attempt to read 
> $HOME/.shrc, for security reasons.

Can you elaborate?  It already reads $HOME/.profile; how is $HOME/.shrc
different?

> Further, it is documented that the contents of ENV may be ignored in 
> privileged mode, negating these changes.

True - so if someone finds the idea of having a suid shell useful - from
what I undestand that's what the privileged mode boils down to - this
change will be a no-op.  I seriously hope nobody does, though.

> If you wanted your new shiny default PS1 to actually have an effect in all 
> modes (including privileged mode, where you probably want it), you would have 
> put it in /etc/profile and not in a file that is wholly ignored by some modes 
> (e.g., privileged mode).
> So the solution is not even the right one for the desired result.

I would, if only it didn't break zsh, and perhaps others.  The
problem here is that zsh uses different syntax for PS1, _and_
it also parses /etc/profile.

And no, I don't care at all about privileged mode, I can't imagine
a situation when using it would be a good idea.

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

Re: svn commit: r343440 - head/bin/sh

[Edward Napierala]

pt., 25 sty 2019 o 19:57 Rodney W. Grimes
 napisał(a):
>
> > Author: trasz
> > Date: Fri Jan 25 17:09:26 2019
> > New Revision: 343440
> > URL: https://svnweb.freebsd.org/changeset/base/343440
> >
> > Log:
> >   Comment out the default sh(1) aliases for root, introduced in r343416.
> >   The rest of this stuff is still to be discussed, but I think at this
> >   point we have the agreement that the aliases should go.
> >
> >   MFC after:  2 weeks
> >   Sponsored by:   DARPA, AFRL
>
> Please just revert this and the prior commit out, and when
> the path forward is clear commit it.  I would not want any of this
> merged to 12/ or 11/ until the time that it is all settled.

Oops, my bad - neither this nor the previous commit is supposed
to be MFC-ed; the "2 weeks" above comes from my default Subversion
config.

Regarding the backoff - just a few hours ago you said you don't have
any problem with this, except for aliases and the default ENV.  The
aliases problem has been addressed, and you hadn't yet responded
to my explanations regarding the ENV.  Another committer asked for
backoff, because "sh is not an interactive shell", while in fact sh(1)
is FreeBSD's default interactive shell except for root.  Finally, there's
one person who asked for revert, but without giving any reasons
whatsoever.

So far nobody had proposed any scenario where this would break
anything, or even affect existing users.  It seems like a typical bikeshed
situation.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r343416 - head/bin/sh

[Edward Napierala]

The aliases are gone, let's continue on the remaining bits below.

On 0125T0539, Rodney W. Grimes wrote:
> > pt., 25 sty 2019 o 11:24 Rodney W. Grimes
> >  napisa?(a):
> > >
> > > > On 0124T1555, Rodney W. Grimes wrote:
> > > > > > Author: trasz
> > > > > > Date: Thu Jan 24 23:34:51 2019
> > > > > > New Revision: 343416

[..]

> > > People that want a Borne shell type interactive shell
> > > invariable choose bash, ksh or some other shell, not
> > > our /bin/sh which is lean mean and a fast machine
> > > because the base system uses it so much.
> > 
> > That's true.  But we discourage using shells from ports/packages
> > as root shell. 
> 
> I am not so sure on that, it use to be more so because /bin/sh
> was statically linked and needed no lib's to run, well that
> is gone out the window.  There is also the issue that other
> shells are installed into /usr/local/bin, which may or may
> not be mounted (less likely now that zfs and be's are all
> the rage.)  Most of the reasons to discourage a pkg root
> shell are now gone.

Yeah.  Still, the commit doesn't make it in any way harder,
and provides a more familiar default.

> > The easiest thing for a new user to do if they want
> > a Bourne-compatible shell for root is to just use chsh(1).  And
> > here's what happens: you get greeted with an alien-looking
> > (new folks usually come from Linux or OSX background) '$'
> If that is alien looking then they need some education on
> how the tool they are using works and how to use it.

It is alien, because it's different from their experience
from other systems they are used to.  Sure, they will know
it is _a_ prompt.  It's just that they'll consider it quite
weird and not very useful, in particular the lack of directory
part.

There's also the consistency argument - our tcsh doesn't use
a plain '%'.

> > prompt.  Which is not a problem, of course, just define PS1,
> > and perhaps some aliases, in a newly created /root/.shrc.
> > Except... that doesn't work, despite the fact that it works just
> > fine for accounts other than root, and that's also how you would
> > fix it with bash.  And then you end up having to read the sh(1)
> > manual page to discover the ENV.
> Or read the .profile of there user account and actually
> understand some of these details.  IMHO this is about user
> education and rather than dumb the system down we should
> try to raise the level of knowledge.

I think this is the main point of disagreement.  Sure, learning
is good, but I'm a big fan of providing useful defaults if possible.
Our default csh prompt - now also used by sh - is a pretty good,
imho.  And it's not just FreeBSD that's been using it (with csh)
for years - Ubuntu comes with something pretty close.

[..]

> > > I am sure there are a few of us around that would actually
> > > like to see the ones left go away and view them as contamination
> > > to what should be the domain of a site administrator or
> > > personal taste.
> > >
> > > Just as some of us would really rather have
> > > cd home
> > > return the proper error rather than doing some
> > > magic when there is not a ./home to cd into.
> > > And having ls .. ; cd ..; ls give 2 different outputs
> > > is just.. well something that should confuse the
> > > heck out of a new user, yet seems completely fine
> > > to have in the system.  Note the above becomes
> > > a fatal mistake when the second ls is a rm
> > > with wild cards.
> > 
> > That's a historical mistake we can't really fix, I'm afraid,
> > unless we want to break compatibility with other systems.
> 
> I seriously doubt that are a lot of people depending
> on cd home to do what it does, most would be lazy
> like me and type cd ~.

This is somewhat orthogonal to the main topic.  But it's not
about 'cd home' at all; it's the result of an architectural
problem in Unix kernel that most shells try to work around.

> > > Howerver I do understand the need to assist the new person
> > > or less informed that do not pack an emacs size environment
> > > with them that there are nifty things they can do
> > > to make life easier.  Perhaps making more extensive
> > > comments in the skel files, or even adding pointers in them
> > > to a set of /usr/share/example/ files?  Perhaps pointers
> > > in roots .files to the skel files as "for a better example
> > > of what can be done in this file see foo".
> > 
> > I'd expect pretty much every user new to FreeBSD to already
> > know about what they can do with shell files.  And there's
> > plenty of advice for that too, including the sources mentioned
> > by Cy.
> > 
> > There are two things, however: first, they don't neccessarily
> > know about things specific to FreeBSD sh(1), such as requiring
> > the ENV to be set to actually read the ~/.shrc.
> 
> Is that only the freebsd shell, I thought most shells need
> special stuff done to get them to do much more than processes
> .profile.

Bash - which is what I'd expect most new users to have experience
with - reads 

Re: svn commit: r343416 - head/bin/sh

[Edward Napierala]

pt., 25 sty 2019 o 11:24 Rodney W. Grimes
 napisał(a):
>
> > On 0124T1555, Rodney W. Grimes wrote:
> > > > Author: trasz
> > > > Date: Thu Jan 24 23:34:51 2019
> > > > New Revision: 343416
> > > > URL: https://svnweb.freebsd.org/changeset/base/343416
> > > >
> > > > Log:
> > > >   Install .shrc for root, and set PS1 for the toor account.
> > >
> > > And a dozen other aliases :-(
> >
> > Six, and they are exactly the same as for ordinary users.
>
> Your right, I drifted to hyperbolie on that,
> but 1 is too many in this case.

Okay, I don't have a problem with removing the default aliases.
(And from all the aliases that are actually there in the default shrc,
the only one I actually do like and use is "ll").

> > But yeah, I can see the point of not defining any aliases
> > by default for the root user.  Would the change be acceptable
> > if the aliases were commented out?  This would be still quite
> > close to the situation for csh.
>
> There is also the issue that we are now going to open 1
> more file every time an interactive /bin/sh is spawned,
> and that file is full of comments, to me thats a waste
> of cycles for probably 95% of the systems out there.

True, but I don't think that's even measurable, at least for
interactive shells (as opposed to shells used to run scripts,
for which the commit changes nothing).

> People that want a Borne shell type interactive shell
> invariable choose bash, ksh or some other shell, not
> our /bin/sh which is lean mean and a fast machine
> because the base system uses it so much.

That's true.  But we discourage using shells from ports/packages
as root shell.  The easiest thing for a new user to do if they want
a Bourne-compatible shell for root is to just use chsh(1).  And
here's what happens: you get greeted with an alien-looking
(new folks usually come from Linux or OSX background) '$'
prompt.  Which is not a problem, of course, just define PS1,
and perhaps some aliases, in a newly created /root/.shrc.
Except... that doesn't work, despite the fact that it works just
fine for accounts other than root, and that's also how you would
fix it with bash.  And then you end up having to read the sh(1)
manual page to discover the ENV.

> > > Please do not contaiminate the prestine environment with
> > > personal preferences.  In the start of the project we
> > > did a great deal of work to remove and eliminate these
> > > types of things, only the few csh aliases where retained.
> >
> > Indeed, and those are pretty much the same aliases.
>
> But those alias have never been there for sh, the few
> we did keep was for historerical history, they had been
> in roots .cshrc for a decade and people got upset when
> we tried to remove them, thus we settled on just the
> few people stated as being the most wanted and used.

They are there in share/skel/dot.shrc, just not for root.
But again - I agree regarding the aliases.

> I am sure there are a few of us around that would actually
> like to see the ones left go away and view them as contamination
> to what should be the domain of a site administrator or
> personal taste.
>
> Just as some of us would really rather have
> cd home
> return the proper error rather than doing some
> magic when there is not a ./home to cd into.
> And having ls .. ; cd ..; ls give 2 different outputs
> is just.. well something that should confuse the
> heck out of a new user, yet seems completely fine
> to have in the system.  Note the above becomes
> a fatal mistake when the second ls is a rm
> with wild cards.

That's a historical mistake we can't really fix, I'm afraid,
unless we want to break compatibility with other systems.

> Howerver I do understand the need to assist the new person
> or less informed that do not pack an emacs size environment
> with them that there are nifty things they can do
> to make life easier.  Perhaps making more extensive
> comments in the skel files, or even adding pointers in them
> to a set of /usr/share/example/ files?  Perhaps pointers
> in roots .files to the skel files as "for a better example
> of what can be done in this file see foo".

I'd expect pretty much every user new to FreeBSD to already
know about what they can do with shell files.  And there's
plenty of advice for that too, including the sources mentioned
by Cy.

There are two things, however: first, they don't neccessarily
know about things specific to FreeBSD sh(1), such as requiring
the ENV to be set to actually read the ~/.shrc.

And second, it's just nice to new users to make stuff just a tiny
bit more familiar looking.  This includes installing the file they can
edit (/root/.shrc), and setting the prompt to something that
resembles other systems.  That's exactly what we do for csh(1).

> > > This is really the domain of a systems administrator to
> > > decide and making work for them to clean this out is
> > > not going to make them happy.
> >
> > Problem is, we're in a strage situation where we ship with
> > root shell which is 

Re: svn commit: r342881 - head/share/skel

[Edward Napierala]

śr., 9 sty 2019 o 16:41 Rodney W. Grimes
 napisał(a):
>
> > Author: trasz
> > Date: Wed Jan  9 11:04:27 2019
> > New Revision: 342881
> > URL: https://svnweb.freebsd.org/changeset/base/342881
> >
> > Log:
> >   Make sh(1) recognize the default $HOME.  By default /home
> >   is a symlink; without this change, when you log in, sh(1)
> >   won't realize the current directory (eg '/usr/home/test')
> >   is the same as $HOME ('/home/test').
>
> Arguably it shouldnt know any of that.

sh(1) needs to know that in order to properly shorten the current
directory path (in prompt) to "~" when you're there.

> Or that $Home is ~ either
> I hate that if I "cd home" and there is not a directory
> where I am at called home it takes me to ~/$home,s
> that also has caused a few script debugging to be
> a royal Pita having to force ./$variable to stop
> home from being treated special.

But none of that seems related to the change above, does it?
All the patch does is: if your current directory is $HOME, but
it's spelled differently, run "cd".  The only thing that does, in turn,
is making sh(1) set the $ENV variable, which it uses to track
the current "logical working directory", eg /home/test. It cannot
obtain that information otherwise, because getcwd(3) in that
directory returns its "physical path", eg /usr/home/test.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r342812 - head/share/skel

[Edward Napierala]

niedz., 6 sty 2019 o 16:50 Cy Schubert  napisał(a):
>
> In message <201901061623.x06gns1w057...@repo.freebsd.org>, Edward
> Tomasz Napier
> ala writes:
> > Author: trasz
> > Date: Sun Jan  6 16:23:28 2019
> > New Revision: 342812
> > URL: https://svnweb.freebsd.org/changeset/base/342812
> >
> > Log:
> >   Give sh(1) a proper default prompt instead of just "$".
> >
> >   Reviewed by:jilles
> >   MFC after:  2 weeks
> >   Relnotes:   totally
> >   Sponsored by:   DARPA, AFRL
> >   Differential Revision:  https://reviews.freebsd.org/D18697
> >
> > Modified:
> >   head/share/skel/dot.shrc
> >
> > Modified: head/share/skel/dot.shrc
> > =
> > =
> > --- head/share/skel/dot.shrc  Sun Jan  6 05:07:52 2019(r342811)
> > +++ head/share/skel/dot.shrc  Sun Jan  6 16:23:28 2019(r342812)
> > @@ -32,8 +32,8 @@ alias g='egrep -i'
> >  # alias rm='rm -i'
> >
> >
> > -# # set prompt: ``username@hostname:directory $ ''
> > -# PS1="`whoami`@\h:\w \\$ "
> > +# set prompt: ``username@hostname:directory $ ''
> > +PS1="`whoami`@\h:\w \\$ "
> >
> >  # search path for cd(1)
> >  # CDPATH=:$HOME
> >
>
> Hmmm. At $JOB the RHEL servers use this prompt. IMO the prompt is
> unwieldy and distracting. Instead of \w could we use \W instead?

The whole point of this change is to make things a little less weird
for newcomers; existing users either use one of the shells from ports,
or just carry their own shell rc file with their preferred PS1; either way
they probably won't even notice.

That's why I chose to follow the _actual_ status quo, both in FreeBSD
(the new prompt is the same as the csh(1) one, apart from the '$')
and Linux.  Thus the '\w'.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r341344 - head/share/man/man7

[Edward Napierala]

pt., 30 lis 2018 o 17:47 John Baldwin  napisał(a):
>
> On 11/30/18 9:37 AM, Ian Lepore wrote:
> > On Fri, 2018-11-30 at 16:01 +, Edward Tomasz Napierala wrote:
> >> Author: trasz
> >> Date: Fri Nov 30 16:01:43 2018
> >> New Revision: 341344
> >> URL: https://svnweb.freebsd.org/changeset/base/341344
> >>
> >> Log:
> >>   Add an example of quick kernel rebuild.
> >>
> >>   MFC after: 2 weeks
> >>   Sponsored by:  DARPA, AFRL
> >>
> >> Modified:
> >>   head/share/man/man7/development.7
> >>
> >> Modified: head/share/man/man7/development.7
> >> =
> >> =
> >> --- head/share/man/man7/development.7Fri Nov 30 15:56:14 2018
> >>  (r341343)
> >> +++ head/share/man/man7/development.7Fri Nov 30 16:01:43 2018
> >>  (r341344)
> >> @@ -127,6 +127,14 @@ case
> >>  cd src/bin/ls
> >>  make clean all install
> >>  .Ed
> >> +.Pp
> >> +Quickly rebuild and reinstall the kernel, only recompiling the files
> >> +changed since last build; note that this will only work if the full
> >> kernel
> >> +build has been completed in the past, not on a fresh source tree:
> >> +.Bd -literal -offset indent
> >> +cd src
> >> +make -j8 kernel KERNFAST=1
> >
> > It might also be worth mentioning that if you're building a kernel
> > other than GENERIC, you can use KERNFAST=configname instead of
> > KERNFAST=1 KERNCONF=configname
>
> You could perhaps just use 'KERNFAST=GENERIC' in this example and it would
> effectively communicate that I think.

We could, but this complicates things.  As it is now, it just doesn't
mention (nor affect) the kernel config name at all, instead using KERNFAST
as a binary flag.  Also, trying to actually set the kernel name using KERNFAST
would probably result in failed build, since for KERNFAST to work, you need
to have previously completed a non-KERNFAST build with that config name.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r341343 - head/share/man/man7

[Edward Napierala]

pt., 30 lis 2018 o 16:43 Bjoern A. Zeeb
 napisał(a):
>
> On 30 Nov 2018, at 16:38, Justin Hibbits wrote:
>
> > On Fri, Nov 30, 2018, 08:36 Warner Losh  >
> >>
> >>
> >> On Fri, Nov 30, 2018 at 9:35 AM Justin Hibbits 
> >> wrote:
> >>
> >>>
> >>>
> >>> On Fri, Nov 30, 2018, 08:24 Bjoern A. Zeeb <
> >>> bzeeb-li...@lists.zabbadoz.net wrote:
> >>>
>  On 30 Nov 2018, at 15:56, Edward Tomasz Napierala wrote:
> 
> > Author: trasz
> > Date: Fri Nov 30 15:56:14 2018
> > New Revision: 341343
> > URL: https://svnweb.freebsd.org/changeset/base/341343
> >
> > Log:
> >   Add an example of rebuilding a single piece of userspace.
> >
> > Modified:
> >   head/share/man/man7/development.7
> >
> > Modified: head/share/man/man7/development.7
> >
>  ==
> > --- head/share/man/man7/development.7 Fri Nov 30 15:52:03
> > 2018  (r341342)
> > +++ head/share/man/man7/development.7 Fri Nov 30 15:56:14
> > 2018  (r341343)
> > @@ -118,6 +118,14 @@ After reboot:
> >  cd src
> >  make -j8 installworld
> >  reboot
> > +.Ed
> > +.Pp
> > +Rebuild and reinstall a single piece of userspace, in this
> > +case
> > +.Xr ls 1 :
> > +.Bd -literal -offset indent
> > +cd src/bin/ls
> > +make clean all install
> 
>  I always thought the proper sequence was:  make clean cleandepend
>  obj
>  depend all install
> 
>  However I have recently figured that it’s not actually true as
>  building inside an individual user space source directory seems to
>  pick
>  up headers etc from the installed machine and not from the source
>  tree.
>  I keep arguing with myself if that had always been the case or
>  not..  I
>  am sure some people here do know better than me (so please see this
>  as
>  asking for help/advise).
> 
>  /bz
> 
> 
>  When I need the build headers I use
> >>>
> >>>
> >>> make buildenv
> >>> ... cd bin/ls
> >>> ... make
> >>>
> >>
> >> You can also do cd bin/ls ; make buildenv now too :)
> >>
> >> Warner
> >>
> >
> > I learn something new everyday! Thanks!
>
> I guess that should be documented as part of the needed steps then?

It should, but as a separate example.  I'd like the default to be as simple
(and quick) as possible.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335941 - head/tools/tools/syscall_timing

[Edward Napierala]

2018-07-04 16:26 GMT+01:00 Rodney W. Grimes 
:

> > > Author: trasz
> > > Date: Wed Jul  4 13:34:43 2018
> > > New Revision: 335941
> > > URL: https://svnweb.freebsd.org/changeset/base/335941
> > >
> > > Log:
> ...
> > > +#ifdef notyet
> > > +   /*
> > > +* XXX: Doesn't work; kernel pipe buffer too small?
> > > +*/
> > > +   { "pipeping_10", test_pipeping, .t_flags = 0, .t_int = 10
> },
> > > +   { "pipeping_100", test_pipeping, .t_flags = 0, .t_int =
> 100 },
> > > + #endif
> >
> > Can you get the size of the pipe buffer and make a run time
> > decision on this?  Not all of us run with defaults
> > Hum, does not seem it is easy to get this pipe size info from userland...
>
> Nvm, if I read the rest of the commit mail correctly you
> already have done this, THANKS!
>

Yeah, I've been merging it from Git, commit by commit, and that's
the result.  Thanks :-)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335004 - head/release/tools

[Edward Napierala]

On 0613T0730, Warner Losh wrote:
> On Wed, Jun 13, 2018 at 6:39 AM, Edward Napierala  wrote:
> 
> > 2018-06-13 12:43 GMT+01:00 Emmanuel Vadot :
> >
> >> On 2018-06-12 18:45, Edward Tomasz Napierala wrote:

[..]

> >> +   echo '# USB OTG virtual serial port' \
> >>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
> >>> +   echo 'ttyU0 "/usr/libexec/getty 3wire"  vt100
> >>>  onifconsole  secure' \
> >>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
> >>> +   echo 'ttyU1 "/usr/libexec/getty 3wire"  vt100
> >>>  onifconsole  secure' \
> >>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
> >>>
> >>
> >>  If I have no OTG port and a usb<->uart plugged into my board that will
> >> give weird result no ?
> >>
> >
> > No, because that port won't be marked as console.  This only applies
> > to the "virtual" OTG serial ports.
> >
> 
> Right, and console is an overloaded term.  Here it just means 'tty marked
> by the kernel that gets a getty started on it automatically after it shows
> up' not 'the device that gets all the kernel I/O.'

Yup.  But again - this reuses the functionality that's already there
in init(8), while avoiding the renaming of device nodes.  And eventually,
those ports might become actual consoles, making things nicely aligned.

[..]

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

Re: svn commit: r335004 - head/release/tools

[Edward Napierala]

2018-06-13 12:43 GMT+01:00 Emmanuel Vadot :

> On 2018-06-12 18:45, Edward Tomasz Napierala wrote:
>
>> Author: trasz
>> Date: Tue Jun 12 16:45:52 2018
>> New Revision: 335004
>> URL: https://svnweb.freebsd.org/changeset/base/335004
>>
>> Log:
>>   Enable USB OTG serial terminal on ARM SD card images.  This configures
>>   the system to make use of USB device mode / USB OTG to provide a
>> "virtual
>>   serial port" on release images.
>>
>>   Reviewed by:  gjb@
>>   MFC after:2 weeks
>>   Relnotes: yes
>>   Sponsored by: The FreeBSD Foundation
>>   Differential Revision:https://reviews.freebsd.org/D15602
>>
>> Modified:
>>   head/release/tools/arm.subr
>>
>> Modified: head/release/tools/arm.subr
>> 
>> ==
>> --- head/release/tools/arm.subr Tue Jun 12 16:44:13 2018(r335003)
>> +++ head/release/tools/arm.subr Tue Jun 12 16:45:52 2018(r335004)
>> @@ -92,6 +92,41 @@ arm_create_user() {
>> return 0
>>  }
>>
>> +arm_setup_usb_otg() {
>> +   # Set up virtual serial port over USB OTG / device mode.
>> +   echo >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '# Required for USB OTG virtual serial port.' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo 'notify 100 {' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '  match "system"  "DEVFS";' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '  match "subsystem"   "CDEV";' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '  match "type""CREATE";' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '  match "cdev""ttyU[0-9]+";' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '  action "/sbin/init q";' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>> +   echo '};' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/devd.conf
>>
>
>  This will be wiped after the first update, better create
> /etc/devd/otg_serial.conf
>

Thanks, I'll look into that.


> +   echo '# USB OTG virtual serial port' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
>> +   echo 'ttyU0 "/usr/libexec/getty 3wire"  vt100
>>  onifconsole  secure' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
>> +   echo 'ttyU1 "/usr/libexec/getty 3wire"  vt100
>>  onifconsole  secure' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/etc/ttys
>>
>
>  If I have no OTG port and a usb<->uart plugged into my board that will
> give weird result no ?
>

No, because that port won't be marked as console.  This only applies
to the "virtual" OTG serial ports.


> +   echo '# Configure USB OTG; see usb_template(4).' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/boot/loader.conf
>> +   echo 'hw.usb.template=3' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/boot/loader.conf
>> +   echo 'umodem_load="YES"' \
>> +   >> ${CHROOTDIR}/${DESTDIR}/boot/loader.conf
>>
>
>  I'm not a big fan of always enabling this functionality. Do you have a
> board that have no uart but an otg port ?
>

I don't, but this makes it possible to use OTG-enabled boards without
using the console cable - having to check the pinouts, making sure the
voltage
is right etc.  Do you see some problems this might cause?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template

[Edward Napierala]

2018-05-24 11:01 GMT+01:00 Hans Petter Selasky <h...@selasky.org>:

> On 05/24/18 11:59, Edward Napierala wrote:
>
>> 2018-05-24 8:41 GMT+01:00 H. Schmalzbauer - OmniLAN <
>> h.schmalzba...@omnilan.de>:
>>
>> Am 23.05.2018 um 22:35 schrieb Ravi Pokala:
>>>
>>> Hi Traz,
>>>>
>>>> You're referring to power consumption in terms of (milli)Amps. That's
>>>> not
>>>> right; power is measured in Watts. What you're actually talking about is
>>>> *current*. And it looks like in some situations USB devices can draw
>>>> more
>>>> than 500mA.
>>>>
>>>>
>>> Since the voltage isn't a variable when talking about USB power, speaking
>>> of "power" while refering to current seems valid to me – it's 5 V only
>>> and
>>> those who read that don't even need to do any math in head.
>>> I never read 2500mW in USB world, 500mA is common.
>>> Just my 2¢
>>>
>>>
>> I've just did some googling, and it seems you're right - while from
>> physics
>> point of view mA is definitely current and not power, pretty much
>> everywhere I look the USB power (reported in bMaxPower) is specified in
>> mA,
>> not mW.  Thus, I'm leaning toward leaving it as it is - wrong from a
>> physics point of view, but aligned with the the USB naming convention.
>>
>>
> Even though implict, we could specify mA at 5Volt in the sysctl
> description.


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

Re: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template

[Edward Napierala]

2018-05-24 8:41 GMT+01:00 H. Schmalzbauer - OmniLAN <
h.schmalzba...@omnilan.de>:

> Am 23.05.2018 um 22:35 schrieb Ravi Pokala:
>
>> Hi Traz,
>>
>> You're referring to power consumption in terms of (milli)Amps. That's not
>> right; power is measured in Watts. What you're actually talking about is
>> *current*. And it looks like in some situations USB devices can draw more
>> than 500mA.
>>
>
> Since the voltage isn't a variable when talking about USB power, speaking
> of "power" while refering to current seems valid to me – it's 5 V only and
> those who read that don't even need to do any math in head.
> I never read 2500mW in USB world, 500mA is common.
> Just my 2¢
>

I've just did some googling, and it seems you're right - while from physics
point of view mA is definitely current and not power, pretty much
everywhere I look the USB power (reported in bMaxPower) is specified in mA,
not mW.  Thus, I'm leaning toward leaving it as it is - wrong from a
physics point of view, but aligned with the the USB naming convention.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332596 - stable/11/sys/fs/autofs

[Edward Napierala]

On 0417T0547, Rodney W. Grimes wrote:
> > 2018-04-16 21:36 GMT+01:00 Rodney W. Grimes 
> > :
> > 
> > > > On 0416T1145, Rodney W. Grimes wrote:
> > > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > > Author: trasz
> > > > > > Date: Mon Apr 16 16:15:31 2018
> > > > > > New Revision: 332596
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/332596
> > > > > >
> > > > > > Log:
> > > > > >   MFC r328339:
> > > > > >
> > > > > >   Add SPDX tags to autofs(5).
> > > > > >
> > > > >
> > > > > Please until I resolve the eadler miss merge/revirt mess with
> > > > > SPDX do NOT touch any SPDX stuff in 11/stable.
> > > >
> > > > Ok.  Although, to be honest, I think I've already MFC-ed all the SPDX
> > > stuff
> > > > I had in my queue before seeing your mail, sorry for that.
> > >
> > > Could you do me a really big favor and see if any of the mfc's you
> > > did is in this list:
> > > Merged /head:r325966,326022-326025,326027,326192-326193,326219,
> > > 326255-326261
> > >
> > 
> > No,  my SPDX MFCs were (HEAD revisions): r328342, r328336, r328335,
> > r328341, r328338, r328339, r328337, and r328196.
> 
> I have moved far enough into the process of cleanup of r330897/331722
> that I can verify so far I only have a small handfull of conflicts
> that are managable.
> 
> Some of your commits are going to temporarily need to be reverted,
> the cleanup work I am doing done,
> and then your commits re-applied.
> 
> The only reason for the temporary revert/reapply is to allow
> the larger revert(s) of 330897 and 331722 to be done with 0
> conflicts.
> 
> Revert log message:
> The intent is to use 1 or 2 line log messages of the form:
> Revert rXX,XX,.. to clear path for Revert of r331722.
> This revert shall be reverted shortly making this a NOP.
> 
> Revert of Revert log message:
> Reapply rXX,XX after revert of r331722.
> 
> I would like to ask for your approval to revert the following
> commits that are in conflict with reverting r331722:
> svn merge -c-332599 .   #trasz
> svn merge -c-332578 .   #trasz
> svn merge -c-332577 .   #trasz
> svn merge -c-332576 .   #trasz
> svn merge -c-332575 .   #trasz
> 
> This block of 5 commits shall be reverted in 1 commit, and
> reapplied in a second commit.
> 
> At present these are the only blocking commits to revert
> r331722, I am still working out the path to revert r330897,
> at present it is at 5 commits needing reverted with 1
> conflict left to figure out.

Sure, no problem, you have my approval.  Sorry for the mess.

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

Re: svn commit: r332596 - stable/11/sys/fs/autofs

[Edward Napierala]

2018-04-16 21:36 GMT+01:00 Rodney W. Grimes 
:

> > On 0416T1145, Rodney W. Grimes wrote:
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > Author: trasz
> > > > Date: Mon Apr 16 16:15:31 2018
> > > > New Revision: 332596
> > > > URL: https://svnweb.freebsd.org/changeset/base/332596
> > > >
> > > > Log:
> > > >   MFC r328339:
> > > >
> > > >   Add SPDX tags to autofs(5).
> > > >
> > >
> > > Please until I resolve the eadler miss merge/revirt mess with
> > > SPDX do NOT touch any SPDX stuff in 11/stable.
> >
> > Ok.  Although, to be honest, I think I've already MFC-ed all the SPDX
> stuff
> > I had in my queue before seeing your mail, sorry for that.
>
> Could you do me a really big favor and see if any of the mfc's you
> did is in this list:
> Merged /head:r325966,326022-326025,326027,326192-326193,326219,
> 326255-326261
>

No,  my SPDX MFCs were (HEAD revisions): r328342, r328336, r328335,
r328341, r328338, r328339, r328337, and r328196.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r326314 - in head/sys: ddb kern sys

[Edward Napierala]

2017-11-28 17:04 GMT+00:00 Bruce Evans :

> On Tue, 28 Nov 2017, Edward Tomasz Napierala wrote:
>
> Log:
>>  Make kdb_reenter() silent when explicitly called from db_error().
>>  This removes the useless backtrace on various ddb(4) user errors.
>>
>>  Reviewed by:   jhb@
>>  Obtained from: CheriBSD
>>  MFC after: 2 weeks
>>  Sponsored by:  DARPA, AFRL
>>  Differential Revision: https://reviews.freebsd.org/D13212
>>
>
> This doesn't fix the spam for user errors that cause a trap, which are
> very common (for mistyping memory addresses).  ddb sets up trap handlers
> using setjmp, and actually does this correctly in many cases, but when
> a trap occurs the error handling is:
>
> trap -> kdb_reenter (print spam here) -> ddb (print error message here)
>

Indeed.  But, as you said later in that email, some of those messages
actually are (or might be) useful.  The intent of that change was only to
silence down those that certainly are not.  Also, differently from silencing
them down with a sysctl, this change makes them silent out of the box.

Agreed about the style problems; I might (can't promise, though) fix that
later.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320892 - head/etc/defaults

[Edward Napierala]

2017-07-11 18:02 GMT+01:00 Rodney W. Grimes 
:

> [ Charset UTF-8 unsupported, converting... ]
> > Author: trasz
> > Date: Tue Jul 11 12:32:40 2017
> > New Revision: 320892
> > URL: https://svnweb.freebsd.org/changeset/base/320892
> >
> > Log:
> >   Make fsck_y_enable default to passing pass -R to fsck_ffs(8) in
> addition
> >   to -y.  To me, fsck_y_enable means "try as hard as possible", and
> without
> >   -R, it... well, doesn't.
>
> To you perhaps, but it has long been and is well known that fsck -y is
> just that, fsck -y, not something more.  If you want it to be more
> your already given a tunable.
>
> I now have to "detune" all installed systems using fsck_y_enable if
> I do not want them to do this.
>

_If_.  But in most cases you do want it (imho -R should become the default
eventually), and you might learn about it in a unpleasantly surprising way.
Making it default is just optimizing for the common case.

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

Re: svn commit: r320892 - head/etc/defaults

[Edward Napierala]

Well, fsck(8) is a bit weird.

Assuming you don't have /dev/md0 in your fstab(5):

[trasz@v2:~]% fsck -d -t ffs -T ufs:-R /dev/md0
start (null) wait fsck_ffs /dev/md0
[trasz@v2:~]% fsck -d -t ufs -T ufs:-R /dev/md0
start (null) wait fsck_ufs -R /dev/md0

However (/ is defined as ufs in my fstab(5)):

[trasz@v2:~]% fsck -d -t ffs -T ufs:-R /
start / wait fsck_ufs -R /dev/ada0s1a
[trasz@v2:~]% fsck -d -t ufs -T ufs:-R /
start / wait fsck_ufs -R /dev/ada0s1a


2017-07-11 16:21 GMT+01:00 Ravi Pokala :

> I appreciate the spirit of this change; thanks Trasz!
>
> A question though: you're telling the generic `fsck' to pass "-R" to
> either `fsck_ffs' or `fsck_ufs', as needed. But those are both names for
> the same executable. Won't the generic `fsck' always end up invoking (per
> sbin/fsck/fsck.c::ptype_map[]) `fsck_ffs'? In which case, is the `fsck_ufs'
> case needed here?
>
> Thanks,
>
> Ravi (rpokala@)
>
> -Original Message-
> From:  on behalf of Edward Tomasz
> Napierala 
> Date: 2017-07-11, Tuesday at 05:32
> To: , , <
> svn-src-h...@freebsd.org>
> Subject: svn commit: r320892 - head/etc/defaults
>
> Author: trasz
> Date: Tue Jul 11 12:32:40 2017
> New Revision: 320892
> URL: https://svnweb.freebsd.org/changeset/base/320892
>
> Log:
>   Make fsck_y_enable default to passing pass -R to fsck_ffs(8) in addition
>   to -y.  To me, fsck_y_enable means "try as hard as possible", and without
>   -R, it... well, doesn't.
>
>   Reviewed by:  mckusick
>   Obtained from:CheriBSD
>   MFC after:2 weeks
>   Sponsored by: DARPA, AFRL
>   Differential Revision:https://reviews.freebsd.org/D11490
>
> Modified:
>   head/etc/defaults/rc.conf
>
> Modified: head/etc/defaults/rc.conf
> 
> ==
> --- head/etc/defaults/rc.conf   Tue Jul 11 06:39:12 2017(r320891)
> +++ head/etc/defaults/rc.conf   Tue Jul 11 12:32:40 2017(r320892)
> @@ -92,7 +92,7 @@ geli_autodetach="YES" # Automatically detach on last c
>  root_rw_mount="YES"# Set to NO to inhibit remounting root read-write.
>  root_hold_delay="30"   # Time to wait for root mount hold release.
>  fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen
> fails.
> -fsck_y_flags=""# Additional flags for fsck -y
> +fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y
>  background_fsck="YES"  # Attempt to run fsck in the background where
> possible.
>  background_fsck_delay="60" # Time to wait (seconds) before starting the
> fsck.
>  netfs_types="nfs:NFS smbfs:SMB" # Net filesystems.
>
>
>
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320362 - head/share/zoneinfo

[Edward Napierala]

Please do.  Thanks again :-)

2017-06-28 15:15 GMT+01:00 Cy Schubert <cy.schub...@komquats.com>:

> It doesn't matter who commits it. If you want me to, I will commit it at
> noon my time as I'm already a tad late for $JOB.
>
> ~cy
>
> In message  KFM7ngEqiW86_g@mail.gmail.c
> om>
> , Edward Napierala writes:
> > --001a113d0020693f04055304b5a4
> > Content-Type: text/plain; charset="UTF-8"
> >
> > This patch seems to fix the problem with "make -j4 installworld" for me.
> > Do you intend to commit it?  Thanks!  (And sorry for the breakage.)
> >
> >
> > 2017-06-27 4:48 GMT+01:00 Cy Schubert <cy.schub...@komquats.com>:
> >
> > > (since we're top posting )
> > >
> > > Hi Sean,
> > >
> > > Do you want to give this a spin?
> > >
> > > Index: share/zoneinfo/Makefile
> > > ===
> > > --- share/zoneinfo/Makefile (revision 320389)
> > > +++ share/zoneinfo/Makefile (working copy)
> > > @@ -94,7 +94,7 @@
> > >  .for f in ${TZS}
> > > ${INSTALL} ${TAG_ARGS} \
> > > -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> > > -   ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f}
> > > ${DESTDIR}/usr/share/zoneinfo/${f}
> > > +   ${TZBUILDDIR}/${f} ${DESTDIR}/usr/share/zoneinfo/${f}
> > >  .endfor
> > > ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m
> ${NOBINMODE} \
> > > ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/
> > >
> > > ~cy
> > >
> > >
> > > In message <f6014fd3-9f4b-b6f5-6997-38293f10e...@freebsd.org>, Sean
> Bruno
> > > write
> > > s:
> > > > This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> > > > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f
> > > > Content-Type: multipart/mixed; boundary="
> VFqTarnRbgKj5gwWULxfLoTjWIwLn2
> > > loQ";
> > > >  protected-headers="v1"
> > > > From: Sean Bruno <sbr...@freebsd.org>
> > > > To: Edward Tomasz Napierala <tr...@freebsd.org>,
> > > src-committ...@freebsd.org,
> > > >  svn-src-all@freebsd.org, svn-src-h...@freebsd.org
> > > > Message-ID: <f6014fd3-9f4b-b6f5-6997-38293f10e...@freebsd.org>
> > > > Subject: Re: svn commit: r320362 - head/share/zoneinfo
> > > > References: <201706261540.v5qfeotj072...@repo.freebsd.org>
> > > > In-Reply-To: <201706261540.v5qfeotj072...@repo.freebsd.org>
> > > >
> > > > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ
> > > > Content-Type: text/plain; charset=utf-8
> > > > Content-Language: en-US
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > Hmmm ... This seems to break 'poudriere jail -c jailname -m
> > > src=3D/usr/sr=
> > > > c
> > > > -v head"
> > > >
> > > > --- realinstall_subdir_share/zoneinfo ---
> > > > install: builddir/Africa/Abidjan: No such file or directory
> > > >
> > > >
> > > > On 06/26/17 09:40, Edward Tomasz Napierala wrote:
> > > > > Author: trasz
> > > > > Date: Mon Jun 26 15:40:24 2017
> > > > > New Revision: 320362
> > > > > URL: https://svnweb.freebsd.org/changeset/base/320362
> > > > >=20
> > > > > Log:
> > > > >   Provide visual feedback when timezone files are installed.
> > > > >   After r320003 it wasn't being shown in any way.
> > > > >  =20
> > > > >   Submitted by: bdrewery
> > > > >   MFC after:1 month
> > > > >   Differential Revision:https://reviews.freebsd.org/D11154
> > > > >=20
> > > > > Modified:
> > > > >   head/share/zoneinfo/Makefile
> > > > >=20
> > > > > Modified: head/share/zoneinfo/Makefile
> > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > > 3D=3D=3D=3D=3D=
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > > 3D=3D=3D=3D=3D=3D=
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > > 3D=3D=3D=3D=3D=3D=
> > > > =3D=3D=3D=3D
> > > > > --- head/share/zoneinfo/MakefileMon Jun 26 15:23:12 2017
> > > (r32036
> > > > 1)
> > > > > +++ head/share/zoneinfo/MakefileM

Re: svn commit: r320362 - head/share/zoneinfo

[Edward Napierala]

This patch seems to fix the problem with "make -j4 installworld" for me.
Do you intend to commit it?  Thanks!  (And sorry for the breakage.)


2017-06-27 4:48 GMT+01:00 Cy Schubert :

> (since we're top posting )
>
> Hi Sean,
>
> Do you want to give this a spin?
>
> Index: share/zoneinfo/Makefile
> ===
> --- share/zoneinfo/Makefile (revision 320389)
> +++ share/zoneinfo/Makefile (working copy)
> @@ -94,7 +94,7 @@
>  .for f in ${TZS}
> ${INSTALL} ${TAG_ARGS} \
> -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> -   ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f}
> ${DESTDIR}/usr/share/zoneinfo/${f}
> +   ${TZBUILDDIR}/${f} ${DESTDIR}/usr/share/zoneinfo/${f}
>  .endfor
> ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/
>
> ~cy
>
>
> In message , Sean Bruno
> write
> s:
> > This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f
> > Content-Type: multipart/mixed; boundary="VFqTarnRbgKj5gwWULxfLoTjWIwLn2
> loQ";
> >  protected-headers="v1"
> > From: Sean Bruno 
> > To: Edward Tomasz Napierala ,
> src-committ...@freebsd.org,
> >  svn-src-all@freebsd.org, svn-src-h...@freebsd.org
> > Message-ID: 
> > Subject: Re: svn commit: r320362 - head/share/zoneinfo
> > References: <201706261540.v5qfeotj072...@repo.freebsd.org>
> > In-Reply-To: <201706261540.v5qfeotj072...@repo.freebsd.org>
> >
> > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ
> > Content-Type: text/plain; charset=utf-8
> > Content-Language: en-US
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hmmm ... This seems to break 'poudriere jail -c jailname -m
> src=3D/usr/sr=
> > c
> > -v head"
> >
> > --- realinstall_subdir_share/zoneinfo ---
> > install: builddir/Africa/Abidjan: No such file or directory
> >
> >
> > On 06/26/17 09:40, Edward Tomasz Napierala wrote:
> > > Author: trasz
> > > Date: Mon Jun 26 15:40:24 2017
> > > New Revision: 320362
> > > URL: https://svnweb.freebsd.org/changeset/base/320362
> > >=20
> > > Log:
> > >   Provide visual feedback when timezone files are installed.
> > >   After r320003 it wasn't being shown in any way.
> > >  =20
> > >   Submitted by: bdrewery
> > >   MFC after:1 month
> > >   Differential Revision:https://reviews.freebsd.org/D11154
> > >=20
> > > Modified:
> > >   head/share/zoneinfo/Makefile
> > >=20
> > > Modified: head/share/zoneinfo/Makefile
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D
> > > --- head/share/zoneinfo/MakefileMon Jun 26 15:23:12 2017
> (r32036
> > 1)
> > > +++ head/share/zoneinfo/MakefileMon Jun 26 15:40:24 2017
> (r32036
> > 2)
> > > @@ -83,14 +83,19 @@ zoneinfo: yearistype ${TDATA}
> > > zic -D -d ${TZBUILDDIR} -p ${POSIXRULES} -m ${NOBINMODE} \
> > > ${LEAPFILE} -y ${.OBJDIR}/yearistype ${TZFILES}
> > > =20
> > > +.if make(*install*)
> > > +TZS!=3D cd ${TZBUILDDIR} && find -s * -type f
> > > +.endif
> > > +
> > >  beforeinstall: install-zoneinfo
> > >  install-zoneinfo:
> > > mkdir -p ${DESTDIR}/usr/share/zoneinfo
> > > cd ${DESTDIR}/usr/share/zoneinfo;  mkdir -p ${TZBUILDSUBDIRS}
> > > -   cd ${TZBUILDDIR} && \
> > > -   find -s * -type f -exec ${INSTALL} ${TAG_ARGS} \
> > > +.for f in ${TZS}
> > > +   ${INSTALL} ${TAG_ARGS} \
> > > -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> > > -   \{} ${DESTDIR}/usr/share/zoneinfo/\{} \;
> > > +   ${TZBUILDDIR:C,^${.OBJDIR}/,,}/${f}
> ${DESTDIR}/usr/share/zoneinfo=
> > /${f}
> > > +.endfor
> > > ${INSTALL} ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> > > ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/
> > > =20
> > >=20
> > >=20
> >
> >
> > --VFqTarnRbgKj5gwWULxfLoTjWIwLn2loQ--
> >
> > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f
> > Content-Type: application/pgp-signature; name="signature.asc"
> > Content-Description: OpenPGP digital signature
> > Content-Disposition: attachment; filename="signature.asc"
> >
> > -BEGIN PGP SIGNATURE-
> >
> > iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAllRUJtfFIAALgAo
> > aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4
> > QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1
> > /LaIFggAlEX4pLTfDUaRsGoxWbGI0DiirmhR1nW74ESXjGXd4u9WSYKfvxK+oGPJ
> > LRwxcimGw/v+h8piM102ijsmquE0+NlyyMAYjFNLb9tsZuR+kfzRbDwqiu3FNg8R
> > zDnsvo69JHiyoi7r9BJB30Q6P9fZDGBtCrSQ9Up2IUiPHjz+pLUK6jxy29wflPSr
> > qVDHitG2A7l7Sdn3Jsj8MWNw/4ehRNlhxudgg+F8v7tEJH9eNBpP6K6jR6B+aU/P
> > 

Re: svn commit: r320174 - head/share/mk

[Edward Napierala]

2017-06-20 21:52 GMT+01:00 Bryan Drewery :

> Author: bdrewery
> Date: Tue Jun 20 20:52:06 2017
> New Revision: 320174
> URL: https://svnweb.freebsd.org/changeset/base/320174
>
> Log:
>   Fix 'make clean all' to work again.
>
>   This likely broke completely with r308599.
>
>   Apply the same fix for 'make destroy' which is a DIRDEPS_BUILD thing.


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

Re: svn commit: r316486 - head/sys/mips/mips

[Edward Napierala]

2017-04-04 17:20 GMT+01:00 John Baldwin :

> On Tuesday, April 04, 2017 08:17:03 AM Edward Tomasz Napierala wrote:
> > Author: trasz
> > Date: Tue Apr  4 08:17:03 2017
> > New Revision: 316486
> > URL: https://svnweb.freebsd.org/changeset/base/316486
> >
> > Log:
> >   Remove dead code/ifdef.
> >
> >   MFC after:  2 weeks
> >   Sponsored by:   DARPA, AFRL
>
> I'm not quite sure how dead this.  We do reserve space in 'struct reg'
> for IC in regnum.h:
>
> /*
>  * IC is valid only on RM7K and RM9K processors. Access to this is
>  * controlled by IC_INT_REG which defined in kernel config
>  */
> #define IC  38
>
> OTOH, I can't find other references to IC outside of regnum.h and what
> you just removed.
>

I've only grepped the sources for the #ifdef, and that it was added with
the initial commit that added the MIPS port.  I didn't do anything with IC,
because I'm not sure if something doesn't depend on the structure size.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"