Re: svn commit: r333919 - in head/contrib/file: . doc magic magic/Magdir python src tests

[Stefan Esser]

Am 20.05.18 um 22:30 schrieb Antoine Brodin:
> On Sun, May 20, 2018 at 7:06 AM, Eitan Adler  wrote:
>> Author: eadler
>> Date: Sun May 20 05:06:42 2018
>> New Revision: 333919
>> URL: https://svnweb.freebsd.org/changeset/base/333919
>>
>> Log:
>>   MFV: file 5.33
>>
>>   Merge the latest file(1) in.
>>
>>   Relevent Changelog:
>>   - extend the support for ${x?:} expansions for magic descriptions
>>   - add support for ${x?:} in mime types to handle pie binaries.
>>   - add support for negative offsets (offsets from the end of file)
>>   - close the file on error when writing magic
>>
>>   Relnotes: yes
> 
> Hi,
> 
> This breaks the ports tree,  please revert and request an exp-run.

This seems to be the cause of LIB_DEPENDS not being correctly checked.

I have fixed this locally with the following patch to find-lib.sh:

Index: Mk/Scripts/find-lib.sh
===
--- Mk/Scripts/find-lib.sh  (Revision 470484)
+++ Mk/Scripts/find-lib.sh  (Arbeitskopie)
@@ -27,7 +27,9 @@
 for libdir in ${dirs} ; do
test -f ${libdir}/${lib} || continue
libfile=${libdir}/${lib}
-   [ `file -b -L --mime-type ${libfile}` = "application/x-sharedlib" ] || 
continue
-   echo $libfile
-   break
+   case `file -b -L --mime-type ${libfile}` in
+   application/x-pie-executable|application/x-sharedlib)
+   echo $libfile
+   break ;;
+   esac
 done

This works for amd64 at least ...

Regards, STefan
___
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: r333995 - head/sys/teken

[Stefan Esser]

Am 22.05.18 um 03:18 schrieb Bruce Evans:
> On Mon, 21 May 2018, [UTF-8] Jean-Sébastien Pédron wrote:
>> -CS    Cursor style    ^[ [ SP q    r
>> +DECSCUSR    Set Cursor Style    ^[ [ SP q    r
>> DA1    Primary Device Attributes    ^[ [ c    r
>> DA2    Secondary Device Attributes    ^[ [ > c    r
>> DC    Delete character    ^[ [ P    n
> 
> Any chance of keeping this file sorted?
> 
> DECSCUSR is a verbose yet cryptic abbreviation which is not even expanded
> its name.  It is the only abbreviation longer than 7 characters.  This messes
> up the souce formatting.
> 
> Not expanding DEC in the name is normal, but other letters are normally
> expanded.  I don't know what USR is.  It looks like a bad abbreviation
> for "user".  'S' in it might mean style.

DECSCUSR = DEC SetCUrSoR ... (not quite so) obviously ;-)

Regards, STefan
___
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: r333388 - in head: . share/man/man4 sys/conf sys/dev/nxge sys/modules sys/modules/nxge tools/kerneldoc/subsys tools/tools tools/tools/nxge usr.sbin/bsdconfig/share

[Stefan Esser]

Am 23.05.18 um 20:14 schrieb Rodney W. Grimes:
>> On Wed, May 23, 2018 at 10:41:17AM -0700, Gleb Smirnoff wrote:
>>> If end of sales and support is enough to remove 10g driver from the kernel,
>>> can we please delete all 10Mbit, 100Mbit 10+ year old drivers from the 
>>> kernel?
>>
>> Depends on how many existing users we want to screw over.  Not everyone
>> replaces all their hardware every 2 years, folks.
> 
> And some of us buy 2 year old hardware because it is cheap,
> and serves our needs just fine.   Even 8 year old servers
> make usable machines today.
> 
>> The difference is that the Exar chips failed in the marketplace; very
>> few seem to have made it out into the wild.
>>
>> Given, 10Mbit-only things are way past their sell-by date.
> 
> Do we even have any 10Mbit only drivers?  I think that all the
> 10mbit drivers also support 100mbit devices, but maybe there
> are some odd cases I cant remeber.

AFAIK and FWIW:

ed(4), le(4) on amd64 and on i386 (ISA and PCI)
ex(4), ep(4) on i386 (ISA and PCcard)

Regards, STefan
___
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: r334617 - in head: . etc

[Stefan Esser]

Am 05.06.18 um 22:43 schrieb Brad Davis:
> 
> On Tue, Jun 5, 2018, at 1:07 PM, Renato Botelho wrote:
>> On 05/06/18 15:26, Konstantin Belousov wrote:
>> > On Tue, Jun 05, 2018 at 12:13:05PM -0600, Brad Davis wrote:
>> >> On Tue, Jun 5, 2018, at 10:46 AM, Konstantin Belousov wrote:
>> >>> I find it often very useful to do
>> >>> (cd src/etc/rc.d && make install)
>> >>> Same for defaults and several other directories which in fact contains
>> >>> non-editable content.  Is this planned to keep working ?
>> >>
>> >> The short answer is, no.  All rc.d scripts get moved to the src of the
> program they start.
>> >>
>> >> That said, if there is a big need for this, we can see about options to
> keep them working.
>> >>
>> >> What are you trying to accomplish when you do this?  Just verify the rc.d
> scripts match your src tree?
>> >
>> > I avoid mergemaster/etcupdate and whatever else. rc.d and /etc/rc,
>> > /etc/rc.subr /etc/rc.network are not suitable to etc, they are binaries
>> > provided by the project not for the user editing.
>> >
>> > When upgrading the host, esp. on HEAD, i usually refresh scripts by this
>> > procedure and avoid any editing and implied conflict resolution for real
>> > configs.
>> >
>> > Not being able to easily install clean copies of these scripts would
>> > be very inconvenient and time consuming.
>>
>> If I understood what Brad is saying, each rc.d script will be installed
>> by the application it belongs to. So when it's installing SSH it will
>> also install /etc/rc.d/sshd and you will not need to deal with rc.d
>> files on mergemaster anymore.
>>
>> Is it correct, Brad?
> 
> Correct.
I have for a long time (decades?) applied local changes to files in src/etc
which (very seldom) may need a conflict resolution, and which make sure that
/etc is populated with files that match my needs.

It is easy to change a file in /etc until it works as desired and then copy
it to src/etc, where it is subject to updating via SVN, but still reflects
my preferences.

With the move to source directories it will be necessary to modify rc files
and other configuration file defaults (e.g. ttys) in a number of places.

E.g., mergemaster will try to remove the shells installed from ports from
/etc/shells on each run and quite a number of other files will either never
be automatically updated (by excluding them from mergemaster runs) or on
every invocation of mergemaster, unless patched in their respective source
directories spread over the whole source tree.

This is a BIG step backwards from my PoV, since src/etc currently is the
equivalent of FreeBSD's concept of using /etc/rc.conf for configuration of
all applicable system settings. Having sources of all files that are going
to be installed in /etc (when a new system is setup or by mergemaster) is
equivalent in the sense that the location where changes have to be applied
is confined to just one directory, src/etc (and a few architecture dependent
sub-directories).

Regards, STefan
___
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: r327086 - head/sys/dev/lmc

[Stefan Esser]

Am 04.01.18 um 00:41 schrieb Pedro Giffuni:
> Either the license is very naively stated or the device should have been added
> in the contrib/gnu branches.

This appears to be one of the dual-licensed drivers, that are the result of
some BSD driver having been ported to Linux with the original copyright left
intact. In the case of lmc, a comment states, that it was originally derived
from the "de" driver (DEC Ethernet) by Matt Thomas, although it appears to
have been rewritten from scratch (with the BSD copyright notice retained).

The same happened to the ncr 53c810 driver which was ported to Linux and then
back-ported to FreeBSD as with extensions developed under Linux to better
support later generations of the controller chip.

> I suspect the former but my attempts to contact the author were unsuccessful
> so it is probably better to just drop it.
> 
>> Inc is for very old interconnect to telco... So maybe that's safe to delete.

It appears to be a strange beast that uses the Ethernet chip to generate a
bit stream which is then converted to HDLC. Not sure whether these were used
for Frame Relay or to connect to the British X.25 JANET, a few decades ago.
Perhaps also to connect to SS7 signaling networks?

Regards, STefan
___
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: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 24.10.20 um 09:48 schrieb Alex Kozlov:

On Fri, Oct 23, 2020 at 09:22:23AM +, Stefan Eßer wrote:

Author: se
Date: Fri Oct 23 09:22:23 2020
New Revision: 366962
URL: https://svnweb.freebsd.org/changeset/base/366962

Log:
   Add search of LOCALBASE/share/calendar for calendars supplied by a port.
   
   Calendar files in LOCALBASE override similarily named ones in the base

   system. This could easily be changed if the base system calendars should
   have precedence, but it could lead to a violation of POLA since then the
   port's files were ignored unless those in base have been deleted.
   
   There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses

   of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease
   a consistent modification of this prefix.

You are hardcoding assumption that LOCALBASE = /usr/local. Please make it
overridable with LOCALBASE environment variable.


This was a trivial change to get us going with calendars provided by
a port (which has not been committed, yet - therefore there are no
port-provided calendars, neither under /usr/local nor under any other
PREFIX, as of now).

I understand what you are asking for, but in such a case I'd rather
think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in
paths.h.

And I have made this a single instance that needs to be changed.
Before my change there were 2 instances of /usr/local hard-coded
in _PATH_DEFPATH - now you have to only change the definition of
_PATH_LOCALBASE to adjust all 3 locations that use it.

If you can show me precedence of a LOCALBASE environment variable
being used in the way you suggest, I'd be willing to make calendar
use it.

But then I think a CALENDAR_HOME variable would be even more useful,
since it would allow to search an additional user selected directory
(and not just share/calendar within what you provide as LOCALBASE).

Regards, STefan

PS: If you are a source committer, you might even commit such a
change yourself. But I'd think it should be reviewed, and it
might be a good idea to wait until other changes (e.g. the
switch-over to port-supplied calendar files) have been worked
out.


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:

On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
wrote:

+#define  _PATH_LOCALBASE "/usr/local"
+


Something feels very wrong about this becoming a  defined path in base,
it is further dependence on /usr/local which in the early days we spent
a great deal of time removing.

I believe the whole ports system allows this to be something other
than /usr/local.  Package should also allow it to be some other place.



This removes a couple of instances of /usr/local being hardcoded and
replaces with a define, so net it's better.


No, its net worse as it now creates a define that is highly likely
to propogate adding additional dependencies on this value.



It could be even better, but this is slightly better than it was before.


I disagree, as it is now easier for additional contamination of
the base system.


There already are places that hard-code /usr/local, and I do agree
that this is architecturally bad, if you want to keep the base system
and ports as independent from each other as possible.

But I do disagree that this was worse than before, and I'd even consider
replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
in our sources (but not introduce new references to LOCALBASE in base).

This would simplify a grep for such source files, for example, and also
to build base for systems with modified LOCALBASE.

The following C header files in base (ignoring contrib) contain the
string /usr/local:

crypto/openssh/pathnames.h
sys/sys/imgact_binmisc.h
sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
usr.bin/fortune/fortune/pathnames.h
usr.bin/mail/pathnames.h
usr.sbin/cron/cron/pathnames.h
usr.sbin/pkg/config.h
usr.sbin/pciconf/pathnames.h
usr.sbin/pciconf-xo/pathnames.h

These are C source files that include that string:

crypto/openssh/ssh-agent.c
crypto/openssh/regress/unittests/sshkey/test_sshkey.c
lib/libfetch/common.c
lib/libc/rpc/getnetconfig.c
lib/libc/nls/msgcat.c
sbin/nvmecontrol/nvmecontrol.c
sys/contrib/openzfs/cmd/zpool/zpool_main.c (FreeBSD specific?)
tools/tools/ath/athprom/athprom.c
tools/tools/net80211/wesside/wesside/wesside.c
usr.bin/env/envopts.c
usr.sbin/bsnmpd/tools/libbsnmptools/bsnmpimport.c
usr.sbin/mailwrapper/mailwrapper.c
usr.sbin/cpucontrol/cpucontrol.c

I intend to prepare a review top make them use _PATH_LOCALBASE instead.
(There might be sources under contrib that have no external up-stream
anymore, but I have not made an attempt to identify them, yet.)

There are 67 man-pages (excluding contrib) that mention /usr/local
and they will not be covered by this C macro definition.

There are further references to /usr/local, e.g. in 32 shell scripts
(outside contrib).

The next step could be to use the LOCALBASE variable that is defined
in Makefile.inc1 to provide the value used to define _PATH_LOCALBASE
in paths.h. This make variable is currently not used in bsd.prog.mk,
but it easily could, allowing to override the value used to build
the world in make.conf.

But I'd suggest to go step by step, and the first step that I suggest
(and am willing to work on) is to remove as many literal uses of
/usr/local in C sources in base (excluding contrib) as reasonable.

Maybe we should have some documentation about building the world for
systems with non-default LOCALBASE ...

Regards, STefan
___
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: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 25.10.20 um 06:56 schrieb Alex Kozlov:

On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote:

Am 24.10.20 um 09:48 schrieb Alex Kozlov:

[...]

You are hardcoding assumption that LOCALBASE = /usr/local. Please make it
overridable with LOCALBASE environment variable.

This was a trivial change to get us going with calendars provided by
a port (which has not been committed, yet - therefore there are no
port-provided calendars, neither under /usr/local nor under any other
PREFIX, as of now).



I understand what you are asking for, but in such a case I'd rather
think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in
paths.h.

The PREFIX != LOCALBASE and both != /usr/local configurations
are supported in the ports tree and the base for a long time, please see
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


Yes, and I do not need to look that up in the handbook, having been
a ports committer for 2 decades by now.


If after this commit you need to rebuild base to use non-default 
LOCALBASE/PREFIX
it is pretty big regression and POLA.


How is that any different than before?

What I did is make the PATH easier to change when you rebuild base.

There are numerous programs in base that contain the literal string
/usr/local - and what I did was implement a mechanism that allows
to replace this literal reference with a simple change in paths.h.

If you do not modify paths.h for a different LOCALBASE, then you'll
get a wrong _PATH_DEFPATH compiled into your binaries, for example.


And I have made this a single instance that needs to be changed.
Before my change there were 2 instances of /usr/local hard-coded
in _PATH_DEFPATH - now you have to only change the definition of
_PATH_LOCALBASE to adjust all 3 locations that use it.

I think you made situation worse, there were two stray hardcoded
string and now there is official LOCALBASE define which likely will be
used by other people in the future.


I'd hope so to get rid of many of the 1713 literal uses of /usr/local
in our source tree.


If you can show me precedence of a LOCALBASE environment variable
being used in the way you suggest, I'd be willing to make calendar
use it.

Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME
is a better name.


Yes, I already suggested CALENDAR_HOME, but as an environment variable
to check, if you want to be able to path an additional directory (or
search path) to the calendar program at run-time. But why introduce
a CALENDAR_HOME macro in the sources, if the port supplied calendar
files are known to be found at LOCALBASE/share/calendar (for some value
of LOCALBASE).

I want to make more programs that currently hard-code /usr/local use
_PATH_LOCALBASE instead. This C macro can then be default to /usr/local
but can be overridden by passing LOCALBASE to the compiler (from the
build infrastructure) when paths.h is included.

Instead of referring to _PATH_LOCALBASE these files could directly use
LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
think it is best to follow this precedent.


But then I think a CALENDAR_HOME variable would be even more useful,
since it would allow to search an additional user selected directory
(and not just share/calendar within what you provide as LOCALBASE).


My change did not add any dependency on LOCALBASE to any previously
existing functionality. It added support for calendar files provided
by a port (a feature that did not exist before) at a location that is
correct for the big majority of users (who do not modify LOCALBASE).

As I said: I'm going to make it easier to build the base system with
a different LOCALBASE, but not by run-time checking an environment
variable that specifies LOCALBASE in each affected program.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 26.10.20 um 00:55 schrieb Rodney W. Grimes:

[ Charset ISO-8859-1 unsupported, converting... ]

On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote:

Am 24.10.20 um 09:48 schrieb Alex Kozlov:

On Fri, Oct 23, 2020 at 09:22:23AM +, Stefan E?er wrote:

Author: se
Date: Fri Oct 23 09:22:23 2020
New Revision: 366962
URL: https://svnweb.freebsd.org/changeset/base/366962

Log:
Add search of LOCALBASE/share/calendar for calendars supplied by a port.
Calendar files in LOCALBASE override similarily named ones in the base
system. This could easily be changed if the base system calendars should
have precedence, but it could lead to a violation of POLA since then the
port's files were ignored unless those in base have been deleted.
There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses
of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease
a consistent modification of this prefix.

You are hardcoding assumption that LOCALBASE = /usr/local. Please make it
overridable with LOCALBASE environment variable.

This was a trivial change to get us going with calendars provided by
a port (which has not been committed, yet - therefore there are no
port-provided calendars, neither under /usr/local nor under any other
PREFIX, as of now).



I understand what you are asking for, but in such a case I'd rather
think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in
paths.h.

The PREFIX != LOCALBASE and both != /usr/local configurations
are supported in the ports tree and the base for a long time, please see
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


Seems all that work for all them years is about to be tossed out
the window as "an out dated concept".


The world outside this project has grown at a much faster rate than
what the project provides. The FreeBSD base system is very usable
as a development system with its integration of editor, compiler,
debugger and the like, but the huge magnitude of software actually
used for development today is not included.

We need to treat ports/packages as necessary extensions of the
system, and thus we need to have hooks in the base system, that
allow to easily integrate such add-on packages.

And more and more extensions that have to be integrated into base
system functionality have been developed outside our project. We
can ignore them or use them, but in the latter case need hooks in
the base system (including references to paths below LOCALBASE).


If after this commit you need to rebuild base to use non-default 
LOCALBASE/PREFIX
it is pretty big regression and POLA.


I guess no one is paying attention to any of this...


What has that got to do with the change I propose?

Recompiling for a different LOCALBASE requires identifying and
patching tens of files distributed over our source tree.

I'm trying to identify those locations and use a parameter that
can be changed at a well known location (the paths.h file) to at
least make a changed LOCALBASE practical with a re-compilation.


And I have made this a single instance that needs to be changed.
Before my change there were 2 instances of /usr/local hard-coded
in _PATH_DEFPATH - now you have to only change the definition of
_PATH_LOCALBASE to adjust all 3 locations that use it.

I think you made situation worse, there were two stray hardcoded
string and now there is official LOCALBASE define which likely will be
used by other people in the future.


Yep, and now that propogation is about to occur.


Sorry, but whether there are more references to LOCALBASE in our base
system will depend on whether it is useful for some purpose.

Having a path defined in paths.h does not lead to it being used in
more places.

And if it was, there was no qualitative change, only a quantitative
one. From tens of places where /usr/local is currently literally used
in our source tree to tens plus 1 where a macro is used for this
purpose.

You have to rebuild after patching tens of locations for a modified
LOCALBASE right now. I'm making it easier, not harder, to overcome
the issues caused by the intrusion of references to /usr/local into
our base system.

And as I have explained in another port to this thread, that while it
is possible to introduce dynamically changed (by environment variable
or sysctl variable) LOCALBASE values into the base system, the security
implications could be severe.

Regards, STefan
___
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: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 26.10.20 um 09:08 schrieb Baptiste Daroussin:

On Mon, Oct 26, 2020 at 02:05:28AM -0600, Scott Long wrote:



On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin  wrote:

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:

[...]

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
of ports will allow you to change it at compile / build time, but not
after. You have to rebuild if you want to change PREFIX...

So I'm a bit puzzled what makes this the wrong approach?



I think what Alex revents to is the following:

Some utilities in base base either have a configurable way to look for things in
localbase (via configuration entries for instances):
- syslog
- periodic
- rc
- man
Some have hardcoded LOCALBASE but only after looking first at the LOCALBASE env
var:
- usr.sbin/pkg
- mailwrapper

which means with a prebuilt base I can still rebuild all my packages with a
different localbase and it will work with only a few configurations changes.
which imho is a good target.

The list of tools which hardcodes /usr/local
- calendar
- fortune
- cron
- bsnmp
- nvmecontrol
- cpucontrol (at least can be workaround via -d option)




It would be pretty trivial to add a new libc function, something like 
getlocaldir.2,
that took care of searching the environment and the invoking a fallback to the
compile-time default from path.h.  I’ll see if I can come up with something for
review before I fall asleep.


Exactly what I was thinking about ;)

could also be a simple static inline function somewhere (path.h?) if we don't
want to "pollute" libc.

I am fine with both.


I'm not opposed to having such a function, but please make sure we do
not open a security loop-hole.

If there was a mechanism that allows the effective LOCALBASE to be set
in a systctl variable, we could expect the valzue to be trustworthy.

If the LOCALBASE setting was provided in an environment variable, I'd
expect at the least, that the full path up to the root directory was
sanity checked (not writable by a non-priviledged account, for example).

Else I might be able to mislead a program that accesses a configuration
file in LOCALBASE that is under control of a privileged account to use
my version of the file.

A library function that provides the value of LOCALBASE should probably
recognize being invoked in a SUID program, but I guess we need quite a
number of extra safe-guards to avoid opening up gaping security holes.

Regards, STefan

PS: I consider work on a dynamic LOCALBASE orthogonal to the proposed
replacement of verbatim uses of /usr/local by _PATH_LOCALBASE.
Please let me know if you disagree and think that the proposed
change should not be applied for this reason.
___
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: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 27.10.20 um 08:37 schrieb Alex Kozlov:

On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
of ports will allow you to change it at compile / build time, but not
after. You have to rebuild if you want to change PREFIX...

So I'm a bit puzzled what makes this the wrong approach?

1) Making it buildtime instead of fixing a few regression cases which as
simple as reading environment variable before fallback to hardcoded /usr/local,
or make it kernel variable/sysctl if security is a concern.


Please provide patches that make the affected programs use a run-time
value for LOCALBASE (start with the base system, but do apply this to
ports that are extensions of the base system functionality to be able
to use packages on such a system with non-default LOCALBASE).

And please show that there are no security issues, that there is no
negative impact on the run-time for the huge majority of installations
that use the default value of LOCALBASE, and that there is no added
complexity to maintain such a system (starting from documentation that
needs to be adapted to a dynamically changeable LOCALBASE).

A compiled-in path is protected against manipulation by an attacker,
and, while a sysctl value could be as well, you ought to be able to
use different LOCALBASE values in jails, to make this really universal.

Please provide an architectural draft that accounts for all these points
and an estimate of the effort required to implement it and be assured
we'll openly discuss it.


2) Codifying LOCALBASE = /usr/local, so from now more people will use
it because it's in defines.


No, the _PATH_LOCALBASE makes it easier to refer to port provided files
*without* hard-coding /usr/local!

But LOCALBASE == /usr/local has been the default for so many decades
that I cannot remember when it started. Probably before BSD-4.2 already,
but we have committers that don't have to guess but have been there ;-)
(I've been a BSD user starting with BSD-4.2, and we have already used
/usr/local for the programs distributed over USENET at that time ...)

A verbatim /usr/local occurs in more than 1700 individual files in base,
and I'm going to remove some 20 of them that get compiled into binaries.

You are welcome to bring this number further down and we are awaiting
your patches.

We do not move base components to ports for fun, but to be able to
disconnect them from the release cycle, to ease outside contributions,
and to reduce the maintenance effort for release-agnostic components
(no need to MFC updates to the calendar files, for example).

And we have to compare the effort caused for the project with the effort
it takes to make FreeBSD use a non-default LOCALBASE for users that
really need it. Those will probably have forked off their own repository
to be able to make much bigger changes to the code base - adjusting the
_PATH_LOCALBASE before building the world is really a minor effort for
them.

And we want to make such a change of LOCALBASE easier than it used to
be for a long time.

If you are affected and the above does not apply to you, then please
provide the patches you probably already have ready since you relied
on them before the introduction of _PATH_LOCALBASE.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367103 - head/usr.bin/calendar

[Stefan Esser]

Am 28.10.20 um 14:12 schrieb Kyle Evans:>> Modified: 
head/usr.bin/calendar/io.c

==
--- head/usr.bin/calendar/io.c  Wed Oct 28 11:54:09 2020(r367102)
+++ head/usr.bin/calendar/io.c  Wed Oct 28 13:06:39 2020(r367103)
@@ -212,6 +212,21 @@ token(char *line, FILE *out, bool *skip)
 return (T_OK);
 }

+   if (strncmp(line, "ifdef", 5) == 0) {
+   walk = line + 6;
+   trimlr(&walk);
+


I think you wanted to step walk forward 5 instead of 6 here


Thank you for spotting this bug ...

It did not show up in my tests, since there generally is a blank
after the token, but I'll fix this immediately since I want to
MFC that change.

Nobody should be affected since #ifdef was officially unsupported
before this change ...

I'm thinking about support for nested conditionals and #else in
calendar files, but I'm not sure about the possibility to MFC
such a change and I do not want to invite users to create calendar
files that work in -CURRENT but not in -STABLE.
___
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: r367103 - head/usr.bin/calendar

[Stefan Esser]

Am 28.10.20 um 14:34 schrieb Kyle Evans:

On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser  wrote:

I'm thinking about support for nested conditionals and #else in
calendar files, but I'm not sure about the possibility to MFC
such a change and I do not want to invite users to create calendar
files that work in -CURRENT but not in -STABLE.


Unsolicited $0.02: Do whatever you feel comfortable with. It's up to
people trying to use the new/advanced features to make sure it's
compatible with the calendar(1) that *they* are using, and I'm having
a hard time imagining folks using deploying additional calendar data
in ports outside of deskutils/calendar-data which you can curate for
stuff like that.


I only read your reply after committing the change that allows for
recursion.

The issue reported by Julian H. Stacey on the freebsd-stable list
made me check for the code that implements these conditions, and
I noticed that there was no #ifdef (which he had tried to use),
but it was trivial to implement.

The man-page mentions that a restricted subset of CPP directives
is supported, and ISTR that an earlier version of the calendar
program actually forked CPP to pre-process the data files.

This approach required a "traditional" CPP that ignored the content
of the non-directives being processed, which is no longer available.

In a way I'm removing some of the limitations that resulted from
the switch to an internal parser for the conditions.

If there is consensus not to introduce any new features into our
calendar program, then I'm going to revert these changes.

I had planned to give time for a discussion about a possible
merge to -STABLE.

I have already created a port of the calendar program as
deskutils/calendar and was planning to upgrade the port to include
these changes in -CURRENT.

The port could be used to provide release users with these features,
if they consider them useful.

Since the changes are fully compatible with old data files, I do
not think that a MFC was a violation of POLA.

We do now have the calendar-data port for use in -CURRENT and it
could be used to distribute calendar files that use the new features.

Since old calendar programs will not look into the port's data file
directory, they will continue to operate on files in the base
system.

If the calendar program from a port is used, it will support the
features of this version and that all calendar files that take
advantage of them.

We might hide these new features by removal from the man-page or we
could discourage their use by declaring them unportable extensions.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367196 - head/lib/libc/gen

[Stefan Esser]

Sorry for the bad bug that I introduced with this attempted style fix!

The correct code has been committed as r367199.

Am 31.10.20 um 12:46 schrieb xto...@hotmail.com:

Stefan Eßer wrote:

Author: se
Date: Sat Oct 31 11:44:10 2020
New Revision: 367196
URL: https://svnweb.freebsd.org/changeset/base/367196

Log:
   Fix style, no functional change
   Submitted by:    kib
   MFC after:    3 days

Modified:
   head/lib/libc/gen/sysctl.c

Modified: head/lib/libc/gen/sysctl.c
== 


--- head/lib/libc/gen/sysctl.c    Sat Oct 31 03:36:31 2020    (r367195)
+++ head/lib/libc/gen/sysctl.c    Sat Oct 31 11:44:10 2020    (r367196)
@@ -79,23 +79,23 @@ sysctl(const int *name, u_int namelen, void *oldp, 
siz

  switch (name[1]) {
  case USER_CS_PATH:
-    if (oldp && orig_oldlen < sizeof(_PATH_STDPATH)) {
+    if (oldp == NULL && orig_oldlen < sizeof(_PATH_STDPATH)) {


These checks are not identical, should not the new one be != NULL?


  errno = ENOMEM;
-    return -1;
+    return (-1);
  }
  *oldlenp = sizeof(_PATH_STDPATH);
  if (oldp != NULL)
  memmove(oldp, _PATH_STDPATH, sizeof(_PATH_STDPATH));
  return (0);
  case USER_LOCALBASE:
-    if (oldp && orig_oldlen < sizeof(_PATH_LOCALBASE)) {
+    if (oldp == NULL && orig_oldlen < sizeof(_PATH_LOCALBASE)) {


Same here.


  errno = ENOMEM;
-    return -1;
+    return (-1);
  }
  *oldlenp = sizeof(_PATH_LOCALBASE);
  if (oldp != NULL)
  memmove(oldp, _PATH_LOCALBASE, sizeof(_PATH_LOCALBASE));
-    return(0);
+    return (0);
  }
  if (oldp && *oldlenp < sizeof(int)) {




OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367221 - head

[Stefan Esser]

Am 01.11.20 um 18:16 schrieb Dan Mack:
Are lines 29 and 36 in /usr/src/UPDATING supposed to be 2020 or is 
the 2010 correct ?


Fixed in SVN rev. r367254

Thanks for spotting this error!

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2, 
2020, Stefan Eßer 
> wrote:

Author: se
Date: Mon Nov  2 18:48:06 2020
New Revision: 367280
URL: https://svnweb.freebsd.org/changeset/base/367280


Log:
   Re-arrange some of the code to separate writable user tree
variables from
   R/O variables.

   While here fix some nearby style. No functional change intended.

   MFC after:    1 month


Is there any phabricator reference for this / these commit(s) + reviewer 
lists?


The previous commit that has been refined in this one has been
discussed in D27009.

I had added the new R/W sysctl variable to a switch statement that
contained one R/O string value, and excluded the OID from causing
an error return when a new value had been passed.

This was functionally OK, but I have decided to move handling of
the new writable variable to before the check for a write attempt
and thus need to test specifically for its OID.

This sysctl variable is referenced in Scott Longs proposed
getlocalbase() function (D27022), but also in the change to make
it define defaults paths in /etc/defaults/rc.conf (D27014).

I do not support to make LOCALBASE dynamic for a broad range of
programs, since this could lead to severe security issues (e.g.
when a program is restricted by policy settings LOCALBASE/etc and
an user-defined LOCALBASE could be used to circumvent them.

There are already programs that respect a LOCALBASE environment
variable, e.g. the pkg program, to allow it to e.g. operate with
a DESTDIR prefix other than "/". This is a program that could
instead use getlocalbase(), IMHO.

But for security reasons all files that determine policies and
exist in LOCALBASE since they are not distributed as part of the
base system, should be located in a secure way, and that is by
referring to a compiled in trusted path, IMHO.

Even if the sysctl variable "user.localbase" can only be written to
by root, the use of getlocalbase() provided by a shared library could
allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
leadsto a user provided policy file instead of the admin controlled
one).

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 22:49 schrieb Emmanuel Vadot:

On Mon, 2 Nov 2020 22:41:38 +0100
Stefan Esser  wrote:


Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2,
2020, Stefan Eßer 
<mailto:s...@freebsd.org>> wrote:

 Author: se
 Date: Mon Nov  2 18:48:06 2020
 New Revision: 367280
 URL: https://svnweb.freebsd.org/changeset/base/367280
 <https://svnweb.freebsd.org/changeset/base/367280>

 Log:
    Re-arrange some of the code to separate writable user tree
 variables from
    R/O variables.

    While here fix some nearby style. No functional change intended.

    MFC after:    1 month


Is there any phabricator reference for this / these commit(s) + reviewer
lists?


The previous commit that has been refined in this one has been
discussed in D27009.

I had added the new R/W sysctl variable to a switch statement that
contained one R/O string value, and excluded the OID from causing
an error return when a new value had been passed.

This was functionally OK, but I have decided to move handling of
the new writable variable to before the check for a write attempt
and thus need to test specifically for its OID.

This sysctl variable is referenced in Scott Longs proposed
getlocalbase() function (D27022), but also in the change to make
it define defaults paths in /etc/defaults/rc.conf (D27014).

I do not support to make LOCALBASE dynamic for a broad range of
programs, since this could lead to severe security issues (e.g.
when a program is restricted by policy settings LOCALBASE/etc and
an user-defined LOCALBASE could be used to circumvent them.

There are already programs that respect a LOCALBASE environment
variable, e.g. the pkg program, to allow it to e.g. operate with
a DESTDIR prefix other than "/". This is a program that could
instead use getlocalbase(), IMHO.

But for security reasons all files that determine policies and
exist in LOCALBASE since they are not distributed as part of the
base system, should be located in a secure way, and that is by
referring to a compiled in trusted path, IMHO.

Even if the sysctl variable "user.localbase" can only be written to
by root, the use of getlocalbase() provided by a shared library could
allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
leadsto a user provided policy file instead of the admin controlled
one).

Regards, STefan


  I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local


The big majority of users will keep the default value, and I do not
see a good reason for a change, except if there is a large installed
base that traditionally uses another prefix (I have seen /vol/local
and /opt, but also OS and architecture-specific prefixes, for example).


  I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.


No, why should we [assess] (assuming that word is to be implied in
your sentence) why people want to be able to easily use a different
prefix? That would be a waste of time, IMHO.

I know that there are legitimate reasons to want a different prefix,
and we had requests to make it easier to support it.

We have literal uses of /usr/local in a lot of files in the FreeBSD
base system (more than 1700) and this is not going to change.

But it was easy to replace a number of such literal pathes in base
system binaries, and we can make it easier for those that need a
different prefix to get it consistently used.


  If they have some good argument, then we should proceed further.


You do not have to participate in this effort - there are so many
other areas to work on (and I know you are very active in one).

But please do not ask those that have started to reduce the use of
literal /usr/local in the base system to justify this work.

If you are happy with /usr/local, then you are not affected at all.
And if you need to configure your system to use a different prefix,
you are welcome to let us know which steps are still causing much
effort and should be worked on to make it easier ...

Do you have any reason to be against removal of literal /usr/local
from the base system in favor of using a symbolic name for it?

Regards, STefan
___
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: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 23:10 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:

  I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local
  I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.
  If they have some good argument, then we should proceed further.


I would be delighted to be able to install _and use_ two independent
set of packages from the same base system install.  Without recursing
to jails, X forwarding, etc.


I understand the use case, and I agree this may be appropriate for
a development system.

But on a production system I'd never want to have a non-constant and
not generally applied LOCALBASE, at least not on a system that gives
a CLI to unprivileged users. Those could build their own copy of the
LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
unmodified, replacing config files that policies that restrict the
user).

And if LOCALBASE is not compiled into binaries but somehow obtained
at run-time, there are a number of attacks I can imagine (e.g. by
LD_PRELOAD replace the sysctl() call in libc by your own version).


In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
machine.  I am fine with me building both of them in my instance of
poudriere.


This is a use-case for architecture dependent path definitions (which
I have used some 30 years ago on HP-UX which supported 68k and HP-PA
on a single file system that way). Such a feature has been discussed
in FreeBSD multiple times over the decades ...


But indeed I am not sure if this worth the effort of many people, for many
hours.  If it puts too high burden on everybody, then it is not a good
feature.  Otherwise, it is very convenient in some situations.


Up to now, not much effort has been spent on this issue. I have defined
_PATH_LOCALBASE in paths.h to make it available for the calendar program
to let it lookup port provided data files (and moving those to a port
will simplify the maintenance of these calendar files).

With _PATH_LOCALBASE available, it was sensible to replace literal uses
of /usr/local in the tree with references to this symbolic name (and
thus to easily build a base system for a different LOCALBASE value).

The addition of the user.localbase sysctl tool less than 20 lines of
code in 2 files (sys/kern_mib.c and lib/libc/gen/sysctl.c). This value
can now be used to make /etc/defaults/rc.conf adapt to a changed
LOCALBASE (just a few lines changed).

All in all less than 50 lines of code have been affected, but this
makes it much easier to build a system for a different (fixed)
LOCALBASE.

The getlocalbase() function proposed by Scott Long will allow to use
a user-configured LOCALBASE in programs that use this function instead
of a compiled in path. Another 20 lines of code, not complicated at all.

But the security implications of the use of a dynamic LOCALBASE can be
significant. And thus I do not think that we should put this function
into programs without a prior security assessment. And it would be a
major effort, which IMHO is not justified for most programs.

But this is not an argument against the steps that have been taken up
to now, with little effort and no weakening of security.

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

   I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local


The big majority of users will keep the default value, and I do not
see a good reason for a change, except if there is a large installed
base that traditionally uses another prefix (I have seen /vol/local
and /opt, but also OS and architecture-specific prefixes, for example).


  I'd still like to see some arguments for such installs.


There are no reasons, if you have a narrow scope where FreeBSD should
get installed. If it only on individual desktop users' system, they
are best served with LOCALBASE immutably fixed to /usr/local.

But there are other kinds of user and I have already given examples.
Companies that have tooling that traditionally used some other prefix
will not rewrite all their tools if we tell them that only /usr/local
is supported, for example.

I do not have to justify the existence of such use cases, and I'm happy
with /usr/local on all my systems. But I do know that such use cases
do exist and I have worked in environments where they were relevant.


   I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.


No, why should we [assess] (assuming that word is to be implied in
your sentence) why people want to be able to easily use a different
prefix? That would be a waste of time, IMHO.

I know that there are legitimate reasons to want a different prefix,
and we had requests to make it easier to support it.


  What are thoses ?


Please check the mail-lists since I did not save those messages.


We have literal uses of /usr/local in a lot of files in the FreeBSD
base system (more than 1700) and this is not going to change.

But it was easy to replace a number of such literal pathes in base
system binaries, and we can make it easier for those that need a
different prefix to get it consistently used.


   If they have some good argument, then we should proceed further.


You do not have to participate in this effort


  I do have to participate, it's a common project.


But it does not affect you if you do not use it.


  Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
there might be some stuff to do there so yes I need to participate.


Ports should already support PREFIX and LOCALBASE other than /usr/local.

And the pkg program even supports the LOCALBASE environment variable.

All we try to do is go away from multiple inconsistent methods and
mechanisms and make it easier for installations that do have a need
for a different LOCALBASE to get in consistently applied to all parts
of the system. (They have to go through the tree and apply local
patches to program sources or config files, currently, but will then
have the same result with much more effort spent by each of them.)


  And since you never really started a conversation on a ml (that I know
of) my only mean to start this participation is answering a commit
email.


There has been a lengthy discussion in the thread about moving the
calendar data files out of the base system.

And there is review D26942, which was announced on the -current list
and which you seem to have missed. Also relevant are D27009, D27014,
and D27022, which have been mentioned in commits as far they have
already been committed, but have not been widely announced. You can
easily


- there are so many
other areas to work on (and I know you are very active in one).


  Only one ? Damn, I should work more then.


The most recent breakage you caused for me was the backlight kernel
option that has been introduced without any discussion I'm aware of.

Yes, I know about your involvement in getting support for modern GPUs
into FreeBSD and appreciate it.


But please do not ask those that have started to reduce the use of
literal /usr/local in the base system to justify this work.


  Seriously ? I have every right to ask you to justify this when it was
not talked about in a public forum.


What is the problem with replacing a literal string with a macro that
provides the exact same string to the compiler (unless its definition
in paths.h is changed).

Why are you against Scott Long suggesting a function getlocalbase()
that can be used as the official method to have a user supplied value
of LOCALBASE become effective in a program instead of local hacks
like checking for the LOCALBASE environment variable in some programs?

This does not affect you at all, since you can continue to hard-code
/usr/local or to continue to fetch LOCALBASE from the environment.

But developers that want to make sure that a non-default value of
LOCALBASE is consistently used by their software can make use of this
function instead of inventing their own.


If you are happy with /usr/local, then you are not affected at all.
And if you need to configure your system to use a

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 04.11.20 um 20:40 schrieb Baptiste Daroussin:

On Wed, Nov 04, 2020 at 11:04:37AM -0800, Rodney W. Grimes wrote:

For 25 years PREFIX has been rigidly a part of the ports infustructure,
why is it that the BASE system has been allowed to de-evolve from this
concept as documented and REQUIRED by:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


I again assert at one time the base system was clean of this,
it has regressed and needs to be fixed.  That fix should restore
the independence of PREFIX.  If 30k ported pieces of software can
do it why can't the base system do it?

Those ports do not require a recompile, why should the base system?


I am just reacting on that phrase, you do really think the ports do not require
a rebuild to be able to relocate from a PREFIX to another? this is a myth!

ports support being built with another prefix than localbase but that is all it
supports.

There has been a flase claim for years that relocating work, but beside the
tools proposing the feature it never worked, or to be fait only on some very
specific port.

But it is just an impossible goal to achieve otherwise as for example all the
path which gets hardcoded at build time depending on the prefix will end up in
the binary looking for resources in a hardcoded prefix at runtime and so fail if
you relocate the package, for example its datadir.


Adding to Baptiste's reply:

While ports have often contained hard-coded dependencies on the PREFIX
used at build time, the changes currently being applied to the base 
system would actually ease having ports that adapt to a different prefix

at run-time.

See Scott Longs proposed getlocalbase() function (D27022), which could
be used by ports to derive at run-time the (currently hard-coded) path
in a standardized way (with fall-back to _PATH_LOCALBASE or /usr/local).

There are potential security issues with a run-time configured PREFIX
though, e.g. if it is used to locate files that contain an admin-
configured policy meant to restrict unprivileged users. Only hard-coded
paths in the respective binaries protect against attacks that manipulate
a dynamic prefix at run-time in such a szenario.

But as long as not all supported versions of FreeBSD support the
getlocalbase() function, it cannot be assumed to be generally available
for use in ports.

And since it will take some time for the currently supported releases to
reach EoL, ports could only conditionally include such a feature when
built on and for a system known to have getlocalbase().

We are in the process of creating the infrastructure that may one day
allow ports to automatically adapt to the PREFIX in use on the system
they are installed on, but we are not there, yet.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 04.11.20 um 20:49 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 11:51:12PM +0100, Stefan Esser wrote:

Am 02.11.20 um 23:10 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:

   I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local
   I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.
   If they have some good argument, then we should proceed further.


I would be delighted to be able to install _and use_ two independent
set of packages from the same base system install.  Without recursing
to jails, X forwarding, etc.


I understand the use case, and I agree this may be appropriate for
a development system.

But on a production system I'd never want to have a non-constant and
not generally applied LOCALBASE, at least not on a system that gives
a CLI to unprivileged users. Those could build their own copy of the
LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
unmodified, replacing config files that policies that restrict the
user).

So how this makes attitude to the feature different ?  For me, dev machine
is my production box because what I do is development.  And for user that
need to run an old binary-only 32bit app which requires X libs, for instance,
it also would be a production.


Maybe I'm using the term in a too strict sense, but it has been
consistently used in this way in all the environments I have worked
in during the last few decades:

The term "production server" is generally applied to systems that
are operated by e.g. an admin team (e.g. ITIL operations processes).

You may consider your development work productive ;-), but that does
not make your development system a production system as found e.g.
in a server farm providing internal or public services.

One difference between test&development vs. production systems is
that development systems are generally operated under less tight
security obligations. You are in full control of the system and
could damage its integrity at will. It does not contain any data
you are not authorized to access.

The opposite is true of most "production systems", which need to
be protected against attacks on confidentiality, integrity, and
availability.


And if LOCALBASE is not compiled into binaries but somehow obtained
at run-time, there are a number of attacks I can imagine (e.g. by
LD_PRELOAD replace the sysctl() call in libc by your own version).

If somebody can LD_PRELOAD their into your process, it makes no sense to talk
about 'security'.


Yes, it takes some effort, but you could e.g. intercept fopen() calls
and manipulate the file name argument.

One of the suggested methods to make programs use a non-default
LOCALBASE was by means of an environment variable, and that makes it
trivial to have programs use an attacker-controlled value compare to
a LD_PRELOAD attack, though. This is acceptable on a development
system, but not on a production system, IMHO.

I'm afraid that sysctl() could be intercepted, if it was used to
determine a run-time value for LOCALBASE, but intercepting fopen()
could accomplish the same result even for hard-coded paths ...


In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
machine.  I am fine with me building both of them in my instance of
poudriere.


This is a use-case for architecture dependent path definitions (which
I have used some 30 years ago on HP-UX which supported 68k and HP-PA
on a single file system that way). Such a feature has been discussed
in FreeBSD multiple times over the decades ...


Ok, let replace /usr/local-i386 by /usr/local-11.4, if you so inclined.


Well, how about /compat/11.4-i386 then?

The HP-UX implementation used e.g. /usr/bin/@hppa/ ... and when a file
name lookup for /usr/bin/somefile did not find it in /usr/bin, it would
try /usr/bin/@ARCH (with ARCH = hppa or 68k, IIRC).

This is not exactly what you asked for, but our Linux emulation might
already contain everything required to allow a 32 bit environment to
exist on a 64 bit system. And by that I mean not the ability to execute
32 bin binaries that we already have, but e.g. to make path lookups by
such binaries consider the compat prefix first.

Ports built in the 32 bit environment should then find all their include
files, libraries ... under the appropriate /compat sub-tree.

That still leaves a few aspects undefined though, e.g. whether config
files in /etc or $LOCALBASE/etc will be different in the "emulation", or
shared with the base system. The same applies to /usr/share, which ought
to be architecture independent.

This could be an alternative layout to e.g. having 32 bit libraries in
/usr/lib32 (with both supported for backwards 

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

[Stefan Esser]

Am 18.11.20 um 22:15 schrieb Jessica Clarke:

On 18 Nov 2020, at 19:44, Stefan Eßer  wrote:

+   /*
+* Check for some other thread already having
+* set localbase - this should use atomic ops.
+* The amount of memory allocated above may leak,
+* if a parallel update in another thread is not
+* detected and the non-NULL pointer is overwritten.
+*/


Why was this committed with a known racy/leaky implementation?


Because the alternatives that I offered for discussion were
less acceptable.


What happens if I set the value with a sysctl and call this?


You'll get the value set with sysctl, unless overridden by the
environment variable. There is a window of a few nano-seconds
where a thread executing in parallel on another core might be
able to set the localbase variable (between the test for NULL
in this function and the assignment to it). The value that will
be returned by either thread will be identical, so there is no
risk of corruption of the result.

This unlikely case may actually leak a heap allocated string
of typically tens of bytes (but with negligible probability).

But this really is a non-issue, since there should never be a
reason to invoke this function in a multi-threaded context.

The result should be constant for the duration of execution
of the process (expect severe inconsistencies if that was not
the case) and all programs in base that are candidates for the
use of this function are non-threaded (and if they were multi-
threaded, then I'd expect this call to occur during start-up
of the program before any further threads are created).

So, this is a non-issue and the comment tries to explain it.
Did I fail to make this clear in the comment? Maybe I should
have written "could use atomic ops" instead?

Use of atomics or locks could prevent the race-condition. But
since I do not expect this function to be called from within
threads (it just doesn't make sense), the tiny time window of
a few nano-seconds which might lead to a double assignment to
the target variable (with one pointer value being lost), and
the worst case loss of 1KB of heap space in that case (more
likely 10 to 20 bytes rounded up to a 16 or 32 byte chunk), I
do not consider the complexities of either a lock or atomic ops
to be justified.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 18.11.20 um 22:27 schrieb Jessica Clarke:

On 18 Nov 2020, at 21:15, Jessica Clarke  wrote:


On 18 Nov 2020, at 19:44, Stefan Eßer  wrote:

+   /*
+* Check for some other thread already having
+* set localbase - this should use atomic ops.
+* The amount of memory allocated above may leak,
+* if a parallel update in another thread is not
+* detected and the non-NULL pointer is overwritten.
+*/


Why was this committed with a known racy/leaky implementation?

What happens if I set the value with a sysctl and call this?


Notably, you go to all this trouble to have a localbase variable that
gets set, but you never actually use it properly as a cache since you
do the full lookup and only then realise that you already had a
(possibly stale) value cached.


Do you want to suggest a better implementation?

As explained in another mail, this case should never happen, since
the function is not called in a multi-threaded context and if it
was, then the test before the assignment reduces the time window
of vulnerability to a few nanoseconds, and if a collision did
occur the amount of heap space lost is negligible.

Or do you think, that the assignment should directly go to the
localbase variable, not to tmppath? That would significantly
enlarge the window of vulnerability, and the code that protects
against this case (though not perfectly) seems worth it.

To give some context (slightly simplified):

if (tmppath = malloc(tmplen)) != NULL &&
sysctl(localbase_oid, 2, tmppath, &tmplen, NULL, 0) == 0) {
if (tmppath[0] != '\0' &&
(volatile const char*)localbase == NULL)
localbase = tmppath;
else
free((void*)tmppath);
return (localbase);

If localbase == NULL then localbase is set to tmppath, but another core
could execute exactly the same instructions in the same few nanoseconds.

The assignment could also have been marked volatile to force the write
to memory, but since this is a library function called from another
compile unit and the value is returned into that other context, I think
the write will happen immediately, anyway.

I know about architectures with non-coherent caches and other issues
that could increase the time window, but as said before, I do not expect
this function to be called in a multi-threaded context, but thought the
protection against a collision in the much larger time window covering
the malloc and sysctl system call might still be worth the 1 extra line
of code required to go through a stack allocated tmppath instead of
directly assigning to localbase.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 18.11.20 um 22:40 schrieb Mateusz Guzik:

+{
+   static const int localbase_oid[2] = {CTL_USER, USER_LOCALBASE};


There is no use for this to be static.


Why not? This makes it part of the constant initialized data of
the library, which is more efficient under run-time and memory
space aspects than initializing them on the stack.

What do I miss?


+   char *tmppath;
+   size_t tmplen;
+   static const char *localbase = NULL;
+
+   if (issetugid() == 0) {
+   tmppath = getenv("LOCALBASE");
+   if (tmppath != NULL && tmppath[0] != '\0')
+   return (tmppath);
+   }
+   if (sysctl(localbase_oid, 2, NULL, &tmplen, NULL, 0) == 0 &&
+   (tmppath = malloc(tmplen)) != NULL &&
+   sysctl(localbase_oid, 2, tmppath, &tmplen, NULL, 0) == 0) {


Apart from the concurrency issue mentioned in the comment this is just
very wasteful. Instead you can have a small local buffer, say 128
bytes and pass that to be populated. The sysctl handler than can
populate that and return an error if the size is too small. I don't
know if sysclt api allows it to return the set size as it is. Worst
case you can just retry with a bigger malloced buffer.


You obviously did not follow the development of this code in the
review. It used to have such a buffer, but this was rejected, since
only very few of the programs that link against this library are
going to call this function.

Allocating a small buffer and replacing it with a larger one if it
was too small adds needless complexity to this program and needs more
code. It is not sensible (IMHO) to reduce the number of system calls
by 1 for the small number of programs that use this feature, and which
perform at least tens of other system calls at start-up.


Once you get the result you can malloc a buffer and
atomic_cmpset_rel_ptr localbase to point to it. If this fails, another
thread got the result, you free your buffer and return (localbase).


Yes, I wrote that I could use atomics, feel free to modify the program
accordingly. It will not make a difference in practice, since there is
no good reason to call this function from within a multi-threaded
context at all, and none of the candidates to be modified to use this
function in base do.


Also the kernel counter part completely unnecessarily comes with a
static 1KB buffer to hold what typically is going to be nothing. This
should also be allocated as needed. Worst case you can add a trivial
lock around it.


The kernel buffer does already exist and you did not complain about
that buffer, when it has been committed. A size of PATHNAMEMAX is
used to allow for any valid path name to be set from the loader.
If there is consensus that the value should be limited to e.g. 64 or
128 bytes, this is trivially changed in kern_mib.c.

I'd be more worried, if this buffer existed not as a single instance
in the kernel but e.g. per process, but this is not the case.

Feel free to make this a dynamically allocated variable, but make
sure that you do not increase the code size by as much as you reduce
the static storage required.

I do not need the dynamic assignment to localbase at all, and I have
suggested to introduce a kernel build option (e.g. WITH_LOCALBASE_VAR)
to control compilation of kernel and library with this function or to
return just the constant string _PATH_LOCALBASE or "/usr/local".

But there were very strong requests for this dynamically set localbase
and I have provided an implementation that is functional and easy to
use.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 18.11.20 um 23:14 schrieb Jessica Clarke:

On 18 Nov 2020, at 21:52, Stefan Esser  wrote:

Am 18.11.20 um 22:15 schrieb Jessica Clarke:

On 18 Nov 2020, at 19:44, Stefan Eßer  wrote:

+   /*
+* Check for some other thread already having
+* set localbase - this should use atomic ops.
+* The amount of memory allocated above may leak,
+* if a parallel update in another thread is not
+* detected and the non-NULL pointer is overwritten.
+*/

Why was this committed with a known racy/leaky implementation?


Because the alternatives that I offered for discussion were
less acceptable.


That has no bearing over whether this one is.


Three alternatives have been discussed:

1) static buffer of size MAXPATHLEN
2) dynamically allocated buffer (as committed)
3) dynamically allocated buffer filled by a constructor

1) has been rejected, since it adds 1 KB of bss to each program
that is linked with libutil, whether it uses getlocalbase() or
not.

3) has been rejected since it causes 1 getenv() and 2 sysctl()
calls when the program linked with libutil starts, independently
of whether getlocalbase() is used or not.

2) has been selected, since it is only called when needed and it
does not pre-allocate a large buffer.

Which other alternative do you want to suggest?

Did you have a look at the review announced on the -current list
and mentioned in the commit?


What happens if I set the value with a sysctl and call this?


You'll get the value set with sysctl, unless overridden by the
environment variable. There is a window of a few nano-seconds
where a thread executing in parallel on another core might be
able to set the localbase variable (between the test for NULL
in this function and the assignment to it). The value that will
be returned by either thread will be identical, so there is no
risk of corruption of the result.


But if I call getlocalbase, then set it via sysctl, then call
getlocalbase again, I see the old value. If, however, I omit the first
getlocalbase, I see the new value. This differs from how getenv/setenv
of the value work, where you always see the up-to-date value. Maybe you
think that's a feature, but it's something to watch out for and
explicitly call out in the documentation.


Actual programs call getlocalbase() exactly once and create the
required pathes from the value returned.

It is possible to copy the value from the environment to a buffer,
but at added complexity and introducing another race condition.

The program itself might have modified its environment and then
use an inconsistent value when it calls getlocalbase() again
thereafter. But why would you want to do this - it seems to be
a complicated way lof foot-shooting to me.

I'm not a native speaker of English and not best qualified to
clearly express this in the man-page. Feel free to commit any
clarification or suggest an addition for me to commit.


You also misunderstand all the subtleties of multithreading here. There
are no acquire/release pairs so it is entirely legal for Thread 2 to
read Thread 1's initialised value for localbase before the contents of
it are visible (i.e. the pointer is initialised but the data is
garbage).


Yes, and thread 2's value will be identical to the one from
thread 1, just in a different heap location, unless there is a
write to the sysctl variable in the kernel at just the same
time. And you cannot protect against this race and you'll get
either the old or new value.


The `(volatile const char*)localbase` cast is also a complete waste of
time. You probably meant to write `(const char * volatile)localbase`
but even then that does nothing useful as the cast is too late. What
you really were trying to write was
`*(const char * volatile *)&localbase`, but you need proper atomics
anyway for this to be safe.


I was not sure about the correct volatile declaration, I've got
to admit. It was in the review and I did not get any comments
regarding that specific modifier. The goal was to enforce the
access to the localbase pointer in memory after returning from
the sysctl to shorten the window.

Perhaps I should just have completely ignore any multi-threading
issues and accepted that an overlapping execution of this function
would allocate multiple sysctl destination buffers but loose all
references but one in the assignment to localbase.

It will not happen in practice, it just does not make sense to
call this function more than once in a program.


This unlikely case may actually leak a heap allocated string
of typically tens of bytes (but with negligible probability).

But this really is a non-issue, since there should never be a
reason to invoke this function in a multi-threaded context.


Why not? There could easily be code out there calling getenv in a
multi-threaded context so this is inadequate as a replacement. Yes it's
inefficient but it

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

[Stefan Esser]

Am 18.11.20 um 23:39 schrieb Jessica Clarke:

On 18 Nov 2020, at 22:32, Stefan Esser  wrote:


Am 18.11.20 um 22:40 schrieb Mateusz Guzik:

+{
+   static const int localbase_oid[2] = {CTL_USER, USER_LOCALBASE};

There is no use for this to be static.


Why not? This makes it part of the constant initialized data of
the library, which is more efficient under run-time and memory
space aspects than initializing them on the stack.

What do I miss?


What is more efficient is not so clear-cut, it depends on things like
the architecture, microarchitecture and ABI. Allocating a small buffer
on the stack is extremely cheap (the memory will almost certainly be in
the L1 cache), whereas globally-allocated storage is less likely to be
in the cache due to being spread out, and on some architecture/ABI
combinations will incur additional indirection through the GOT. Also, 8
bytes of additional stack use is lost in the noise.


The memory latency of the extra access to the constant will be hidden in 
the noise. The data will probably be in a page that has already been

accessed (so no TLB load penalty) and modern CPUs will be able to deal
with the cache miss (if any, because the cache line may already be
loaded depending on other data near-by).

Yes, I do agree that a stack local variable could have been used and
it could have been created with little effort by a modern multi-issue
CPU. The code size would have been larger, though, by some 10 to 20
bytes, I'd assume - but I doubt a single path through this code is
measurable, much less observable in practice.

We are talking about nano-seconds here (even if the cache line did
not contain the constant data, it would probably be accessed just a
few instructions further down and incur the same latency then).

I have followed CPU development over more than 45 years and know many
architectures and their specifics, but the time were I have programmed
drivers in assembly and counted instruction cycles is long gone.

This is nitpicking at a level that I do not want to continue. I'm not
opposed to achieving efficiency where it is relevant. This function is
providing useful functionality and I do not mind a wasted microsecond,
it is not relevant here. (This was different if it was wasted within
a tight loop - but it is not, it is typically called once if at all).

Feel free to replace my code with your implementation, if you think it
is not acceptable as written by me.

I just wanted to provide an implementation of this functionality to
be used in a number of programs where other developers had expressed
interest in such a feature (and one of these programs has been worked
on by me in recent weeks, so I'm now able to make use of it myself).

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 19.11.20 um 01:37 schrieb Mateusz Guzik:

On 11/19/20, Stefan Esser  wrote:

[...]

I just wanted to provide an implementation of this functionality to
be used in a number of programs where other developers had expressed
interest in such a feature (and one of these programs has been worked
on by me in recent weeks, so I'm now able to make use of it myself).


The entire localbase saga is getting way out of hand.


Yes, apparently.


To address this e-mail and things you wrote in another reply, my
comlaints are very simple and are not getting less valid for not being
raised sooner. I just was not watching any of this until recent
fallout.

For the change at hand, there has to be a reason to use a static
symbol. Standard example is catching otherwise expensive to obtain
data. For that the static localbase pointer makes perfect sense, while
the static lookup array does not have any justification that I see.


The reason to use a static symbol for the return value is that I do
not want to have to use the getlocalbase() on my systems at all.

The static lookup array is trivially changed to be stack allocated
and filled at run-time, this is a non-issue, IMHO.


As explained in an earlier discussion, I'd rather build my systems
with a _PATH_LOCALBASE set to a non-default value than use any
run-time setting of this value. And thus, my implementation will
be just to define getlocalbase in the libutil.h on my systems:

#define getlocalbase() _PATH_LOCALBASE

Copying into a user provided buffer is of course possible, and such
an implementation had been committed before. It does not allow to
enforce a compiled in _PATH_LOCALBASE in the way I want to use it,
but I would find a way around this.

But the diffs to programs that use getlocalbase with caller supplied
buffers were significantly larger. My version can just replace the
getenv("LOCALBASE") found in a number of places by getlocalbase()
(and since getlocalbase() returns the default value if the environment
variable has not been set, remove the fallback code for that case).


Bringing cache, TLB or whatever microarchitectural details into the
discussion is beyond not warranted.

I did not start bringing in such issues, see the mail I responded to.
And I argued that it just did not matter which way the argument array
was defined, since either method has minor advantages and disadvantages.


More importantly though the commit comes with a self-confessed memory
leak and is a show stopper.


There is no memory leak, actually. Only if you called getlocalbase()
in a multi-threaded environment multiple times and in such a way that
the non-NULL test before the assignment overlaps with an assignment
in another thread, there could have been a leak of a few bytes. But
you could not exploit this leak in any way, since there is a limited
number of cores that can execute threads in parallel.

My supposed initial version did not have any memory leak and had been
rejected due to the pre-allocation of a static buffer. I do not agree
that this is an issue, since the number of VM pages allocated for the
data segment of the library does not grow, and this is what counts.

It is easily possible to limit the user.localbase variable to a useful
size in the kernel and the library (e.g. 64 bytes, which should be
sufficient as a PREFIX). But even at MAXPATHLEN, the memory usage is
not increased by this buffer.


That said, I'll see about patching this up.


I have created a new review with a static buffer. It does not have any
memory leaks, does not increase the memory usage of libutil, and it is
fully thread safe and guaranteed to return the same value on each
successive invocation (which seems to make sense for a system parameter
like LOCALBASE - the code can easily be changed to perform the getenv
and sysctl calls on each invocation again).

https://reviews.freebsd.org/D27370

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 19.11.20 um 00:20 schrieb Brooks Davis:

On Thu, Nov 19, 2020 at 12:05:51AM +0100, Stefan Esser wrote:

Am 18.11.20 um 23:14 schrieb Jessica Clarke:

Why not? There could easily be code out there calling getenv in a
multi-threaded context so this is inadequate as a replacement. Yes it's
inefficient but it's perfectly legal and imaginable.


Yes, calling getenv() might occur, but getlocalbase() is generally
called before configuration files are accessed, and the resulting
path is saved in the program. Other uses are possible, but this is
the recurring pattern.


This seems like a very naive assumption.  I could easily see libraries
wanting to know where localbase is and calling this completely without
knowledge of the application programmer.


Yes, and what's the issue, then?

The implementation that I provided could be called in a multi-
threaded environment and from within libraries.

It checked whether a new allocation was required and returned
the pointer stored by another thread (but with identical contents)
in case it lost a potential race that could exist once during the
execution of this function for a fraction of a microsecond. Only
if another thread had managed to store its pointer after the check
for it being NULL simultaneously, then a few bytes could have been
lost. You might have been able to trigger this with a specifically
built test program.

But I had only added the run-time allocation of that buffer (which
might be exploited to leak at most a few KB or heap space) due to
requests in the discussion. My initial version used a statically
allocated buffer and was completely safe.


I have written about this possibility and I had appreciated
if comments had been made on Phabricator before the commit.


Don't mistake posting something for review with obtaining
consensus.  I glanced at the review, but it contained no use cases or
justification for the feature so it was impossible to comment on the
implementation in the time I had.  I still don't understand what you aim
to support and why (except that your implementation fails to support
things like per-jail or per-ABI localbase which both seem like things
people might want.)


As described in the review, adding per-jail variables is a way to
extend the usefulness of this function, but out-of-scope at this
time. It requires changes to other parts of FreeBSD (kernel, jails)
that might then lead to an update of this function, but which can
be developed independently of the initial use of this function in
the limit way currently supported by the kernel.

And I do not need the run-time configurability at all. In fact,
I'd replace getlocalbase() calls by a macro substitution that just
returns _PATH_LOCALBASE as the default value the system was built
with.

But there has been interest in this feature and getenv("LOCALBASE")
has been used in a number of programs to be able to manipulate that
prefix at run-time.

This implementation just simplifies the getenv() calls in that case,
and that alone might be a justification for this function. It has
the added security feature of checking issetugid() and not using
the environment value in that case.

Thus it simplifies programs and allows them to take advantage of
other methods to configure LOCALBASE (e.g. later per jail or per
ABI) without changes to the programs reaching into LOCALBASE.


The getlocalbase() function had been suggested by Scott Long to
provide a generic means to retrieve the LOCALBASE prefix in
programs. Therefore, he implemented the getenv() functionality
found in a number of programs, before.

I had patched the calendar program to support data files provided
by a port (deskutils/calendar-data) to ease maintenance of these
date files outside of the base system. While doing this, I noticed
the use of literal "/usr/local" in a number of base system utilities
and provided this value as _PATH_LOCALBASE to make it easier to
override, if desired (not needed by me, but again requested on the
maillists in several threads).

A non-default _PATH_LOCALBASE can be compiled into programs, but
not in e.g. shell scripts. I have added the user.localbase sysctl
to query _PATH_LOCALBASE from programs that do not have it compiled
in (e.g. shell scripts).

The user.localbase sysctl variable is queried and passed to the
rc subsystem as ${_localbase} by changes committed by me in
SVN rev. 367294.

All these changes are meant to allow building a system that has a
non-default LOCALBASE, without hunting down all literal occurances
of "/usr/local" in the tree.

Making sysctl("user.localbase") available in getlocalbase() is then
a logical consequence of all the other changes.


As I wrote before: I'm interested in providing a standard method
to obtain LOCALBASE in case it is not set to the FreeBSD default
value of "/usr/local" to allow as many components of the system
to automatically use the correct paths in such an environmen

Re: svn commit: r368072 - in head/contrib/bc: . gen include manuals manuals/bc manuals/dc src src/bc src/dc src/history src/rand tests

[Stefan Esser]

Am 26.11.20 um 19:19 schrieb O. Hartmann:

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"

Buildworld fails with  "don't know how to make bc/bc.c":

===> usr.sbin/ndp (all)
- --- all_subdir_usr.bin ---
make[4]: make[4]: don't know how to make bc/bc.c. Stop


Hi Oliver,

thanks - I had already noticed that for some reason the Makefile
in usr.bin/gh-bc had not been included in the commit.

I just checked the command in the shell history and found that
I have used a wrong path in the commit:

$ cd /usr/svn/base/head
$ svn ci contrib/bc usr.bin/bc

And that should have been usr.bin/gh-bc ...

Sorry for the breakage! I have committed the fix before seeing
your mail ...

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r368072 - in head/contrib/bc: . gen include manuals manuals/bc manuals/dc src src/bc src/dc src/history src/rand tests

[Stefan Esser]

Am 26.11.20 um 21:03 schrieb Cy Schubert:> But this is still a problem:


ld: error: undefined symbol: bc_lib_name

referenced by vm.c:752 (/opt/src/svn-current/contrib/bc/src/vm.c:752)
   lto.tmp:(bc_vm_boot)


ld: error: undefined symbol: bc_lib

referenced by lex.c:225 (/opt/src/svn-current/contrib/bc/src/lex.c:225)
   lto.tmp:(bc_vm_boot)
referenced by lex.c:227 (/opt/src/svn-current/contrib/bc/src/lex.c:227)
   lto.tmp:(bc_vm_boot)

cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [gh-bc.full] Error code 1


I cannot reproduce this issue on my system.

The symbols are defined in files generated by gen/strgen.sh and
there was a change in the parameters passed to this script, but
I had fixed usr.bin/gh-bc/Makefile accordingly (first in the port
and then in base).

The generated file lib.c should start like this:
-
// Copyright (c) 2018-2020 Gavin D. Howard and contributors.
// Licensed under the 2-clause BSD license.
// *** AUTOMATICALLY GENERATED FROM gen/lib.bc. DO NOT MODIFY. ***

#if 1
extern const char *bc_lib_name;

extern const char bc_lib[];

const char *bc_lib_name = "gen/lib.bc";

const char bc_lib[] =
"scale=20\n"
-

This file is generated by this rule in usr.bin/gh-bc/Makefile:

lib.c:  lib.bc
cd ${BCDIR} && sh gen/strgen.sh gen/lib.bc 
${.OBJDIR}/lib.c bc_lib bc_lib_name 1 1


By a script that assigns parameters to variables:

input="$1"
output="$2"
name="$3"
label="$4"
define="$5"
remove_tabs="$6"

And label="bc_lib_name" is used to generate lib.c as included
above (passed as 4th parameter).

I'm rebuilding a clean world, now, but I'd be surprised if it failed
after succeeding before readying the commit ...

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r368072 - in head/contrib/bc: . gen include manuals manuals/bc manuals/dc src src/bc src/dc src/history src/rand tests

[Stefan Esser]

FYI: Another "make buildworld" has succeeded on my system.

I cannot reproduce the issue your report and need more
information from your system, e.g. a TAR file with the
contents of usr.bin/gh-bc, contrib/bc and your object
directory ${.OBJDIR}.

Regards, STefan

Am 26.11.20 um 22:23 schrieb Stefan Esser:

Am 26.11.20 um 21:03 schrieb Cy Schubert:> But this is still a problem:


ld: error: undefined symbol: bc_lib_name

referenced by vm.c:752 (/opt/src/svn-current/contrib/bc/src/vm.c:752)
   lto.tmp:(bc_vm_boot)


ld: error: undefined symbol: bc_lib
referenced by lex.c:225 
(/opt/src/svn-current/contrib/bc/src/lex.c:225)

   lto.tmp:(bc_vm_boot)
referenced by lex.c:227 
(/opt/src/svn-current/contrib/bc/src/lex.c:227)

   lto.tmp:(bc_vm_boot)
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [gh-bc.full] Error code 1


I cannot reproduce this issue on my system.

The symbols are defined in files generated by gen/strgen.sh and
there was a change in the parameters passed to this script, but
I had fixed usr.bin/gh-bc/Makefile accordingly (first in the port
and then in base).

The generated file lib.c should start like this:
-
// Copyright (c) 2018-2020 Gavin D. Howard and contributors.
// Licensed under the 2-clause BSD license.
// *** AUTOMATICALLY GENERATED FROM gen/lib.bc. DO NOT MODIFY. ***

#if 1
extern const char *bc_lib_name;

extern const char bc_lib[];

const char *bc_lib_name = "gen/lib.bc";

const char bc_lib[] =
"scale=20\n"
-

This file is generated by this rule in usr.bin/gh-bc/Makefile:

lib.c:  lib.bc
     cd ${BCDIR} && sh gen/strgen.sh gen/lib.bc 
${.OBJDIR}/lib.c bc_lib bc_lib_name 1 1


By a script that assigns parameters to variables:

input="$1"
output="$2"
name="$3"
label="$4"
define="$5"
remove_tabs="$6"

And label="bc_lib_name" is used to generate lib.c as included
above (passed as 4th parameter).

I'm rebuilding a clean world, now, but I'd be surprised if it failed
after succeeding before readying the commit ...

Regards, STefan





OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r368072 - in head/contrib/bc: . gen include manuals manuals/bc manuals/dc src src/bc src/dc src/history src/rand tests

[Stefan Esser]

Am 26.11.20 um 23:47 schrieb Cy Schubert:

A clean build (sort of) did fix it: rm the appropriate subdir actually.


Now I see what caused your issues:

The file lib.c is created by running strgen.sh with parameters
from the Makefile, and the invocation of this script changed.

I have made the generated files depend on the Makefile to catch
and parameter changes. Maybe I should have added a dependency
on the script too, but do not expect it to change again.

Regards, STefan
___
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: r368606 - head/usr.bin/calendar

[Stefan Esser]

Am 13.12.20 um 12:13 schrieb Yuri Pankov:

Stefan Eßer wrote:

Author: se
Date: Sun Dec 13 09:38:50 2020
New Revision: 368606
URL: https://svnweb.freebsd.org/changeset/base/368606

Log:
   Fix WITHOUT_ICONV build
   There was an unprotected use of nl_langinfo() to determine the 
order of

   day vs. month in the generated output.


That's strange, nl_langinfo() is standard and its visibility should not 
(and does not?) depend on WITH/WITHOUT_ICONV.  May be just move 
langinfo.h include outside of "#ifdef WITH_ICONV" block?


Yes, you are perfectly right ...

I had noticed that WITHOUT_ICONV lead to a problem due to the missing 
prototype, but I had not seen that this was due to the include of

langinfo.h being conditional on WITH_ICONV.

I'll revert this commit and move the include of langinfo.h out of the
conditional block, as suggested by you.

Thanks for pointing this out!

Best regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

svn commit: r355382 - head/sys/dev/pci

[Stefan Esser]

Author: se
Date: Wed Dec  4 08:03:33 2019
New Revision: 355382
URL: https://svnweb.freebsd.org/changeset/base/355382

Log:
  Remove "All rights reserved" phrase from copyright notes.
  
  With the ratification of the Berne Convention in 2000, it became obsolete.
  
  I have removed that phrase and the "(c)" only from files without copyright
  claims by other parties. There are 2 files (pci.c, pci_private.h) that are
  also claimed by Michael Smith  and by BSDi, which have
  therefore not been included in this commit.
  
  When all member nations of the Buenos Aires Convention adopted the Berne
  Convention, the phrase "All rights reserved" became unnecessary to assert
  copyright. Remove it from files under my copyright.
  
  There are 2 files (pci.c, pci_private.h) that) that do also bear msmith's
  and BSDi's copyright. I have left them unchanged for now, since I do not
  know whether they (or the legal successor in case of BSDi) would agree.

Modified:
  head/sys/dev/pci/hostb_pci.c
  head/sys/dev/pci/pci_user.c
  head/sys/dev/pci/pcireg.h
  head/sys/dev/pci/pcivar.h

Modified: head/sys/dev/pci/hostb_pci.c
==
--- head/sys/dev/pci/hostb_pci.cWed Dec  4 04:01:53 2019
(r355381)
+++ head/sys/dev/pci/hostb_pci.cWed Dec  4 08:03:33 2019
(r355382)
@@ -1,8 +1,7 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
- * Copyright (c) 1997, Stefan Esser 
- * All rights reserved.
+ * Copyright 1997, Stefan Esser 
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions

Modified: head/sys/dev/pci/pci_user.c
==
--- head/sys/dev/pci/pci_user.c Wed Dec  4 04:01:53 2019(r355381)
+++ head/sys/dev/pci/pci_user.c Wed Dec  4 08:03:33 2019(r355382)
@@ -1,8 +1,7 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
- * Copyright (c) 1997, Stefan Esser 
- * All rights reserved.
+ * Copyright 1997, Stefan Esser 
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions

Modified: head/sys/dev/pci/pcireg.h
==
--- head/sys/dev/pci/pcireg.h   Wed Dec  4 04:01:53 2019(r355381)
+++ head/sys/dev/pci/pcireg.h   Wed Dec  4 08:03:33 2019(r355382)
@@ -1,8 +1,7 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
- * Copyright (c) 1997, Stefan Esser 
- * All rights reserved.
+ * Copyright 1997, Stefan Esser 
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions

Modified: head/sys/dev/pci/pcivar.h
==
--- head/sys/dev/pci/pcivar.h   Wed Dec  4 04:01:53 2019(r355381)
+++ head/sys/dev/pci/pcivar.h   Wed Dec  4 08:03:33 2019(r355382)
@@ -1,8 +1,7 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
- * Copyright (c) 1997, Stefan Esser 
- * All rights reserved.
+ * Copyright 1997, Stefan Esser 
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
___
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"

svn commit: r355591 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Tue Dec 10 19:52:29 2019
New Revision: 355591
URL: https://svnweb.freebsd.org/changeset/base/355591

Log:
  Replace two remaining hex values for control codes with their names.
  
  These were the only values in the range from 0 to 0x1f that were defined
  as hex values, all other occurances have been converted before.
  
  MFC after:1 week

Modified:
  head/share/vt/keymaps/hu.102.kbd
  head/share/vt/keymaps/us.kbd

Modified: head/share/vt/keymaps/hu.102.kbd
==
--- head/share/vt/keymaps/hu.102.kbdTue Dec 10 19:16:00 2019
(r355590)
+++ head/share/vt/keymaps/hu.102.kbdTue Dec 10 19:52:29 2019
(r355591)
@@ -48,7 +48,7 @@
   038   'l''L'ff ff 0x0141 nopff ff  C
   039   0xe9   0xc9   nopnop'$'nopnopnop C
   040   0xe1   0xc1   nopnop0xdf   nopnopnop C
-  041   '0'0x15   nopnopnopnopnopnop O
+  041   '0'naknopnopnopnopnopnop O
   042   lshift lshift lshift lshift lshift lshift lshift lshift  O
   043   0x0171 0x0170 fs fs 0xa4   nopfs fs  C
   044   'y''Y'em em '>''<'em em  C

Modified: head/share/vt/keymaps/us.kbd
==
--- head/share/vt/keymaps/us.kbdTue Dec 10 19:16:00 2019
(r355590)
+++ head/share/vt/keymaps/us.kbdTue Dec 10 19:52:29 2019
(r355591)
@@ -56,7 +56,7 @@
   050   'm''M'cr cr 'm''M'cr cr  C
   051   ',''<'nopnop',''<'nopnop O
   052   '.''>'nopnop'.''>'nopnop O
-  053   '/''?'0x1f   nop'/''?'nopnop O
+  053   '/''?'us nop'/''?'nopnop O
   054   rshift rshift rshift rshift rshift rshift rshift rshift  O
   055   '*''*''*''*''*''*''*''*' O
   056   lalt   lalt   lalt   lalt   lalt   lalt   lalt   laltO
___
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"

svn commit: r324721 - in head/share/man: man5 man8

[Stefan Esser]

Author: se
Date: Wed Oct 18 13:25:44 2017
New Revision: 324721
URL: https://svnweb.freebsd.org/changeset/base/324721

Log:
  Add references to sysrc(8).
  
  Reported by:  Kurt Jaeger (lists at opsec.eu)

Modified:
  head/share/man/man5/rc.conf.5
  head/share/man/man8/rc.8

Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5   Wed Oct 18 08:18:01 2017
(r324720)
+++ head/share/man/man5/rc.conf.5   Wed Oct 18 13:25:44 2017
(r324721)
@@ -4537,6 +4537,7 @@ configuration file.
 .Xr swapon 8 ,
 .Xr sysctl 8 ,
 .Xr syslogd 8 ,
+.Xr sysrc 8 ,
 .Xr timed 8 ,
 .Xr unbound 8 ,
 .Xr usbconfig 8 ,

Modified: head/share/man/man8/rc.8
==
--- head/share/man/man8/rc.8Wed Oct 18 08:18:01 2017(r324720)
+++ head/share/man/man8/rc.8Wed Oct 18 13:25:44 2017(r324721)
@@ -548,7 +548,8 @@ is unnecessary, but is often included.
 .Xr rc.subr 8 ,
 .Xr rcorder 8 ,
 .Xr reboot 8 ,
-.Xr savecore 8
+.Xr savecore 8 ,
+.Xr sysrc 8
 .Sh HISTORY
 The
 .Nm
___
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"

svn commit: r324823 - in head/share/man: man5 man8

[Stefan Esser]

Author: se
Date: Sat Oct 21 16:55:52 2017
New Revision: 324823
URL: https://svnweb.freebsd.org/changeset/base/324823

Log:
  Mention sysrc(8) as scripting interface for the modification of config
  files. This is a follow up commit to r324721, which added sysrc(8) to
  the SEE ALSO list.
  
  Submitted by: Kurt Jaeger (lists at opsec.eu)
  MFC after:1 week

Modified:
  head/share/man/man5/rc.conf.5
  head/share/man/man8/rc.8

Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5   Sat Oct 21 16:12:00 2017
(r324822)
+++ head/share/man/man5/rc.conf.5   Sat Oct 21 16:55:52 2017
(r324823)
@@ -64,6 +64,9 @@ is used to override settings in
 .Pa /etc/rc.conf
 for historical reasons.
 .Pp
+The sysrc(8) command provides a scripting interface to modify system
+config files.
+.Pp
 In addition to
 .Pa /etc/rc.conf.local
 you can also place smaller configuration files for each

Modified: head/share/man/man8/rc.8
==
--- head/share/man/man8/rc.8Sat Oct 21 16:12:00 2017(r324822)
+++ head/share/man/man8/rc.8Sat Oct 21 16:55:52 2017(r324823)
@@ -87,6 +87,9 @@ The
 .Nm rc.d/
 directories contain scripts which will be automatically
 executed at boot time and shutdown time.
+.Pp
+The sysrc(8) command provides a scripting interface to modify system
+config files.
 .Ss Operation of Nm
 .Bl -enum
 .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: r325954 - in head: . share/mk sys/conf usr.sbin/config

[Stefan Esser]

Am 18.11.17 um 03:31 schrieb Pedro Giffuni:
> 
>> On Nov 17, 2017, at 20:34, Rodney W. Grimes  
>> wrote:
>>
>> [ Charset UTF-8 unsupported, converting... ]
>>> Kib@ posted to arch that we were removing it, nobody objected, we removed
>>> it. If it was a working feature that might have a few users, that's one
>>> thing. But I don't think make lint has actually worked in at least a decade.
>>
>> Thats a sad state of affairs.
>>
> 
> t’s not sad, just the way things are, modern compilers are doing much of the 
> checking older tools like lint used to do.. OpenBSD and DragonflyBSD both 
> killed lint ages ago.
> 
> OTOH, we should probably consider other tools, like sparse:
> 
> https://sparse.wiki.kernel.org/index.php/Main_Page
>  
> The license is fine and it plays nice with the compiler.

It builds on -CURRENT, but the Makefile needs some tweaks (it does
not find LLVM or Gtk+-2.0, even though they are present on my system).

I'll work on a port over the weekend ...

Regards, STefan
___
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: r325954 - in head: . share/mk sys/conf usr.sbin/config

[Stefan Esser]

Am 18.11.17 um 16:01 schrieb Pedro Giffuni:
> Hi;
> 
> On 11/18/17 09:15, Stefan Esser wrote:
>> Am 18.11.17 um 03:31 schrieb Pedro Giffuni:
>>>> On Nov 17, 2017, at 20:34, Rodney W. Grimes
>>>>  wrote:
>>>>
>>>> [ Charset UTF-8 unsupported, converting... ]
>>>>> Kib@ posted to arch that we were removing it, nobody objected, we removed
>>>>> it. If it was a working feature that might have a few users, that's one
>>>>> thing. But I don't think make lint has actually worked in at least a 
>>>>> decade.
>>>> Thats a sad state of affairs.
>>>>
>>> t’s not sad, just the way things are, modern compilers are doing much of
>>> the checking older tools like lint used to do.. OpenBSD and DragonflyBSD
>>> both killed lint ages ago.
>>>
>>> OTOH, we should probably consider other tools, like sparse:
>>>
>>> https://sparse.wiki.kernel.org/index.php/Main_Page
>>>   The license is fine and it plays nice with the compiler.
>> It builds on -CURRENT, but the Makefile needs some tweaks (it does
>> not find LLVM or Gtk+-2.0, even though they are present on my system).
>>
>> I'll work on a port over the weekend ...
> 
> Thanks!

I've got a port that builds all of sparse except sparse-llvm. The sources
use GNU extensions, and I do not think it is worth the effort to provide
standard compliant replacements for them at this time.

Building sparc´se-llvm will take some more effort and require the LLVM port
to be installed, since it references headers not installed by our system
compiler. It is an optional component, but one we definitely should have.

I'm not sure how to proceed, but the easiest path forward is to make the
LLVM support optional and depend on one particular LLVM version (i.e. 4.0
for now) built from a port if the option is enabled.

> For it to be really useful we still would have to add annotations to the
> kernel headers.

Well, those could be added over time ...

> I just resurrected a recent proposal from brooks@ into the IdeasPage:
> 
> https://wiki.freebsd.org/IdeasPage#Userspace_Address_Space_Annotation
> 
> It is actually a fun project but my hands are full!

The port was easy, so far, I'll commit it without sparse-llvm for now.
LLVM support will follow when I've got the remaining build issues resolved.

Regards, STefan
___
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"

svn commit: r228572 - head/sys/dev/drm

[Stefan Esser]

Author: se
Date: Fri Dec 16 12:42:02 2011
New Revision: 228572
URL: http://svn.freebsd.org/changeset/base/228572

Log:
  Fix format string Z --> z, since the former is a deprecated and (in FreeBSD)
  unsupported form of the latter. This change has been reviewed and accepted
  in the -hackers list.
  
  Submitted by: Alexander Best
  Reviewed by:  David Schulz

Modified:
  head/sys/dev/drm/mga_drv.h

Modified: head/sys/dev/drm/mga_drv.h
==
--- head/sys/dev/drm/mga_drv.h  Fri Dec 16 12:16:56 2011(r228571)
+++ head/sys/dev/drm/mga_drv.h  Fri Dec 16 12:42:02 2011(r228572)
@@ -288,7 +288,7 @@ do {
\
 do {   \
if ( MGA_VERBOSE ) {\
DRM_INFO( "BEGIN_DMA( %d )\n", (n) );   \
-   DRM_INFO( "   space=0x%x req=0x%Zx\n",  \
+   DRM_INFO( "   space=0x%x req=0x%zx\n",  \
  dev_priv->prim.space, (n) * DMA_BLOCK_SIZE ); \
}   \
prim = dev_priv->prim.start;\
@@ -338,7 +338,7 @@ do {
\
 #define DMA_WRITE( offset, val )   \
 do {   \
if ( MGA_VERBOSE ) {\
-   DRM_INFO( "   DMA_WRITE( 0x%08x ) at 0x%04Zx\n",\
+   DRM_INFO( "   DMA_WRITE( 0x%08x ) at 0x%04zx\n",\
  (u32)(val), write + (offset) * sizeof(u32) ); \
}   \
*(volatile u32 *)(prim + write + (offset) * sizeof(u32)) = val; \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r223596 - head/share/mk

[Stefan Esser]

Author: se
Date: Mon Jun 27 13:23:51 2011
New Revision: 223596
URL: http://svn.freebsd.org/changeset/base/223596

Log:
  Add macros to specify owner, group and mode of config files for installation.
  
  Submitted by: Chris Rees (crees)

Modified:
  head/share/mk/bsd.own.mk

Modified: head/share/mk/bsd.own.mk
==
--- head/share/mk/bsd.own.mkMon Jun 27 13:02:23 2011(r223595)
+++ head/share/mk/bsd.own.mkMon Jun 27 13:23:51 2011(r223596)
@@ -63,6 +63,15 @@
 # SHAREMODEASCII text file mode. [${NOBINMODE}]
 #
 #
+# CONFDIR  Base path for configuration files. [/etc]
+#
+# CONFOWN  Configuration file owner. [root]
+#
+# CONFGRP  Configuration file group. [wheel]
+#
+# CONFMODE Configuration file mode. [644]
+#
+#
 # DOCDIR   Base path for system documentation (e.g. PSD, USD,
 #  handbook, FAQ etc.). [${SHAREDIR}/doc]
 #
@@ -145,6 +154,11 @@ SHAREOWN?= root
 SHAREGRP?= wheel
 SHAREMODE?=${NOBINMODE}
 
+CONFDIR?=  /etc
+CONFOWN?=  root
+CONFGRP?=  wheel
+CONFMODE?= 644
+
 MANDIR?=   ${SHAREDIR}/man/man
 MANOWN?=   ${SHAREOWN}
 MANGRP?=   ${SHAREGRP}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r223881 - head/bin/expr

[Stefan Esser]

Author: se
Date: Sat Jul  9 12:05:53 2011
New Revision: 223881
URL: http://svn.freebsd.org/changeset/base/223881

Log:
  Make /bin/expr support 64bit numeric range and range checks by default,
  again. This brings back the behaviour of expr in FreeBSD-4, which had been
  reverted due to an assumed incompatbility with POSIX.1 for FreeBSD-5.
  
  This issue has been discussed in the freebsd-standards list, and the
  consensus was, that POSIX.1 is in fact not violated by this extension,
  since it affects only cases of POSIX undefined behaviour (overflow of
  signed long).
  
  Other operating systems did upgrade their versions of expr to support
  64bit range, after it had been initially brought to FreeBSD. They have
  used it for a decade without problems, meanwhile.
  
  The -e option is retained, but it will only select less strict checking
  of numeric parameters (leading white-space, leading "+" are allowed and
  skipped, an empty string is considered to represent 0 in numeric context.)
  The call of check_utility_compat() as a means of establishing backwards
  compatibility with FreeBSD-4 is considered obsolete, but preserved in
  this commit. It is expected to be removed in a later revision of this
  file.
  Reviewed by:  bde, das, jilles
  MFC after:2 month (those parts that do not violate POLA)

Modified:
  head/bin/expr/expr.1
  head/bin/expr/expr.y

Modified: head/bin/expr/expr.1
==
--- head/bin/expr/expr.1Sat Jul  9 12:02:40 2011(r223880)
+++ head/bin/expr/expr.1Sat Jul  9 12:05:53 2011(r223881)
@@ -50,25 +50,25 @@ and writes the result on standard output
 All operators and operands must be passed as separate arguments.
 Several of the operators have special meaning to command interpreters
 and must therefore be quoted appropriately.
-All integer operands are interpreted in base 10.
+All integer operands are interpreted in base 10 and must consist of only
+an optional leading minus sign followed by one or more digits (unless
+less strict parsing has been enabled for backwards compatibilty with
+prior versions of
+.Nm
+in
+.Fx ) .
 .Pp
-Arithmetic operations are performed using signed integer math.
-If the
-.Fl e
-flag is specified, arithmetic uses the C
+Arithmetic operations are performed using signed integer math with a
+range according to the C
 .Vt intmax_t
-data type (the largest integral type available), and
-.Nm
-will detect arithmetic overflow and return an error indication.
-If a numeric operand is specified which is so large as to overflow
-conversion to an integer, it is parsed as a string instead.
-If
+data type (the largest signed integral type available).
+All conversions and operations are checked for overflow.
+Overflow results in program termination with an error message on stdout
+and with an error status.
+.Pp
+The
 .Fl e
-is not specified, arithmetic operations and parsing of integer
-arguments will overflow silently according to the rules of the C
-standard, using the
-.Vt long
-data type.
+option enables backwards compatible behaviour as detailed below.
 .Pp
 Operators are listed below in order of increasing precedence; all
 are left-associative.
@@ -82,7 +82,9 @@ Return the evaluation of
 .Ar expr1
 if it is neither an empty string nor zero;
 otherwise, returns the evaluation of
-.Ar expr2 .
+.Ar expr2
+if it is not an empty string;
+otherwise, returns zero.
 .It Ar expr1 Li & Ar expr2
 Return the evaluation of
 .Ar expr1
@@ -163,25 +165,26 @@ function (with a
 .Fa utility
 argument of
 .Dq Li expr )
-is used to determine whether compatibility mode should be enabled.
+is used to determine whether backwards compatibility mode should be enabled.
 This feature is intended for use as a transition and debugging aid, when
 .Nm
 is used in complex scripts which cannot easily be recast to avoid the
 non-portable usage.
-Enabling compatibility mode
-also implicitly enables the
+Enabling backwards compatibility mode also implicitly enables the
 .Fl e
 option, since this matches the historic behavior of
 .Nm
 in
-.Fx .
+.Fx . This option makes number parsing less strict and permits leading
+white space and an optional leading plus sign. In addition, empty operands
+have an implied value of zero in numeric context.
 For historical reasons, defining the environment variable
 .Ev EXPR_COMPAT
-also enables compatibility mode.
+also enables backwards compatibility mode.
 .Sh ENVIRONMENT
 .Bl -tag -width ".Ev EXPR_COMPAT"
 .It Ev EXPR_COMPAT
-If set, enables compatibility mode.
+If set, enables backwards compatibility mode.
 .El
 .Sh EXIT STATUS
 The
@@ -270,8 +273,37 @@ expands to the required number.
 The
 .Nm
 utility conforms to
-.St -p1003.1-2001 ,
-provided that compatibility mode is not enabled.
+.St -p1003.1-2008 ,
+provided that backwards compatibility mode is not enabled.
+.Pp
+Backwards compatibility mode performs less strict checks of numeric arguments:
+.Bl -bullet
+.

svn commit: r223882 - head/bin/expr

[Stefan Esser]

Author: se
Date: Sat Jul  9 12:14:57 2011
New Revision: 223882
URL: http://svn.freebsd.org/changeset/base/223882

Log:
  Some refactoring for easier maintenance of the code. This is a follow-up
  to re-establishment of 64bit arithmetic, but is committed separately, to
  not obscure that conversion. This commit does not change the observed
  behaviour of expr in any way. Style will be fixed in a follow-up commit.

Modified:
  head/bin/expr/expr.y

Modified: head/bin/expr/expr.y
==
--- head/bin/expr/expr.ySat Jul  9 12:05:53 2011(r223881)
+++ head/bin/expr/expr.ySat Jul  9 12:14:57 2011(r223882)
@@ -40,13 +40,16 @@ struct val {
} u;
 } ;
 
+char   **av;
+intnonposix;
 struct val *result;
 
 void   assert_to_integer(struct val *);
-intchk_div(intmax_t, intmax_t);
-intchk_minus(intmax_t, intmax_t, intmax_t);
-intchk_plus(intmax_t, intmax_t, intmax_t);
-intchk_times(intmax_t, intmax_t, intmax_t);
+void   assert_div(intmax_t, intmax_t);
+void   assert_minus(intmax_t, intmax_t, intmax_t);
+void   assert_plus(intmax_t, intmax_t, intmax_t);
+void   assert_times(intmax_t, intmax_t, intmax_t);
+intcompare_vals(struct val *, struct val *);
 void   free_value(struct val *);
 intis_integer(const char *);
 intisstring(struct val *);
@@ -73,8 +76,6 @@ int   yyerror(const char *);
 intyylex(void);
 intyyparse(void);
 
-static int nonposix;
-char **av;
 %}
 
 %union
@@ -344,138 +345,77 @@ op_and(struct val *a, struct val *b)
}
 }
 
-struct val *
-op_eq(struct val *a, struct val *b)
+int
+compare_vals(struct val *a, struct val *b)
 {
-   struct val *r;
+   int r;
 
-   if (isstring (a) || isstring (b)) {
-   to_string (a);
-   to_string (b);  
-   r = make_integer ((intmax_t)(strcoll (a->u.s, b->u.s) == 0));
+   if (isstring(a) || isstring(b)) {
+   to_string(a);
+   to_string(b);
+   r = strcoll(a->u.s, b->u.s);
} else {
assert_to_integer(a);
assert_to_integer(b);
-   r = make_integer ((intmax_t)(a->u.i == b->u.i));
+   if (a->u.i > b->u.i)
+   r = 1;
+   else if (a->u.i < b->u.i)
+   r = -1;
+   else
+   r = 0;
}
 
-   free_value (a);
-   free_value (b);
-   return r;
+   free_value(a);
+   free_value(b);
+   return (r);
 }
 
 struct val *
-op_gt(struct val *a, struct val *b)
+op_eq(struct val *a, struct val *b)
 {
-   struct val *r;
-
-   if (isstring (a) || isstring (b)) {
-   to_string (a);
-   to_string (b);
-   r = make_integer ((intmax_t)(strcoll (a->u.s, b->u.s) > 0));
-   } else {
-   assert_to_integer(a);
-   assert_to_integer(b);
-   r = make_integer ((intmax_t)(a->u.i > b->u.i));
-   }
+   return (make_integer((intmax_t)(compare_vals(a, b) == 0)));
+}
 
-   free_value (a);
-   free_value (b);
-   return r;
+struct val *
+op_gt(struct val *a, struct val *b)
+{
+   return (make_integer((intmax_t)(compare_vals(a, b) > 0)));
 }
 
 struct val *
 op_lt(struct val *a, struct val *b)
 {
-   struct val *r;
-
-   if (isstring (a) || isstring (b)) {
-   to_string (a);
-   to_string (b);
-   r = make_integer ((intmax_t)(strcoll (a->u.s, b->u.s) < 0));
-   } else {
-   assert_to_integer(a);
-   assert_to_integer(b);
-   r = make_integer ((intmax_t)(a->u.i < b->u.i));
-   }
-
-   free_value (a);
-   free_value (b);
-   return r;
+   return (make_integer((intmax_t)(compare_vals(a, b) < 0)));
 }
 
 struct val *
 op_ge(struct val *a, struct val *b)
 {
-   struct val *r;
-
-   if (isstring (a) || isstring (b)) {
-   to_string (a);
-   to_string (b);
-   r = make_integer ((intmax_t)(strcoll (a->u.s, b->u.s) >= 0));
-   } else {
-   assert_to_integer(a);
-   assert_to_integer(b);
-   r = make_integer ((intmax_t)(a->u.i >= b->u.i));
-   }
-
-   free_value (a);
-   free_value (b);
-   return r;
+   return (make_integer((intmax_t)(compare_vals(a, b) >= 0)));
 }
 
 struct val *
 op_le(struct val *a, struct val *b)
 {
-   struct val *r;
-
-   if (isstring (a) || isstring (b)) {
-   to_string (a);
-   to_string (b);
-   r = make_integer ((intmax_t)(strcoll (a->u.s, b->u.s) <= 0));
-   } else {
-   assert_to_integer(a);
-   assert_to_integer(b);
-   r = make_integer ((intmax_t)

svn commit: r223883 - head/bin/expr

[Stefan Esser]

Author: se
Date: Sat Jul  9 12:20:15 2011
New Revision: 223883
URL: http://svn.freebsd.org/changeset/base/223883

Log:
  Fix style, since this file has just been touched in a major way.
  No actual code changes.

Modified:
  head/bin/expr/expr.y

Modified: head/bin/expr/expr.y
==
--- head/bin/expr/expr.ySat Jul  9 12:14:57 2011(r223882)
+++ head/bin/expr/expr.ySat Jul  9 12:20:15 2011(r223883)
@@ -1,6 +1,6 @@
 %{
 /*-
- * Written by Pace Willisson (p...@blitz.com) 
+ * Written by Pace Willisson (p...@blitz.com)
  * and placed in the public domain.
  *
  * Largely rewritten by J.T. Conklin (j...@wimsey.com)
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-  
+
 /*
  * POSIX specifies a specific error code for syntax errors.  We exit
  * with this code for all errors.
@@ -42,7 +42,7 @@ struct val {
 
 char   **av;
 intnonposix;
-struct val *result;
+struct val *result;
 
 void   assert_to_integer(struct val *);
 void   assert_div(intmax_t, intmax_t);
@@ -52,7 +52,7 @@ void  assert_times(intmax_t, intmax_t, i
 intcompare_vals(struct val *, struct val *);
 void   free_value(struct val *);
 intis_integer(const char *);
-intisstring(struct val *);
+intis_string(struct val *);
 intis_zero_or_null(struct val *);
 struct val *make_integer(intmax_t);
 struct val *make_str(const char *);
@@ -99,23 +99,22 @@ start: expr { result = $$; }
 
 expr:  TOKEN
| '(' expr ')' { $$ = $2; }
-   | expr '|' expr { $$ = op_or ($1, $3); }
-   | expr '&' expr { $$ = op_and ($1, $3); }
-   | expr '=' expr { $$ = op_eq ($1, $3); }
-   | expr '>' expr { $$ = op_gt ($1, $3); }
-   | expr '<' expr { $$ = op_lt ($1, $3); }
-   | expr GE expr  { $$ = op_ge ($1, $3); }
-   | expr LE expr  { $$ = op_le ($1, $3); }
-   | expr NE expr  { $$ = op_ne ($1, $3); }
-   | expr '+' expr { $$ = op_plus ($1, $3); }
-   | expr '-' expr { $$ = op_minus ($1, $3); }
-   | expr '*' expr { $$ = op_times ($1, $3); }
-   | expr '/' expr { $$ = op_div ($1, $3); }
-   | expr '%' expr { $$ = op_rem ($1, $3); }
-   | expr ':' expr { $$ = op_colon ($1, $3); }
+   | expr '|' expr { $$ = op_or($1, $3); }
+   | expr '&' expr { $$ = op_and($1, $3); }
+   | expr '=' expr { $$ = op_eq($1, $3); }
+   | expr '>' expr { $$ = op_gt($1, $3); }
+   | expr '<' expr { $$ = op_lt($1, $3); }
+   | expr GE expr  { $$ = op_ge($1, $3); }
+   | expr LE expr  { $$ = op_le($1, $3); }
+   | expr NE expr  { $$ = op_ne($1, $3); }
+   | expr '+' expr { $$ = op_plus($1, $3); }
+   | expr '-' expr { $$ = op_minus($1, $3); }
+   | expr '*' expr { $$ = op_times($1, $3); }
+   | expr '/' expr { $$ = op_div($1, $3); }
+   | expr '%' expr { $$ = op_rem($1, $3); }
+   | expr ':' expr { $$ = op_colon($1, $3); }
;
 
-
 %%
 
 struct val *
@@ -123,14 +122,13 @@ make_integer(intmax_t i)
 {
struct val *vp;
 
-   vp = (struct val *) malloc (sizeof (*vp));
-   if (vp == NULL) {
+   vp = (struct val *)malloc(sizeof(*vp));
+   if (vp == NULL)
errx(ERR_EXIT, "malloc() failed");
-   }
 
vp->type = integer;
vp->u.i  = i;
-   return vp; 
+   return (vp);
 }
 
 struct val *
@@ -138,28 +136,25 @@ make_str(const char *s)
 {
struct val *vp;
 
-   vp = (struct val *) malloc (sizeof (*vp));
-   if (vp == NULL || ((vp->u.s = strdup (s)) == NULL)) {
+   vp = (struct val *)malloc(sizeof(*vp));
+   if (vp == NULL || ((vp->u.s = strdup(s)) == NULL))
errx(ERR_EXIT, "malloc() failed");
-   }
 
if (is_integer(s))
vp->type = numeric_string;
else
vp->type = string;
 
-   return vp;
+   return (vp);
 }
 
-
 void
 free_value(struct val *vp)
 {
if (vp->type == string || vp->type == numeric_string)
-   free (vp->u.s); 
+   free(vp->u.s);
 }
 
-
 int
 to_integer(struct val *vp)
 {
@@ -171,7 +166,7 @@ to_integer(struct val *vp)
i  = strtoimax(vp->u.s, (char **)NULL, 10);
/* just keep as numeric_string, if the conversion fails */
if (errno != ERANGE) {
-   free (vp->u.s);
+   free(vp->u.s);
vp->u.i = i;
vp->type = integer;
}
@@ -179,7 +174,6 @@ to_integer(struct val *vp)
return (vp->type == integer);
 }
 
-
 void
 assert_to_integer(struct val *vp)
 {
@@ -212,7 +206,6 @@ to_string(struct val *vp)
vp->u.s  = tmp;
 }
 
-
 int
 is_integer(const char *s)
 {
@@ -231,15 +224,13 @@ is_integer(const char *s)
return (*s == '\0');
 }
 
-
 int
-isstring(struct val *vp)
+is_string(struct val *vp)
 {
/* only TRUE if 

svn commit: r226470 - head/etc/periodic/daily

[Stefan Esser]

Author: se
Date: Mon Oct 17 14:33:41 2011
New Revision: 226470
URL: http://svn.freebsd.org/changeset/base/226470

Log:
  Fix error message in case the backup storage directory does not exist and
  cannot be created ($daily_backup_pkgdb_dbdir -> $daily_backup_pkgdb_dir).
  MFC after:1 week

Modified:
  head/etc/periodic/daily/220.backup-pkgdb

Modified: head/etc/periodic/daily/220.backup-pkgdb
==
--- head/etc/periodic/daily/220.backup-pkgdbMon Oct 17 14:17:37 2011
(r226469)
+++ head/etc/periodic/daily/220.backup-pkgdbMon Oct 17 14:33:41 2011
(r226470)
@@ -25,7 +25,7 @@ case "$daily_backup_pkgdb_enable" in
then
install -d -o root -g wheel -m 750 $bak || {
echo '$daily_backup_pkgdb_enable is enabled but' \
-   "$daily_backup_pkgdb_dbdir doesn't exist" ;
+   "$daily_backup_pkgdb_dir doesn't exist" ;
exit 2 ; }
fi
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r226471 - head/etc/defaults

[Stefan Esser]

Author: se
Date: Mon Oct 17 14:37:24 2011
New Revision: 226471
URL: http://svn.freebsd.org/changeset/base/226471

Log:
  Add missing default values for daily/800.scrub-zfs for documentation
  purposes. No functional change, since all parameters are set to their
  default values.
  MFC after:1 week

Modified:
  head/etc/defaults/periodic.conf

Modified: head/etc/defaults/periodic.conf
==
--- head/etc/defaults/periodic.conf Mon Oct 17 14:33:41 2011
(r226470)
+++ head/etc/defaults/periodic.conf Mon Oct 17 14:37:24 2011
(r226471)
@@ -147,6 +147,12 @@ daily_status_pkg_changes_enable="NO"   
#
 daily_queuerun_enable="YES"# Run mail queue
 daily_submit_queuerun="YES"# Also submit queue
 
+# 800.scrub-zfs
+daily_scrub_zfs_enable="NO"
+daily_scrub_zfs_pools=""   # empty string selects all pools
+daily_scrub_zfs_default_threshold="30" # days between scrubs
+#daily_scrub_zfs_${poolname}_threshold="30"# pool specific threshold
+
 # 999.local
 daily_local="/etc/daily.local" # Local scripts
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r338253 - head/sbin/pfctl

[Stefan Esser]

Am 23.08.18 um 18:10 schrieb Patrick Kelsey:
> Author: pkelsey
> Date: Thu Aug 23 16:10:28 2018
> New Revision: 338253
> URL: https://svnweb.freebsd.org/changeset/base/338253
> 
> Log:
>   Extend tbrsize heuristic in pfctl(8) to provide a sensible value for
>   higher bandwidth interfaces.  The new value is used above 2.5 Gbps,
>   which is the highest standard rate that could be used prior to
>   r338209, so the default behavior for all existing systems should
>   remain the same.
>   
>   The value of 128 chosen is a balance between being big enough to
>   reduce potential precision/quantization effects stemming from frequent
>   bucket refills over small time intervals and being small enough to
>   prevent a greedy driver from burst dequeuing more packets than it has
>   available hardware ring slots for whenever altq transitions from idle
>   to backlogged.
>   
>   Reviewed by:jmallett, kp
>   MFC after:  2 weeks
>   Sponsored by:   RG Nets
>   Differential Revision: https://reviews.freebsd.org/D16852
> 
> Modified:
>   head/sbin/pfctl/pfctl_altq.c
> 
> Modified: head/sbin/pfctl/pfctl_altq.c
> ==
> --- head/sbin/pfctl/pfctl_altq.c  Thu Aug 23 15:01:27 2018
> (r338252)
> +++ head/sbin/pfctl/pfctl_altq.c  Thu Aug 23 16:10:28 2018
> (r338253)
> @@ -299,8 +299,10 @@ eval_pfaltq(struct pfctl *pf, struct pf_altq *pa, stru
>   size = 4;
>   else if (rate <= 200 * 1000 * 1000)
>   size = 8;
> - else
> + else if (rate <= 2500 * 1000 * 1000)
>   size = 24;
> + else
> + size = 128;
>   size = size * getifmtu(pa->ifname);
>   pa->tbrsize = size;
>   }
> 

This breaks the build on my amd64 box:

/usr/svn/base/head/sbin/pfctl/pfctl_altq.c:302:32: error: overflow in
expression; result is -1794967296 with type 'int' [-Werror,-Winteger-overflow]
else if (rate <= 2500 * 1000 * 1000)
 ^

While "rate" is unsigned long, the expression being calculated is not ...

Regards, STefan
___
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"

svn commit: r321859 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Tue Aug  1 09:34:15 2017
New Revision: 321859
URL: https://svnweb.freebsd.org/changeset/base/321859

Log:
  Adjust path to X11 locale files (/usr/X11 has been changed to /usr/local a
  long ago) in comment. No functional change.

Modified:
  head/share/vt/keymaps/INDEX.keymaps

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Tue Aug  1 09:30:21 2017
(r321858)
+++ head/share/vt/keymaps/INDEX.keymaps Tue Aug  1 09:34:15 2017
(r321859)
@@ -15,7 +15,7 @@
 #  german.iso.kbd:en:german
 #
 # See also setlocal
-# /usr/share/locale, /usr/X11/lib/X11/locale/locale.alias
+# /usr/share/locale, /usr/local/lib/X11/locale/locale.alias
 #
 #
 # Language support: MENU, FONT
@@ -510,9 +510,9 @@ uk.kbd:es:Británico
 
 uk.capsctrl.kbd:en:United Kingdom (Caps Lock acts as Left Ctrl)
 uk.capsctrl.kbd:de:Vereinigtes Königreich (Caps Lock als linke Strg)
-#uk.iso-ctrl.kbd:fr:Royaume Uni (caps lock acts as Left Ctrl)
-#uk.iso-ctrl.kbd:pt:Reino Unido (caps lock acts as Left Ctrl)
-#uk.iso-ctrl.kbd:es:Británico (caps lock acts as Left Ctrl)
+#uk.capsctrl.kbd:fr:Royaume Uni (caps lock acts as Left Ctrl)
+#uk.capsctrl.kbd:pt:Reino Unido (caps lock acts as Left Ctrl)
+#uk.capsctrl.kbd:es:Británico (caps lock acts as Left Ctrl)
 
 uk.dvorak.kbd:en:United Kingdom Dvorak
 uk.dvorak.kbd:de:Vereinigtes Königreich Dvorak
___
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"

svn commit: r321858 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Tue Aug  1 09:30:21 2017
New Revision: 321858
URL: https://svnweb.freebsd.org/changeset/base/321858

Log:
  Add alternate Turkish keyboard layout F. The layout and menu texts have
  been provided by Ufuk Güler, with minor changes for consistency by me.
  
  Submitted by: Ufuk Güler 
  MFC after:1 week

Added:
  head/share/vt/keymaps/tr.f.kbd   (contents, props changed)
Modified:
  head/share/vt/keymaps/INDEX.keymaps
  head/share/vt/keymaps/Makefile

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Tue Aug  1 09:26:22 2017
(r321857)
+++ head/share/vt/keymaps/INDEX.keymaps Tue Aug  1 09:30:21 2017
(r321858)
@@ -31,6 +31,7 @@ MENU:he:ךלש תדלקמה תפש תא רחב
 MENU:uk:Оберiть розкладку клавіатури
 MENU:el:Επιλέξτε το πληκτρολόγιο της κονσόλας
 MENU:hy:Ընտրեք ստեղնաշարի դասավորությունը
+MENU:tr:Klavye düzeninizi seçiniz
 
 #
 # The font definition for "en" is the fall-back font for
@@ -210,6 +211,7 @@ de.kbd:de:Deutsch
 de.kbd:fr:Allemand
 de.kbd:pt:Alemão
 de.kbd:es:Alemán
+de.kbd:tr:Almanca
 de.kbd:uk:Німецька
 
 de.acc.kbd:en:German (accent keys)
@@ -488,10 +490,17 @@ ch.macbook.acc.kbd:fr:Suisse-Allemand  Macbook/Macbook
 ch.macbook.acc.kbd:pt:Suiço-Alemão Macbook/Macbook Pro (com acentos)
 ch.macbook.acc.kbd:es:Germanosuizo  Macbook/Macbook Pro (con acentos)
 
-tr.kbd:en:Turkish
-tr.kbd:de:Türkisch
-tr.kbd:fr:Turc
-tr.kbd:uk:Турецька
+tr.kbd:en:Turkish (Q)
+tr.kbd:de:Türkisch (Q)
+tr.kbd:fr:Turc (Q)
+tr.kbd:uk:Турецька (Q)
+tr.kbd:tr:Türkçe (Q)
+
+tr.f.kbd:en:Turkish (F)
+tr.f.kbd:de:Türkisch (F)
+tr.f.kbd:fr:Turc (F)
+tr.f.kbd:uk:Турецька (F)
+tr.f.kbd:tr:Türkçe (F)
 
 uk.kbd:en:United Kingdom
 uk.kbd:de:Vereinigtes Königreich

Modified: head/share/vt/keymaps/Makefile
==
--- head/share/vt/keymaps/Makefile  Tue Aug  1 09:26:22 2017
(r321857)
+++ head/share/vt/keymaps/Makefile  Tue Aug  1 09:30:21 2017
(r321858)
@@ -67,6 +67,7 @@ FILES=INDEX.keymaps \
se.kbd \
si.kbd \
sk.kbd \
+   tr.f.kbd \
tr.kbd \
ua.kbd \
ua.shift.alt.kbd \

Added: head/share/vt/keymaps/tr.f.kbd
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/vt/keymaps/tr.f.kbd  Tue Aug  1 09:30:21 2017
(r321858)
@@ -0,0 +1,121 @@
+# Turkish F Keyboard (01-08-2017)
+#
+# $FreeBSD$
+#
+# Ufuk Guler
+# ufukgu...@yahoo.com
+#
+# Mobile: +(90) 544 848 39 09
+# alt
+# scan   cntrl  altalt   cntrl lock
+# code  base   shift  cntrl  shift  altshift  cntrl  shift state
+# --
+  000   nopnopnopnopnopnopnopnop O
+  001   escescescescescescdebug  esc O
+  002   '1''!''1''!'0xB9   0xA1   '1''!' O
+  003   '2''"'nul'"'0xB2   nop'2'nul O
+  004   '3''^'nopnop'#'0xB3   '#''#' O
+  005   '4''$'nop'$'0xBC   nop'4''$' O
+  006   '5''%'nop'%'0xBD   nop'5''%' O
+  007   '6''&'nop'&'0xBE   nop'6'nop O
+  008   '7''''nop''''{'nopnop'&' O
+  009   '8''('nop'(''['nopnop'*' O
+  010   '9'')''9'')'']'0xB1   gs '(' O
+  011   '0''='nop'=''}'0xB0   nop')' O
+  012   '/''?'nopnop'\'0xBF   fs nop O
+  013   '-''_'nopnop'|'nopnop'+' O
+  014   bs bs deldelbs bs deldel O
+  015   ht btab   nopnopht btab   nopnop O
+  016   'f''F'ackack'@'nopackack C
+  017   'g''G'belbelbelbelbelbel C
+  018   0x011F 0x011E nopnopnopnopnopnop C
+  019   0x0131 'I'ht ht 0xB6   ht ht ht  C
+  020   'o''O'si si 0xF4   0xD4   si si  C
+  021   'd''D'eoteot0xA5   eoteoteot C
+  022   'r''R'dc2dc20xAE   dc2dc2dc2 C
+  023   'n''N'so so so so so so  C
+  024   'h''H'bs bs 0xB0   bs bs bs  C
+  025   'p''P'dledle0xA3   dledledle C
+  026   'q''Q'dc1dc10xA8   dc1dc1dc1 C
+  027   'w''W'etbetb0x7E   nopnopnop C
+  028   cr cr nl nl cr cr nl nl  O
+  029   lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctr

svn commit: r340428 - in head: . usr.sbin/ctm/ctm

[Stefan Esser]

Author: se
Date: Wed Nov 14 08:45:48 2018
New Revision: 340428
URL: https://svnweb.freebsd.org/changeset/base/340428

Log:
  Prepare move of ctm from base to a port (misc/ctm) by:
  - Adding a note to UPDATING
  - Adding a note to the history section of the manpage ctm.1
  - Adding a message printed to STDERR to the ctm program
  
  This version is meant for release in FreeBSD-12.0 and should remain in
  FreeBSD-12 over its life-time.
  
  A follow-up commit will remove ctm from -CURRENT after the MFC to 12
  has happened.
  
  Approved by:  imp, rgrimes, bcr (man-page)
  MFC after:3 days
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D17969

Modified:
  head/UPDATING
  head/usr.sbin/ctm/ctm/ctm.1
  head/usr.sbin/ctm/ctm/ctm.c

Modified: head/UPDATING
==
--- head/UPDATING   Wed Nov 14 06:46:44 2018(r340427)
+++ head/UPDATING   Wed Nov 14 08:45:48 2018(r340428)
@@ -31,6 +31,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20181115:
+   The set of CTM commands (ctm, ctm_smail, ctm_rmail, ctm_dequeue)
+   has been converted to a port (misc/ctm) and will be removed from
+   FreeBSD-13.  It is available as a package (ctm) for all supported
+   FreeBSD versions.
+
 20181110:
The default newsyslog.conf(5) file has been changed to only include
files in /etc/newsyslog.conf.d/ and /usr/local/etc/newsyslog.conf.d/ if

Modified: head/usr.sbin/ctm/ctm/ctm.1
==
--- head/usr.sbin/ctm/ctm/ctm.1 Wed Nov 14 06:46:44 2018(r340427)
+++ head/usr.sbin/ctm/ctm/ctm.1 Wed Nov 14 08:45:48 2018(r340428)
@@ -12,7 +12,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd April 14, 2016
+.Dd November 15, 2018
 .Dt CTM 1
 .Os
 .Sh NAME
@@ -321,6 +321,12 @@ The
 .Nm
 command appeared in
 .Fx 2.1 .
+.Pp
+The latest
+.Nm
+code has been made available as a port (misc/ctm) in preparation of removal
+from base in
+.Fx 13.0 .
 .Sh AUTHORS
 .An -nosplit
 The CTM system has been designed and implemented by

Modified: head/usr.sbin/ctm/ctm/ctm.c
==
--- head/usr.sbin/ctm/ctm/ctm.c Wed Nov 14 06:46:44 2018(r340427)
+++ head/usr.sbin/ctm/ctm/ctm.c Wed Nov 14 08:45:48 2018(r340428)
@@ -144,6 +144,9 @@ main(int argc, char **argv)
warnx("%d errors during option processing",stat);
return Exit_Pilot;
 }
+fprintf(stderr, "CTM will be removed from FreeBSD-13, and will be "
+   "provided as a port (misc/ctm) or package (ctm).\n\n");
+
 stat = Exit_Done;
 argc -= optind;
 argv += optind;
___
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: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

[Stefan Esser]

Am 10.12.18 um 07:47 schrieb Warner Losh:
> 
> 
> On Sun, Dec 9, 2018, 11:40 PM Cy Schubert   wrote:
> 
> In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net
> >,
> "Rodney W. Gri
> mes" writes:
> > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter
> mailto:oliver.pin...@hardenedbsd.org>
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > On Sunday, December 9, 2018, Warner Losh  > wrote:
> > > >
> > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> > > >> free...@pdx.rh.cn85.dnsmgr.net
> > wrote:
> > > >>
> > > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org
> >, Cy
> > > >> Schubert
> > > >> > > writes:
> > > >> > > > Author: cy
> > > >> > > > Date: Sun Dec  9 06:45:49 2018
> > > >> > > > New Revision: 341759
> > > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759
> > > >> > > >
> > > >> > > > Log:
> > > >> > > >   MFV r341618:
> > > >> > > >
> > > >> > > >   Update wpa 2.6 --> 2.7.
> > > >> > >
> > > >> > > Relnotes: yes
> > > >> >
> > > >> > As an FYI, or maybe a new procedure, doing a reply to
> > > >> > a commit message adding relnotes: yes does very little
> > > >> > to insure that this commit gets refered to in release
> > > >> > notes.
> > > >> >
> > > >> > What about we add RELNOTES.missed to the tree
> > > >> > next to UPDATING, and when someone forgets to tag
> > > >> > the Relnotes:yes into a commit you just follow up
> > > >> > with a commit to that file, stating the svn revision
> > > >> > which was missing the note and then we have a nice
> > > >> > documented and clean way to extract the missing
> > > >> > release note items, rather than trying to cull it
> > > >> > from a thread in a mail list archive.
> > > >> >
> > > >> > The file would get truncated to 0 at appropriate
> > > >> > times on various branches.
> > > >> >
> > > >>
> > > >> How about just RELNOTES. You put the revision that is relevant and
> a qui
> > ck
> > > >> blurb. That way we don't have to look in two places. All release
> notes g
> > o
> > > >> in here, no exceptions. You can retroactively tag them, or you can
> commi
> > t
> > > >> this as part of commit.
> >
> > My one concern is that if we remove the Relnotes: yes line
> > from the commits then we may end up totally ignoring the
> > need to put entries in RELNOTES, which unlike UPDATING
> > do not have consequences if ignored.
> >
> > > >
> > > >
> > > >>
> > > > I don't really know SVN, but there wouldn't be a chicken egg probem
> durin
> > g
> > > > commit time? I mean you would really know the SVN id. So you could
> only a
> > dd
> > > > a specific revision in a different commit to RELEASE file.
> > > >
> > >
> > > Generally, you can guess really well, and fix it in the case of a lost
> race
> > > easily.
> >
> > No reason to guess, if you add the RELNOTES change with the commit
> > then it is the revision that added the RELNOTES entry, so a log view
> > of RELNOTES would show you the revision.  If you do it after words
> > or edit an existing entry in the RELNOTES file that is also fairly
> > clear as that commit has no other files touched.
> >
> > >
> > > You'd add the release notes text in full to the file, with a pointer
> to the
> > > revision(s) for the feature.
> >
> > If you modify RELNOTES with the commit adding the feature we
> > could easily use a pointer of "this commit", the svn version number
> > of that added entry is self referencing to the actual change,
> > which I actually rather like the idea of.
> >
> > >
> > > Warner
> > >
> > > >
> > > >> Have a blurb at the top that tells people what
> > > >> order to add them in, and you'd be set. We'd then retire "relnotes:
> yes"
> > > >> in
> > > >> the commit message. This would also allow 'helpers' to format the
> RELNOT
> > ES
> > > >> file as we go rather than having to play 2 years of catch-up at 
> major
> > > >> branch times.
> >
> > Yes.  You could actually "delete" an entry from RELNOTES once a
> > proper entry in the actual release notes had been created, such
> > that RELNOTES is really a list of pending items.
> >
> > > >>
> > > >> Having it in the commit message just doesn't work, and this is one
> of ma
> > ny
> > > >> reasons: Cy forgot. Other times I'll do something and it's only a 
> month
> > > >> later I realize it needs to be in the release notes aft

svn commit: r342126 - in head: share/man/man5 tools/build/mk tools/build/options usr.sbin usr.sbin/ctm

[Stefan Esser]

Author: se
Date: Sat Dec 15 16:53:15 2018
New Revision: 342126
URL: https://svnweb.freebsd.org/changeset/base/342126

Log:
  Remove CTM from 13-CURRENT after the release of FreeBSD-12.0.
  
  The removal (and creation of a port) has been pre-announced in UPDATING
  1 month ago. Packages are available for all supported FreeBSD vesions.
  
  I did not think that another entry in UPDATING is required to note the
  actual removal.
  
  No MFC is planned - CTM shall be kept in base for all releases up to 12.x.
  
  Reviewed by:  rgrimes
  Approved by:  imp, bcr (manpages)
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D17935

Deleted:
  head/tools/build/options/WITHOUT_CTM
  head/usr.sbin/ctm/
Modified:
  head/share/man/man5/src.conf.5
  head/tools/build/mk/OptionalObsoleteFiles.inc
  head/usr.sbin/Makefile

Modified: head/share/man/man5/src.conf.5
==
--- head/share/man/man5/src.conf.5  Sat Dec 15 15:06:22 2018
(r342125)
+++ head/share/man/man5/src.conf.5  Sat Dec 15 16:53:15 2018
(r342126)
@@ -479,10 +479,6 @@ is set explicitly)
 Set to compile with CTF (Compact C Type Format) data.
 CTF data encapsulates a reduced form of debugging information
 similar to DWARF and the venerable stabs and is required for DTrace.
-.It Va WITHOUT_CTM
-Set to not build
-.Xr ctm 1
-and related utilities.
 .It Va WITHOUT_CUSE
 Set to not build CUSE-related programs and libraries.
 .It Va WITHOUT_CXGBETOOL

Modified: head/tools/build/mk/OptionalObsoleteFiles.inc
==
--- head/tools/build/mk/OptionalObsoleteFiles.inc   Sat Dec 15 15:06:22 
2018(r342125)
+++ head/tools/build/mk/OptionalObsoleteFiles.inc   Sat Dec 15 16:53:15 
2018(r342126)
@@ -1551,18 +1551,6 @@ OLD_FILES+=usr/bin/cpp
 OLD_FILES+=usr/share/man/man1/cpp.1.gz
 .endif
 
-.if ${MK_CTM} == no
-OLD_FILES+=usr/sbin/ctm
-OLD_FILES+=usr/sbin/ctm_dequeue
-OLD_FILES+=usr/sbin/ctm_rmail
-OLD_FILES+=usr/sbin/ctm_smail
-OLD_FILES+=usr/share/man/man1/ctm.1.gz
-OLD_FILES+=usr/share/man/man1/ctm_dequeue.1.gz
-OLD_FILES+=usr/share/man/man1/ctm_rmail.1.gz
-OLD_FILES+=usr/share/man/man1/ctm_smail.1.gz
-OLD_FILES+=usr/share/man/man5/ctm.5.gz
-.endif
-
 .if ${MK_CUSE} == no
 OLD_FILES+=usr/include/fs/cuse/cuse_defs.h
 OLD_FILES+=usr/include/fs/cuse/cuse_ioctl.h

Modified: head/usr.sbin/Makefile
==
--- head/usr.sbin/Makefile  Sat Dec 15 15:06:22 2018(r342125)
+++ head/usr.sbin/Makefile  Sat Dec 15 16:53:15 2018(r342126)
@@ -123,7 +123,6 @@ SUBDIR.${MK_BLUETOOTH}+=bluetooth
 SUBDIR.${MK_BOOTPARAMD}+=  bootparamd
 SUBDIR.${MK_BSDINSTALL}+=  bsdinstall
 SUBDIR.${MK_BSNMP}+=   bsnmpd
-SUBDIR.${MK_CTM}+= ctm
 SUBDIR.${MK_CXGBETOOL}+=   cxgbetool
 SUBDIR.${MK_DIALOG}+=  bsdconfig
 SUBDIR.${MK_EFI}+= efivar efidp efibootmgr
___
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"

svn commit: r342162 - head

[Stefan Esser]

Author: se
Date: Mon Dec 17 10:17:56 2018
New Revision: 342162
URL: https://svnweb.freebsd.org/changeset/base/342162

Log:
  Add removed CTM files to ObsoleteFiles.inc as a follow-up to r342126.

Modified:
  head/ObsoleteFiles.inc

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Mon Dec 17 07:43:29 2018(r342161)
+++ head/ObsoleteFiles.inc  Mon Dec 17 10:17:56 2018(r342162)
@@ -38,6 +38,16 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20181215: Migration of CTM to ports
+OLD_FILES+=usr/sbin/ctm
+OLD_FILES+=usr/sbin/ctm_dequeue
+OLD_FILES+=usr/sbin/ctm_rmail
+OLD_FILES+=usr/sbin/ctm_smail
+OLD_FILES+=usr/share/man/man1/ctm.1.gz
+OLD_FILES+=usr/share/man/man1/ctm_dequeue.1.gz
+OLD_FILES+=usr/share/man/man1/ctm_rmail.1.gz
+OLD_FILES+=usr/share/man/man1/ctm_smail.1.gz
+OLD_FILES+=usr/share/man/man5/ctm.5.gz
 # 20181214: Remove timed files
 OLD_FILES+=etc/rc.d/timed
 OLD_FILES+=usr/sbin/timed
___
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"

svn commit: r343303 - head/usr.sbin/kbdmap

[Stefan Esser]

Author: se
Date: Tue Jan 22 13:11:15 2019
New Revision: 343303
URL: https://svnweb.freebsd.org/changeset/base/343303

Log:
  Silence a CI warning regarding the use of strcpy().
  
  While this is a false positive (a sufficiently large buffer has been
  allocated in the line above), the use of strdup() simplifies and clarifies
  the code.
  
  MFC after:2 weeks

Modified:
  head/usr.sbin/kbdmap/kbdmap.c

Modified: head/usr.sbin/kbdmap/kbdmap.c
==
--- head/usr.sbin/kbdmap/kbdmap.c   Tue Jan 22 12:56:49 2019
(r343302)
+++ head/usr.sbin/kbdmap/kbdmap.c   Tue Jan 22 13:11:15 2019
(r343303)
@@ -241,8 +241,7 @@ get_font(void)
if (strcmp(buf, "NO")) {
if (fnt)
free(fnt);
-   fnt = (char *) malloc(strlen(buf) + 1);
-   strcpy(fnt, buf);
+   fnt = strdup(buf);
}
}
}
___
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"

svn commit: r343339 - head/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Wed Jan 23 10:05:27 2019
New Revision: 343339
URL: https://svnweb.freebsd.org/changeset/base/343339

Log:
  Silence Clang Scan warning about use of unitialized variable.
  
  While the warning is a false positive, it is possible to clarify the code by
  always initializing the variable. This does also allow to make the sending
  of the "beep" control sequence depend on the validity of its parameters.
  
  I have left the redundant assignment of 0 to the now initialized variables
  in place since this makes the code simpler to understand and does not add
  any run-time overhead (the compiler completely removes the "else if" test
  and the assignments).
  
  There was an embedded literal escape character in a string, which messes up
  diplaying the source code on a terminal that interprets ANSI sequences. The
  literal escape has been replaced by \e (non-standard, but supported by all
  relevant compilers, and already used in other source files in base).
  
  MFC after:2 weeks

Modified:
  head/usr.sbin/kbdcontrol/kbdcontrol.c

Modified: head/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- head/usr.sbin/kbdcontrol/kbdcontrol.c   Wed Jan 23 02:46:35 2019
(r343338)
+++ head/usr.sbin/kbdcontrol/kbdcontrol.c   Wed Jan 23 10:05:27 2019
(r343339)
@@ -961,6 +961,8 @@ set_bell_values(char *opt)
int bell, duration, pitch;
 
bell = 0;
+   duration = 0;
+   pitch = 0;
if (!strncmp(opt, "quiet.", 6)) {
bell = CONS_QUIET_BELL;
opt += 6;
@@ -991,8 +993,8 @@ badopt:
}
 
ioctl(0, CONS_BELLTYPE, &bell);
-   if (!(bell & CONS_VISUAL_BELL))
-   fprintf(stderr, "[=%d;%dB", pitch, duration);
+   if (duration > 0 && pitch > 0)
+   fprintf(stderr, "\e[=%d;%dB", pitch, duration);
 }
 
 static void
___
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"

svn commit: r343408 - head/usr.bin/whereis

[Stefan Esser]

Author: se
Date: Thu Jan 24 18:39:45 2019
New Revision: 343408
URL: https://svnweb.freebsd.org/changeset/base/343408

Log:
  Silence Clang Scan warnings regarding the use of strcp().
  
  While these warnings are false positives, the use of strdup() instead of
  malloc() and strcpy() simplifies and clarifies the code.
  
  While checking the remaining uses of strcpy and strcat I noticed an
  assignment of a strlen() to a variable "s", whose value needs to be
  preserved for use in later output routines (where it is used to allocate
  a buffer). I do not think that the value of "s" will come out lower than
  its correct value and thus there is no risk of a buffer overflow, in the
  general case, but a specially crafter argument might lead to an overflow.
  
  The bogus assignment to "s" is removed since this value was only used a
  single time in the following malloc() call, which has been removed.
  
  MFC after:2 weeks

Modified:
  head/usr.bin/whereis/whereis.c

Modified: head/usr.bin/whereis/whereis.c
==
--- head/usr.bin/whereis/whereis.c  Thu Jan 24 18:26:30 2019
(r343407)
+++ head/usr.bin/whereis/whereis.c  Thu Jan 24 18:39:45 2019
(r343408)
@@ -285,9 +285,9 @@ defaults(void)
bindirs[nele] = NULL;
if ((cp = getenv("PATH")) != NULL) {
/* don't destroy the original environment... */
-   if ((b = malloc(strlen(cp) + 1)) == NULL)
+   b = strdup(cp);
+   if (b == NULL)
abort();
-   strcpy(b, cp);
decolonify(b, &bindirs, &nele);
}
}
@@ -301,18 +301,18 @@ defaults(void)
err(EX_OSERR, "error processing manpath results");
if ((b = strchr(buf, '\n')) != NULL)
*b = '\0';
-   if ((b = malloc(strlen(buf) + 1)) == NULL)
+   b = strdup(buf);
+   if (b == NULL)
abort();
-   strcpy(b, buf);
nele = 0;
decolonify(b, &mandirs, &nele);
}
 
/* -s defaults to precompiled list, plus subdirs of /usr/ports */
if (!sourcedirs) {
-   if ((b = malloc(strlen(sourcepath) + 1)) == NULL)
+   b = strdup(sourcepath);
+   if (b == NULL)
abort();
-   strcpy(b, sourcepath);
nele = 0;
decolonify(b, &sourcedirs, &nele);
 
@@ -523,11 +523,9 @@ main(int argc, char **argv)
 * man -w found plain source
 * page, use it.
 */
-   s = strlen(buf);
-   cp2 = malloc(s + 1);
+   cp2 = strdup(buf);
if (cp2 == NULL)
abort();
-   strcpy(cp2, buf);
}
 
if (man == NULL) {
___
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"

svn commit: r343479 - head/libexec/getty

[Stefan Esser]

Author: se
Date: Sat Jan 26 20:43:28 2019
New Revision: 343479
URL: https://svnweb.freebsd.org/changeset/base/343479

Log:
  Fix potential buffer overflow and undefined behavior.
  
  The buffer allocated in read_chat() could be 1 element too short, if the
  chatstr parameter passed in is 1 or 3 charachters long (e.g. "a" or "a b").
  The allocation of the pointer array does not account for the terminating
  NULL pointer in that case.
  
  Overlapping source and destination strings are undefined in strcpy().
  Instead of moving a string to the left by one character just increment the
  char pointer before it is assigned to the results array.
  
  MFC after:2 weeks

Modified:
  head/libexec/getty/chat.c

Modified: head/libexec/getty/chat.c
==
--- head/libexec/getty/chat.c   Sat Jan 26 18:23:19 2019(r343478)
+++ head/libexec/getty/chat.c   Sat Jan 26 20:43:28 2019(r343479)
@@ -141,7 +141,7 @@ read_chat(char **chatstr)
int l;
 
if ((l=strlen(str)) > 0 && (tmp=malloc(l + 1)) != NULL &&
-   (res=malloc((l / 2 + 1) * sizeof(char *))) != NULL) {
+   (res=malloc(((l + 1) / 2 + 1) * sizeof(char *))) != NULL) {
static char ws[] = " \t";
char * p;
 
@@ -216,7 +216,7 @@ read_chat(char **chatstr)
q = strrchr(p+1, *p);
if (q != NULL && *q == *p && q[1] == 
'\0') {
*q = '\0';
-   strcpy(p, p+1);
+   p++;
}
}
 
___
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"

svn commit: r343480 - head/lib/libfigpar

[Stefan Esser]

Author: se
Date: Sat Jan 26 21:30:26 2019
New Revision: 343480
URL: https://svnweb.freebsd.org/changeset/base/343480

Log:
  Silence Clang Scan warning about potentially unsafe use of strcpy.
  
  While this is a false positive, the use of strdup() simplifies the code.
  
  MFC after:2 weeks

Modified:
  head/lib/libfigpar/string_m.c

Modified: head/lib/libfigpar/string_m.c
==
--- head/lib/libfigpar/string_m.c   Sat Jan 26 20:43:28 2019
(r343479)
+++ head/lib/libfigpar/string_m.c   Sat Jan 26 21:30:26 2019
(r343480)
@@ -119,10 +119,9 @@ replaceall(char *source, const char *find, const char 
 
/* If replace is longer than find, we'll need to create a temp copy */
if (rlen > flen) {
-   temp = malloc(slen + 1);
-   if (errno != 0) /* could not allocate memory */
+   temp = strdup(source);
+   if (temp == NULL) /* could not allocate memory */
return (-1);
-   strcpy(temp, source);
} else
temp = source;
 
___
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"

svn commit: r343482 - head/lib/libfigpar

[Stefan Esser]

Author: se
Date: Sat Jan 26 22:24:15 2019
New Revision: 343482
URL: https://svnweb.freebsd.org/changeset/base/343482

Log:
  Slightly improve previous commit that silenced a Clang Scan warning.
  
  The strdup() call does not take advantage of the known length of the
  source string. Replace by malloc() and memcpy() utilizimng the pre-
  calculated string length.
  
  Submitted by: cperciva
  Reported by:  rgrimes
  MFC after:2 weeks

Modified:
  head/lib/libfigpar/string_m.c

Modified: head/lib/libfigpar/string_m.c
==
--- head/lib/libfigpar/string_m.c   Sat Jan 26 21:35:51 2019
(r343481)
+++ head/lib/libfigpar/string_m.c   Sat Jan 26 22:24:15 2019
(r343482)
@@ -119,9 +119,10 @@ replaceall(char *source, const char *find, const char 
 
/* If replace is longer than find, we'll need to create a temp copy */
if (rlen > flen) {
-   temp = strdup(source);
+   temp = malloc(slen + 1);
if (temp == NULL) /* could not allocate memory */
return (-1);
+   memcpy(temp, source, slen + 1);
} else
temp = source;
 
___
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: r343480 - head/lib/libfigpar

[Stefan Esser]

Am 26.01.19 um 22:59 schrieb Colin Percival:
> On 1/26/19 1:36 PM, Rodney W. Grimes wrote:
>>> Author: se
>>> Date: Sat Jan 26 21:30:26 2019
>>> New Revision: 343480
>>> URL: https://svnweb.freebsd.org/changeset/base/343480
>>>
>>> Log:
>>>   Silence Clang Scan warning about potentially unsafe use of strcpy.
>>>   
>>>   While this is a false positive, the use of strdup() simplifies the code.
>>
>> Though that might be true, it also has to recalculate the
>> length of the string which was already known by slen.
>>
>> I am not sure how often this code is called,
>> but that is wasted cycles in a library.
> 
> The length of the string was already being recalculated, by strcpy.
> 
> It seems to me that this could be written as
> 
>   temp = malloc(slen + 1);
>   if (temp == NULL) /* could not allocate memory */
>   return (-1);
>   memcpy(temp, source, slen + 1);
> 
> which avoids both recalculating the string length and using strcpy?

In principle you are right, there is a small run-time cost by not using
the known length for the allocation.

The Clang Scan checks are leading to lots (thousands) of false positives
and a I have looked at quite a number and abstained from silencing them
in the hope that the scan will be improved.

It should learn that at least the trivial case of an allocation of the
value of strlen()+1 followed by a strcpy (and no further strcat or the
like) is safe.

But I have seen cases where the assumption is that "i<0" followed by
"i>=0" at the same location and then a warning about potential problem.

I have committed the version you suggest in rev. 343482 ...

Regards, STefan
___
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"

svn commit: r269119 - head/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Sat Jul 26 12:17:26 2014
New Revision: 269119
URL: http://svnweb.freebsd.org/changeset/base/269119

Log:
  Fix obvious off by one error: prefix[1] should be set to the path of the
  newcons specific keymap files, not prefix[2]. The result of this bug was
  that kbdcontrol ignored the files in the syscons keymap directory, which
  apparently still work under newcons, for most locales.
  
  MFC after:1 week

Modified:
  head/usr.sbin/kbdcontrol/kbdcontrol.c

Modified: head/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- head/usr.sbin/kbdcontrol/kbdcontrol.c   Sat Jul 26 10:20:48 2014
(r269118)
+++ head/usr.sbin/kbdcontrol/kbdcontrol.c   Sat Jul 26 12:17:26 2014
(r269119)
@@ -804,7 +804,7 @@ load_keymap(char *opt, int dumponly)
char*postfix[] = {blank, dotkbd, NULL};
 
if (is_vt4())
-   prefix[2] = vt_keymap_path;
+   prefix[1] = vt_keymap_path;
cp = getenv("KEYMAP_PATH");
if (cp != NULL)
asprintf(&(prefix[0]), "%s/", cp);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r269120 - head/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Sat Jul 26 13:14:28 2014
New Revision: 269120
URL: http://svnweb.freebsd.org/changeset/base/269120

Log:
  The previous commit (r269119) introduced a regression: It removed the
  ability to specify the the full path name of the keymap file.
  
  Instead leave the original search order intact, but insert the path for
  newcons-specific fonts (if run on a system using newcons):
  
- KEYMAP_PATH in environment
- full path name
- /usr/share/vt/keymaps (only if newcons is in use!)
- /usr/share/syscons/keymaps(also as fall-back for newcons)
  
  MFC after:1 week

Modified:
  head/usr.sbin/kbdcontrol/kbdcontrol.c

Modified: head/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- head/usr.sbin/kbdcontrol/kbdcontrol.c   Sat Jul 26 12:17:26 2014
(r269119)
+++ head/usr.sbin/kbdcontrol/kbdcontrol.c   Sat Jul 26 13:14:28 2014
(r269120)
@@ -800,11 +800,11 @@ load_keymap(char *opt, int dumponly)
char*name, *cp;
charblank[] = "", keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
-   char*prefix[]  = {blank, blank, keymap_path, NULL};
+   char*prefix[]  = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
 
if (is_vt4())
-   prefix[1] = vt_keymap_path;
+   prefix[2] = vt_keymap_path;
cp = getenv("KEYMAP_PATH");
if (cp != NULL)
asprintf(&(prefix[0]), "%s/", cp);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r269976 - head/usr.sbin/kbdmap

[Stefan Esser]

Author: se
Date: Thu Aug 14 14:22:12 2014
New Revision: 269976
URL: http://svnweb.freebsd.org/changeset/base/269976

Log:
  Add support for NEWCONS to kbdmap and vidfont.
  
  The path to keymaps and fonts is selected based on the existence and value
  of "sysctl kern.vty".
  
  MFC after:1 week

Modified:
  head/usr.sbin/kbdmap/kbdmap.c
  head/usr.sbin/kbdmap/kbdmap.h

Modified: head/usr.sbin/kbdmap/kbdmap.c
==
--- head/usr.sbin/kbdmap/kbdmap.c   Thu Aug 14 14:07:05 2014
(r269975)
+++ head/usr.sbin/kbdmap/kbdmap.c   Thu Aug 14 14:22:12 2014
(r269976)
@@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -47,10 +48,10 @@ static const char *lang_default = DEFAUL
 static const char *font;
 static const char *lang;
 static const char *program;
-static const char *keymapdir = DEFAULT_KEYMAP_DIR;
-static const char *fontdir = DEFAULT_FONT_DIR;
+static const char *keymapdir = DEFAULT_VT_KEYMAP_DIR;
+static const char *fontdir = DEFAULT_VT_FONT_DIR;
+static const char *font_default = DEFAULT_VT_FONT;
 static const char *sysconfig = DEFAULT_SYSCONFIG;
-static const char *font_default = DEFAULT_FONT;
 static const char *font_current;
 static const char *dir;
 static const char *menu = "";
@@ -146,6 +147,22 @@ add_keymap(const char *desc, int mark, c
 }
 
 /*
+ * Return 0 if syscons is in use (to select legacy defaults).
+ */
+static int
+check_newcons(void)
+{
+   size_t len;
+   char term[3];
+
+   len = 3;
+   if (sysctlbyname("kern.vty", &term, &len, NULL, 0) != 0 ||
+   strcmp(term, "vt") != 0)
+   return 0;
+   return -1;
+}
+
+/*
  * Figure out the default language to use.
  */
 static const char *
@@ -815,6 +832,12 @@ main(int argc, char **argv)
sleep(2);
}
 
+   if (check_newcons() == 0) {
+   keymapdir = DEFAULT_SC_KEYMAP_DIR;
+   fontdir = DEFAULT_SC_FONT_DIR;
+   font_default = DEFAULT_SC_FONT;
+   }
+
SLIST_INIT(&head);
 
lang = get_locale();

Modified: head/usr.sbin/kbdmap/kbdmap.h
==
--- head/usr.sbin/kbdmap/kbdmap.h   Thu Aug 14 14:07:05 2014
(r269975)
+++ head/usr.sbin/kbdmap/kbdmap.h   Thu Aug 14 14:22:12 2014
(r269976)
@@ -28,7 +28,12 @@
 
 
 #define DEFAULT_LANG   "en"
-#define DEFAULT_KEYMAP_DIR "/usr/share/syscons/keymaps"
-#define DEFAULT_FONT_DIR   "/usr/share/syscons/fonts"
 #define DEFAULT_SYSCONFIG  "/etc/rc.conf"
-#define DEFAULT_FONT   "cp437-8x16.fnt"
+
+#define DEFAULT_SC_KEYMAP_DIR  "/usr/share/syscons/keymaps"
+#define DEFAULT_SC_FONT_DIR"/usr/share/syscons/fonts"
+#define DEFAULT_SC_FONT"cp437-8x16.fnt"
+
+#define DEFAULT_VT_KEYMAP_DIR  "/usr/share/vt/keymaps"
+#define DEFAULT_VT_FONT_DIR"/usr/share/vt/fonts"
+#define DEFAULT_VT_FONT"vgarom-thin-8x16.fnt"
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270098 - head/share/syscons/keymaps

[Stefan Esser]

Author: se
Date: Sun Aug 17 11:59:23 2014
New Revision: 270098
URL: http://svnweb.freebsd.org/changeset/base/270098

Log:
  Add a few missing entries and fix entries that are obviously wrong.
  The use of the old ISO language code "iw" for Hebrew was inconsistent
  and it is replaced by the new language code "he" (which was already
  used for the keyboard menu entry, but not for the menu heading or the
  default font).
  
  These changes are in preparation of the conversion of this file and
  the keymap definitions to Unicode for use with NEWCONS.

Modified:
  head/share/syscons/keymaps/INDEX.keymaps

Modified: head/share/syscons/keymaps/INDEX.keymaps
==
--- head/share/syscons/keymaps/INDEX.keymapsSun Aug 17 10:25:27 2014
(r270097)
+++ head/share/syscons/keymaps/INDEX.keymapsSun Aug 17 11:59:23 2014
(r270098)
@@ -4,7 +4,7 @@
 #
 # Format ::
 #
-# lang: ar bg cs da de el en es fi fr hr hu hy is it iw ja kk ko nl no pl
+# lang: ar bg cs da de el en es fi fr he hr hu hy is it ja kk ko nl no pl
 #   pt ro ru sh sk sl sv tr uk zh
 # lang: lang,lang
 #
@@ -27,7 +27,7 @@ MENU:fr:Choisissez la nationalit� de vot
 MENU:pl:Wybierz uk�ad klawiatury
 MENU:pt:Escolha o layout do teclado
 MENU:es:Seleccione el idioma de su teclado
-MENU:iw:��� �� ��� �� ���
+MENU:he:��� �� ��� �� ���
 MENU:uk:B���Ҧ�� � ���צ�
 MENU:el: ��  ��� 
 MENU:hy:�� ݳ߳�� ���
@@ -36,7 +36,7 @@ FONT:en:cp437-8x16.fnt
 FONT:de,fr,da,no,sv,pt,es:iso-8x16.fnt
 FONT:ru:koi8-r-8x16.fnt
 FONT:pl:iso02-8x16.fnt
-FONT:iw:iso08-8x16.fnt
+FONT:he:iso08-8x16.fnt
 FONT:uk:koi8-u-8x16.fnt
 FONT:el:iso07-8x16.fnt
 FONT:hy:haik8-8x16.fnt
@@ -52,8 +52,10 @@ be.iso.acc.kbd:fr:Belge ISO-8859-1 (avec
 be.iso.acc.kbd:pt:Belga ISO-8859-1 (com acentos)
 be.iso.acc.kbd:es:Belga ISO-8859-1 (con acentos)
 
-bg.bds.ctrlcaps.kbd:bg:Bulgarian BDS
-bg.phonetic.ctrlcaps.kbd:bg:Bulgarian Phonetic
+bg.bds.ctrlcaps.kbd:en:Bulgarian (BDS)
+bg.bds.ctrlcaps.kbd:de:Bulgarisch (BDS)
+bg.phonetic.ctrlcaps.kbd:en:Bulgarian (Phonetic)
+bg.phonetic.ctrlcaps.kbd:de:Bulgarisch (phonetisch)
 
 br275.iso.kbd:en:Brazilian 275 ISO-8859-1
 br275.iso.kbd:de:Brasilianisch 275 ISO-8859-1
@@ -74,10 +76,13 @@ br275.cp850.kbd:pt:Brasileiro 275 Codepa
 br275.cp850.kbd:es:Brasile�o 275 Codepage 850
 
 by.cp1131.kbd:en:Belarusian Codepage 1131
+by.cp1131.kbd:de:Wei�russisch Code page 1131
 by.cp1131.kbd:fr:Bi�lorusse Code page 1131
+by.cp1251.kbd:de:Wei�russisch Codepage 1251
 by.cp1251.kbd:en:Belarusian Codepage 1251
 by.cp1251.kbd:fr:Bi�lorusse Code page 1251
 by.iso5.kbd:en:Belarusian ISO-8859-5
+by.iso5.kbd:de:Wei�russisch ISO-8859-5
 by.iso5.kbd:fr:Bi�lorusse ISO-8859-5
 
 ce.iso2.kbd:en:Central European ISO-8859-2
@@ -88,6 +93,7 @@ ce.iso2.kbd:es:Centroeuropeo ISO-8859-2
 colemak.iso15.acc.kbd:en:Colemak ergonomic alternative
 
 cs.latin2.qwertz.kbd:en:Czech ISO-8859-2 (QWERTZ, accent keys)
+cs.latin2.qwertz.kbd:de:Tschechisch ISO-8859-2 (QWERTZ, mit Akzenten)
 cs.latin2.qwertz.kbd:fr:Tch�que ISO-8859-2 (QWERTZ, avec accents)
 cs.latin2.qwertz.kbd:es:Checo ISO-8859-2 (QWERTZ, con acentos)
 
@@ -118,8 +124,14 @@ danish.cp865.kbd:pt:Dinamarqu�s Codepage
 danish.cp865.kbd:es:Dan�s Codepage 865
 
 danish.iso.macbook.kbd:da:Danish ISO-8859-1 (macbook)
+danish.iso.macbook.kbd:da:Dansk ISO-8859-1 (macbook)
+danish.iso.macbook.kbd:de:D�nisch ISO-8859-1 (Macbook)
+danish.iso.macbook.kbd:fr:Danois ISO-8859-1 (macbook)
+danish.iso.macbook.kbd:pt:Dinamarqu�s ISO-8859-1 (macbook)
+danish.iso.macbook.kbd:es:Dan�s ISO-8859-1 (macbook)
 
 dutch.iso.acc.kbd:en:Dutch ISO keymap (accent keys)
+dutch.iso.acc.kbd:de:Holl�ndisch (mit Akzenten)
 
 eee_nordic.kbd:en:Nordic layout on Asus eeePC
 eee_nordic.kbd:fr:Norv�gien phon�tique sur Asus eeePC
@@ -193,19 +205,19 @@ fr_CA.iso.acc.kbd:fr:Fran�ais Canadien I
 fr_CA.iso.acc.kbd:es:Francocanadiense ISO-8859-1 (con acentos)
 fr_CA.iso.acc.kbd:uk:��-� ISO-8859-1 (accent keys)
 
-german.iso.kbd:en:German ISO-8859-1
-german.iso.kbd:de:Deutsch ISO-8859-1
-german.iso.kbd:fr:Allemand ISO-8859-1
-german.iso.kbd:pt:Alem�o ISO-8859-1
-german.iso.kbd:es:Alem�n ISO-8859-1
-german.iso.kbd:uk: ISO-8859-1
-
-german.iso.acc.kbd:en:German ISO-8859-1 (accent keys)
-german.iso.acc.kbd:de:Deutsch ISO-8859-1 (mit Akzenten)
-german.iso.acc.kbd:fr:Allemand ISO-8859-1 (avec accents)
-german.iso.acc.kbd:pt:Alem�o ISO-8859-1 (com acentos)
-german.iso.acc.kbd:es:Alem�n ISO-8859-1 (con acentos)
-german.iso.acc.kbd:uk: ISO-8859-1 (accent keys)
+german.iso.kbd:en:German ISO-8859-15
+german.iso.kbd:de:Deutsch ISO-8859-15
+german.iso.kbd:fr:Allemand ISO-8859-15
+german.iso.kbd:pt:Alem�o ISO-8859-15
+german.iso.kbd:es:Alem�n ISO-8859-15
+german.iso.kbd:uk: ISO-8859-15
+
+german.iso.acc.kbd:en:German ISO-8859-15 (accent keys)
+german.iso.acc.kbd:de:Deutsch ISO-8859-15 (mit Akzenten)
+german.iso.acc.k

svn commit: r270114 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Sun Aug 17 19:54:21 2014
New Revision: 270114
URL: http://svnweb.freebsd.org/changeset/base/270114

Log:
  Attempt at converting the SYSCONS keymaps to Unicode for use with NEWCONS.
  I have spent many hours comparing source and destination formats, and hope
  to have caught the most severe conversion errors.
  
  Files were converted with a Perl script which I'll shortly commit to the
  tools directory. This script is a much enhanced version of the one
  provided by ray@ and is expected to support the full kbdmap(5) syntax.
  
  The naming convention used is:
  
   <2-letter country code>..kbd
  
  Only if there are multiple layouts for different languages:
  
   <2-letter country code>-<2-letter language code>..kbd
  
  In nearly all cases, the keyboards are country specific, only. Currently
  there is only one case where the language was added ("ch-fr.kbd" for
  the Swiss-French keyboard layout).
  
  I choose to write Unicode character codes as hex numbers. While this
  increases the diff to the SYSCONS keymap files for the trivial cases
  (conversion from ISO8859-1), it really helps to verify the more complex
  cases against a Unicode table (which is indexed by hex numbers).
  
  This commit does not cover all files that have been converted, since I
  need to sort out which ones to use, if there were several with different
  source encodings to choose from.
  
  Review and test of the keymap files is highly desirable before 10.1 is
  released. I'd also appreciate educated opinions regarding the optimum
  variant (to be made available as the default for each language).
  
  Since there are no NEWCONS keymaps in 10-STABLE, I plan to MFC after
  the minimum allowed delay of 3 days, to allow at least a few weeks to
  test and improve what will be in the next release.
  
  MFC after:3 days

Added:
  head/share/vt/keymaps/INDEX.keymaps   (contents, props changed)
  head/share/vt/keymaps/am.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/hy.armscii-8.kbd
  head/share/vt/keymaps/be.acc.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/be.iso.acc.kbd
  head/share/vt/keymaps/bg.bds.ctrlcaps.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/bg.phonetic.ctrlcaps.kbd
  head/share/vt/keymaps/bg.bds.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/bg.bds.ctrlcaps.kbd
  head/share/vt/keymaps/br.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/br275.iso.acc.kbd
  head/share/vt/keymaps/br.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/br275.iso.kbd
  head/share/vt/keymaps/ca.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/fr_CA.iso.acc.kbd
  head/share/vt/keymaps/centraleuropean.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/ce.iso2.kbd
  head/share/vt/keymaps/ch-fr.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/swissfrench.iso.acc.kbd
  head/share/vt/keymaps/ch-fr.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/swissfrench.iso.kbd
  head/share/vt/keymaps/ch.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/swissgerman.iso.acc.kbd
  head/share/vt/keymaps/ch.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/swissgerman.iso.kbd
  head/share/vt/keymaps/ch.macbook.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/swissgerman.macbook.acc.kbd
  head/share/vt/keymaps/colemak.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/colemak.iso15.acc.kbd
  head/share/vt/keymaps/cz.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/cs.latin2.qwertz.kbd
  head/share/vt/keymaps/de.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/german.iso.acc.kbd
  head/share/vt/keymaps/de.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/german.iso.kbd
  head/share/vt/keymaps/dk.acc.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/danish.iso.acc.kbd
  head/share/vt/keymaps/dk.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/danish.iso.kbd
  head/share/vt/keymaps/dk.macbook.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/danish.iso.macbook.kbd
  head/share/vt/keymaps/ee.kbd   (contents, props changed)
 - copied, changed from r270082, 
head/share/syscons/keymaps/estonian.is

Re: svn commit: r270114 - head/share/vt/keymaps

[Stefan Esser]

Am 17.08.2014 um 22:20 schrieb Pedro Giffuni:
> 
> On 08/17/14 14:54, Stefan Esser wrote:
>> Author: se
>> Date: Sun Aug 17 19:54:21 2014
>> New Revision: 270114
>> URL: http://svnweb.freebsd.org/changeset/base/270114
>>
>> Log:
>>Attempt at converting the SYSCONS keymaps to Unicode for use with
>> NEWCONS.
>>I have spent many hours comparing source and destination formats,
>> and hope
>>to have caught the most severe conversion errors.
>>   Files were converted with a Perl script which I'll shortly
>> commit to the
>>tools directory. This script is a much enhanced version of the one
>>provided by ray@ and is expected to support the full kbdmap(5) syntax.
>>   The naming convention used is:
>><2-letter country code>..kbd
>>   Only if there are multiple layouts for different languages:
>><2-letter country code>-<2-letter language code>..kbd
>>   In nearly all cases, the keyboards are country specific, only.
>> Currently
>>there is only one case where the language was added ("ch-fr.kbd" for
>>the Swiss-French keyboard layout).
> 
> My $0.02
> I think es-la could/should  be used for the latin-american keyboard.
> es is basically used only in Spain so it should be es-es

This has been discussed in the mail-list over quite a few days,
and in the end I think that Ed Maste was right with his suggestion
to just use country codes.

My idea was to use the locale IDs, which are of the form
_. But keyboard maps depend more on national
standards than on languages. If you start with the language,
then you need to add the country, but if you start with the
country, you hardly ever need to support language specific
layouts. (The Swiss-French keyboard differs only in two keys
which have the shifted and unshifted characters exchanged.)

> This is just IMHO, and could easily divert into a bikeshed
> though.

It already kind of did, over the last few days ;-)

I spent quite some time discussing the naming scheme and that
time could have been spent on the conversion and review process,
instead ... But I really think that the scheme suggested be Ed
is a good one - it is simple and uses the selector everybody
knows (the country code as used in domain names), while the
language codes are often hard to remember (and SYSCONS keymaps
existed with either one used to name them, as a result).

Therefore, what you'd name "es_LA" (or es-la) is now latinamerican
(it could be "latinamerican-es" if you wanted to make the language
visible in the name). The country comes first, and if there is no
country code (e.g. because the keymap is used in many countries),
a longer name is used.


Sorry, if this is not what you'd have used. Up until two days
ago, I also was in favour of the locale based names. But (just)
the country is much more intuitive selector (and it works for
nearly all countries - and it is easy to support those few that
need both country and language ...)

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

svn commit: r270131 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Mon Aug 18 09:40:19 2014
New Revision: 270131
URL: http://svnweb.freebsd.org/changeset/base/270131

Log:
  Import the tools used to convert the keymap files from SYSCONS (in locale
  dependent encoding) to NEWCONS (Unicode).
  
  The file "LANG.map" is used to convert INDEX.keymaps. It has 3 columns:
  - the language ID as used in the source file
  - the language ID to be used in the generated file (e.g. "iw" -> "he")
  - the encoding of the menu texts for this language
  The conversion result is written to STDOUT.
  
  The file "KBDFILES.map" is used to batch convert keymap files. It's
  columns are:
  - the encoding used for the keymap sounce file
  - the name of the source file
  - the name of the generated file
  The output files are created in the TEMP sub-directory of the vt keymap
  directory, in order to preserve (possibly uncommitted) keymap files in
  /usr/src/share/vt/keymaps.
  
  The convert-keymap.pl script can be directly executed by passing the
  source file name and the encoding on the command line. It writes to
  STDOUT and generates hex Unicode codepoints by default. (This can be
  changed to decimal in the script.)
  
  While written for the one-time conversion of the SYSCONS keymaps into
  the format required for NEWCONS, I think these tools may be useful for
  easy conversion of possible further SYSCONS keymap files, that have not
  been committed to the source tree.

Added:
  head/tools/tools/vt/keymaps/
  head/tools/tools/vt/keymaps/KBDFILES.map   (contents, props changed)
  head/tools/tools/vt/keymaps/LANG.map   (contents, props changed)
  head/tools/tools/vt/keymaps/convert-INDEX.pl   (contents, props changed)
  head/tools/tools/vt/keymaps/convert-keymap.pl   (contents, props changed)
  head/tools/tools/vt/keymaps/convert-keymaps.pl   (contents, props changed)

Added: head/tools/tools/vt/keymaps/KBDFILES.map
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tools/tools/vt/keymaps/KBDFILES.mapMon Aug 18 09:40:19 2014
(r270131)
@@ -0,0 +1,141 @@
+# $FreeBSD$
+
+ISO8859-15 be.iso.kbd  be.kbd
+ISO8859-15 be.iso.acc.kbd  be.acc.kbd
+
+ISO8859-5  bg.bds.ctrlcaps.kbd bg.bds.kbd
+ISO8859-5  bg.phonetic.ctrlcaps.kbdbg.bds.ctrlcaps.kbd
+
+ISO8859-1  br275.iso.kbd   br.kbd
+ISO8859-1  br275.iso.acc.kbd   br.acc.kbd
+CP850  br275.cp850.kbd br.kbd.from-cp850
+
+CP1131 by.cp1131.kbd   by.kbd.from-cp1131
+CP1251 by.cp1251.kbd   by.kbd.from-cp1251
+ISO8859-5  by.iso5.kbd by.kbd.from-iso5
+
+ISO8859-2  ce.iso2.kbd centraleuropean.kbd
+
+ISO8859-1  colemak.iso15.acc.kbd   colemak.kbd
+
+ISO8859-2  cs.latin2.qwertz.kbdcz.kbd
+ISO8859-2  cz.iso2.kbd cz.kbd.from-ce
+
+ISO8859-15 danish.iso.kbd  dk.kbd
+ISO8859-15 danish.iso.acc.kbd  dk.acc.kbd
+CP865  danish.cp865.kbddk.kbd.from-cp865
+ISO8859-1  danish.iso.macbook.kbd  dk.macbook.kbd
+
+ISO8859-1  dutch.iso.acc.kbd   nl.kbd
+
+ISO8859-15 eee_nordic.kbd  nordic.asus-eee.kbd
+
+ISO8859-7  el.iso07.kbdgr.kbd
+
+ISO8859-1  estonian.iso.kbdee.kbd.from-iso1
+ISO8859-15 estonian.iso15.kbd  ee.kbd
+CP850  estonian.cp850.kbd  ee.kbd.from-cp850
+
+ISO8859-15 finnish.iso.kbd fi.kbd
+CP850  finnish.cp850.kbd   fi.kbd.from-cp850
+
+ISO8859-15 fr.iso.kbd  fr.kbd
+ISO8859-15 fr.iso.acc.kbd  fr.acc.kbd
+ISO8859-15 fr.macbook.acc.kbd  fr.macbook.kbd
+ISO8859-1  fr.dvorak.kbd   fr.dvorak.kbd
+ISO8859-15 fr.dvorak.acc.kbd   fr.dvorak.acc.kbd
+
+ISO8859-15 fr_CA.iso.acc.kbd   ca-fr.kbd
+
+ISO8859-15 german.iso.kbd  de.kbd
+ISO8859-15 german.iso.acc.kbd  de.acc.kbd
+CP850  german.cp850.kbdde.kbd.from-cp850
+
+ISO8859-7  gr.elot.acc.kbd gr.elot.acc.kbd
+ISO8859-7  gr.us101.acc.kbdgr.101.acc.kbd
+
+ISO8859-8  iw.iso8.kbd il.kbd
+
+ISO8859-2  hr.iso.kbd  hr.kbd
+
+ISO8859-2  hu.iso2.101keys.kbd hu.101.kbd
+ISO8859-2  hu.iso2.102keys.kbd hu.102.kbd
+
+ARMSCII-8  hy.armscii-8.kbdam.kbd
+
+ISO8859-1  icelandic.iso.kbd   is.kbd
+ISO8859-1  icelandic.iso.acc.kbd   is.acc.kbd
+
+ISO8859-15 it.iso.kbd  it.kbd
+
+ISO8859-1  jp.106.kbd  jp.kbd
+ISO8859-1  jp.106x.kbd

Re: svn commit: r270114 - head/share/vt/keymaps

[Stefan Esser]

Am 17.08.2014 um 23:40 schrieb Pedro Giffuni:
> 
> Il giorno 17/ago/2014, alle ore 16:09, Stefan Esser  <mailto:s...@freebsd.org>> ha scritto:
>> Therefore, what you'd name "es_LA" (or es-la) is now latinamerican
>> (it could be "latinamerican-es" if you wanted to make the language
>> visible in the name). The country comes first, and if there is no
>> country code (e.g. because the keymap is used in many countries),
>> a longer name is used.
> 
> That would, IMHO, be fine. What I dislike is that all other files are using
> two letter codes and meanwhile the latinamerican thing has the long
> name :-P.

Ahh, I see. Well, this long name is meant to stand out when looking at
the keymap files. If you use kbdmap to select a keymap, then it does
not matter how long the name is. And if you select the file by name
from within the keymaps directory, then a short name could easily be
overlooked.

And se-la would mean "Spain using the latinamerican language" ;-)
since the first part is the country, not the language.

But you are not suffering alone: there is "centraleuropean.iso", too.

> FWIW, I tried to change that in syscons but the reduced nomenclature
> came too late and changing names caused too much trouble in
> sysinstall..

I thought it was a good time since nearly all files needed to change
anyway, because of the removal of the encoding from the names.

Names in syscons are probably encoded in lots of rc.conf files, and
changing them might have been a big POLA.

one thing that I'm thinking about is whether we should have an
optional keymap_sc and keymap_vt in rc.conf, which allows to have
different keymap files when running under SYSCONS vs. NEWCONS.

This would be easy to implement, with keymap still being used,
unless the more specific variable for the console driver used has
an override.

I think I'll just implement this for -CURRENT and wait for opinions,
whether this should be merged to -STABLE ...

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

svn commit: r270152 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Mon Aug 18 20:55:11 2014
New Revision: 270152
URL: http://svnweb.freebsd.org/changeset/base/270152

Log:
  Minor fixes to convert-keymap.pl (conversion of 8bit characters in the form
  'x' with high bit set) and to KBDFILES.map (fix encodings and comment out a
  few redundant keymap files).
  
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/KBDFILES.map
  head/tools/tools/vt/keymaps/convert-keymap.pl

Modified: head/tools/tools/vt/keymaps/KBDFILES.map
==
--- head/tools/tools/vt/keymaps/KBDFILES.mapMon Aug 18 20:28:08 2014
(r270151)
+++ head/tools/tools/vt/keymaps/KBDFILES.mapMon Aug 18 20:55:11 2014
(r270152)
@@ -6,13 +6,13 @@ ISO8859-15be.iso.acc.kbd  be.acc.kbd
 ISO8859-5  bg.bds.ctrlcaps.kbd bg.bds.kbd
 ISO8859-5  bg.phonetic.ctrlcaps.kbdbg.bds.ctrlcaps.kbd
 
-ISO8859-1  br275.iso.kbd   br.kbd
-ISO8859-1  br275.iso.acc.kbd   br.acc.kbd
-CP850  br275.cp850.kbd br.kbd.from-cp850
-
-CP1131 by.cp1131.kbd   by.kbd.from-cp1131
-CP1251 by.cp1251.kbd   by.kbd.from-cp1251
-ISO8859-5  by.iso5.kbd by.kbd.from-iso5
+#ISO8859-1 br275.iso.kbd   br.kbd.from-iso1(only 
AltGr-Shift-6 differs from CP850)
+ISO8859-1  br275.iso.acc.kbd   br.kbd
+CP850  br275.cp850.kbd br.noacc.kbd
+
+#CP1131by.cp1131.kbd   by.kbd.from-cp1131  
(Shift-3 not OK)
+#CP1251by.cp1251.kbd   by.kbd.from-cp1251  
(result identical to CP1251)
+ISO8859-5  by.iso5.kbd by.kbd
 
 ISO8859-2  ce.iso2.kbd centraleuropean.kbd
 
@@ -119,11 +119,11 @@ ISO8859-1 swissgerman.macbook.acc.kbd ch
 
 ISO8859-9  tr.iso9.q.kbd   tr.kbd
 
-ISO8859-1  uk.iso.kbd  uk.kbd
-ISO8859-1  uk.iso-ctrl.kbd uk.capsctrl.kbd
-CP850  uk.cp850.kbduk.kbd.from-cp850
-CP850  uk.cp850-ctrl.kbd   uk.capsctrl.kbd.from-cp850
-ISO8859-1  uk.dvorak.kbd   uk.dvorak.kbd
+ISO8859-15 uk.iso.kbd  uk.kbd
+ISO8859-15 uk.iso-ctrl.kbd uk.capsctrl.kbd
+#CP850 uk.cp850.kbduk.kbd.from-cp850   
(no � and different Alt/Alt-Shift encodings)
+#CP850 uk.cp850-ctrl.kbd   uk.capsctrl.kbd.from-cp850  
(no � and different Alt/Alt-Shift encodings)
+ISO8859-15 uk.dvorak.kbd   uk.dvorak.kbd
 
 ISO8859-1  us.iso.kbd  us.kbd
 ISO8859-1  us.iso.acc.kbd  us.acc.kbd

Modified: head/tools/tools/vt/keymaps/convert-keymap.pl
==
--- head/tools/tools/vt/keymaps/convert-keymap.pl   Mon Aug 18 20:28:08 
2014(r270151)
+++ head/tools/tools/vt/keymaps/convert-keymap.pl   Mon Aug 18 20:55:11 
2014(r270152)
@@ -46,7 +46,7 @@ sub convert_token
 if $C =~ m/^(\d+)$/;# decimal number
 return local_to_UCS_code(chr(hex($1)))
 if $C =~ m/^0x([0-9a-f]+)$/i;   # hex number
-return local_to_UCS_code($1)
+return local_to_UCS_code(chr(ord($1)))
 if $C =~ m/^'(.)'$/;# character
 return "";# uncovered case
 }
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270153 - head/share/syscons/keymaps

[Stefan Esser]

Author: se
Date: Mon Aug 18 20:58:17 2014
New Revision: 270153
URL: http://svnweb.freebsd.org/changeset/base/270153

Log:
  Fix minor problems found while converting to NEWCONS format.
  
  MFC after:3 days

Modified:
  head/share/syscons/keymaps/be.iso.acc.kbd
  head/share/syscons/keymaps/cs.latin2.qwertz.kbd
  head/share/syscons/keymaps/uk.iso-ctrl.kbd
  head/share/syscons/keymaps/uk.iso.kbd

Modified: head/share/syscons/keymaps/be.iso.acc.kbd
==
--- head/share/syscons/keymaps/be.iso.acc.kbd   Mon Aug 18 20:55:11 2014
(r270152)
+++ head/share/syscons/keymaps/be.iso.acc.kbd   Mon Aug 18 20:58:17 2014
(r270153)
@@ -42,7 +42,7 @@
   036   'j''J'nl nl 'j''J'nl nl  C
   037   'k''K'vt vt 'k''K'vt vt  C
   038   'l''L'ff ff 'l''L'ff ff  C
-  039   'm''M'cr cr 'm''M'cr cr  O
+  039   'm''M'cr cr 'm''M'cr cr  C
   040   249'%'nopnopdacu   dacu   nopnop O
   041   178179nopnop178179nopnop O
   042   lshift lshift lshift lshift lshift lshift lshift lshift  O
@@ -53,7 +53,7 @@
   047   'v''V'synsyn'v''V'synsyn C
   048   'b''B'stxstx'b''B'stxstx C
   049   'n''N'so so 'n''N'so so  C
-  050   ',''?'nopnop',''?'nopnop C
+  050   ',''?'nopnop',''?'nopnop O
   051   ';''.'nopnop';''.'nopnop O
   052   ':''/'nopnop':''/'nopnop O
   053   '=''+'nopnopdtil   dtil   nopnop O

Modified: head/share/syscons/keymaps/cs.latin2.qwertz.kbd
==
--- head/share/syscons/keymaps/cs.latin2.qwertz.kbd Mon Aug 18 20:55:11 
2014(r270152)
+++ head/share/syscons/keymaps/cs.latin2.qwertz.kbd Mon Aug 18 20:58:17 
2014(r270153)
@@ -1,5 +1,5 @@
 # Czech Standard Typewriter QWERTZ Keyboard
-# by Rudolf Cejka 
+# by Rudolf Cejka 
 #
 # $FreeBSD$
 #

Modified: head/share/syscons/keymaps/uk.iso-ctrl.kbd
==
--- head/share/syscons/keymaps/uk.iso-ctrl.kbd  Mon Aug 18 20:55:11 2014
(r270152)
+++ head/share/syscons/keymaps/uk.iso-ctrl.kbd  Mon Aug 18 20:58:17 2014
(r270153)
@@ -46,7 +46,7 @@
   040   ''''@'nulnul''''@'nulnul O
   041   '`'172nopnop'|''|'nopnop O
   042   lshift lshift lshift lshift lshift lshift lshift lshift  O
-  043   '#''~'nopnop'~''~'nopnop O
+  043   '#''~'nopnop'#''~'nopnop O
   044   'z''Z'subsub'z''Z'subsub C
   045   'x''X'cancan'x''X'cancan C
   046   'c''C'etxetx'c''C'etxetx C

Modified: head/share/syscons/keymaps/uk.iso.kbd
==
--- head/share/syscons/keymaps/uk.iso.kbd   Mon Aug 18 20:55:11 2014
(r270152)
+++ head/share/syscons/keymaps/uk.iso.kbd   Mon Aug 18 20:58:17 2014
(r270153)
@@ -46,7 +46,7 @@
   040   ''''@'nulnul''''@'nulnul O
   041   '`'172nopnop'|''|'nopnop O
   042   lshift lshift lshift lshift lshift lshift lshift lshift  O
-  043   '#''~'nopnop'~''~'nopnop O
+  043   '#''~'nopnop'#''~'nopnop O
   044   'z''Z'subsub'z''Z'subsub C
   045   'x''X'cancan'x''X'cancan C
   046   'c''C'etxetx'c''C'etxetx C
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270156 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Mon Aug 18 21:07:12 2014
New Revision: 270156
URL: http://svnweb.freebsd.org/changeset/base/270156

Log:
  Fix a few conversion problems (e.g. when a keymap is derived from ISO8859-1,
  but shall provide an Euro sign - similar for Japanese Yen).
  
  The Brazilian keymap "br.kbd" now has accents, by default - the no-accents
  version has been renamed to "br.noacc.kbd".
  
  MFC after:3 days

Added:
  head/share/vt/keymaps/br.noacc.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/br275.cp850.kbd
  head/share/vt/keymaps/by.kbd   (contents, props changed)
 - copied, changed from r270082, head/share/syscons/keymaps/by.cp1251.kbd
Replaced:
  head/share/vt/keymaps/br.kbd
 - copied, changed from r270149, head/share/vt/keymaps/br.acc.kbd
Deleted:
  head/share/vt/keymaps/br.acc.kbd
Modified:
  head/share/vt/keymaps/INDEX.keymaps
  head/share/vt/keymaps/Makefile
  head/share/vt/keymaps/ch.acc.kbd
  head/share/vt/keymaps/ch.kbd
  head/share/vt/keymaps/cz.kbd
  head/share/vt/keymaps/hr.kbd
  head/share/vt/keymaps/jp.capsctrl.kbd
  head/share/vt/keymaps/jp.kbd
  head/share/vt/keymaps/si.kbd
  head/share/vt/keymaps/uk.capsctrl.kbd

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Mon Aug 18 21:04:44 2014
(r270155)
+++ head/share/vt/keymaps/INDEX.keymaps Mon Aug 18 21:07:12 2014
(r270156)
@@ -56,35 +56,21 @@ bg.bds.kbd:de:Bulgarisch (BDS)
 bg.bds.ctrlcaps.kbd:en:Bulgarian (Phonetic)
 bg.bds.ctrlcaps.kbd:de:Bulgarisch (phonetisch)
 
-br.kbd:en:Brazilian
-br.kbd:de:Brasilianisch
-br.kbd:fr:Brésilien
-br.kbd:pt:Brasileiro
-br.kbd:es:Brasileño
-
-br.acc.kbd:en:Brazilian (accent keys)
-br.acc.kbd:de:Brasilianisch (mit Akzenten)
-br.acc.kbd:fr:Brésilien (avec accents)
-br.acc.kbd:pt:Brasileiro (com acentos)
-br.acc.kbd:es:Brasileño (con acentos)
-
-br.kbd.from-cp850:en:Brazilian
-br.kbd.from-cp850:de:Brasilianisch
-br.kbd.from-cp850:fr:Brésilien
-br.kbd.from-cp850:pt:Brasileiro
-br.kbd.from-cp850:es:Brasileño
-
-by.kbd.from-cp1131:en:Belarusian
-by.kbd.from-cp1131:de:Weißrussisch
-by.kbd.from-cp1131:fr:Biélorusse
-
-by.kbd.from-cp1251:en:Belarusian
-by.kbd.from-cp1251:de:Weißrussisch
-by.kbd.from-cp1251:fr:Biélorusse
-
-by.kbd.from-iso5:en:Belarusian
-by.kbd.from-iso5:de:Weißrussisch
-by.kbd.from-iso5:fr:Biélorusse
+br.kbd:en:Brazilian (accent keys)
+br.kbd:de:Brasilianisch (mit Akzenten)
+br.kbd:fr:Brésilien (avec accents)
+br.kbd:pt:Brasileiro (com acentos)
+br.kbd:es:Brasileño (con acentos)
+
+br.noacc.kbd:en:Brazilian (without accent keys)
+br.noacc.kbd:de:Brasilianisch (ohne Akzente)
+br.noacc.kbd:fr:Brésilien (sans accents)
+br.noacc.kbd:pt:Brasileiro (without accent keys)
+br.noacc.kbd:es:Brasileño (without accent keys)
+
+by.kbd:en:Belarusian
+by.kbd:de:Weißrussisch
+by.kbd:fr:Biélorusse
 
 centraleuropean.kbd:en:Central European
 centraleuropean.kbd:de:Zentral Europäisch

Modified: head/share/vt/keymaps/Makefile
==
--- head/share/vt/keymaps/Makefile  Mon Aug 18 21:04:44 2014
(r270155)
+++ head/share/vt/keymaps/Makefile  Mon Aug 18 21:07:12 2014
(r270156)
@@ -4,7 +4,6 @@ FILES=  INDEX.keymaps \
am.kbd \
bg.bds.ctrlcaps.kbd \
bg.bds.kbd \
-   br.acc.kbd \
br.kbd \
ca.kbd \
ca-fr.kbd \

Copied and modified: head/share/vt/keymaps/br.kbd (from r270149, 
head/share/vt/keymaps/br.acc.kbd)
==
--- head/share/vt/keymaps/br.acc.kbdMon Aug 18 19:27:47 2014
(r270149, copy source)
+++ head/share/vt/keymaps/br.kbdMon Aug 18 21:07:12 2014
(r270156)
@@ -149,7 +149,3 @@
   duml 0xa8( 'a'0xe4) ( 'A'0xc4) ( 'e'0xeb) ( 'E'  
  0xcb)
( 'i'0xef) ( 'I'0xcf) ( 'o'0xf6) ( 'O'  
  0xd6)
( 'u'0xfc) ( 'U'0xdc) ( 'y'0xff)
-
-  drin 0xb0( 'a'0xe5) ( 'A'0xc5)
-
-  dced 0xb8( 'c'0xe7) ( 'C'0xc7)

Copied and modified: head/share/vt/keymaps/br.noacc.kbd (from r270082, 
head/share/syscons/keymaps/br275.cp850.kbd)
==
--- head/share/syscons/keymaps/br275.cp850.kbd  Sun Aug 17 03:01:56 2014
(r270082, copy source)
+++ head/share/vt/keymaps/br.noacc.kbd  Mon Aug 18 21:07:12 2014
(r270156)
@@ -5,18 +5,18 @@
 # --
   000   nopnopnopnopnopnopnopnop O
   001   escescescescescescdebug  esc O
-  002   '1''!'nopnop251'!'nopnop O
-  003   '2''@'nulnul253'@'nulnul O
-  004   '3''#

svn commit: r270199 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Wed Aug 20 07:46:28 2014
New Revision: 270199
URL: http://svnweb.freebsd.org/changeset/base/270199

Log:
  Fix further conversion errors found while testing the converted keymaps.
  
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/convert-keymap.pl
  head/tools/tools/vt/keymaps/convert-keymaps.pl

Modified: head/tools/tools/vt/keymaps/convert-keymap.pl
==
--- head/tools/tools/vt/keymaps/convert-keymap.pl   Wed Aug 20 06:34:24 
2014(r270198)
+++ head/tools/tools/vt/keymaps/convert-keymap.pl   Wed Aug 20 07:46:28 
2014(r270199)
@@ -35,33 +35,50 @@ sub local_to_UCS_code
 return prettyprint_token(ord(Encode::decode("UTF-8", 
local_to_UCS_string($char;
 }
 
+sub malformed_to_UCS_code
+{
+my ($char) = @_;
+
+return prettyprint_token(ord(Encode::decode("UTF-8", $char)));
+}
 
 sub convert_token
 {
 my ($C) = @_;
 
 return $1
-if $C =~ m/^([a-z][a-z0-9]*)$/; # key token
+if $C =~ m/^([a-z][a-z0-9]*)$/;# key token
 return local_to_UCS_code(chr($1))
-if $C =~ m/^(\d+)$/;# decimal number
+if $C =~ m/^(\d+)$/;   # decimal number
 return local_to_UCS_code(chr(hex($1)))
-if $C =~ m/^0x([0-9a-f]+)$/i;   # hex number
+if $C =~ m/^0x([0-9a-f]+)$/i;  # hex number
 return local_to_UCS_code(chr(ord($1)))
-if $C =~ m/^'(.)'$/;# character
-return "";# uncovered case
+if $C =~ m/^'(.)'$/;   # character
+return malformed_to_UCS_code($1)
+if $C =~ m/^'(.+)'$/;  # character
+return "";   # uncovered case
 }
 
 sub tokenize { # split on white space and parentheses (but not within token)
 my ($line) = @_;
 
-$line =~ s/' '/ _spc_ /g; # prevent splitting of ' '
+#print "<< $line";
 $line =~ s/'\('/ _lpar_ /g; # prevent splitting of '('
 $line =~ s/'\)'/ _rpar_ /g; # prevent splitting of ')'
+$line =~ s/'''/'_squote_'/g; # remove quoted single quotes from matches 
below
 $line =~ s/([()])/ $1 /g; # insert blanks around remaining parentheses
+my $matches;
+do {
+   $matches = ($line =~ s/^([^']*)'([^']+)'/$1_squoteL_$2_squoteR_/g);
+#  print "-> $line<> $matches: ('$1','$2')\n";
+} while $matches;
+$line =~ s/_squoteL_ _squoteR_/ _spc_ /g; # prevent splitting of ' '
 my @KEYTOKEN = split (" ", $line);
+grep(s/_squote[LR]?_/'/g, @KEYTOKEN);
 grep(s/_spc_/' '/, @KEYTOKEN);
 grep(s/_lpar_/'('/, @KEYTOKEN);
 grep(s/_rpar_/')'/, @KEYTOKEN);
+#printf ">> $line%s\n", join('|', @KEYTOKEN);
 return @KEYTOKEN;
 }
 
@@ -85,7 +102,7 @@ while () {
} elsif ($C eq "(") {
printf "%17s", "( "; # paren continues accent definition
} else {
-   print "UNKNOWN DEFINITION: $_";
+   print "Unknown input line format: $_";
}
$at_bol = 0;
} else {

Modified: head/tools/tools/vt/keymaps/convert-keymaps.pl
==
--- head/tools/tools/vt/keymaps/convert-keymaps.pl  Wed Aug 20 06:34:24 
2014(r270198)
+++ head/tools/tools/vt/keymaps/convert-keymaps.pl  Wed Aug 20 07:46:28 
2014(r270199)
@@ -94,6 +94,6 @@ foreach $kbdfile (glob("$dir_keymaps_sys
print "$kbdfile not found\n";
}
 } else {
-   print "Unknown input file: $basename\n";
+   print "Ignore '$basename': No encoding defined in KBDFILES.map\n";
 }
 }
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270200 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Wed Aug 20 07:48:09 2014
New Revision: 270200
URL: http://svnweb.freebsd.org/changeset/base/270200

Log:
  Fix conversion errors leading to malformed keymap files.
  
  MFC after:3 days

Modified:
  head/share/vt/keymaps/cz.kbd
  head/share/vt/keymaps/fr.dvorak.acc.kbd
  head/share/vt/keymaps/nordic.asus-eee.kbd
  head/share/vt/keymaps/pl.dvorak.kbd

Modified: head/share/vt/keymaps/cz.kbd
==
--- head/share/vt/keymaps/cz.kbdWed Aug 20 07:46:28 2014
(r270199)
+++ head/share/vt/keymaps/cz.kbdWed Aug 20 07:48:09 2014
(r270200)
@@ -262,7 +262,7 @@
( 'i'0xed) ( 'n'0x0144  ) ( 'o'0xf3) ( 'u'  
  0xfa)
( 'y'0xfd)
 
-  dcir '^' (  ' '  ) ( 'A'0xc2) ( 'I'0xce) 
( 'O'0xd4)
+  dcir '^' ( '^''^' ) ( 'A'0xc2) ( 'I'0xce) ( 'O'  
  0xd4)
( 'a'0xe2) ( 'i'0xee) ( 'o'0xf4)
 
   dbre 0x02d8  ( 0x02d8 0x02d8  ) ( 'A'0x0102  ) ( 'a'0x0103  )

Modified: head/share/vt/keymaps/fr.dvorak.acc.kbd
==
--- head/share/vt/keymaps/fr.dvorak.acc.kbd Wed Aug 20 07:46:28 2014
(r270199)
+++ head/share/vt/keymaps/fr.dvorak.acc.kbd Wed Aug 20 07:48:09 2014
(r270200)
@@ -1,7 +1,7 @@
 # A Dvorak keyboard for French
 #
 # This is a Dvorak-like layout for French
-# according to Francis Leboutte on
+# according to Francis Leboutte on 
 # http://www.algo.be/ergo/dvorak-fr.html
 #
 #   -Frédéric Praca 
@@ -14,58 +14,58 @@
 # --
   000   nopnopnopnopnopnopnopnop O
   001   escescescescescescdebug  esc O
-  002  '=''1'nopnopnopnopnopnop C
-  003  '/''2'nopnopnopnopnopnop C
-  004  '-''3'nopnopnopnopnopnop C
-  005  'è''4'nopnopnopnopnopnop C
-  006  '\''5'nopnopnopnopnopnop C
-  007  dcir   '6'nopnopnopnopnopnop C
-  008  '(''7'nopnopnopnopnopnop C
-  009  dgra   '8'nopnopnopnopnopnop C
-  010  ')''9'nopnopnopnopnopnop C
-  011  '"''0'nopnopnopnopnopnop C
-  012  '[''+'nopnopnopnopnopnop C
-  013  ']''%'nopnopnopnopnopnop C
+  002   '=''1'nopnopnopnopnopnop C
+  003   '/''2'nopnopnopnopnopnop C
+  004   '-''3'nopnopnopnopnopnop C
+  005   0xe8   '4'nopnopnopnopnopnop C
+  006   '\''5'nopnopnopnopnopnop C
+  007   dcir   '6'nopnopnopnopnopnop C
+  008   '(''7'nopnopnopnopnopnop C
+  009   dgra   '8'nopnopnopnopnopnop C
+  010   ')''9'nopnopnopnopnopnop C
+  011   '"''0'nopnopnopnopnopnop C
+  012   '[''+'nopnopnopnopnopnop C
+  013   ']''%'nopnopnopnopnopnop C
   014   bs bs deldelbs bs deldel O
   015   ht btab   nopnopht btab   nopnop O
-  016  ':''?'nopnopnopnopnopnop O
-  017  ''''<'nopnopnopnopnopnop C
-  018  'é''>'nopnopnopnopnopnop C
-  019  'g''G'nopnopnopnopnopnop C
-  020  '.''!'nopnopnopnopnopnop O
-  021  'h''H'nopnopnopnopnopnop C
-  022  'v''V'nopnopnopnopnopnop C
-  023  'c''C'nopnopnopnopnopnop C
-  024  'm''M'nopnopnopnopnopnop C
-  025  'k''K'nopnopnopnopnopnop C
-  026  'z''Z'nopnopnopnopnopnop C
-  027  ddia   '&'nopnopnopnopnopnop O
+  016   ':''?'nopnopnopnopnopnop O
+  017   ''''<'nopnopnopnopnopnop C
+  018   0xe9   '>'nopnopnopnopnopnop C
+  019   'g''G'nopnopnopnopnopnop C
+  020   '.''!'nopnopnopnopnopnop O
+  021   'h''H'nopnopnopnopnopnop C
+  022   'v''V'nopnopnopnopnopnop C
+  023   'c''C'nopnopnopnopnop

svn commit: r270229 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Wed Aug 20 17:00:47 2014
New Revision: 270229
URL: http://svnweb.freebsd.org/changeset/base/270229

Log:
  Another rpund of fixes, after checking keymaps for plausibility and with
  several updates to the converter tools. There is now support for hybrid
  source keymaps, which e.g. use ISO8859-1 (not -15) but still provide an
  Euro key (on the "E" key). ISO8859-1 currency symbols on other keys are
  still converted to that character, not the Euro sign. A similar hack was
  applied to the Japanese keyboards to add the Yen key, that could not be
  expressed in SYSCONS.
  
  Several modifications have been applied after the conversion (removal of
  unused accents tables, some reformatting, exchange of a few key symbols).
  
  The German keymap (de.kbd) is now using deadkeys only for those keys,
  that behave that way under Windows. There are now ".acc" and ".noacc"
  variants, which use deadkeys vs. nodeadkeys for all accent keys.
  
  I'm still in the process of comparing keymaps that existed in different
  encodings in SYSCONS. These are generally translated slightly differently,
  either because of mistakes, or because of different preferences, or due
  to limitations of the respective encoding.
  
  MFC after:3 days

Added:
  head/share/vt/keymaps/centraleuropean.qwerty.kbd
 - copied, changed from r270200, head/share/vt/keymaps/centraleuropean.kbd
  head/share/vt/keymaps/de.noacc.kbd
 - copied, changed from r270210, head/share/vt/keymaps/de.kbd
Replaced:
  head/share/vt/keymaps/de.kbd
 - copied, changed from r270200, head/share/vt/keymaps/de.acc.kbd
Modified:
  head/share/vt/keymaps/INDEX.keymaps
  head/share/vt/keymaps/Makefile
  head/share/vt/keymaps/am.kbd
  head/share/vt/keymaps/be.acc.kbd
  head/share/vt/keymaps/ca-fr.kbd
  head/share/vt/keymaps/centraleuropean.kbd
  head/share/vt/keymaps/ch-fr.acc.kbd
  head/share/vt/keymaps/ch-fr.kbd
  head/share/vt/keymaps/de.acc.kbd
  head/share/vt/keymaps/dk.acc.kbd
  head/share/vt/keymaps/dk.kbd
  head/share/vt/keymaps/dk.macbook.kbd
  head/share/vt/keymaps/es.dvorak.kbd
  head/share/vt/keymaps/fi.kbd
  head/share/vt/keymaps/fr.acc.kbd
  head/share/vt/keymaps/fr.dvorak.acc.kbd
  head/share/vt/keymaps/fr.dvorak.kbd
  head/share/vt/keymaps/fr.macbook.kbd
  head/share/vt/keymaps/is.kbd
  head/share/vt/keymaps/it.kbd
  head/share/vt/keymaps/jp.pc98.iso.kbd
  head/share/vt/keymaps/jp.pc98.kbd
  head/share/vt/keymaps/no.dvorak.kbd
  head/share/vt/keymaps/no.kbd
  head/share/vt/keymaps/nordic.asus-eee.kbd
  head/share/vt/keymaps/se.kbd
  head/share/vt/keymaps/uk.capsctrl.kbd
  head/share/vt/keymaps/uk.kbd
  head/share/vt/keymaps/us.acc.kbd

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Wed Aug 20 16:59:33 2014
(r270228)
+++ head/share/vt/keymaps/INDEX.keymaps Wed Aug 20 17:00:47 2014
(r270229)
@@ -77,6 +77,11 @@ centraleuropean.kbd:de:Zentral Europäis
 centraleuropean.kbd:fr:Centre européen
 centraleuropean.kbd:es:Centroeuropeo
 
+centraleuropean.qwerty.kbd:en:Central European (QWERTY)
+centraleuropean.qwerty.kbd:de:Zentral Europäisch (QWERTY)
+centraleuropean.qwerty.kbd:fr:Centre européen (QWERTY)
+centraleuropean.qwerty.kbd:es:Centroeuropeo (QWERTY)
+
 colemak.kbd:en:Colemak ergonomic alternative
 
 cz.kbd:en:Czech (QWERTZ, accent keys)
@@ -89,6 +94,11 @@ cz.kbd.from-ce:de:Tschechisch
 cz.kbd.from-ce:fr:Tchèque
 cz.kbd.from-ce:es:Checo
 
+cz.qwerty.kbd.from-ce:en:Czech (QWERTY)
+cz.qwerty.kbd.from-ce:de:Tschechisch (QWERTY)
+cz.qwerty.kbd.from-ce:fr:Tchèquey (QWERTY)
+cz.qwerty.kbd.from-ce:es:Checo (QWERTY)
+
 dk.kbd:en:Danish
 dk.kbd:da:Dansk
 dk.kbd:de:Dänisch
@@ -208,6 +218,13 @@ de.acc.kbd:pt:Alemão (com acentos)
 de.acc.kbd:es:Alemán (con acentos)
 de.acc.kbd:uk:Німецька (accent keys)
 
+de.noacc.kbd:en:German (no accent keys)
+de.noacc.kbd:de:Deutsch (ohne Akzente)
+de.noacc.kbd:fr:Allemand (sans accents)
+de.noacc.kbd:pt:Alemão (no accent keys)
+de.noacc.kbd:es:Alemán (no accent keys)
+de.noacc.kbd:uk:Німецька (no accent keys)
+
 de.kbd.from-cp850:en:German
 de.kbd.from-cp850:de:Deutsch
 de.kbd.from-cp850:fr:Allemand
@@ -501,18 +518,6 @@ uk.capsctrl.kbd:de:Vereinigtes Königrei
 #uk.iso-ctrl.kbd:pt:Reino Unido (caps lock acts as Left Ctrl)
 #uk.iso-ctrl.kbd:es:Brit�nico (caps lock acts as Left Ctrl)
 
-uk.kbd.from-cp850:en:United Kingdom
-uk.kbd.from-cp850:de:Vereinigtes Königreich
-uk.kbd.from-cp850:fr:Royaume Uni
-uk.kbd.from-cp850:pt:Reino Unido
-uk.kbd.from-cp850:es:Británico
-
-uk.capsctrl.kbd.from-cp850:en:United Kingdom (Caps Lock acts as Left Ctrl)
-uk.kbd.from-cp850:de:Vereinigtes Königreich (Caps Lock als linke Strg)
-#uk.cp850.kbd:fr:Royaume Uni (caps lock acts as Left Ctrl)
-#uk.cp850.kbd:pt:Reino Unido (caps lock acts as Left Ctrl)
-#uk.cp850.kbd:es:Brit�nico (caps lock acts as Left Ctrl)
-
 uk.dvorak.kbd:en:United Kingdom Dvorak
 uk.dvorak.kbd:de:Vereinigtes Königreich Dvorak
 uk.

svn commit: r270232 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Wed Aug 20 17:07:41 2014
New Revision: 270232
URL: http://svnweb.freebsd.org/changeset/base/270232

Log:
  The conversion tools have been further improved and some erroneous
  conversions have been detected and fixed.
  
  It is now possible to add options after the encoding in the parameter
  list for convert-keymap.pl. This is currently used to selectively
  enable interpretation of the ISO8859-1 currency symbol as the Euro
  sign found in ISO5589-15, or to add a Yen symbol in place of '\' for
  specific Japanese keyboards. The option are appended to the parameter
  list, as in e.g. "convert-keymap.pl german.iso.kbd ISO5589-1 EURO".
  
  The options are appended to the encoding in the form "+EURO" or "+YEN"
  in KBDFILES.map, to keep the meaning of the columns intact.
  
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/KBDFILES.map
  head/tools/tools/vt/keymaps/convert-keymap.pl
  head/tools/tools/vt/keymaps/convert-keymaps.pl

Modified: head/tools/tools/vt/keymaps/KBDFILES.map
==
--- head/tools/tools/vt/keymaps/KBDFILES.mapWed Aug 20 17:04:49 2014
(r270231)
+++ head/tools/tools/vt/keymaps/KBDFILES.mapWed Aug 20 17:07:41 2014
(r270232)
@@ -1,7 +1,15 @@
 # $FreeBSD$
-
-ISO8859-15 be.iso.kbd  be.kbd
-ISO8859-15 be.iso.acc.kbd  be.acc.kbd
+#
+# The Files are converted by "convert-keymaps.pl" from the given encoding to 
UCS.
+#
+# An additional "+EURO" causes the translation of the generic currency symbol 
to 
+# an Euro symbol, even if the source locale does not support an Euro symbol.
+# This conversion is only performed for the "E" key (not e.g. on Shift-4, 
which 
+# still generates the currency symbol).
+#
+# Encoding  syscons file name   newcons (vt) file name
+ISO8859-1+EURO be.iso.kbd  be.kbd
+ISO8859-1+EURO be.iso.acc.kbd  be.acc.kbd
 
 ISO8859-5  bg.bds.ctrlcaps.kbd bg.bds.kbd
 ISO8859-5  bg.phonetic.ctrlcaps.kbdbg.bds.ctrlcaps.kbd
@@ -14,15 +22,15 @@ CP850   br275.cp850.kbd 
br.noacc.kbd
 #CP1251by.cp1251.kbd   by.kbd.from-cp1251  
(result identical to CP1251)
 ISO8859-5  by.iso5.kbd by.kbd
 
-ISO8859-2  ce.iso2.kbd centraleuropean.kbd
+ISO8859-2  ce.iso2.kbd centraleuropean.qwerty.kbd
 
 ISO8859-1  colemak.iso15.acc.kbd   colemak.kbd
 
 ISO8859-2  cs.latin2.qwertz.kbdcz.kbd
-ISO8859-2  cz.iso2.kbd cz.kbd.from-ce
+ISO8859-2  cz.iso2.kbd cz.qwerty.kbd.from-ce
 
-ISO8859-15 danish.iso.kbd  dk.kbd
-ISO8859-15 danish.iso.acc.kbd  dk.acc.kbd
+ISO8859-1+EURO danish.iso.kbd  dk.kbd
+ISO8859-1+EURO danish.iso.acc.kbd  dk.acc.kbd
 CP865  danish.cp865.kbddk.kbd.from-cp865
 ISO8859-1  danish.iso.macbook.kbd  dk.macbook.kbd
 
@@ -36,19 +44,19 @@ ISO8859-1   estonian.iso.kbdee.kbd.from-
 ISO8859-15 estonian.iso15.kbd  ee.kbd
 CP850  estonian.cp850.kbd  ee.kbd.from-cp850
 
-ISO8859-15 finnish.iso.kbd fi.kbd
+ISO8859-1+EURO finnish.iso.kbd fi.kbd
 CP850  finnish.cp850.kbd   fi.kbd.from-cp850
 
-ISO8859-15 fr.iso.kbd  fr.kbd
-ISO8859-15 fr.iso.acc.kbd  fr.acc.kbd
-ISO8859-15 fr.macbook.acc.kbd  fr.macbook.kbd
-ISO8859-1  fr.dvorak.kbd   fr.dvorak.kbd
-ISO8859-15 fr.dvorak.acc.kbd   fr.dvorak.acc.kbd
+ISO8859-1+EURO fr.iso.kbd  fr.kbd
+ISO8859-1+EURO fr.iso.acc.kbd  fr.acc.kbd
+ISO8859-1+EURO fr.macbook.acc.kbd  fr.macbook.kbd
+ISO8859-1+EURO fr.dvorak.kbd   fr.dvorak.kbd
+ISO8859-1  fr.dvorak.acc.kbd   fr.dvorak.acc.kbd
 
-ISO8859-15 fr_CA.iso.acc.kbd   ca-fr.kbd
+ISO8859-1+EURO fr_CA.iso.acc.kbd   ca-fr.kbd
 
-ISO8859-15 german.iso.kbd  de.kbd
-ISO8859-15 german.iso.acc.kbd  de.acc.kbd
+ISO8859-1+EURO german.iso.kbd  de.noacc.kbd
+ISO8859-1+EURO german.iso.acc.kbd  de.acc.kbd
 CP850  german.cp850.kbdde.kbd.from-cp850
 
 ISO8859-7  gr.elot.acc.kbd gr.elot.acc.kbd
@@ -66,12 +74,12 @@ ARMSCII-8   hy.armscii-8.kbdam.kbd
 ISO8859-1  icelandic.iso.kbd   is.kbd
 ISO8859-1  icelandic.iso.acc.kbd   is.acc.kbd
 
-ISO8859-15 it.iso.kbd  it.kbd
+ISO8859-1+EURO it.iso.kbd  it.kbd
 
-ISO8859-1  jp.106.kbd  jp.kbd
-ISO8859-1  jp.106x.kbd   

svn commit: r270300 - head/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Thu Aug 21 20:33:09 2014
New Revision: 270300
URL: http://svnweb.freebsd.org/changeset/base/270300

Log:
  Next round of fixes.
  
  MFC after:3 days

Added:
  head/share/vt/keymaps/bg.phonetic.kbd
 - copied unchanged from r270290, head/share/vt/keymaps/bg.bds.ctrlcaps.kbd
  head/share/vt/keymaps/colemak.acc.kbd
 - copied unchanged from r270290, head/share/vt/keymaps/colemak.kbd
Deleted:
  head/share/vt/keymaps/bg.bds.ctrlcaps.kbd
  head/share/vt/keymaps/colemak.kbd
Modified:
  head/share/vt/keymaps/INDEX.keymaps
  head/share/vt/keymaps/Makefile
  head/share/vt/keymaps/ca-fr.kbd
  head/share/vt/keymaps/ca.kbd
  head/share/vt/keymaps/jp.pc98.kbd

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Thu Aug 21 20:10:05 2014
(r270299)
+++ head/share/vt/keymaps/INDEX.keymaps Thu Aug 21 20:33:09 2014
(r270300)
@@ -53,8 +53,9 @@ be.acc.kbd:es:Belga (con acentos)
 
 bg.bds.kbd:en:Bulgarian (BDS)
 bg.bds.kbd:de:Bulgarisch (BDS)
-bg.bds.ctrlcaps.kbd:en:Bulgarian (Phonetic)
-bg.bds.ctrlcaps.kbd:de:Bulgarisch (phonetisch)
+
+bg.phonetic.kbd:en:Bulgarian (Phonetic)
+bg.phonetic.kbd:de:Bulgarisch (phonetisch)
 
 br.kbd:en:Brazilian (accent keys)
 br.kbd:de:Brasilianisch (mit Akzenten)
@@ -82,7 +83,7 @@ centraleuropean.qwerty.kbd:de:Zentral Eu
 centraleuropean.qwerty.kbd:fr:Centre européen (QWERTY)
 centraleuropean.qwerty.kbd:es:Centroeuropeo (QWERTY)
 
-colemak.kbd:en:Colemak ergonomic alternative
+colemak.acc.kbd:en:Colemak ergonomic alternative
 
 cz.kbd:en:Czech (QWERTZ, accent keys)
 cz.kbd:de:Tschechisch (QWERTZ, mit Akzenten)

Modified: head/share/vt/keymaps/Makefile
==
--- head/share/vt/keymaps/Makefile  Thu Aug 21 20:10:05 2014
(r270299)
+++ head/share/vt/keymaps/Makefile  Thu Aug 21 20:33:09 2014
(r270300)
@@ -2,9 +2,13 @@
 
 FILES= INDEX.keymaps \
am.kbd \
-   bg.bds.ctrlcaps.kbd \
+   be.acc.kbd \
+   be.kbd \
bg.bds.kbd \
+   bg.phonetic.kbd \
br.kbd \
+   br.noacc.kbd \
+   by.kbd \
ca.kbd \
ca-fr.kbd \
centraleuropean.kbd \
@@ -14,9 +18,10 @@ FILES=   INDEX.keymaps \
ch.acc.kbd \
ch.kbd \
ch.macbook.acc.kbd \
-   colemak.kbd \
+   colemak.acc.kbd \
cz.kbd \
de.acc.kbd \
+   de.noacc.kbd \
de.kbd \
dk.acc.kbd \
dk.kbd \
@@ -26,6 +31,9 @@ FILES=INDEX.keymaps \
es.dvorak.kbd \
es.kbd \
fi.kbd \
+   fr.dvorak.acc.kbd \
+   fr.dvorak.kbd \
+   fr.macbook.kbd \
gr.101.acc.kbd \
gr.elot.acc.kbd \
gr.kbd \

Copied: head/share/vt/keymaps/bg.phonetic.kbd (from r270290, 
head/share/vt/keymaps/bg.bds.ctrlcaps.kbd)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/vt/keymaps/bg.phonetic.kbd   Thu Aug 21 20:33:09 2014
(r270300, copy of r270290, head/share/vt/keymaps/bg.bds.ctrlcaps.kbd)
@@ -0,0 +1,260 @@
+# $FreeBSD$
+# alt
+# scan   cntrl  altalt   cntrl lock
+# code  base   shift  cntrl  shift  altshift  cntrl  shift state
+# --
+  000   nopnopnopnopnopnopnopnop O
+  001   escescescescescescdebug  esc O
+  002   '1''!'nopnop'1''!'nopnop O
+  003   '2''@'nulnul'2''@'nulnul O
+  004   '3''#'nopnop'3''#'nopnop O
+  005   '4''$'nopnop'4''$'nopnop O
+  006   '5''%'nopnop'5''%'nopnop O
+  007   '6''^'rs rs '6''^'rs rs  O
+  008   '7''&'nopnop'7''&'nopnop O
+  009   '8''*'nopnop'8''*'nopnop O
+  010   '9''('nopnop'9''('nopnop O
+  011   '0'')'nopnop'0'')'nopnop O
+  012   '-''_'us us '-''_'us us  O
+  013   '=''+'nopnop'=''+'nopnop O
+  014   bs bs deldelbs bs deldel O
+  015   ht btab   nopnopht btab   nopnop O
+  016   'q''Q'dc1dc1'q''Q'dc1dc1 C
+  017   'w''W'etbetb'w''W'etbetb C
+  018   'e''E'enqenq'e''E'enqenq C
+  019   'r''R'dc2dc2'r''R'dc2dc2 C
+  020   't''T'dc4dc4't''T'dc4dc4 C
+  021   'y''Y'em em 'y''

svn commit: r270301 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Thu Aug 21 20:35:39 2014
New Revision: 270301
URL: http://svnweb.freebsd.org/changeset/base/270301

Log:
  Modify a few output file names as used with vt.
  
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/KBDFILES.map

Modified: head/tools/tools/vt/keymaps/KBDFILES.map
==
--- head/tools/tools/vt/keymaps/KBDFILES.mapThu Aug 21 20:33:09 2014
(r270300)
+++ head/tools/tools/vt/keymaps/KBDFILES.mapThu Aug 21 20:35:39 2014
(r270301)
@@ -12,7 +12,7 @@ ISO8859-1+EURObe.iso.kbd  be.kbd
 ISO8859-1+EURO be.iso.acc.kbd  be.acc.kbd
 
 ISO8859-5  bg.bds.ctrlcaps.kbd bg.bds.kbd
-ISO8859-5  bg.phonetic.ctrlcaps.kbdbg.bds.ctrlcaps.kbd
+ISO8859-5  bg.phonetic.ctrlcaps.kbdbg.phonetic.kbd
 
 #ISO8859-1 br275.iso.kbd   br.kbd.from-iso1(only 
AltGr-Shift-6 differs from CP850)
 ISO8859-1  br275.iso.acc.kbd   br.kbd
@@ -24,7 +24,7 @@ ISO8859-5 by.iso5.kbd by.kbd
 
 ISO8859-2  ce.iso2.kbd centraleuropean.qwerty.kbd
 
-ISO8859-1  colemak.iso15.acc.kbd   colemak.kbd
+ISO8859-1  colemak.iso15.acc.kbd   colemak.acc.kbd
 
 ISO8859-2  cs.latin2.qwertz.kbdcz.kbd
 ISO8859-2  cz.iso2.kbd cz.qwerty.kbd.from-ce
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r250943 - head/usr.bin/patch

[Stefan Esser]

Author: se
Date: Thu May 23 20:57:20 2013
New Revision: 250943
URL: http://svnweb.freebsd.org/changeset/base/250943

Log:
  Fix target selection logic, which did not comply with the man page.
  
  Instead of using the file with the least order of path name components,
  shortest filename and finally the shortest basename (with the search
  stopping as soon as one of these conditions is true), the first filename
  checked was used as the reference, and another filename was only selected
  if all of the above comparisons are in favour of the latter file.
  
  This was wrong, because filenames with path less components were only
  considered, if both of the other conditions were true as well. In fact,
  the first filename to be checked had good chances to be selected in the
  end, since it only needed to be better with regard to any one of the
  three criteria ...
  
  Reviewed by:  delp...@freebsd.org

Modified:
  head/usr.bin/patch/pch.c

Modified: head/usr.bin/patch/pch.c
==
--- head/usr.bin/patch/pch.cThu May 23 20:52:30 2013(r250942)
+++ head/usr.bin/patch/pch.cThu May 23 20:57:20 2013(r250943)
@@ -1537,10 +1537,16 @@ best_name(const struct file_name *names,
continue;
if ((tmp = num_components(names[i].path)) > min_components)
continue;
-   min_components = tmp;
+   if (tmp < min_components) {
+   min_components = tmp;
+   best = names[i].path;
+   }
if ((tmp = strlen(basename(names[i].path))) > min_baselen)
continue;
-   min_baselen = tmp;
+   if (tmp < min_baselen) {
+   min_baselen = tmp;
+   best = names[i].path;
+   }
if ((tmp = strlen(names[i].path)) > min_len)
continue;
min_len = tmp;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r250972 - head/usr.bin/patch

[Stefan Esser]

Author: se
Date: Fri May 24 18:54:52 2013
New Revision: 250972
URL: http://svnweb.freebsd.org/changeset/base/250972

Log:
  The error handling for writes to the target file could lead to the final
  fclose() being skipped. Fix this by using boolean "&" and "|" instead of
  short-cut operators "&&" and "||".
  While here, increment the last part of the version string. The reason is
  the fixed output file selection logic in pch.c, which was committed as
  r250943, yesterday.
  
  Reviewed by:  pfg

Modified:
  head/usr.bin/patch/patch.c
  head/usr.bin/patch/util.c

Modified: head/usr.bin/patch/patch.c
==
--- head/usr.bin/patch/patch.c  Fri May 24 18:28:27 2013(r250971)
+++ head/usr.bin/patch/patch.c  Fri May 24 18:54:52 2013(r250972)
@@ -303,7 +303,7 @@ main(int argc, char *argv[])
++fuzz <= mymaxfuzz);
 
if (skip_rest_of_patch) {   /* just got 
decided */
-   if (ferror(ofp) || fclose(ofp)) {
+   if (ferror(ofp) | fclose(ofp)) {
say("Error writing %s\n",
TMPOUTNAME);
error = 1;
@@ -385,7 +385,7 @@ main(int argc, char *argv[])
}
}
}
-   if (ferror(rejfp) || fclose(rejfp)) {
+   if (ferror(rejfp) | fclose(rejfp)) {
say("Error writing %s\n", rejname);
error = 1;
}
@@ -977,7 +977,7 @@ spew_output(void)
 #endif
if (input_lines)
copy_till(input_lines, true);   /* dump remainder of file */
-   rv = ferror(ofp) == 0 && fclose(ofp) == 0;
+   rv = ferror(ofp) == 0 & fclose(ofp) == 0;
ofp = NULL;
return rv;
 }

Modified: head/usr.bin/patch/util.c
==
--- head/usr.bin/patch/util.c   Fri May 24 18:28:27 2013(r250971)
+++ head/usr.bin/patch/util.c   Fri May 24 18:54:52 2013(r250972)
@@ -412,7 +412,7 @@ checked_in(char *file)
 void
 version(void)
 {
-   fprintf(stderr, "patch 2.0-12u8 FreeBSD\n");
+   fprintf(stderr, "patch 2.0-12u9 FreeBSD\n");
my_exit(EXIT_SUCCESS);
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r250972 - head/usr.bin/patch

[Stefan Esser]

Am 25.05.2013 06:31, schrieb Bruce Evans:
> On Fri, 24 May 2013, Stefan Esser wrote:
> 
>> ...
>> Log:
>>  The error handling for writes to the target file could lead to the final
>>  fclose() being skipped. Fix this by using boolean "&" and "|" instead of
>>  short-cut operators "&&" and "||".
>>  While here, increment the last part of the version string. The reason is
>>  the fixed output file selection logic in pch.c, which was committed as
>>  r250943, yesterday.
>>
>>  Reviewed by:pfg
>> ...
>> Modified: head/usr.bin/patch/patch.c
>> ==
>>
>> --- head/usr.bin/patch/patch.cFri May 24 18:28:27 2013(r250971)
>> +++ head/usr.bin/patch/patch.cFri May 24 18:54:52 2013(r250972)
>> @@ -303,7 +303,7 @@ main(int argc, char *argv[])
>> ++fuzz <= mymaxfuzz);
>>
>> if (skip_rest_of_patch) {/* just got decided */
>> -if (ferror(ofp) || fclose(ofp)) {
>> +if (ferror(ofp) | fclose(ofp)) {
>> say("Error writing %s\n",
>> TMPOUTNAME);
>> error = 1;
> 
> This is more broken than before.  Now the order of operations is
> indeterminate, so the behaviour is undefined if fclose(ofp) is evaluated
> before ferror(ofp) (then ferror(ofp) is passed an invalid pointer).
> Now even the usual case when there is no error initially is broken.

Oh, I see ... Sorry, I should have noticed this myself.

I had considered two more complex solutions, one with a temporary
variable "result" which was set by the call to ferror and where the
result of fclose was ORed in, the other with duplication of the
error message and setting of error. I guess that using a temporary
variable for the ferror result is better ...

> Error handling is very rarely correct in utilities that use stdio.
> patch at least checks for errors.  The easiest way to improve it (not
> just for patch) is to sprinkle fflush()es.  Blindly doing voided
> fflush()es before every ferror() check ensures that output gets done
> and checked even if you neglect to do fclose() or check for errors in
> it (provided you have enough ferror() checks).  This is especially

Yes, I had considered an fflush with error checking before the
fclose, but thought this was unnecessary (one extra call), and
that it were better to use a temporary result variable, instead.
And then I erroneously removed that variable and used the boolean
operators, instead ... (It's good to simplify an algorithm, but
not further than required to keep it functional ;-) ).

> important and especially mostly not done for stdout and stderr, since
> it is best to never close these (it may be impossible to report errors
> on stdout or stderr on themself, especially for stderr, but it doesn't
> hurt to try, except this may inhibit more correct error handling like
> logging the error to another file).
> 
> patch/pch.c has another ferror() || fclose() that wasn't touched by this
> commit.  It is almost OK, since the file was just opened successfully
> so ferror() on it "can't happen".  But this means that the normal
> broken idiom 'ferror() || fclose()' is not even wrong.

I noticed that case, but did not bother to change it, since
pfatal() is called immediately after a failed ferror(). This
will terminate the program and thus there is no resource leak.

> I think ferror() in 'ferror() || fclose()' should never be necessary
> unless you actually want to keep the file open if ferror(), and then
> you should normally use clearerr() in the error handling.  C99 is
> almost clear that fclose() must fail if ferror() was true when it was
> called.  It says that fclose() returns EOF iff any errors were detected,
> and it would take a weaselish reading of this to not allow detection
> of errors that are already present when it was called.  patch might
> be using 'ferror() || fclose() because it doesn't trust pre-C90 stdio.

Our version of patch must only work on supported releases of
FreeBSD. The ferror() before flcose() does not exist in the
versions it is derived from. It was added after the code was
imported from OpenBSD.

> It is also a style bug to use the bitwise boolean operations for logical
> boolean operations.  When we need sequential evaluation, this becomes a
> bug. We want sequential evaluation, and that should be written normally
> using
> sequence points (which are easiest to get using separate statements) if
> the logical boolean operations aren't suit

svn commit: r265433 - in head/sys: conf modules/drm2

[Stefan Esser]

Author: se
Date: Tue May  6 11:12:56 2014
New Revision: 265433
URL: http://svnweb.freebsd.org/changeset/base/265433

Log:
  Fix buildkernel breakage, which was fall-out from the move of options to
  src.opts.mk.

Modified:
  head/sys/conf/kmod.mk
  head/sys/modules/drm2/Makefile

Modified: head/sys/conf/kmod.mk
==
--- head/sys/conf/kmod.mk   Tue May  6 10:53:51 2014(r265432)
+++ head/sys/conf/kmod.mk   Tue May  6 11:12:56 2014(r265433)
@@ -72,6 +72,7 @@ OBJCOPY?= objcopy
 .error "Do not use KMODDEPS on 5.0+; use MODULE_VERSION/MODULE_DEPEND"
 .endif
 
+.include 
 .include 
 .include 
 

Modified: head/sys/modules/drm2/Makefile
==
--- head/sys/modules/drm2/Makefile  Tue May  6 10:53:51 2014
(r265432)
+++ head/sys/modules/drm2/Makefile  Tue May  6 11:12:56 2014
(r265433)
@@ -1,5 +1,6 @@
 # $FreeBSD$
 
+.include 
 .include 
 
 .if ${MACHINE_CPUARCH} == "amd64"
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r265436 - head/usr.bin/bmake

[Stefan Esser]

Author: se
Date: Tue May  6 12:31:17 2014
New Revision: 265436
URL: http://svnweb.freebsd.org/changeset/base/265436

Log:
  Fix include statement to accept src.opts.mk from a source directory
  instead of from /usr/share/mk.
  
  I'm not sure that this will let buildworld complete on a system with
  no installed src.opts.mk (make buildworld is still running), but the
  tinderbox builds are all failing earlyon without this patch.

Modified:
  head/usr.bin/bmake/Makefile.inc

Modified: head/usr.bin/bmake/Makefile.inc
==
--- head/usr.bin/bmake/Makefile.inc Tue May  6 12:20:07 2014
(r265435)
+++ head/usr.bin/bmake/Makefile.inc Tue May  6 12:31:17 2014
(r265436)
@@ -1,6 +1,6 @@
 # $FreeBSD$ 
 
-.include "src.opts.mk"
+.include 
 
 .if defined(.PARSEDIR)
 # make sure this is available to unit-tests/Makefile
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r265443 - head/usr.bin/bmake

[Stefan Esser]

Author: se
Date: Tue May  6 14:01:48 2014
New Revision: 265443
URL: http://svnweb.freebsd.org/changeset/base/265443

Log:
  Revert r265436, since it is not the correct fix.

Modified:
  head/usr.bin/bmake/Makefile.inc

Modified: head/usr.bin/bmake/Makefile.inc
==
--- head/usr.bin/bmake/Makefile.inc Tue May  6 13:52:13 2014
(r265442)
+++ head/usr.bin/bmake/Makefile.inc Tue May  6 14:01:48 2014
(r265443)
@@ -1,6 +1,6 @@
 # $FreeBSD$ 
 
-.include 
+.include "src.opts.mk"
 
 .if defined(.PARSEDIR)
 # make sure this is available to unit-tests/Makefile
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r258687 - head/share/misc

[Stefan Esser]

Author: se
Date: Wed Nov 27 19:12:29 2013
New Revision: 258687
URL: http://svnweb.freebsd.org/changeset/base/258687

Log:
  - add myself to the committers list (it's about time,
having been a committer for more than 19 years ...)

Modified:
  head/share/misc/committers-src.dot

Modified: head/share/misc/committers-src.dot
==
--- head/share/misc/committers-src.dot  Wed Nov 27 17:59:13 2013
(r258686)
+++ head/share/misc/committers-src.dot  Wed Nov 27 19:12:29 2013
(r258687)
@@ -263,6 +263,7 @@ sbruno [label="Sean Bruno\nsbruno@FreeBS
 scf [label="Sean C. Farley\n...@freebsd.org\n2007/06/24"]
 schweikh [label="Jens Schweikhardt\nschwe...@freebsd.org\n2001/04/06"]
 scottl [label="Scott Long\nsco...@freebsd.org\n2000/09/28"]
+se [label="Stefan Esser\n...@freebsd.org\n1994/08/26"]
 sephe [label="Sepherosa Ziehau\nse...@freebsd.org\n2007/03/28"]
 sepotvin [label="Stephane E. Potvin\nsepot...@freebsd.org\n2007/02/15"]
 simon [label="Simon L. Nielsen\nsi...@freebsd.org\n2006/03/07"]
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r259609 - head/sys/kern

[Stefan Esser]

Author: se
Date: Thu Dec 19 09:01:46 2013
New Revision: 259609
URL: http://svnweb.freebsd.org/changeset/base/259609

Log:
  Fix overflow for timeout values of more than 68 years, which is the maximum
  covered by sbintime (LONG_MAX seconds).
  
  Some programs use timeout values in excess of 1000 years. The conversion
  to sbintime caused wrap-around on overflow, which resulted in short or
  negative timeout values. This caused long delays on sockets opened by
  affected programs (e.g. OpenSSH).
  
  Kernels compiled without -fno-strict-overflow were not affected, apparently
  because the compiler tested the sign of the timeout value before performing
  the multiplication that lead to overflow.
  
  When the -fno-strict-overflow option was added to CFLAGS, this optimization
  was disabled and the test was performed on the result of the multiplication.
  Negative products were caught and resulted in EINVAL being returned, but
  wrap-around to positive values just shortened the timeout value to the
  residue of the result that could be represented by sbintime.
  
  The fix is to cap the timeout values at the maximum that can be represented
  by sbintime, which is 2^31 - 1 seconds or more than 68 years.
  
  After this change, the kernel can be compiled with -fno-strict-overflow
  with no ill effects.
  
  MFC after:3 days

Modified:
  head/sys/kern/kern_event.c

Modified: head/sys/kern/kern_event.c
==
--- head/sys/kern/kern_event.c  Thu Dec 19 07:33:07 2013(r259608)
+++ head/sys/kern/kern_event.c  Thu Dec 19 09:01:46 2013(r259609)
@@ -526,7 +526,8 @@ knote_fork(struct knlist *list, int pid)
 static __inline sbintime_t 
 timer2sbintime(intptr_t data)
 {
-
+   if (data > LLONG_MAX / SBT_1MS)
+   return LLONG_MAX;
return (SBT_1MS * data);
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

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

[Stefan Esser]

Am 19.12.2013 11:49, schrieb Bruce Evans:
> On Thu, 19 Dec 2013, Stefan Esser wrote:
> 
>> Log:
>>  Fix overflow for timeout values of more than 68 years, which is the
>> maximum
>>  covered by sbintime (LONG_MAX seconds).
> 
> Not LONG_MAX seconds, but INT32_MAX seconds.  LONG_MAX seconds is about
> 2**32
> times larger on 64-bit arches.

Hi Bruce,

yes, you are of course correct ... The limit is 2^31-2^-32 seconds,
to be exact ;-)

This is represented by LONG_MAX in sbintime, which made me use that
wrong constant in the commit message.

> sbintimes and their complexity give many more possibilities for overflow.
> I thought that the new overflow bugs and some old ones were already  fixed.
> 
>>  Some programs use timeout values in excess of 1000 years. The conversion
>>  to sbintime caused wrap-around on overflow, which resulted in short or
>>  negative timeout values. This caused long delays on sockets opened by
>>  affected programs (e.g. OpenSSH).
>>
>>  Kernels compiled without -fno-strict-overflow were not affected,
>> apparently
>>  because the compiler tested the sign of the timeout value before
>> performing
>>  the multiplication that lead to overflow.
> 
> I think it just gave a garbage value that was accidentally less harmful.

The result of the multiplication was performed modulo 2^64 due to
the limited range of the operation. The result was then interpreted
as a signed 64 bit 2s-complement number.

The factor 2^32/1000 is 0x418937, which multiplied with a round
decimal number over 1000*2^32 will result in "random" bit sequence
in the resulting sbintime.

Half the values will have been positive, and many will have
corresponded to substantial timeout values, but some will have
been very low, resulting in unexpectedly low timeouts.

>>  When the -fno-strict-overflow option was added to CFLAGS, this
>> optimization
>>  was disabled and the test was performed on the result of the
>> multiplication.
>>  Negative products were caught and resulted in EINVAL being returned, but
>>  wrap-around to positive values just shortened the timeout value to the
>>  residue of the result that could be represented by sbintime.
> 
> This shows one reason why -fno-strict-overflow shouldn't be used.  It just
> wastes time to give different undefined behaviour with undocumented
> details.

Well, I thought so when I found the cause of the breakage (long
delays opening TCP connections) that were the result of the
compilation with -fno-strict-overflow.

But I reconsidered, because a real bug in the code has been identied,
this way. The bug existed, without being detected (because too short
but non-zero timeout values were caught at the application layer, which
just re-issued the call with the remaining time as timeout parameter).

If applications didn't have to worry about short timeouts for other
reasons, then this bug would have led to observable problems, even
with -fno-strict-overflow.

>>  The fix is to cap the timeout values at the maximum that can be
>> represented
>>  by sbintime, which is 2^31 - 1 seconds or more than 68 years.
> 
> 2^31 - 1 is a correct spelling of INT32_MAX, unlike LONG_MAX.

Yes, sbintime is defined in units of 2^-32 seconds, which makes the
highest representable time exactly (2^31 - 2^-32) seconds. This
value is represented by LLONG_MAX units of 2^32 seconds ...

>>  After this change, the kernel can be compiled with -fno-strict-overflow
>>  with no ill effects.
> 
>> Modified: head/sys/kern/kern_event.c
>> ==
>>
>> --- head/sys/kern/kern_event.cThu Dec 19 07:33:07 2013(r259608)
>> +++ head/sys/kern/kern_event.cThu Dec 19 09:01:46 2013(r259609)
>> @@ -526,7 +526,8 @@ knote_fork(struct knlist *list, int pid)
>> static __inline sbintime_t
>> timer2sbintime(intptr_t data)
>> {
>> -
>> +if (data > LLONG_MAX / SBT_1MS)
>> +return LLONG_MAX;
>> return (SBT_1MS * data);
>> }
> 
> This has the following style bugs:
> - it removes the empty line after the (null) declarations
> - it is missing parentheses around the return value
> - it uses the long long abomination

Ughh, I'll fix the style bugs ...

It had taken me several hours over the last week to find this bug,
and I committed the fix that worked on my system without making it
compliant with FreeBSD style. Sorry for that ...

> This has the following type errors:
> - using the long long abomination is not just a style bug.  sbintime_t has
>   type int64_t, not long long.  The overflow check will break if long long
>   becomes longer than int64_t

The definition of sbintime is int64_t on a

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

[Stefan Esser]

Am 19.12.2013 21:46, schrieb Andreas Tobler:
> On 19.12.13 18:00, Stefan Esser wrote:
> 
>> I'd replace the two occurances of LLONG_MAX with INT64_MAX and add the
>> missing empty line:
>>
>> static __inline sbintime_t
>> timer2sbintime(intptr_t data)
>> {
>>
>> if (data > INT64_MAX / SBT_1MS)
>> return INT64_MAX;
>> return (SBT_1MS * data);
>> }
>>
>> If you can show evidence that a limit of INT64_MAX/2 is more appropriate
>> (2^30 seconds or 34 years), the limit could be of course be reduced to
>> that value.
>>
>> I could not find any code that would not tolerate INT64_MAX, though ...
> 
> Aehm, what about 32-bit systems where intptr_t == __int32_t?
> 
> cc1: warnings being treated as errors
> /export/devel/fbsd/src/sys/kern/kern_event.c: In function 'timer2sbintime':
> /export/devel/fbsd/src/sys/kern/kern_event.c:529: warning: comparison is
> always false due to limited range of data type

You are right, this needs to be fixed, too :(

I see two possibilities:

1) Conditional compilation: There is no need to check an upper bound on
   ILP32 architectures. INT32_MAX seconds can be expressed as sbintime.
   Architectures where intptr_t has at least 48 bits will support the
   maximum time that can be expressed in sbintime and the comparison
   can be left as is for them.

2) Calculate the upper bound in such a way, that it is guaranteed to be
   lower than the highest value that can be expressed as intptr_t. This
   value is (INT32_MAX - 1) on 32 bit architectures, while it remains
   (INT64_MAX / SBT_1MS) on 64 bit architectures.

I'm afraid that the warning emitted for 32 bit architectures will cause
tinderbox build failures, but I haven't seen a failure message, yet.

Should I back-out the commit that added the range check?

As long as -fno-strict-overflow is not put back into CFLAGS, the test
is not strictly required (only for the extremely unlikely case that a
number > 1000 * MAX32_INT results in an extremely short remainder after
multiplication with SBT_1MS modulo 32 ...).

Regards, STefan

NB: I should have known better and should have asked for a review of
this change before it wa committed. Sorry for the inconvenience
caused :(
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r259633 - head/sys/kern

[Stefan Esser]

Author: se
Date: Thu Dec 19 21:35:33 2013
New Revision: 259633
URL: http://svnweb.freebsd.org/changeset/base/259633

Log:
  Fix compilation on 32 bit architectures and use INT64_MAX instead of
  LONG_MAX for the upper bound check.

Modified:
  head/sys/kern/kern_event.c

Modified: head/sys/kern/kern_event.c
==
--- head/sys/kern/kern_event.c  Thu Dec 19 21:31:28 2013(r259632)
+++ head/sys/kern/kern_event.c  Thu Dec 19 21:35:33 2013(r259633)
@@ -523,11 +523,14 @@ knote_fork(struct knlist *list, int pid)
  * XXX: EVFILT_TIMER should perhaps live in kern_time.c beside the
  * interval timer support code.
  */
-static __inline sbintime_t 
+static __inline sbintime_t
 timer2sbintime(intptr_t data)
 {
-   if (data > LLONG_MAX / SBT_1MS)
-   return LLONG_MAX;
+
+#ifdef __LP64__
+   if (data > INT64_MAX / SBT_1MS)
+   return INT64_MAX;
+#endif
return (SBT_1MS * data);
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r277798 - head/bin/expr

[Stefan Esser]

Author: se
Date: Tue Jan 27 18:04:41 2015
New Revision: 277798
URL: https://svnweb.freebsd.org/changeset/base/277798

Log:
  Fix overflow check for multiplication:
  - Add special test to detect the case of -1 * INTMAX_MIN
  - Protect against elimination of the test division by the optimizer
  
  Garrett Cooper noticed that the overflow checks were incomplete, and Bruce
  Evans suggested the use of the "volatile" qualifier to counter the effect
  of the undefined behaviour, when the prior multiplication caused overflow,
  and he also suggested improvements to the comments.
  
  Reviewed by:  bde
  MFC after:1 week

Modified:
  head/bin/expr/expr.y

Modified: head/bin/expr/expr.y
==
--- head/bin/expr/expr.yTue Jan 27 17:46:55 2015(r277797)
+++ head/bin/expr/expr.yTue Jan 27 18:04:41 2015(r277798)
@@ -444,14 +444,26 @@ op_minus(struct val *a, struct val *b)
return (r);
 }
 
+/*
+ * We depend on undefined behaviour giving a result (in r).
+ * To test this result, pass it as volatile.  This prevents
+ * optimizing away of the test based on the undefined behaviour.
+ */
 void
-assert_times(intmax_t a, intmax_t b, intmax_t r)
+assert_times(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/*
-* if first operand is 0, no overflow is possible,
-* else result of division test must match second operand
+* If the first operand is 0, no overflow is possible, 
+* else the result of the division test must match the
+* second operand.
+*
+* Be careful to avoid overflow in the overflow test, as
+* in assert_div().  Overflow in division would kill us
+* with a SIGFPE before getting the test wrong.  In old
+* buggy versions, optimization used to give a null test
+* instead of a SIGFPE.
 */
-   if (a != 0 && r / a != b)
+   if ((a == -1 && b == INTMAX_MIN) || (a != 0 && r / a != b))
errx(ERR_EXIT, "overflow");
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270647 - in head: etc/defaults share/man/man4 share/man/man5 share/man/man7 share/man/man8

[Stefan Esser]

Author: se
Date: Tue Aug 26 08:13:30 2014
New Revision: 270647
URL: http://svnweb.freebsd.org/changeset/base/270647

Log:
  Add references to vt(4) and the configuration files in /usr7share/vt where
  appropriate (i.e. where syscons was already mentioned and vt supports the
  feature). Comments in defaults/rc.conf are updated to match the contents
  of the modified man-page rc.conf(5).
  
  Reviewed by:  pluknet, emaste
  MFC after:3 days

Modified:
  head/etc/defaults/rc.conf
  head/share/man/man4/atkbd.4
  head/share/man/man4/kbdmux.4
  head/share/man/man4/splash.4
  head/share/man/man4/ukbd.4
  head/share/man/man4/vkbd.4
  head/share/man/man4/vt.4
  head/share/man/man5/rc.conf.5
  head/share/man/man7/hier.7
  head/share/man/man8/nanobsd.8

Modified: head/etc/defaults/rc.conf
==
--- head/etc/defaults/rc.conf   Tue Aug 26 06:31:52 2014(r270646)
+++ head/etc/defaults/rc.conf   Tue Aug 26 08:13:30 2014(r270647)
@@ -516,15 +516,15 @@ ip6addrctl_policy="AUTO"  # A pre-defined
 ##
 
 keyboard=""# keyboard device to use (default /dev/kbd0).
-keymap="NO"# keymap in /usr/share/syscons/keymaps/* (or NO).
+keymap="NO"# keymap in /usr/share/{syscons,vt}/keymaps/* (or NO).
 keyrate="NO"   # keyboard rate to: slow, normal, fast (or NO).
 keybell="NO"   # See kbdcontrol(1) for options.  Use "off" to disable.
 keychange="NO" # function keys default values (or NO).
 cursor="NO"# cursor type {normal|blink|destructive} (or NO).
 scrnmap="NO"   # screen map in /usr/share/syscons/scrnmaps/* (or NO).
-font8x16="NO"  # font 8x16 from /usr/share/syscons/fonts/* (or NO).
-font8x14="NO"  # font 8x14 from /usr/share/syscons/fonts/* (or NO).
-font8x8="NO"   # font 8x8 from /usr/share/syscons/fonts/* (or NO).
+font8x16="NO"  # font 8x16 from /usr/share/{syscons,vt}/fonts/* (or 
NO).
+font8x14="NO"  # font 8x14 from /usr/share/{syscons,vt}/fonts/* (or 
NO).
+font8x8="NO"   # font 8x8 from /usr/share/{syscons,vt}/fonts/* (or NO).
 blanktime="300"# blank time (in seconds) or "NO" to turn it 
off.
 saver="NO" # screen saver: Uses /boot/kernel/${saver}_saver.ko
 moused_nondefault_enable="YES" # Treat non-default mice as enabled unless

Modified: head/share/man/man4/atkbd.4
==
--- head/share/man/man4/atkbd.4 Tue Aug 26 06:31:52 2014(r270646)
+++ head/share/man/man4/atkbd.4 Tue Aug 26 08:13:30 2014(r270647)
@@ -51,7 +51,9 @@ driver, provides access to the AT 84 key
 which is connected to the AT keyboard controller.
 .Pp
 This driver is required for the console driver
-.Xr syscons 4 .
+.Xr syscons 4
+or
+.Xr vt 4 .
 .Pp
 There can be only one
 .Nm
@@ -211,6 +213,7 @@ In both cases, you also need to have fol
 .Xr atkbdc 4 ,
 .Xr psm 4 ,
 .Xr syscons 4 ,
+.Xr vt 4 ,
 .Xr kbdmap 5 ,
 .Xr loader 8
 .Sh HISTORY

Modified: head/share/man/man4/kbdmux.4
==
--- head/share/man/man4/kbdmux.4Tue Aug 26 06:31:52 2014
(r270646)
+++ head/share/man/man4/kbdmux.4Tue Aug 26 08:13:30 2014
(r270647)
@@ -34,7 +34,8 @@ utility.
 .Xr kbdcontrol 1 ,
 .Xr atkbd 4 ,
 .Xr syscons 4 ,
-.Xr ukbd 4
+.Xr ukbd 4 ,
+.Xr vt 4
 .Sh HISTORY
 The
 .Nm

Modified: head/share/man/man4/splash.4
==
--- head/share/man/man4/splash.4Tue Aug 26 06:31:52 2014
(r270646)
+++ head/share/man/man4/splash.4Tue Aug 26 08:13:30 2014
(r270647)
@@ -245,6 +245,7 @@ bitmap_name="/boot/splash.bin"
 .Xr vidcontrol 1 ,
 .Xr syscons 4 ,
 .Xr vga 4 ,
+.Xr vt 4 ,
 .Xr loader.conf 5 ,
 .Xr rc.conf 5 ,
 .Xr kldload 8 ,
@@ -285,6 +286,8 @@ code.
 .Sh CAVEATS
 Both the splash screen and the screen saver work with
 .Xr syscons 4
+ or
+.Xr vt 4
 only.
 .Sh BUGS
 If you load a screen saver while another screen saver has already

Modified: head/share/man/man4/ukbd.4
==
--- head/share/man/man4/ukbd.4  Tue Aug 26 06:31:52 2014(r270646)
+++ head/share/man/man4/ukbd.4  Tue Aug 26 08:13:30 2014(r270647)
@@ -127,7 +127,9 @@ Make the keyboards available through a c
 The above lines will put the French ISO keymap in the ukbd driver.
 You can specify any keymap in
 .Pa /usr/share/syscons/keymaps
-with this option.
+or
+.Pa /usr/share/vt/keymaps
+(depending on the console driver being used) with this option.
 .Pp
 .D1 Cd "options KBD_DISABLE_KEYMAP_LOADING"
 .Pp
@@ -151,6 +153,7 @@ driver to the kernel.
 .Xr syscons 4 ,
 .Xr uhci 4 ,
 .Xr usb 4 ,
+.Xr vt 4 ,
 .Xr config 8
 .Sh AUTHORS
 .An -nosplit

Modified: head/share/man

svn commit: r270652 - head/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Tue Aug 26 09:37:43 2014
New Revision: 270652
URL: http://svnweb.freebsd.org/changeset/base/270652

Log:
  Remove band.aid that made kbdcontrol lookup keymap files in the syscons
  path even under vt, which is no longer useful, since the syscons keymap
  files have been converted and committed for use by vt.

Modified:
  head/usr.sbin/kbdcontrol/kbdcontrol.c

Modified: head/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- head/usr.sbin/kbdcontrol/kbdcontrol.c   Tue Aug 26 09:12:41 2014
(r270651)
+++ head/usr.sbin/kbdcontrol/kbdcontrol.c   Tue Aug 26 09:37:43 2014
(r270652)
@@ -800,7 +800,7 @@ load_keymap(char *opt, int dumponly)
char*name, *cp;
charblank[] = "", keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
-   char*prefix[]  = {blank, blank, blank, keymap_path, NULL};
+   char*prefix[]  = {blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
 
if (is_vt4())
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270653 - head/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Tue Aug 26 09:40:14 2014
New Revision: 270653
URL: http://svnweb.freebsd.org/changeset/base/270653

Log:
  Update man-pages to correctly refer to changed pathes and naming conventions
  for systems with vt(4) consoles.
  
  MFC after:3 days

Modified:
  head/usr.sbin/kbdcontrol/kbdcontrol.1
  head/usr.sbin/kbdcontrol/kbdmap.5

Modified: head/usr.sbin/kbdcontrol/kbdcontrol.1
==
--- head/usr.sbin/kbdcontrol/kbdcontrol.1   Tue Aug 26 09:37:43 2014
(r270652)
+++ head/usr.sbin/kbdcontrol/kbdcontrol.1   Tue Aug 26 09:40:14 2014
(r270653)
@@ -1,5 +1,5 @@
 .\"
-.\" kbdcontrol - a utility for manipulating the syscons keyboard driver section
+.\" kbdcontrol - a utility for manipulating the syscons or vt keyboard driver 
section
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
@@ -41,6 +41,8 @@ The
 .Nm
 command is used to set various keyboard related options for the
 .Xr syscons 4
+or
+.Xr vt 4
 console driver and the keyboard drivers,
 such as key map, keyboard repeat and delay rates, bell
 characteristics etc.
@@ -213,7 +215,9 @@ for details.
 .Sh FILES
 .Bl -tag -width /usr/share/syscons/keymaps/foo_bar -compact
 .It Pa /usr/share/syscons/keymaps/*
-keyboard map files
+keyboard map files for syscons
+.It Pa /usr/share/vt/keymaps/*
+keyboard map files for vt
 .El
 .Sh EXAMPLES
 The following command will load the keyboard map file
@@ -222,9 +226,19 @@ The following command will load the keyb
 .Dl kbdcontrol -l /usr/share/syscons/keymaps/ru.koi8-r.kbd
 .Pp
 So long as the keyboard map file resides in
-.Pa /usr/share/syscons/keymaps ,
+.Pa /usr/share/syscons/keymaps
+(if using
+.Xr syscons 4 ) or
+.Pa /usr/share/vt/keymaps
+(if using 
+.Xr vt 4 ) ,
 you may abbreviate the file name as
 .Pa ru.koi8-r .
+Since
+.Xr vt 4
+uses Unicode, the corresponding keyboard file names omit the encoding
+and typically are just a country code, e.g.\&
+.Pa ru .
 .Pp
 .Dl kbdcontrol -l ru.koi8-r
 .Pp
@@ -268,6 +282,7 @@ kbdcontrol -k /dev/kbdmux0 < /dev/consol
 .Xr screen 4 ,
 .Xr syscons 4 ,
 .Xr ukbd 4 ,
+.Xr vt 4 ,
 .Xr kbdmap 5 ,
 .Xr rc.conf 5
 .Sh AUTHORS

Modified: head/usr.sbin/kbdcontrol/kbdmap.5
==
--- head/usr.sbin/kbdcontrol/kbdmap.5   Tue Aug 26 09:37:43 2014
(r270652)
+++ head/usr.sbin/kbdcontrol/kbdmap.5   Tue Aug 26 09:40:14 2014
(r270653)
@@ -313,13 +313,16 @@ for that vowel with a grave accent.
 .Sh FILES
 .Bl -tag -width /usr/share/syscons/keymaps/* -compact
 .It Pa /usr/share/syscons/keymaps/*
-standard keyboard map files
+standard keyboard map files for syscons
+.It Pa /usr/share/vt/keymaps/*
+standard keyboard map files for vt
 .El
 .Sh SEE ALSO
 .Xr kbdcontrol 1 ,
 .Xr kbdmap 1 ,
 .Xr keyboard 4 ,
 .Xr syscons 4 ,
+.Xr vt 4 ,
 .Xr ascii 7
 .Sh HISTORY
 This manual page first appeared in
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270657 - in head: usr.bin/lock usr.sbin/bsdconfig usr.sbin/bsdinstall usr.sbin/kbdmap

[Stefan Esser]

Author: se
Date: Tue Aug 26 10:55:08 2014
New Revision: 270657
URL: http://svnweb.freebsd.org/changeset/base/270657

Log:
  More man pages that need to know about vt in addition to syscons.
  
  MFC after:3 dayS

Modified:
  head/usr.bin/lock/lock.1
  head/usr.sbin/bsdconfig/bsdconfig.8
  head/usr.sbin/bsdinstall/bsdinstall.8
  head/usr.sbin/kbdmap/kbdmap.1

Modified: head/usr.bin/lock/lock.1
==
--- head/usr.bin/lock/lock.1Tue Aug 26 10:35:32 2014(r270656)
+++ head/usr.bin/lock/lock.1Tue Aug 26 10:55:08 2014(r270657)
@@ -69,11 +69,14 @@ option of
 and thus has the same restrictions.
 It is only available if the terminal in question is a
 .Xr syscons 4
+or
+.Xr vt 4
 virtual terminal.
 .El
 .Sh SEE ALSO
 .Xr vidcontrol 1 ,
 .Xr syscons 4
+.Xr vt 4
 .Sh HISTORY
 The
 .Nm

Modified: head/usr.sbin/bsdconfig/bsdconfig.8
==
--- head/usr.sbin/bsdconfig/bsdconfig.8 Tue Aug 26 10:35:32 2014
(r270656)
+++ head/usr.sbin/bsdconfig/bsdconfig.8 Tue Aug 26 10:55:08 2014
(r270657)
@@ -172,16 +172,27 @@ Shortcut to the Delete menu under the Vi
 (startup_rcconf) of startup.
 .It Cm startup_rcvar
 Shortcut to the Toggle Startup Services menu under startup.
+.\" use neutral name, e.g. console_keymap instead of syscons_keymap?
+.\" font (encoding) selection not applicable to vt(4)!
 .It Cm syscons_font
 Shortcut to the Font menu under console.
+.\" .It Cm console_keymap
+.\" Shortcut to the Keymap menu under console.
 .It Cm syscons_keymap
 Shortcut to the Keymap menu under console.
+.\" .It Cm vt_repeat
+.\" Shortcut to the Repeat menu under console.
 .It Cm syscons_repeat
 Shortcut to the Repeat menu under console.
+.\" .It Cm vt_saver
+.\" Shortcut to the Saver menu under console.
 .It Cm syscons_saver
 Shortcut to the Saver menu under console.
+.\" screenmap (encoding) selection not applicable to vt(4)!
 .It Cm syscons_screenmap
 Shortcut to the Screenmap menu under console.
+.\" .It Cm vt_syscons_ttys
+.\" Shortcut to the Ttys menu under console.
 .It Cm syscons_ttys
 Shortcut to the Ttys menu under console.
 .It Cm timezone

Modified: head/usr.sbin/bsdinstall/bsdinstall.8
==
--- head/usr.sbin/bsdinstall/bsdinstall.8   Tue Aug 26 10:35:32 2014
(r270656)
+++ head/usr.sbin/bsdinstall/bsdinstall.8   Tue Aug 26 10:55:08 2014
(r270657)
@@ -95,6 +95,8 @@ for more information on this target.
 .It Cm keymap
 If the current controlling TTY is a
 .Xr syscons 4
+or
+.Xr vt 4
 console, asks the user to set the current keymap, and saves the result to the
 new system's
 .Pa rc.conf .

Modified: head/usr.sbin/kbdmap/kbdmap.1
==
--- head/usr.sbin/kbdmap/kbdmap.1   Tue Aug 26 10:35:32 2014
(r270656)
+++ head/usr.sbin/kbdmap/kbdmap.1   Tue Aug 26 10:55:08 2014
(r270657)
@@ -29,7 +29,7 @@
 .Sh NAME
 .Nm kbdmap ,
 .Nm vidfont
-.Nd front end for syscons
+.Nd front end for syscons and vt
 .Sh SYNOPSIS
 .Nm
 .Op Fl K
@@ -106,8 +106,10 @@ preferred language
 .Sh FILES
 .Bl -tag -width ".Pa /usr/share/syscons/keymaps/INDEX.keymaps" -compact
 .It Pa /usr/share/syscons/keymaps/INDEX.keymaps
+.It Pa /usr/share/vt/keymaps/INDEX.keymaps
 database for keymaps
 .It Pa /usr/share/syscons/fonts/INDEX.fonts
+.It Pa /usr/share/vt/fonts/INDEX.fonts
 database for fonts
 .It Pa /etc/rc.conf
 default font
@@ -120,6 +122,8 @@ values
 .Xr dialog 1 ,
 .Xr kbdcontrol 1 ,
 .Xr vidcontrol 1 ,
+.Xr syscons 4 ,
+.Xr vt 4 ,
 .Xr kbdmap 5 ,
 .Xr rc.conf 5
 .Sh HISTORY
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270660 - head/share/man/man4

[Stefan Esser]

Author: se
Date: Tue Aug 26 11:13:07 2014
New Revision: 270660
URL: http://svnweb.freebsd.org/changeset/base/270660

Log:
  Back-out the references to vt(4) from this man-page. It appears that the
  splash support in vt is implemented within the vt driver and does not
  depend on splash(4).
  
  Submitted by: mar...@alchemy.franken.de

Modified:
  head/share/man/man4/splash.4

Modified: head/share/man/man4/splash.4
==
--- head/share/man/man4/splash.4Tue Aug 26 11:04:51 2014
(r270659)
+++ head/share/man/man4/splash.4Tue Aug 26 11:13:07 2014
(r270660)
@@ -245,7 +245,6 @@ bitmap_name="/boot/splash.bin"
 .Xr vidcontrol 1 ,
 .Xr syscons 4 ,
 .Xr vga 4 ,
-.Xr vt 4 ,
 .Xr loader.conf 5 ,
 .Xr rc.conf 5 ,
 .Xr kldload 8 ,
@@ -286,8 +285,6 @@ code.
 .Sh CAVEATS
 Both the splash screen and the screen saver work with
 .Xr syscons 4
- or
-.Xr vt 4
 only.
 .Sh BUGS
 If you load a screen saver while another screen saver has already
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r270647 - in head: etc/defaults share/man/man4 share/man/man5 share/man/man7 share/man/man8

[Stefan Esser]

Am 26.08.2014 um 10:53 schrieb Marius Strobl:
> On Tue, Aug 26, 2014 at 08:13:30AM +0000, Stefan Esser wrote:
>> Author: se
>> Date: Tue Aug 26 08:13:30 2014
>> New Revision: 270647
>> URL: http://svnweb.freebsd.org/changeset/base/270647
>>
>> Log:
>>   Add references to vt(4) and the configuration files in /usr7share/vt where
>>   appropriate (i.e. where syscons was already mentioned and vt supports the
>>   feature). Comments in defaults/rc.conf are updated to match the contents
>>   of the modified man-page rc.conf(5).
>>   
>>   Reviewed by:   pluknet, emaste
>>   MFC after: 3 days
>>
> 
> <...>
> 
>> Modified: head/share/man/man4/splash.4
>> ==
>> --- head/share/man/man4/splash.4 Tue Aug 26 06:31:52 2014
>> (r270646)
>> +++ head/share/man/man4/splash.4 Tue Aug 26 08:13:30 2014
>> (r270647)
>> @@ -245,6 +245,7 @@ bitmap_name="/boot/splash.bin"
>>  .Xr vidcontrol 1 ,
>>  .Xr syscons 4 ,
>>  .Xr vga 4 ,
>> +.Xr vt 4 ,
>>  .Xr loader.conf 5 ,
>>  .Xr rc.conf 5 ,
>>  .Xr kldload 8 ,
>> @@ -285,6 +286,8 @@ code.
>>  .Sh CAVEATS
>>  Both the splash screen and the screen saver work with
>>  .Xr syscons 4
>> + or
>> +.Xr vt 4
>>  only.
>>  .Sh BUGS
>>  If you load a screen saver while another screen saver has already
>>
> 
> That information is incorrect; vt(4) has only very limited splash
> screen support and doesn't interface with splash(4) for that. Screen
> saver support even is entirely nonexistent with vt(4) to date.

Hi Marius,

thank you for pointing that out.

I had added vt(4) behind comment markers in that file, since I did not
know whether splash(4) was used with vt or not.  From the feedback that
I received, I assumed that it should work (and I seemed to remember
that there was some kind of splash support in vt), but apparently in
error.

I'll back-out the change from splash.4 then ...

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

svn commit: r270931 - head/usr.sbin/smbmsg

[Stefan Esser]

Author: se
Date: Mon Sep  1 16:12:29 2014
New Revision: 270931
URL: http://svnweb.freebsd.org/changeset/base/270931

Log:
  Fix typo (by -> be).
  
  MFC after:3 days

Modified:
  head/usr.sbin/smbmsg/smbmsg.8

Modified: head/usr.sbin/smbmsg/smbmsg.8
==
--- head/usr.sbin/smbmsg/smbmsg.8   Mon Sep  1 14:57:04 2014
(r270930)
+++ head/usr.sbin/smbmsg/smbmsg.8   Mon Sep  1 16:12:29 2014
(r270931)
@@ -59,7 +59,7 @@ The first form shown in the synopsis can
 the devices on the SMBus.
 This is done by sending each valid device address one
 receive byte, and one quick read message, respectively.
-Devices that respond to these requests will by displayed
+Devices that respond to these requests will be displayed
 by their device address, followed by the strings
 .Ql r ,
 .Ql w ,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270933 - in head: sbin/conscontrol usr.sbin/vidcontrol

[Stefan Esser]

Author: se
Date: Mon Sep  1 16:25:08 2014
New Revision: 270933
URL: http://svnweb.freebsd.org/changeset/base/270933

Log:
  Add references to vt(4) to further man-pages.
  
  MFC after:3 days

Modified:
  head/sbin/conscontrol/conscontrol.8
  head/usr.sbin/vidcontrol/vidcontrol.1

Modified: head/sbin/conscontrol/conscontrol.8
==
--- head/sbin/conscontrol/conscontrol.8 Mon Sep  1 16:24:25 2014
(r270932)
+++ head/sbin/conscontrol/conscontrol.8 Mon Sep  1 16:25:08 2014
(r270933)
@@ -104,6 +104,7 @@ This is an interface to the tty ioctl
 .Xr sio 4 ,
 .Xr syscons 4 ,
 .Xr tty 4 ,
+.Xr vt 4 ,
 .Xr boot 8 ,
 .Xr loader 8
 .Sh HISTORY

Modified: head/usr.sbin/vidcontrol/vidcontrol.1
==
--- head/usr.sbin/vidcontrol/vidcontrol.1   Mon Sep  1 16:24:25 2014
(r270932)
+++ head/usr.sbin/vidcontrol/vidcontrol.1   Mon Sep  1 16:25:08 2014
(r270933)
@@ -1,5 +1,5 @@
 .\"
-.\" vidcontrol - a utility for manipulating the syscons video driver
+.\" vidcontrol - a utility for manipulating the syscons or vt video driver
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
@@ -48,9 +48,15 @@ The
 .Nm
 utility is used to set various options for the
 .Xr syscons 4
+or
+.Xr vt 4
 console driver,
 such as video mode, colors, cursor shape, screen output map, font and screen
 saver timeout.
+Only a small subset of options is supported by
+.Xr vt 4 .
+Unsupported options lead to error messages, typically including
+the text "Inappropriate ioctl for device".
 .Pp
 The following command line options are supported:
 .Bl -tag -width indent
@@ -158,8 +164,11 @@ See also
 .Sx Video Mode Support
 and
 .Sx EXAMPLES
-below and the man page for
-.Xr syscons 4 .
+below and the man page for either
+.Xr syscons 4
+or
+.Xr vt 4
+(depending on which driver you use).
 .It Fl g Ar geometry
 Set the
 .Ar geometry
@@ -185,7 +194,10 @@ Shows the possible video modes with the 
 Install screen output map file from
 .Ar screen_map .
 See also
-.Xr syscons 4 .
+.Xr syscons 4
+or
+.Xr vt 4
+(depending on which driver you use).
 .It Fl L
 Install default screen output map.
 .It Fl M Ar char
@@ -307,12 +319,18 @@ kernel with the
 option.
 See
 .Xr syscons 4
+or
+.Xr vt 4
+(depending on which driver you use)
 for more details on this kernel option.
 .Ss Format of Video Buffer Dump
 The
 .Nm
 utility uses the
 .Xr syscons 4
+.\" is it supported on vt(4)???
+or
+.Xr vt 4
 .Dv CONS_SCRSHOT
 .Xr ioctl 2
 to capture the current contents of the video buffer.
@@ -453,9 +471,12 @@ for details.
 .Sh FILES
 .Bl -tag -width /usr/share/syscons/scrnmaps/foo-bar -compact
 .It Pa /usr/share/syscons/fonts/*
+.It Pa /usr/share/vt/fonts/*
 font files.
 .It Pa /usr/share/syscons/scrnmaps/*
-screen output map files.
+screen output map files (relevant for
+.Xr syscons 4
+only).
 .El
 .Sh EXAMPLES
 If you want to load
@@ -467,7 +488,10 @@ as:
 .Dl vidcontrol -f 8x16 /usr/share/syscons/fonts/iso-8x16.fnt
 .Pp
 So long as the font file is in
-.Pa /usr/share/syscons/fonts ,
+.Pa /usr/share/syscons/fonts
+(if using syscons) or
+.Pa /usr/share/vt/fonts
+(if using vt),
 you may abbreviate the file name as
 .Pa iso-8x16 :
 .Pp
@@ -521,6 +545,7 @@ to the standard output in the human read
 .Xr screen 4 ,
 .Xr syscons 4 ,
 .Xr vga 4 ,
+.Xr vt 4 ,
 .Xr rc.conf 5 ,
 .Xr kldload 8 ,
 .Xr moused 8 ,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270934 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Mon Sep  1 16:26:57 2014
New Revision: 270934
URL: http://svnweb.freebsd.org/changeset/base/270934

Log:
  Final patches to the tools used to convert syscons keymaps for use with
  vt.
  
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/KBDFILES.map
  head/tools/tools/vt/keymaps/convert-keymap.pl

Modified: head/tools/tools/vt/keymaps/KBDFILES.map
==
--- head/tools/tools/vt/keymaps/KBDFILES.mapMon Sep  1 16:25:08 2014
(r270933)
+++ head/tools/tools/vt/keymaps/KBDFILES.mapMon Sep  1 16:26:57 2014
(r270934)
@@ -144,6 +144,6 @@ ISO8859-1   us.emacs.kbdus.emacs.kbd
 ISO8859-1  us.pc-ctrl.kbd  us.ctrl.kbd
 ISO8859-1  us.unix.kbd us.unix.kbd
 
-ISO8859-5  ua.iso5.kbd ua.kbd.from-iso5
+#ISO8859-5 ua.iso5.kbd ua.kbd.from-iso5
 KOI8-U ua.koi8-u.kbd   ua.kbd
 KOI8-U ua.koi8-u.shift.alt.kbd ua.shift.alt.kbd

Modified: head/tools/tools/vt/keymaps/convert-keymap.pl
==
--- head/tools/tools/vt/keymaps/convert-keymap.pl   Mon Sep  1 16:25:08 
2014(r270933)
+++ head/tools/tools/vt/keymaps/convert-keymap.pl   Mon Sep  1 16:26:57 
2014(r270934)
@@ -7,7 +7,7 @@ use strict;
 use utf8;
 
 # command line parsing
-die "Usage: $0 filename.kbd CHARSET [EURO]"
+die "Usage: $0 filename.kbd charset [EURO|YEN]\n"
 unless ($ARGV[1]);
 
 my $inputfile = shift; # first command argument
@@ -60,8 +60,8 @@ sub local_to_UCS_code
 $ucs_char = 0xa5   # replace with Jap. Yen character on PC kbd
if $ucs_char == ord('\\') and $use_yen and $current_scancode == 125;
 
-$ucs_char = 0xa5   # replace with Jap. Yen character on PC98x1 kbd
-   if $ucs_char == ord('\\') and $use_yen and $current_scancode == 13;
+#$ucs_char = 0xa5  # replace with Jap. Yen character on PC98x1 kbd
+#  if $ucs_char == ord('\\') and $use_yen and $current_scancode == 13;
 
 return prettyprint_token($ucs_char);
 }
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r270935 - head/etc/rc.d

[Stefan Esser]

Author: se
Date: Mon Sep  1 16:51:57 2014
New Revision: 270935
URL: http://svnweb.freebsd.org/changeset/base/270935

Log:
  Add vt(4) support to the console initialisation script, specifically:
  
  - Identify the console driver used and print syscons or vt as appropriate.
  
  - If vt is used and a keymap could not be loaded, then try to replace the
keymap name configured in rc.conf based on a replacement list in this
script. Warn about the fact, that a syscons keyname is configured and
report the replacement used under vt.
  
  - If no replacement keymap is found, no keymap is loaded and a warning
is displayed, which points at the conversion script and allows the
conversion of keymaps not part of the official distribution.
  
  This patch has been sent to the -hackers list for review, but no comment
  has been received, yet. It is tested to work under syscons and vt on my
  system (on vt with either the syscons or vt keymap file name in rc.conf).
  
  MFC after:3 days

Modified:
  head/etc/rc.d/syscons

Modified: head/etc/rc.d/syscons
==
--- head/etc/rc.d/syscons   Mon Sep  1 16:26:57 2014(r270934)
+++ head/etc/rc.d/syscons   Mon Sep  1 16:51:57 2014(r270935)
@@ -45,16 +45,122 @@ stop_cmd=":"
 kbddev=/dev/ttyv0
 viddev=/dev/ttyv0
 
-_sc_config="syscons"
+_sc_config=
+_sc_console=
 _sc_initdone=
+_sc_keymap_msg=
 sc_init()
 {
if [ -z "${_sc_initdone}" ]; then
+   if [ -z "${_sc_console}" ]; then
+   if [ x`sysctl -n kern.vty` = x"vt" ]; then
+   _sc_console="vt"
+   else
+   _sc_console="syscons"
+   fi
+   _sc_config="${_sc_console}"
+   fi
echo -n "Configuring ${_sc_config}:"
_sc_initdone=yes
fi
 }
 
+# syscons to vt migration helper
+lookup_keymap_for_vt()
+{
+   keymap=`basename $1 .kbd`
+   case $keymap in
+hy.armscii-8)  echo am;;
+be.iso.acc)echo be.acc;;
+be.iso)echo be;;
+bg.bds.ctrlcaps)   echo bg.bds;;
+bg.phonetic.ctrlcaps)  echo bg.phonetic;;
+br275.iso.acc) echo br;;
+br275.*)   echo br.noacc;;
+by.*)  echo by;;
+fr_CA.iso.acc) echo ca-fr;;
+swissgerman.macbook.acc)   echo ch.macbook.acc;;
+swissgerman.iso.acc)   echo ch.acc;;
+swissgerman.*) echo ch;;
+swissfrench.iso.acc)   echo ch-fr.acc;;
+swissfrench.*) echo ch-fr;;
+ce.iso2)   echo centraleuropean.qwerty;;
+colemak.iso15.acc) echo colemak.acc;;
+cs.*|cz.*) echo cz;;
+german.iso.acc)echo de.acc;;
+german.*)  echo de;;
+danish.iso.acc)echo dk.acc;;
+danish.iso.macbook)echo dk.macbook;;
+danish.*)  echo dk;;
+estonian.*)echo ee;;
+spanish.dvorak)echo es.dvorak;;
+spanish.iso*.acc)  echo es.acc;;
+spanish.iso)   echo es;;
+finnish.*) echo fi;;
+fr.macbook.acc)echo fr.macbook;;
+fr.iso.acc)echo fr.acc;;
+fr.iso)echo fr;;
+el.iso07)  echo gr;;
+gr.us101.acc)  echo gr.101.acc;;
+hr.iso)echo hr;;
+hu.iso2.101keys)   echo hu.101;;
+hu.iso2.102keys)   echo hu.102;;
+iw.iso8)   echo il;;
+icelandic.iso.acc) echo is.acc;;
+icelandic.iso) echo is;;
+it.iso)echo it;;
+jp.106x)   echo jp.capsctrl;;
+jp.106)echo jp;;
+#?? jp.pc98.iso)   echo jp.pc98;;
+kk.pt154.io)   echo kz.io;;
+kk.pt154.kst)  echo kz.kst;;
+latinamerican.iso.acc) echo latinamerican.acc;;
+lt.iso4)   echo lt;;
+norwegian.iso) echo no;;
+norwegian.dvorak)  echo no.dvorak;;
+dutch.iso.acc) echo nl;;
+eee_nordic)echo nordic.asus-eee;;
+pl_PL.dvorak)  echo pl.dvorak;;
+pl_PL.ISO8859-2)   echo pl;;
+pt.iso.acc)echo pt.acc;;
+pt.iso)echo pt;;
+ru.koi8-r.shift)   echo ru.shift;;
+ru.koi8-r.win) echo ru.win;;
+ru.*)  echo ru;;
+swedish.*) echo se;;
+si.iso)echo si;;
+sk.iso2)   echo sk;;
+tr.iso9.q) echo tr;;
+ua.koi8-u.shift.alt)   echo ua.shift.alt;

svn commit: r271108 - head/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Thu Sep  4 17:19:16 2014
New Revision: 271108
URL: http://svnweb.freebsd.org/changeset/base/271108

Log:
  Fix debug output that has erroneously been committed with the last update.
  
  Obtained from:Jan Beich
  MFC after:3 days

Modified:
  head/tools/tools/vt/keymaps/convert-keymap.pl

Modified: head/tools/tools/vt/keymaps/convert-keymap.pl
==
--- head/tools/tools/vt/keymaps/convert-keymap.pl   Thu Sep  4 17:05:57 
2014(r271107)
+++ head/tools/tools/vt/keymaps/convert-keymap.pl   Thu Sep  4 17:19:16 
2014(r271108)
@@ -51,7 +51,7 @@ sub local_to_UCS_code
 
 my $ucs_char = ord(Encode::decode("UTF-8", local_to_UCS_string($char)));
 
-$current_char = lc(chr($ucs_char)), print("SETCUR: $ucs_char\n")
+$current_char = lc(chr($ucs_char))
if $current_char eq "";
 
 $ucs_char = 0x20ac # replace with Euro character
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"