Re: svn commit: r365917 - in releng/12.2: cddl/contrib/opensolaris/cmd/zfs cddl/contrib/opensolaris/cmd/zpool sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys sys/cddl/contrib/opensola

[Stefan Esser]

Am 17.12.20 um 10:00 schrieb Stefan Esser:

Am 16.12.20 um 21:30 schrieb Alan Somers:
This sounds quite useful!  I've often wished that I could see 
per-dataset traffic statistics.  Are there any user-friendly frontends 
to this?  Like zfs-stats, or an updated zpool iostat?


I have updated zfs-stats for OpenZFS a few months ago and I'd be willing
to add printing these new values to the port.

The maintainer of the upstream version had little interest to accept my
patches into his repository (after sending several request) and thus I
have added a large patch to the port.

If further changes are applied, I might fork the upstream repository
and base the zfs-stats port on that fork (but I did not want to grab it
without the current maintainer agreeing ...)


The zfst-stats port has been updated to include per dataset operations
statistics (new version 1.3.0_2).

I could imagine to add average operations rates (operations per second
of uptime), but this new version displays just the totals, for now.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r365917 - in releng/12.2: cddl/contrib/opensolaris/cmd/zfs cddl/contrib/opensolaris/cmd/zpool sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys sys/cddl/contrib/opensola

[Stefan Esser]

Am 16.12.20 um 21:30 schrieb Alan Somers:
On Sat, Sep 19, 2020 at 2:47 PM Allan Jude > wrote:


Author: allanjude
Date: Sat Sep 19 20:46:56 2020
New Revision: 365917
URL: https://svnweb.freebsd.org/changeset/base/365917


Log:
   MFS r365689,r365808,r365860

   MFOpenZFS: Introduce read/write kstats per dataset

   The following patch introduces a few statistics on reads and writes
   grouped by dataset. These statistics are implemented as kstats
   (backed by aggregate sums for performance) and can be retrieved by
   using the dataset objset ID number. The motivation for this change is
   to provide some preliminary analytics on dataset usage/performance.

   Reviewed-by: Richard Elling 
   Reviewed-by: Brian Behlendorf mailto:behlendo...@llnl.gov>>
   Reviewed by: Matthew Ahrens mailto:mahr...@delphix.com>>
   Signed-off-by: Serapheim Dimitropoulos mailto:seraph...@delphix.com>>

   openzfs/zfs@a448a2557ec4938ed6944c7766fe0b8e6e5f6456

   Also contains parts of:
   MFOpenZFS: Connect dataset_kstats for FreeBSD

   Example output:
   kstat.zfs.mypool.dataset.objset-0x10b.nread: 150528
   kstat.zfs.mypool.dataset.objset-0x10b.reads: 48
   kstat.zfs.mypool.dataset.objset-0x10b.nwritten: 134217728
   kstat.zfs.mypool.dataset.objset-0x10b.writes: 1024
   kstat.zfs.mypool.dataset.objset-0x10b.dataset_name:
mypool/datasetname

   Reviewed-by: Ryan Moeller 
   Reviewed by: Sean Eric Fagan mailto:s...@ixsystems.com>>
   Reviewed-by: Serapheim Dimitropoulos mailto:seraph...@delphix.com>>
   Reviewed-by: Brian Behlendorf mailto:behlendo...@llnl.gov>>
   Signed-off-by: Allan Jude mailto:al...@klarasystems.com>>

   openzfs/zfs@4547fc4e071ceb1818b3a46c3035b923e06e5390

   Approved by:  re (gjb)
   Relnotes:     yes
   Sponsored by: Klara Inc.


This sounds quite useful!  I've often wished that I could see 
per-dataset traffic statistics.  Are there any user-friendly frontends 
to this?  Like zfs-stats, or an updated zpool iostat?


I have updated zfs-stats for OpenZFS a few months ago and I'd be willing
to add printing these new values to the port.

The maintainer of the upstream version had little interest to accept my
patches into his repository (after sending several request) and thus I
have added a large patch to the port.

If further changes are applied, I might fork the upstream repository
and base the zfs-stats port on that fork (but I did not want to grab it
without the current maintainer agreeing ...)

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

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

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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 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 19:19 schrieb O. Hartmann:

svn-src-h...@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: 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 environment.

The function should always 

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 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 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 *)`, 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's perfectly legal and imaginable.


Yes, calling getenv

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, , NULL, 0) == 0 &&
+   (tmppath = malloc(tmplen)) != NULL &&
+   sysctl(localbase_oid, 2, tmppath, , 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 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, , 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: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: 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 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 compatibility).

Regards, STefan


OpenPGP_

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]

   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 

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]

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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: 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: 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: 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: 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();
+


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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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: r365643 - head/bin/cp

[Stefan Esser]

Am 24.09.20 um 08:54 schrieb Warner Losh:



On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <mailto:s...@freebsd.org>> wrote:


Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not
mounting devfs early enough.  We should
 > fix that. Removing /dev/null from the boot process likely is
never going
 > to happen because we use it all over the place to discard output...
 > There's ~200 instances of it in the boot rc scripts, so getting
rid of
 > it there would also be quite the effort, with the same question.

Removal of /dev/null from rc.d scripts should be quite simple,
since most cases could just use ">-" (close file descriptor)
instead. Other usage could be substituted with ":>" followed
by chown.


So closing fd1 and fd2 doesn't cause them to be available for these 
programs to get as an fd on open, causing other issues?


But >- isn't documented in sh(1) as doing the close thing. On a whim I 
did the following:

$ echo fred >-
$ ls -last ./-
4 -rw-r--r--  1 imp  imp  5 Sep 24 00:50 ./-
$ cat ./-
fred
$
which suggests maybe you now have a lot of files named - instead...


Yes, sorry, please ignore what I wrote - I was thinking of ">&-" of
course, but that is not gracefully accepted by many commands (they
are aborted when trying to write to the closed file descriptor).

I had thought about piping into a command that ignores STDIN, first,
e.g. "| :", but that generates a SIGPIPE when trying to flush the
FILE buffer (i.e. after 4 KB, which might be sufficient for most
cases, but it is not a general solution).

A program that reads from STDIN and generates no output could be used,
though, e.g. "| sed d".

But this would cause lots of extra forked processes and increase the
start-up time and is not acceptable.


but e.g. rc.d/syscons
uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.

So those interactions should be disaled by rc variables...  Or we should 
be failing the operation...


Going multi-user should not be stopped by any of the rc scripts
failing due to lack of /dev. But since most developers will only
test with /dev available, there is a risk that changes to rc files
will not gracefully handle a missing /dev.


But those further references to /dev nodes will in general be
NOPs if /dev is not available (some test for existence of the
node they rely on, other just fail trying to access them, but
without negative effect on going multi-user).


Yea, that's more minor, but if /dev/ isn't there, they likely should 
fail, or shouldn't proceed... But in a way that allows the rest of the 
rc scripts to continue...


Since the issue of no devfs mounted it not typical, tests will be
required to prevent regressions. If a failure in such a case stops
the multi-user start-up, then it will most likely be in situations
where there is no good way to provide diagnostics (e.g. no console
that works for user land programs, no known writable file system
locations, ...).

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r365643 - head/bin/cp

[Stefan Esser]

Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not 
mounting devfs early enough.  We should
fix that. Removing /dev/null from the boot process likely is never going 
to happen because we use it all over the place to discard output... 
There's ~200 instances of it in the boot rc scripts, so getting rid of 
it there would also be quite the effort, with the same question.


Removal of /dev/null from rc.d scripts should be quite simple,
since most cases could just use ">-" (close file descriptor)
instead. Other usage could be substituted with ":>" followed
by chown.

I'd be willing to generate patches for review, if there is any
chance such a change might be accepted into -CURRENT.

I could not find any use of /dev/zero, but e.g. rc.d/syscons
uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.

But those further references to /dev nodes will in general be
NOPs if /dev is not available (some test for existence of the
node they rely on, other just fail trying to access them, but
without negative effect on going multi-user).

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r364321 - head/sbin/ipfw

[Stefan Esser]

Am 31.08.20 um 16:09 schrieb Rodney W. Grimes:

Hrm, it seems this reply ended up in my spam folder; sorry for not
replying until now.


lol Oh, bad filter :-)


   *strchr(timestr, '\n') = '\0';
   bprintf(bp, "%s ", timestr);

^ Isnt this the +1 space?


   } else {
- bprintf(bp, "%*s", twidth, " ");
+ bprintf(bp, "%*s", twidth + 1, " ");

 ^missing from this string?


Inserting an extra space in the format string would also work, sure. I
considered doing it that way but in the end decided it's not
materially more clear one way or another, so used the patch as
submitted.


For me the + 1 leads to a "why is this here", where as the space
in the format string clearly matches the other condition of the else.


In this case it doesn't seem to make much of a difference, since
the string passed is just a blank character (and it does not make
any difference whether a blank is inserted before or behind it).

But in general, I'd rather see "%*s " as the format (which makes
it clear, that the blank is inserted behind the string argument
referenced by %s, not to the left of it - or " %*s" for the other
placement of the extra blank).

But in this particular case I'd use

printf(bp, "%*s ", twidth, "");

since there is no need to pass a non-zero length argument for %s and
I'd think that the purpose of the format string is to make the columns
line up and then to provide one additional blank as a separator for
maximum length values.

Adding 1 to the width argument of "%*s" adds blanks to the left of
the string, which is obvious given the semantics of the format string,
but still takes some thinking compared to trivially seeing the place
where the extra blank is put in a format string ...


Also + 1 causes a run time computation, the extra space does not.


Well, the parsing of the extra blank in the format string can be
assumed to cost more cycles than the increment of a variable plus
the extra loop iteration it causes for the alignment blanks that are
written. But the code length will be shorter with the blank in the
format string and the extra cycles will be irrelevant ...

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r344127 - stable/11/lib/libfigpar

[Stefan Esser]

Author: se
Date: Thu Feb 14 15:42:29 2019
New Revision: 344127
URL: https://svnweb.freebsd.org/changeset/base/344127

Log:
  MFC r343480,343482: Silence Clang Scan warning about unsafe use of strcpy.
  
  Replace   strcpy() by memcpy to the previously allocated range of known 
size.

Modified:
  stable/11/lib/libfigpar/string_m.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/lib/libfigpar/string_m.c
==
--- stable/11/lib/libfigpar/string_m.c  Thu Feb 14 15:41:05 2019
(r344126)
+++ stable/11/lib/libfigpar/string_m.c  Thu Feb 14 15:42:29 2019
(r344127)
@@ -120,9 +120,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 */
+   if (temp == NULL) /* could not allocate memory */
return (-1);
-   strcpy(temp, source);
+   memcpy(temp, source, slen + 1);
} else
temp = source;
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r344126 - stable/11/libexec/getty

[Stefan Esser]

Author: se
Date: Thu Feb 14 15:41:05 2019
New Revision: 344126
URL: https://svnweb.freebsd.org/changeset/base/344126

Log:
  MFC r343479: 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.

Modified:
  stable/11/libexec/getty/chat.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/libexec/getty/chat.c
==
--- stable/11/libexec/getty/chat.c  Thu Feb 14 15:39:17 2019
(r344125)
+++ stable/11/libexec/getty/chat.c  Thu Feb 14 15:41:05 2019
(r344126)
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r344125 - stable/11/usr.bin/whereis

[Stefan Esser]

Author: se
Date: Thu Feb 14 15:39:17 2019
New Revision: 344125
URL: https://svnweb.freebsd.org/changeset/base/344125

Log:
  MFC r343408: Silence Clang Scan warnings regarding unsafe use of strcp().
  
  While these warnings are false positives, the use of strdup() instead of
  malloc() and strcpy() simplifies and clarifies the code.
  
  A bogus assignment to a variable (whose previous value may be required in
  a later block) has also been removed.

Modified:
  stable/11/usr.bin/whereis/whereis.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/usr.bin/whereis/whereis.c
==
--- stable/11/usr.bin/whereis/whereis.c Thu Feb 14 15:33:04 2019
(r344124)
+++ stable/11/usr.bin/whereis/whereis.c Thu Feb 14 15:39:17 2019
(r344125)
@@ -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, , );
}
}
@@ -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, , );
}
 
/* -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, , );
 
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r344124 - stable/11/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Thu Feb 14 15:33:04 2019
New Revision: 344124
URL: https://svnweb.freebsd.org/changeset/base/344124

Log:
  MFC r343339: Silence Clang Scan warning about use of unitialized variable.
  
  The logic is changed to depend on actual "beep" parameters instead of on a
  flag that may be set for invalid parameters.
  
  An embedded literal escape character has been replaced by "\e", since it
  could confuse terminals when displaying the affected line.

Modified:
  stable/11/usr.sbin/kbdcontrol/kbdcontrol.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- stable/11/usr.sbin/kbdcontrol/kbdcontrol.c  Thu Feb 14 15:15:32 2019
(r344123)
+++ stable/11/usr.sbin/kbdcontrol/kbdcontrol.c  Thu Feb 14 15:33:04 2019
(r344124)
@@ -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, );
-   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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343941 - stable/12/lib/libfigpar

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:44:17 2019
New Revision: 343941
URL: https://svnweb.freebsd.org/changeset/base/343941

Log:
  MFC r343480,343482: Silence Clang Scan warning about unsafe use of strcpy.
  
  Replace   strcpy() by memcpy to the previously allocated range of known 
size.

Modified:
  stable/12/lib/libfigpar/string_m.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/lib/libfigpar/string_m.c
==
--- stable/12/lib/libfigpar/string_m.c  Sat Feb  9 14:33:43 2019
(r343940)
+++ stable/12/lib/libfigpar/string_m.c  Sat Feb  9 14:44:17 2019
(r343941)
@@ -120,9 +120,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 */
+   if (temp == NULL) /* could not allocate memory */
return (-1);
-   strcpy(temp, source);
+   memcpy(temp, source, slen + 1);
} else
temp = source;
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343940 - in stable/12/usr.sbin/timed: timed timedc

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:33:43 2019
New Revision: 343940
URL: https://svnweb.freebsd.org/changeset/base/343940

Log:
  Add notes regarding the deprecation and removal of timed and timedc in
  -CURRENT to binaries and man-pages.
  
  This is a direct commit to -STABLE, since the removal from -CURRENT has
  already been done.

Modified:
  stable/12/usr.sbin/timed/timed/timed.8
  stable/12/usr.sbin/timed/timed/timed.c
  stable/12/usr.sbin/timed/timedc/timedc.8
  stable/12/usr.sbin/timed/timedc/timedc.c

Modified: stable/12/usr.sbin/timed/timed/timed.8
==
--- stable/12/usr.sbin/timed/timed/timed.8  Sat Feb  9 14:21:29 2019
(r343939)
+++ stable/12/usr.sbin/timed/timed/timed.8  Sat Feb  9 14:33:43 2019
(r343940)
@@ -286,3 +286,9 @@ The
 .Nm
 utility appeared in
 .Bx 4.3 .
+.Pp
+The latest
+.Nm
+code has been made available as a port (net/timed) in preparation of removal
+from base in
+.Fx 13.0 .

Modified: stable/12/usr.sbin/timed/timed/timed.c
==
--- stable/12/usr.sbin/timed/timed/timed.c  Sat Feb  9 14:21:29 2019
(r343939)
+++ stable/12/usr.sbin/timed/timed/timed.c  Sat Feb  9 14:33:43 2019
(r343940)
@@ -192,6 +192,9 @@ main(int argc, char *argv[])
if (optind < argc)
usage();
 
+   fprintf(stderr, "TIMED will be removed from FreeBSD-13, and will be "
+   "provided as a port (net/timed) or package (timed).\n");
+
/* If we care about which machine is the master, then we must
 *  be willing to be a master
 */

Modified: stable/12/usr.sbin/timed/timedc/timedc.8
==
--- stable/12/usr.sbin/timed/timedc/timedc.8Sat Feb  9 14:21:29 2019
(r343939)
+++ stable/12/usr.sbin/timed/timedc/timedc.8Sat Feb  9 14:33:43 2019
(r343940)
@@ -139,3 +139,9 @@ The
 .Nm
 utility appeared in
 .Bx 4.3 .
+.Pp
+The latest
+.Nm
+code has been made available as a port (net/timed) in preparation of removal
+from base in
+.Fx 13.0 .

Modified: stable/12/usr.sbin/timed/timedc/timedc.c
==
--- stable/12/usr.sbin/timed/timedc/timedc.cSat Feb  9 14:21:29 2019
(r343939)
+++ stable/12/usr.sbin/timed/timedc/timedc.cSat Feb  9 14:33:43 2019
(r343940)
@@ -97,6 +97,9 @@ main(int argc, char *argv[])
}
 
fromatty = isatty(fileno(stdin));
+   if (fromatty)
+   printf("TIMEDC will be removed from FreeBSD-13, and will be "
+   "provided as a port (net/timed) or package (timed).\n");
if (setjmp(toplevel))
putchar('\n');
(void) signal(SIGINT, intr);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343939 - stable/12/libexec/getty

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:21:29 2019
New Revision: 343939
URL: https://svnweb.freebsd.org/changeset/base/343939

Log:
  MFC r343479: 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.

Modified:
  stable/12/libexec/getty/chat.c

Modified: stable/12/libexec/getty/chat.c
==
--- stable/12/libexec/getty/chat.c  Sat Feb  9 14:19:09 2019
(r343938)
+++ stable/12/libexec/getty/chat.c  Sat Feb  9 14:21:29 2019
(r343939)
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343938 - stable/12/usr.bin/whereis

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:19:09 2019
New Revision: 343938
URL: https://svnweb.freebsd.org/changeset/base/343938

Log:
  MFC r343408: Silence Clang Scan warnings regarding unsafe use of strcp().
  
  While these warnings are false positives, the use of strdup() instead of
  malloc() and strcpy() simplifies and clarifies the code.
  
  A bogus assignment to a variable (whose previous value may be required in
  a later block) has also been removed.

Modified:
  stable/12/usr.bin/whereis/whereis.c

Modified: stable/12/usr.bin/whereis/whereis.c
==
--- stable/12/usr.bin/whereis/whereis.c Sat Feb  9 14:13:49 2019
(r343937)
+++ stable/12/usr.bin/whereis/whereis.c Sat Feb  9 14:19:09 2019
(r343938)
@@ -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, , );
}
}
@@ -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, , );
}
 
/* -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, , );
 
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343937 - stable/12/usr.sbin/kbdcontrol

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:13:49 2019
New Revision: 343937
URL: https://svnweb.freebsd.org/changeset/base/343937

Log:
  MFC r343339: Silence Clang Scan warning about use of unitialized variable.
  
  The logic is changed to depend on actual "beep" parameters instead of on a
  flag that may be set for invalid parameters.
  
  An embedded literal escape character is replaced by "\e".

Modified:
  stable/12/usr.sbin/kbdcontrol/kbdcontrol.c

Modified: stable/12/usr.sbin/kbdcontrol/kbdcontrol.c
==
--- stable/12/usr.sbin/kbdcontrol/kbdcontrol.c  Sat Feb  9 14:07:04 2019
(r343936)
+++ stable/12/usr.sbin/kbdcontrol/kbdcontrol.c  Sat Feb  9 14:13:49 2019
(r343937)
@@ -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, );
-   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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r343936 - stable/12/usr.sbin/kbdmap

[Stefan Esser]

Author: se
Date: Sat Feb  9 14:07:04 2019
New Revision: 343936
URL: https://svnweb.freebsd.org/changeset/base/343936

Log:
  MFC r343303: 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.

Modified:
  stable/12/usr.sbin/kbdmap/kbdmap.c

Modified: stable/12/usr.sbin/kbdmap/kbdmap.c
==
--- stable/12/usr.sbin/kbdmap/kbdmap.c  Sat Feb  9 12:01:10 2019
(r343935)
+++ stable/12/usr.sbin/kbdmap/kbdmap.c  Sat Feb  9 14:07:04 2019
(r343936)
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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, , );
}
}
@@ -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, , );
}
 
/* -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, , );
 
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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, );
-   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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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 

svn commit: r340444 - in stable/12: . usr.sbin/ctm/ctm

[Stefan Esser]

Author: se
Date: Wed Nov 14 20:35:04 2018
New Revision: 340444
URL: https://svnweb.freebsd.org/changeset/base/340444

Log:
  MFC S340428: 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:re
  Relnotes:   yes
  Differential Revision:  https://reviews.freebsd.org/D17969

Modified:
  stable/12/UPDATING
  stable/12/usr.sbin/ctm/ctm/ctm.1
  stable/12/usr.sbin/ctm/ctm/ctm.c

Modified: stable/12/UPDATING
==
--- stable/12/UPDATING  Wed Nov 14 19:10:35 2018(r340443)
+++ stable/12/UPDATING  Wed Nov 14 20:35:04 2018(r340444)
@@ -16,6 +16,13 @@ from older versions of FreeBSD, try WITHOUT_CLANG and 
 the tip of head, and then rebuild without this option. The bootstrap process
 from older version of current across the gcc/clang cutover is a bit fragile.
 
+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.  A depreciation warning will be printed to stderr by
+   the ctm command, but the functionality will remain in base for all
+   FreeBSD-12 releases.
+
 20181019:
The stable/12 branch has been created in subversion from head
revision r339432.

Modified: stable/12/usr.sbin/ctm/ctm/ctm.1
==
--- stable/12/usr.sbin/ctm/ctm/ctm.1Wed Nov 14 19:10:35 2018
(r340443)
+++ stable/12/usr.sbin/ctm/ctm/ctm.1Wed Nov 14 20:35:04 2018
(r340444)
@@ -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: stable/12/usr.sbin/ctm/ctm/ctm.c
==
--- stable/12/usr.sbin/ctm/ctm/ctm.cWed Nov 14 19:10:35 2018
(r340443)
+++ stable/12/usr.sbin/ctm/ctm/ctm.cWed Nov 14 20:35:04 2018
(r340444)
@@ -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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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
>>>> <free...@pdx.rh.cn85.dnsmgr.net> 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: 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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r325053 - in stable/10/share/man: man5 man8

[Stefan Esser]

Author: se
Date: Sat Oct 28 07:06:57 2017
New Revision: 325053
URL: https://svnweb.freebsd.org/changeset/base/325053

Log:
  MFC 324721: Add references to sysrc(8) to SEE ALSO.
  MFC 324823: Mention sysrc(8) as scripting interface for config files.

Modified:
  stable/10/share/man/man5/rc.conf.5
  stable/10/share/man/man8/rc.8
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/share/man/man5/rc.conf.5
==
--- stable/10/share/man/man5/rc.conf.5  Sat Oct 28 07:06:30 2017
(r325052)
+++ stable/10/share/man/man5/rc.conf.5  Sat Oct 28 07:06:57 2017
(r325053)
@@ -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
@@ -4693,6 +4696,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: stable/10/share/man/man8/rc.8
==
--- stable/10/share/man/man8/rc.8   Sat Oct 28 07:06:30 2017
(r325052)
+++ stable/10/share/man/man8/rc.8   Sat Oct 28 07:06:57 2017
(r325053)
@@ -91,6 +91,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
@@ -557,7 +560,8 @@ is unnecessary, but is often included.
 .Xr rcorder 8 ,
 .Xr rc.subr 8 ,
 .Xr reboot 8 ,
-.Xr savecore 8
+.Xr savecore 8 ,
+.Xr sysrc 8
 .Sh HISTORY
 The
 .Nm
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r325052 - in stable/11/share/man: man5 man8

[Stefan Esser]

Author: se
Date: Sat Oct 28 07:06:30 2017
New Revision: 325052
URL: https://svnweb.freebsd.org/changeset/base/325052

Log:
  MFC 324721: Add references to sysrc(8) to SEE ALSO.
  MFC 324823: Mention sysrc(8) as scripting interface for config files.

Modified:
  stable/11/share/man/man5/rc.conf.5
  stable/11/share/man/man8/rc.8
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/share/man/man5/rc.conf.5
==
--- stable/11/share/man/man5/rc.conf.5  Sat Oct 28 02:51:27 2017
(r325051)
+++ stable/11/share/man/man5/rc.conf.5  Sat Oct 28 07:06:30 2017
(r325052)
@@ -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
@@ -4666,6 +4669,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: stable/11/share/man/man8/rc.8
==
--- stable/11/share/man/man8/rc.8   Sat Oct 28 02:51:27 2017
(r325051)
+++ stable/11/share/man/man8/rc.8   Sat Oct 28 07:06:30 2017
(r325052)
@@ -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
@@ -557,7 +560,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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324620 - head/sys/fs/fuse

[Stefan Esser]

Am 14.10.17 um 21:02 schrieb Fedor Uporov:
> Author: fsu
> Date: Sat Oct 14 19:02:52 2017
> New Revision: 324620
> URL: https://svnweb.freebsd.org/changeset/base/324620
> 
> Log:
>   Add extended attributes support to fuse kernel module.
>   
>   Author: kem
>   Reviewed by:cem, pfg (mentor)
>   Approved by:pfg (mentor)
>   MFC after:  2 weeks
>   
>   Differential Revision: https://reviews.freebsd.org/D12485

Should any of these defines have been updated?

/sys/fuse/fs/fuse.h:
#define FUSE_FREEBSD_VERSION"0.4.4"

/sys/fuse/fs/fuse_kernel.h:
#define FUSE_KERNEL_VERSION 7
#define FUSE_KERNEL_MINOR_VERSION 8

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

svn commit: r322225 - stable/10/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Tue Aug  8 10:45:22 2017
New Revision: 35
URL: https://svnweb.freebsd.org/changeset/base/35

Log:
  MFC 321858: Add alternate Turkish keyboard layout F, submitted by Ufur Guler.
  MFC 321859: While here, adjust a few file and path names in comments.

Added:
  stable/10/share/vt/keymaps/tr.f.kbd
 - copied unchanged from r321858, head/share/vt/keymaps/tr.f.kbd
Modified:
  stable/10/share/vt/keymaps/INDEX.keymaps
  stable/10/share/vt/keymaps/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/share/vt/keymaps/INDEX.keymaps
==
--- stable/10/share/vt/keymaps/INDEX.keymapsTue Aug  8 10:45:13 2017
(r34)
+++ stable/10/share/vt/keymaps/INDEX.keymapsTue Aug  8 10:45:22 2017
(r35)
@@ -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
@@ -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)
@@ -502,11 +504,18 @@ 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
 uk.kbd:fr:Royaume Uni
@@ -515,9 +524,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

Modified: stable/10/share/vt/keymaps/Makefile
==
--- stable/10/share/vt/keymaps/Makefile Tue Aug  8 10:45:13 2017
(r34)
+++ stable/10/share/vt/keymaps/Makefile Tue Aug  8 10:45:22 2017
(r35)
@@ -69,6 +69,7 @@ FILES=INDEX.keymaps \
se.kbd \
si.kbd \
sk.kbd \
+   tr.f.kbd \
tr.kbd \
ua.kbd \
ua.shift.alt.kbd \

Copied: stable/10/share/vt/keymaps/tr.f.kbd (from r321858, 
head/share/vt/keymaps/tr.f.kbd)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ stable/10/share/vt/keymaps/tr.f.kbd Tue Aug  8 10:45:22 2017
(r35, copy of r321858, head/share/vt/keymaps/tr.f.kbd)
@@ -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'+'   

svn commit: r322224 - stable/11/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Tue Aug  8 10:45:13 2017
New Revision: 34
URL: https://svnweb.freebsd.org/changeset/base/34

Log:
  MFC 321858: Add alternate Turkish keyboard layout F, submitted by Ufur Guler.
  MFC 321859: While here, adjust a few file and path names in comments.

Added:
  stable/11/share/vt/keymaps/tr.f.kbd
 - copied unchanged from r321858, head/share/vt/keymaps/tr.f.kbd
Modified:
  stable/11/share/vt/keymaps/INDEX.keymaps
  stable/11/share/vt/keymaps/Makefile
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/share/vt/keymaps/INDEX.keymaps
==
--- stable/11/share/vt/keymaps/INDEX.keymapsTue Aug  8 10:44:48 2017
(r33)
+++ stable/11/share/vt/keymaps/INDEX.keymapsTue Aug  8 10:45:13 2017
(r34)
@@ -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
@@ -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)
@@ -502,11 +504,18 @@ 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
 uk.kbd:fr:Royaume Uni
@@ -515,9 +524,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

Modified: stable/11/share/vt/keymaps/Makefile
==
--- stable/11/share/vt/keymaps/Makefile Tue Aug  8 10:44:48 2017
(r33)
+++ stable/11/share/vt/keymaps/Makefile Tue Aug  8 10:45:13 2017
(r34)
@@ -69,6 +69,7 @@ FILES=INDEX.keymaps \
se.kbd \
si.kbd \
sk.kbd \
+   tr.f.kbd \
tr.kbd \
ua.kbd \
ua.shift.alt.kbd \

Copied: stable/11/share/vt/keymaps/tr.f.kbd (from r321858, 
head/share/vt/keymaps/tr.f.kbd)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ stable/11/share/vt/keymaps/tr.f.kbd Tue Aug  8 10:45:13 2017
(r34, copy of r321858, head/share/vt/keymaps/tr.f.kbd)
@@ -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'+'   

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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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  

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

[Stefan Esser]

Am 16.06.2016 um 05:00 schrieb Glen Barber:
> Author: gjb
> Date: Thu Jun 16 03:00:10 2016
> New Revision: 301944
> URL: https://svnweb.freebsd.org/changeset/base/301944
> 
> Log:
>   Fix zoneinfo file packaging.
>   
>   This change fixes 468 of 488 zoneinfo file packaging issues,
>   the rest still to be investigated.
>   
>   Approved by:re (blanket, pkgbase)
>   Sponsored by:   The FreeBSD Foundation
> 
> Modified:
>   head/share/zoneinfo/Makefile
> 
> Modified: head/share/zoneinfo/Makefile
> ==
> --- head/share/zoneinfo/Makefile  Thu Jun 16 02:48:18 2016
> (r301943)
> +++ head/share/zoneinfo/Makefile  Thu Jun 16 03:00:10 2016
> (r301944)
> @@ -82,10 +82,10 @@ zoneinfo: yearistype ${TDATA}
>  beforeinstall: install-zoneinfo
>  install-zoneinfo:
>   cd ${TZBUILDDIR} && \
> - find -s * -type f -print -exec ${INSTALL} \
> + find -s * -type f -print -exec ${INSTALL} -T ${TAGS} \
>   -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
>   \{} ${DESTDIR}/usr/share/zoneinfo/\{} \;
> - ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
> + ${INSTALL} -T ${TAGS} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
>   ${CONTRIBDIR}/zone.tab ${DESTDIR}/usr/share/zoneinfo/

This change breaks installworld for me.

${TAGS} is empty and makes ${INSTALL} fail:

===> share/zoneinfo (install)
cd /usr/obj/usr/svn/base/head/share/zoneinfo/builddir &&  find -s *
-type f -print -exec install -T   -o root -g wheel -m 444  \{}
//usr/share/zoneinfo/\{} \;
Africa/Abidjan
install: target `//usr/share/zoneinfo/Africa/Abidjan' is not a directory
usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
   [-M log] [-D dest] [-h hash] [-T tags]
   [-B suffix] [-l linkflags] [-N dbdir]
   file1 file2
   install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
   [-M log] [-D dest] [-h hash] [-T tags]
   [-B suffix] [-l linkflags] [-N dbdir]
   file1 ... fileN directory
   install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]
   [-M log] [-D dest] [-h hash] [-T tags]
   directory ...
...

A simple work-around might be double quotes around ${TAGS} which makes
${INSTALL} happy - it accepts the empty string as parameter for -T
without complaints.

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

svn commit: r298539 - head/etc/rc.d

[Stefan Esser]

Author: se
Date: Sun Apr 24 12:07:44 2016
New Revision: 298539
URL: https://svnweb.freebsd.org/changeset/base/298539

Log:
  Fix typo (forgotten "=" after desc).

Modified:
  head/etc/rc.d/ccd

Modified: head/etc/rc.d/ccd
==
--- head/etc/rc.d/ccd   Sun Apr 24 11:41:36 2016(r298538)
+++ head/etc/rc.d/ccd   Sun Apr 24 12:07:44 2016(r298539)
@@ -9,7 +9,7 @@
 . /etc/rc.subr
 
 name="ccd"
-desc"Concatenated disks setup"
+desc="Concatenated disks setup"
 start_cmd="ccd_start"
 stop_cmd=":"
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r295800 - head/usr.bin/cap_mkdb

[Stefan Esser]

Am 20.02.2016 um 03:31 schrieb Eric van Gyzen:
> On 2/19/16 6:40 PM, Bryan Drewery wrote:
>> On 2/19/2016 12:42 AM, Stefan Esser wrote:
>>> Author: se
>>> Date: Fri Feb 19 08:42:13 2016
>>> New Revision: 295800
>>> URL: https://svnweb.freebsd.org/changeset/base/295800
>>>
>>> Log:
>>>Remove O_SYNC from the options passed to dbmopen().
>> Uh, this is a full revert of r293312's changes to cap_mkdb which were
>> made for good reason. So this seems simply wrong without a better fix.
>>
>>>   The output file is created as a temporary file that is moved
>>> over the
>>>existing file after completion. Thus there is no need to immediately
>>>flush all created db records to the temporary file.
>> This is not right either. Depending on the use of soft updates /
>> journaling the data and metadata (file name / rename) may be written at
>> different times. It is entirely possible to get a renamed file with no
>> or junk content without an fsync. That's exactly what r293312 mentions
>> in its commit message.

I had performed multiple tests and found, that the file was always
created identical whether with or without O_SYNC. But I've got to
admit, that I did not check the SVN log.

After reading the commit log entry for r293312, I understand there is
the risk of an empty db file if a system crash happens before all data
and metadata has been flushed.

I had assumed that one of the guarantees soft-updates makes is that
data and meta-data operations are ordered relative to each other.

I'm not sure, whether this is a hypothetical case, or whether such a
case had been observed in reality, but I understand that you don't
want to take risk when operating on critical system files.

O_SYNC was first added to updates of the password db, and I think that
was the file with the biggest risk of accidental damage due to a crash.

But services_mkdb and cap_mkdb are only invoked by the administrator
after the text files are modified and it is highly unlikely (but of
course not impossible) that a crash occurs at just that moment.

> dwmalone@ plans to put the fsync() in the db close method, which makes a
> lot of sense, and would fix this in a better way.
> 
> https://reviews.freebsd.org/D5186
> 
> This commit probably should have waited for D5186 to be committed, but
> at least that seems imminent.

Yes, I mentioned review D5186 in the commit log and was aware, that
there was consensus that dwmalone's change to hash.c is about to be
committed. I was afraid that D5186 could be committed without the
removal of O_SYNC and that D5186 might be merged to 10.3, but that
cap_mkdb kept O_SYNC and would be slow throughout the lifetime of
10.3.

So the commit was expected to be followed by the fsync() patch in
hash.c very soon and I had mentioned, that the MFC of the mkdb patch
should be performed in conjunction (or after) the MFC of D5186.

I think it is important that the mkdb utilities do not take tens of
seconds and up to several minutes in 10.3 ...

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

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

[Stefan Esser]

Author: se
Date: Fri Feb 19 16:53:21 2016
New Revision: 295816
URL: https://svnweb.freebsd.org/changeset/base/295816

Log:
  Fix syntax error introduced in previous commit where I removed one
  character to few. I should have waited for the kernel compile to finish,
  even though the change seemed so trivial.

Modified:
  head/sys/dev/pci/pci_user.c

Modified: head/sys/dev/pci/pci_user.c
==
--- head/sys/dev/pci/pci_user.c Fri Feb 19 16:43:37 2016(r295815)
+++ head/sys/dev/pci/pci_user.c Fri Feb 19 16:53:21 2016(r295816)
@@ -711,7 +711,7 @@ pci_ioctl(struct cdev *dev, u_long cmd, 
for (cio->num_matches = 0, error = 0, i = 0,
 dinfo = STAILQ_FIRST(devlist_head);
 (dinfo != NULL) && (cio->num_matches < ionum) &&
-(error == 0) && (i < pci_numdevs));
+(error == 0) && (i < pci_numdevs);
 dinfo = STAILQ_NEXT(dinfo, pci_links), i++) {
 
if (i < cio->offset)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Stefan Esser]

Author: se
Date: Fri Feb 19 16:43:03 2016
New Revision: 295813
URL: https://svnweb.freebsd.org/changeset/base/295813

Log:
  Remove redundant check for "(dinfo != NULL)", it has already been performed
  as the first part of this complex loop conditional.
  
  Found by:PVS Static Analysis

Modified:
  head/sys/dev/pci/pci_user.c

Modified: head/sys/dev/pci/pci_user.c
==
--- head/sys/dev/pci/pci_user.c Fri Feb 19 16:37:06 2016(r295812)
+++ head/sys/dev/pci/pci_user.c Fri Feb 19 16:43:03 2016(r295813)
@@ -709,9 +709,9 @@ pci_ioctl(struct cdev *dev, u_long cmd, 
 * that match the user's criteria.
 */
for (cio->num_matches = 0, error = 0, i = 0,
-dinfo = STAILQ_FIRST(devlist_head);
-(dinfo != NULL) && (cio->num_matches < ionum)
-&& (error == 0) && (i < pci_numdevs) && (dinfo != NULL);
+dinfo = STAILQ_FIRST(devlist_head);
+(dinfo != NULL) && (cio->num_matches < ionum) &&
+(error == 0) && (i < pci_numdevs));
 dinfo = STAILQ_NEXT(dinfo, pci_links), i++) {
 
if (i < cio->offset)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r295806 - head/usr.sbin/pciconf

[Stefan Esser]

Author: se
Date: Fri Feb 19 14:01:35 2016
New Revision: 295806
URL: https://svnweb.freebsd.org/changeset/base/295806

Log:
  Fix possible out-of-bounds access detected by Ulrich Spörleins "scan-build".
  Some invalid PCI device selectors could cause read access to an initialized
  variable next to the array (local loop index variable).
  
  While here, the parser has been made more strict with regard to the syntax
  of PCI device selectors as documented in the man-page. E.g. "pci:" used to
  be interpreted as "pci0:0".
  
  MFC after:3 days

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

Modified: head/usr.sbin/pciconf/pciconf.c
==
--- head/usr.sbin/pciconf/pciconf.c Fri Feb 19 11:25:18 2016
(r295805)
+++ head/usr.sbin/pciconf/pciconf.c Fri Feb 19 14:01:35 2016
(r295806)
@@ -897,7 +897,6 @@ static struct pcisel
 parsesel(const char *str)
 {
const char *ep;
-   const char *epbase;
char *eppos;
struct pcisel sel;
unsigned long selarr[4];
@@ -909,30 +908,27 @@ parsesel(const char *str)
else
ep = str;
 
-   epbase = ep;
-
if (strncmp(ep, "pci", 3) == 0) {
ep += 3;
i = 0;
-   do {
+   while (isdigit(*ep) && i < 4) {
selarr[i++] = strtoul(ep, , 10);
ep = eppos;
-   } while ((*ep == ':' || *ep == '.') && *++ep != '\0' && i < 4);
-
-   if (i > 2)
-   sel.pc_func = selarr[--i];
-   else
-   sel.pc_func = 0;
-   sel.pc_dev = selarr[--i];
-   sel.pc_bus = selarr[--i];
-   if (i > 0)
-   sel.pc_domain = selarr[--i];
-   else
-   sel.pc_domain = 0;
+   if (*ep == ':') {
+   ep++;
+   if (*ep  == '\0')
+   i = 0;
+   }
+   }
+   if (i > 0 && *ep == '\0') {
+   sel.pc_func = (i > 2) ? selarr[--i] : 0;
+   sel.pc_dev = (i > 0) ? selarr[--i] : 0;
+   sel.pc_bus = (i > 0) ? selarr[--i] : 0;
+   sel.pc_domain = (i > 0) ? selarr[--i] : 0;
+   return (sel);
+   }
}
-   if (*ep != '\x0' || ep == epbase)
-   errx(1, "cannot parse selector %s", str);
-   return sel;
+   errx(1, "cannot parse selector %s", str);
 }
 
 static struct pcisel
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r295800 - head/usr.bin/cap_mkdb

[Stefan Esser]

Author: se
Date: Fri Feb 19 08:42:13 2016
New Revision: 295800
URL: https://svnweb.freebsd.org/changeset/base/295800

Log:
  Remove O_SYNC from the options passed to dbmopen().
  
  The output file is created as a temporary file that is moved over the
  existing file after completion. Thus there is no need to immediately
  flush all created db records to the temporary file.
  
  This speeds up creation of the termcap db by a factor of 40 on my
  ZFS based /etc filesytem (from 25 seconds to 0.6 seconds).
  
  I have compared multiple output files created with and without O_SYNC
  and they came out identical each time.  Nonetheless it might be best
  to MFC this change and the similar one for services_mkdb (r295465) at
  the same time when the changes to hash.c in review D5186 are merged.
  
  MFC:   1 week

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

Modified: head/usr.bin/cap_mkdb/cap_mkdb.c
==
--- head/usr.bin/cap_mkdb/cap_mkdb.cFri Feb 19 08:41:47 2016
(r295799)
+++ head/usr.bin/cap_mkdb/cap_mkdb.cFri Feb 19 08:42:13 2016
(r295800)
@@ -119,7 +119,7 @@ main(int argc, char *argv[])
(void)snprintf(buf, sizeof(buf), "%s.db", capname ? capname : *argv);
if ((capname = strdup(buf)) == NULL)
errx(1, "strdup failed");
-   if ((capdbp = dbopen(capname, O_CREAT | O_TRUNC | O_RDWR | O_SYNC,
+   if ((capdbp = dbopen(capname, O_CREAT | O_TRUNC | O_RDWR,
DEFFILEMODE, DB_HASH, )) == NULL)
err(1, "%s", buf);
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r295769 - head/usr.sbin/pciconf

[Stefan Esser]

Author: se
Date: Thu Feb 18 20:20:36 2016
New Revision: 295769
URL: https://svnweb.freebsd.org/changeset/base/295769

Log:
  Use __unused instead of casting to void to silence the unused parameter
  warning.
  
  Fix the indentation of 2 lines to conform with the style of this file.
  
  Submitted by: jhb

Modified:
  head/usr.sbin/pciconf/cap.c
  head/usr.sbin/pciconf/pciconf.c

Modified: head/usr.sbin/pciconf/cap.c
==
--- head/usr.sbin/pciconf/cap.c Thu Feb 18 20:08:01 2016(r295768)
+++ head/usr.sbin/pciconf/cap.c Thu Feb 18 20:20:36 2016(r295769)
@@ -117,12 +117,9 @@ cap_agp(int fd, struct pci_conf *p, uint
 }
 
 static void
-cap_vpd(int fd, struct pci_conf *p, uint8_t ptr)
+cap_vpd(int fd __unused, struct pci_conf *p __unused, uint8_t ptr __unused)
 {
 
-   (void)fd;   /* UNUSED */
-   (void)p;/* UNUSED */
-   (void)ptr;  /* UNUSED */
printf("VPD");
 }
 
@@ -520,12 +517,9 @@ cap_msix(int fd, struct pci_conf *p, uin
 }
 
 static void
-cap_sata(int fd, struct pci_conf *p, uint8_t ptr)
+cap_sata(int fd __unused, struct pci_conf *p __unused, uint8_t ptr __unused)
 {
 
-   (void)fd;   /* UNUSED */
-   (void)p;/* UNUSED */
-   (void)ptr;  /* UNUSED */
printf("SATA Index-Data Pair");
 }
 

Modified: head/usr.sbin/pciconf/pciconf.c
==
--- head/usr.sbin/pciconf/pciconf.c Thu Feb 18 20:08:01 2016
(r295768)
+++ head/usr.sbin/pciconf/pciconf.c Thu Feb 18 20:20:36 2016
(r295769)
@@ -915,8 +915,8 @@ parsesel(const char *str)
ep += 3;
i = 0;
do {
- selarr[i++] = strtoul(ep, , 10);
- ep = eppos;
+   selarr[i++] = strtoul(ep, , 10);
+   ep = eppos;
} while ((*ep == ':' || *ep == '.') && *++ep != '\0' && i < 4);
 
if (i > 2)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r295760 - head/usr.sbin/pciconf

[Stefan Esser]

Am 18.02.2016 um 19:07 schrieb John Baldwin:
> On Thursday, February 18, 2016 03:23:26 PM Stefan Esser wrote:
>> Author: se
>> Date: Thu Feb 18 15:23:25 2016
>> New Revision: 295760
>> URL: https://svnweb.freebsd.org/changeset/base/295760
>>
>> Log:
>>   Make WARNS=6 safe.
>>   
>>   Tested with Clang 3.7.1, GCC 4.2.1 and GCC 4.8.5 on amd64.
> 
> Thanks.
> 
>> Modified: head/usr.sbin/pciconf/cap.c
>> ==
>> --- head/usr.sbin/pciconf/cap.c  Thu Feb 18 15:12:52 2016
>> (r295759)
>> +++ head/usr.sbin/pciconf/cap.c  Thu Feb 18 15:23:25 2016
>> (r295760)
>> @@ -120,6 +120,9 @@ static void
>>  cap_vpd(int fd, struct pci_conf *p, uint8_t ptr)
>>  {
>>  
>> +(void)fd;   /* UNUSED */
>> +(void)p;/* UNUSED */
>> +(void)ptr;  /* UNUSED */
>>  printf("VPD");
>>  }
> 
> I think we prefer __unused in the parameter declaration instead?  That is:

Since I was not sure about the best way to silence this warning, I had
looked at the mail archive and found a mail thread from July 2012 with
subject "(void)foo or __unused foo ?". The cast to void seemed to be
the most portable method, but in fact I prefer the __unused modifier
myself.

> cap_vpd(int fd __unused, struct pci_conf *p __unused, uint8_t ptr __unused)

Yes, I'll commit that version in a minute.

>> @@ -172,6 +175,7 @@ cap_pcix(int fd, struct pci_conf *p, uin
>>  }
>>  if ((p->pc_hdr & PCIM_HDRTYPE) == 1)
>>  return;
>> +max_burst_read = 0;
>>  switch (status & PCIXM_STATUS_MAX_READ) {
>>  case PCIXM_STATUS_MAX_READ_512:
>>  max_burst_read = 512;
> 
> Compilers are simply not smart enough. :-P

Well, clang-3.7.1 in -CURRENT is ...

But both gcc-4.2.1 and gcc-4.8.5 warn about a possibly uninitialized
variable.

I could have changed the last case selector into "default" to silence
the warning without need for an initializer before the switch statement,
but that would be too ugly and misleading.

>> Modified: head/usr.sbin/pciconf/pciconf.c
>> ==
>> --- head/usr.sbin/pciconf/pciconf.c  Thu Feb 18 15:12:52 2016
>> (r295759)
>> +++ head/usr.sbin/pciconf/pciconf.c  Thu Feb 18 15:23:25 2016
>> (r295760)
>> @@ -913,7 +915,8 @@ parsesel(const char *str)
>>  ep += 3;
>>  i = 0;
>>  do {
>> -selarr[i++] = strtoul(ep, , 10);
>> +  selarr[i++] = strtoul(ep, , 10);
>> +  ep = eppos;
>>  } while ((*ep == ':' || *ep == '.') && *++ep != '\0' && i < 4);
> 
> This is now indented oddly (2 spaces instead of a tab?).

Sorry, the pciconf sources do not comply with "style" and I'm to blame,
since I committed the initial version nearly 20 years ago ...

But you are correct, I got even the wrong indentation wrong ;-)

Thank you for the review and your comments, I'll commit a fixed version
now.

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

svn commit: r295760 - head/usr.sbin/pciconf

[Stefan Esser]

Author: se
Date: Thu Feb 18 15:23:25 2016
New Revision: 295760
URL: https://svnweb.freebsd.org/changeset/base/295760

Log:
  Make WARNS=6 safe.
  
  Tested with Clang 3.7.1, GCC 4.2.1 and GCC 4.8.5 on amd64.

Modified:
  head/usr.sbin/pciconf/Makefile
  head/usr.sbin/pciconf/cap.c
  head/usr.sbin/pciconf/pciconf.c

Modified: head/usr.sbin/pciconf/Makefile
==
--- head/usr.sbin/pciconf/Makefile  Thu Feb 18 15:12:52 2016
(r295759)
+++ head/usr.sbin/pciconf/Makefile  Thu Feb 18 15:23:25 2016
(r295760)
@@ -5,6 +5,4 @@ PROG=   pciconf
 SRCS=  pciconf.c cap.c err.c
 MAN=   pciconf.8
 
-WARNS?=3
-
 .include 

Modified: head/usr.sbin/pciconf/cap.c
==
--- head/usr.sbin/pciconf/cap.c Thu Feb 18 15:12:52 2016(r295759)
+++ head/usr.sbin/pciconf/cap.c Thu Feb 18 15:23:25 2016(r295760)
@@ -120,6 +120,9 @@ static void
 cap_vpd(int fd, struct pci_conf *p, uint8_t ptr)
 {
 
+   (void)fd;   /* UNUSED */
+   (void)p;/* UNUSED */
+   (void)ptr;  /* UNUSED */
printf("VPD");
 }
 
@@ -172,6 +175,7 @@ cap_pcix(int fd, struct pci_conf *p, uin
}
if ((p->pc_hdr & PCIM_HDRTYPE) == 1)
return;
+   max_burst_read = 0;
switch (status & PCIXM_STATUS_MAX_READ) {
case PCIXM_STATUS_MAX_READ_512:
max_burst_read = 512;
@@ -186,6 +190,7 @@ cap_pcix(int fd, struct pci_conf *p, uin
max_burst_read = 4096;
break;
}
+   max_splits = 0;
switch (status & PCIXM_STATUS_MAX_SPLITS) {
case PCIXM_STATUS_MAX_SPLITS_1:
max_splits = 1;
@@ -518,6 +523,9 @@ static void
 cap_sata(int fd, struct pci_conf *p, uint8_t ptr)
 {
 
+   (void)fd;   /* UNUSED */
+   (void)p;/* UNUSED */
+   (void)ptr;  /* UNUSED */
printf("SATA Index-Data Pair");
 }
 
@@ -759,7 +767,7 @@ ecap_sriov(int fd, struct pci_conf *p, u
print_bar(fd, p, "iov bar  ", ptr + PCIR_SRIOV_BAR(i));
 }
 
-struct {
+static struct {
uint16_t id;
const char *name;
 } ecap_names[] = {

Modified: head/usr.sbin/pciconf/pciconf.c
==
--- head/usr.sbin/pciconf/pciconf.c Thu Feb 18 15:12:52 2016
(r295759)
+++ head/usr.sbin/pciconf/pciconf.c Thu Feb 18 15:23:25 2016
(r295760)
@@ -67,7 +67,7 @@ struct pci_vendor_info
 char   *desc;
 };
 
-TAILQ_HEAD(,pci_vendor_info)   pci_vendors;
+static TAILQ_HEAD(,pci_vendor_info)pci_vendors;
 
 static struct pcisel getsel(const char *str);
 static void list_bridge(int fd, struct pci_conf *p);
@@ -896,16 +896,18 @@ getdevice(const char *name)
 static struct pcisel
 parsesel(const char *str)
 {
-   char *ep = strchr(str, '@');
-   char *epbase;
+   const char *ep;
+   const char *epbase;
+   char *eppos;
struct pcisel sel;
unsigned long selarr[4];
int i;
 
-   if (ep == NULL)
-   ep = (char *)str;
-   else
+   ep = strchr(str, '@');
+   if (ep != NULL)
ep++;
+   else
+   ep = str;
 
epbase = ep;
 
@@ -913,7 +915,8 @@ parsesel(const char *str)
ep += 3;
i = 0;
do {
-   selarr[i++] = strtoul(ep, , 10);
+ selarr[i++] = strtoul(ep, , 10);
+ ep = eppos;
} while ((*ep == ':' || *ep == '.') && *++ep != '\0' && i < 4);
 
if (i > 2)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r295465 - head/usr.sbin/services_mkdb

[Stefan Esser]

Am 11.02.2016 um 10:15 schrieb David Malone:
> On Wed, Feb 10, 2016 at 09:40:45AM +0000, Stefan Esser wrote:
>> Author: se
>> Date: Wed Feb 10 09:40:45 2016
>> New Revision: 295465
>> URL: https://svnweb.freebsd.org/changeset/base/295465
>>
>> Log:
>>   Remove O_SYNC from the options passed to dbmopen().
>>   
>>   The services db is created as a temporary file that is moved over the
>>   existing file after completion. Thus there is no need to immediately
>>   flush all created db records to the temporary file.
> 
> This was changed to fix a problem with fsync not being called, which
> can leave the db files empty after a sudden reboot. O_SYNC is not
> the right fix, but I think I've found the real problem and there
> is an open phabricator report on this, which fixes the problem in
> a better way:
> 
>   https://reviews.freebsd.org/D5186

I added the following information as a comment to D5168:

- I think that buffers are flushed in hdestroy() in hash.c, at least
  there is a comment that seems to indicate this.

- Tests showed that the _mdb commands create bitwise identical files
  with or without O_SYNC (and without the _fsync() calls you suggest
  in D5168).

- The cap_mkdb command does also use dbopen(O_SYNC) and completes in
  less than 1 second instead of more than 25 with O_SYNC removed.


BTW there is one further problem in services_mkdb:

There is a check for the existence of the temporary output file and if
a second instance of services_mkdb is started, it will terminate, but
only *after unlinking the other instance's temp output file*.

Due to the speed-up without O_SYNC the time window is much smaller now,
but I can easily provoke this even with the faster version:

# services_mkdb -qo /tmp/xx.db & services_mkdb -qo /tmp/xx.db
[2] 71869
services_mkdb: Error opening temporary database `/tmp/xx.db.tmp': File
exists
# services_mkdb-SYNC: Cannot rename `/tmp/xx.db.tmp' to `/tmp/xx.db': No
such file or directory

[2]-  Exit 1  services_mkdb -qo /tmp/xx.db

The second process detects that the temp output file exists complains
and deletes it. When the first process completed the creation of the
db, it tries to rename the file (that has already been removed by the
second command).

A better approach might be to have the second process unlink the temp
file, but then to continue after creation of its own temp file. Then
the first process will still find that it cannot rename the temp file
to its final name, but the second one will complete its temp file and
then rename it to its final name.

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

svn commit: r295465 - head/usr.sbin/services_mkdb

[Stefan Esser]

Author: se
Date: Wed Feb 10 09:40:45 2016
New Revision: 295465
URL: https://svnweb.freebsd.org/changeset/base/295465

Log:
  Remove O_SYNC from the options passed to dbmopen().
  
  The services db is created as a temporary file that is moved over the
  existing file after completion. Thus there is no need to immediately
  flush all created db records to the temporary file.
  
  This speeds up creation of the services db by a factor of 500 on my
  ZFS based /var/db filesytem (from 110 seconds to 0.235 seconds).
  
  MFC after:1 week

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

Modified: head/usr.sbin/services_mkdb/services_mkdb.c
==
--- head/usr.sbin/services_mkdb/services_mkdb.c Wed Feb 10 09:19:29 2016
(r295464)
+++ head/usr.sbin/services_mkdb/services_mkdb.c Wed Feb 10 09:40:45 2016
(r295465)
@@ -141,7 +141,7 @@ main(int argc, char *argv[])
err(1, "Cannot install exit handler");
 
(void)snprintf(tname, sizeof(tname), "%s.tmp", dbname);
-   db = dbopen(tname, O_RDWR | O_CREAT | O_EXCL | O_SYNC,
+   db = dbopen(tname, O_RDWR | O_CREAT | O_EXCL,
(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH), DB_HASH, );
if (!db)
err(1, "Error opening temporary database `%s'", tname);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys

[Stefan Esser]

Am 19.01.2016 um 18:08 schrieb Kurt Lidl:
> Removing the ability to run different zpools on top of a zvol is
> a significant reduction in functionality of the entire system, and a
> huge violation of the POLA.
> 
> At the very least, can you not add a sysctl that allows the
> dangerous behavior (even if it defaults to off)?  Myself
> and certainly others rely on having being able to use a zpool
> installed into a zvol for hosting bhyve virtual machines.
> 
> I've managed to deadlock the system when experimenting with this,
> but for the normal course of operations, it works just fine.
> 
> -Kurt

I already sent a private message to Alan because I also have
a system that has been running for years with such a setup.

A tunable might be even better than a sysctl (or the sysctl
might be initialized from the tunable) to allow booting with
the old behavior.

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

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r272112 - stable/10/etc/rc.d

[Stefan Esser]

Author: se
Date: Thu Sep 25 16:35:19 2014
New Revision: 272112
URL: http://svnweb.freebsd.org/changeset/base/272112

Log:
  MFC r271958:
  
  Permit use of no as specification of a Norwegian keymap file.
  Only keymap=NO (the default in defaults/rc.conf) or keymap=
  (an empty value) will prevent loading of a keymap file.
  
  Approved by:  re (gjb)

Modified:
  stable/10/etc/rc.d/syscons
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/etc/rc.d/syscons
==
--- stable/10/etc/rc.d/syscons  Thu Sep 25 16:22:32 2014(r272111)
+++ stable/10/etc/rc.d/syscons  Thu Sep 25 16:35:19 2014(r272112)
@@ -167,7 +167,7 @@ syscons_configure_keyboard()
# keymap
#
case ${keymap} in
-   [Nn][Oo] | '')
+   NO | '')
;;
*)
sc_init
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r271958 - head/etc/rc.d

[Stefan Esser]

Author: se
Date: Mon Sep 22 11:54:13 2014
New Revision: 271958
URL: http://svnweb.freebsd.org/changeset/base/271958

Log:
  The new naming scheme for keymap files for use with vt(4) introduced a
  collision for no as a country code with NO meaning do not load any
  keymap (which also has been the default value in etc/defaults/rc.conf
  for a long time).
  
  The result of this collision is, that kbdcontrol -l no will load the
  Norwegian keymap, while keymap=no in rc.conf was interpreted as the
  lower case spelling of NO meaning no keyboard (and no.kbd was not
  loaded).
  
  Fix this by matching only the upper-case spelling NO in rc.d/syscons
  when deciding whether to load a keymap file.
  
  This will lead to no.kbd being loaded, if the until now valid (but
  non-default) spelling no was used in an individual rc.conf file to mean
  no keyboard. But all alternatives I could think of introduce a larger
  violation of POLA ...
  
  Reported by:Gyrd Thane Lange (gyrd-se at thanelange.no)
  MFC after:3 days

Modified:
  head/etc/rc.d/syscons

Modified: head/etc/rc.d/syscons
==
--- head/etc/rc.d/syscons   Mon Sep 22 11:35:06 2014(r271957)
+++ head/etc/rc.d/syscons   Mon Sep 22 11:54:13 2014(r271958)
@@ -167,7 +167,7 @@ syscons_configure_keyboard()
# keymap
#
case ${keymap} in
-   [Nn][Oo] | '')
+   NO | '')
;;
*)
sc_init
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r271646 - stable/10/share/vt/keymaps

[Stefan Esser]

Author: se
Date: Mon Sep 15 20:08:07 2014
New Revision: 271646
URL: http://svnweb.freebsd.org/changeset/base/271646

Log:
  MFC r271452:
  
  Add two forgotten keymap names (fr.kbd and fr.acc.kbd) to the list
  of files to be installed.
  
  Approved by:  re

Modified:
  stable/10/share/vt/keymaps/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/share/vt/keymaps/Makefile
==
--- stable/10/share/vt/keymaps/Makefile Mon Sep 15 19:53:49 2014
(r271645)
+++ stable/10/share/vt/keymaps/Makefile Mon Sep 15 20:08:07 2014
(r271646)
@@ -31,8 +31,10 @@ FILES=   INDEX.keymaps \
es.dvorak.kbd \
es.kbd \
fi.kbd \
+   fr.acc.kbd \
fr.dvorak.acc.kbd \
fr.dvorak.kbd \
+   fr.kbd \
fr.macbook.kbd \
gr.101.acc.kbd \
gr.elot.acc.kbd \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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

[Stefan Esser]

Author: se
Date: Fri Sep 12 06:23:57 2014
New Revision: 271452
URL: http://svnweb.freebsd.org/changeset/base/271452

Log:
  Add forgotten keymap files fr.kbd and fr.acc.kbd to the FILES list.
  
  Obtained from:thierry
  MFC after:3 days

Modified:
  head/share/vt/keymaps/Makefile

Modified: head/share/vt/keymaps/Makefile
==
--- head/share/vt/keymaps/Makefile  Fri Sep 12 06:15:20 2014
(r271451)
+++ head/share/vt/keymaps/Makefile  Fri Sep 12 06:23:57 2014
(r271452)
@@ -31,8 +31,10 @@ FILES=   INDEX.keymaps \
es.dvorak.kbd \
es.kbd \
fi.kbd \
+   fr.acc.kbd \
fr.dvorak.acc.kbd \
fr.dvorak.kbd \
+   fr.kbd \
fr.macbook.kbd \
gr.101.acc.kbd \
gr.elot.acc.kbd \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r271095 - in stable/10: etc/defaults etc/rc.d sbin/conscontrol share/man/man4 share/man/man5 share/man/man7 share/man/man8 tools/tools/vt/keymaps usr.bin/lock usr.sbin/bsdconfig usr.sbi...

[Stefan Esser]

Author: se
Date: Thu Sep  4 13:45:16 2014
New Revision: 271095
URL: http://svnweb.freebsd.org/changeset/base/271095

Log:
  MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
  MFC r270653: Update man-pages to correctly refer to changed pathes and namin
  MFC r270657: More man pages that need to know about vt in addition to syscon
  MFC r270659: (by pluknet@) Missed comma.
  MFC r270660: Back-out the references to vt(4) from this man-page. It appears
  MFC r270933: Add references to vt(4) to further man-pages.
  MFC r270934: Final patches to the tools used to convert syscons keymaps for
  MFC r270935: Add vt(4) support to the console initialisation script, specifi
  
  Second batch of MFCs to add support for Unicode keymaps for use with vt(4).
  
  It contains the following changes:
  
  - Add references to vt(4) to relevant man-pages.
  - Update comment in defaults/rc.conf to mention vt
  - Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
  - Minor changes to the conversion tool based on mail comments on keymaps.
  
  Relnotes: yes

Modified:
  stable/10/etc/defaults/rc.conf
  stable/10/etc/rc.d/syscons
  stable/10/sbin/conscontrol/conscontrol.8
  stable/10/share/man/man4/atkbd.4
  stable/10/share/man/man4/kbdmux.4
  stable/10/share/man/man4/ukbd.4
  stable/10/share/man/man4/vkbd.4
  stable/10/share/man/man4/vt.4
  stable/10/share/man/man5/rc.conf.5
  stable/10/share/man/man7/hier.7
  stable/10/share/man/man8/nanobsd.8
  stable/10/tools/tools/vt/keymaps/KBDFILES.map
  stable/10/tools/tools/vt/keymaps/convert-keymap.pl
  stable/10/usr.bin/lock/lock.1
  stable/10/usr.sbin/bsdconfig/bsdconfig.8
  stable/10/usr.sbin/bsdinstall/bsdinstall.8
  stable/10/usr.sbin/kbdcontrol/kbdcontrol.1
  stable/10/usr.sbin/kbdcontrol/kbdmap.5
  stable/10/usr.sbin/kbdmap/kbdmap.1
  stable/10/usr.sbin/vidcontrol/vidcontrol.1
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/etc/defaults/rc.conf
==
--- stable/10/etc/defaults/rc.conf  Thu Sep  4 13:13:42 2014
(r271094)
+++ stable/10/etc/defaults/rc.conf  Thu Sep  4 13:45:16 2014
(r271095)
@@ -524,15 +524,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: stable/10/etc/rc.d/syscons
==
--- stable/10/etc/rc.d/syscons  Thu Sep  4 13:13:42 2014(r271094)
+++ stable/10/etc/rc.d/syscons  Thu Sep  4 13:45:16 2014(r271095)
@@ -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` = xvt ]; 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.*)  

svn commit: r271096 - stable/10/usr.sbin/smbmsg

[Stefan Esser]

Author: se
Date: Thu Sep  4 13:47:55 2014
New Revision: 271096
URL: http://svnweb.freebsd.org/changeset/base/271096

Log:
  MFC r270931: Fix typo (by - be).

Modified:
  stable/10/usr.sbin/smbmsg/smbmsg.8
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/usr.sbin/smbmsg/smbmsg.8
==
--- stable/10/usr.sbin/smbmsg/smbmsg.8  Thu Sep  4 13:45:16 2014
(r271095)
+++ stable/10/usr.sbin/smbmsg/smbmsg.8  Thu Sep  4 13:47:55 2014
(r271096)
@@ -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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r271109 - stable/10/tools/tools/vt/keymaps

[Stefan Esser]

Author: se
Date: Thu Sep  4 17:21:54 2014
New Revision: 271109
URL: http://svnweb.freebsd.org/changeset/base/271109

Log:
  Fix debug output that has erroneously been committed with the last update.
  
  Obtained from:Jan Beich

Modified:
  stable/10/tools/tools/vt/keymaps/convert-keymap.pl
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/tools/tools/vt/keymaps/convert-keymap.pl
==
--- stable/10/tools/tools/vt/keymaps/convert-keymap.pl  Thu Sep  4 17:19:16 
2014(r271108)
+++ stable/10/tools/tools/vt/keymaps/convert-keymap.pl  Thu Sep  4 17:21:54 
2014(r271109)
@@ -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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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

[Stefan Esser]

Am 04.09.2014 um 16:52 schrieb Jan Beich:
 Stefan Esser s...@freebsd.org writes:
 
 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.
 [...]
  sub local_to_UCS_code
  {
  my ($char) = @_;
  
 -return prettyprint_token(ord(Encode::decode(UTF-8, 
 local_to_UCS_string($char;
 +my $ucs_char = ord(Encode::decode(UTF-8, local_to_UCS_string($char)));
 +
 +$current_char = lc(chr($ucs_char)), print(SETCUR: $ucs_char\n)
 +if $current_char eq ;
 
 The script now emits |SETCUR: 123| lines that kbdcontrol(1) doesn't like.
 Either removing debug |print| or adding STDERR seems to fix.

Hi Jan,

this is (obviously) a left-over from some tests, which I have now
removed again.

Thanks for reporting!

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

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

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` = xvt ]; 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;;
+ua.*)