Re: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template
2018-05-24 11:01 GMT+01:00 Hans Petter Selasky : > 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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335004 - head/release/tools
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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335004 - head/release/tools
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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326314 - in head/sys: ddb kern sys
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r320174 - head/share/mk
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r320362 - head/share/zoneinfo
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-...@freebsd.org, svn-src-head@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
> > VCPrKO1rRmmJTPxxPwskLLX4/xXrf8hmUFTm0uBbLtKbvzsaO5IZ9HKXJdYFlaRo
> > dCw6yY1xFlMv/OrUWgSxj02fsd7GHg==
> > =9Mia
> > -END PGP SIGNATURE-
> >
> > --WTKxh8RiNpWJJ66LumpxWUq5KMtbGfm2f--
> >
> >
>
> --
>
Re: svn commit: r320362 - head/share/zoneinfo
Please do. Thanks again :-)
2017-06-28 15:15 GMT+01:00 Cy Schubert :
> 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 :
> >
> > > (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-...@freebsd.org, svn-src-head@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 ${P
Re: svn commit: r320892 - head/etc/defaults
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-head@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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r320892 - head/etc/defaults
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r345549 - head/sys/dev/smartpqi
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r346120 - head/sys/kern
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r346120 - head/sys/kern
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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/
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350331 - in head: sbin/camcontrol sys/cam/ata sys/cam/scsi sys/sys
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366748 - head/sys/fs/pseudofs
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357203 - head/sys/compat/linux
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335941 - head/tools/tools/syscall_timing
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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r345549 - head/sys/dev/smartpqi
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r346120 - head/sys/kern
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r346120 - head/sys/kern
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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/
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r316486 - head/sys/mips/mips
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341343 - head/share/man/man7
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341344 - head/share/man/man7
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r342812 - head/share/skel
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r342881 - head/share/skel
ś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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343416 - head/bin/sh
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 just
Re: svn commit: r343416 - head/bin/sh
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 ~/.ba
Re: svn commit: r343440 - head/bin/sh
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343440 - head/bin/sh
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343440 - head/bin/sh
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 a
Re: svn commit: r343440 - head/bin/sh
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343440 - head/bin/sh
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343440 - head/bin/sh
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]c
Re: svn commit: r343440 - head/bin/sh
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344021 - head/share/man/man7
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver
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: r344758 - in head/sys/fs: nfs nfsserver
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver
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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
