Re: routed && route6d removal proposal

[Hiroki Sato]

"Alexander V. Chernikov"  wrote
  in <273191592779...@mail.yandex.ru>:

me> Hey,
me>
me> I would like to propose removal of  sbin/routed and usr.sbin/route6d.

 I am still using both of them in production environments because they
 work well at least for my configurations and most of promising
 alternatives are under GPL, not BSDL.

 Why do we need to rush to remove them?  Discussion about whether we
 should keep or remove such old bits tends to be controversial when
 there is a user like me.  I would agree with the removal if they were
 harmful or impossible to maintain, but would not for the reason that
 they are simply old and probably no one uses it today.  Reason 1 and
 2 look like the latter at least to me.  "too old to be worth keeping"
 is a matter of degree.  Uucp, rlogind, and timed should be removed
 (and were removed) because there are few non-FreeBSD platforms which
 support these protocols.  RIP is still widely supported---just like
 FTP, which nowadays no one prefers to use and major www browsers are
 about to drop the support of---and not be considered an inherently
 vulnerable protocol like telnet.  And keeping these daemons is not
 harmful even for users who want to use third-party routing daemons
 you listed.

me> 1.1. Nowadays the daemon name is simply misleading. Given situation
me> described above, one does expect far wider functionality from the
me> program named "route[6]d" than just RIP implementation.

 I do not think this is a good reason to remove something nor people
 have got confused actually.  If this is true, quagga or bird are much
 worse.

me> 2. Multiple routing stacks supporting all major routing protocol
me> including RIP exists these days: bird, frr, quagga. Many BGP-only
me> designs in are gaining popularity, so do bgp speakers such as exabgp
me> or gobgp.  Nowadays, if one needs dynamic routing on the host, OSPF or
me> BGP speaker is the choice. FreeBSD packages contains well-maintained
me> ports for these. Having RIP[ng] speakers in base offers no advantage.
me>
me> 3. Both routed/route6d are largely unmaintained [4] and presents an
me> additional attack vector. Here is the list of last non-trivial commits
me> to routed/route6d:

 I think this is a separate issue.  What attack vectors which are
 known to be vulnerable do they have?

 The small commit counts are not equal to its unreliability.  Older
 daemons such as ppp(8), dhclient(8), ftpd(8), or bootpd(8) have
 received few substantial changes in recent years because they are
 mature.

 I am not a strong protester and will be happy to keep them as ports
 if everyone wants to remove them and it will happen, but I would like
 consistent criteria on removing software in the base system (they do
 not need to be perfect nor strict, though).  I believe harmfulness is
 more important than the fact that it is old or we have more choices
 in the ports tree.  If we have negative factors on maintaining them,
 removing them would be one of the choices as a result.  If the
 existing routed/route6d makes difficulty on people who want to use
 third-party routing daemons, it should be fixed.  These kind of
 harmfulness look below the threshold to me at this moment though I
 may be biased because I am still using them today...

-- Hiroki


pgpCyJ99YHF_f.pgp
Description: PGP signature

Re: net.inet6.ip6.deembed_scopeid removal

[Hiroki Sato]

"Alexander V. Chernikov"  wrote
  in <645741592773...@mail.yandex.ru>:

me> [re-sending email with as non-html]
me>
me> Hey,
me>
me> I would like to deprecate net.inet6.ip6.deembed_scopeid sysctl while
me> leaving the current default behaviour.
me>
me> This sysctl controls whether IPv6 scope is embedded in the IPv6
me> address or not when reading or writing route/interface/ifaddr data via
me> rtsock/sysctl.
me>
me> Embedding scope in the address is a hack, that overwrites some of the
me> bits that can be used otherwise. It was probably implemented that way
me> to simplify route table interactions, as rtable uses this hack to add
me> link-local addresses to the same radix tree.
me>
me> The change to fix the userland api by filling in sin6_scopeid and
me> avoid touching IPv6 address was added in r243187, 7 years ago. It
me> provided the sysctl in question, allowing to preserve compatibility
me> with older applications, by reverting to the old behavior.
me>
me> 7 years looks like enough timeframe for the applications to be
me> adjusted. Unless any major objections arise, I'm going to remove the
me> code and make de-embedded IPv6 addresses the only option on July 5
me> 2020.

 I agree that it is time to remove it and I do not think we need to
 wait more.  This knob was for debugging purpose rather than for
 keeping compatibility.  A concern was that recovering the scopeid
 might have performance penalty.

-- Hiroki


pgphFhheJxoAp.pgp
Description: PGP signature

Re: TLS certificates for NFS-over-TLS floating client

[Hiroki Sato]

Rick Macklem  wrote
  in 
:

rm> Hi,
rm>
rm> I am slowly trying to understand TLS certificates and am trying to figure
rm> out how to do the following:
rm> -> For an /etc/exports file with...
rm> /home -tls -network 192.168.1.0 -mask 255.255.255.0
rm> /home -tlscert
rm>
rm> This syntax isn't implemented yet, but the thinking is that clients on the
rm> 192.168.1 subnet would use TLS, but would not require a certificate.
rm> For access from anywhere else, the client(s) would be required to have a
rm> certificate.
rm>
rm> A typical client mounting from outside of the subnet might be my laptop,
rm> which is using wifi and has no fixed IP/DNS name.
rm> --> How do you create a certificate that the laptop can use, which the NFS
rm>server can trust enough to allow the mount?
rm> My thinking is that a "secret" value can be put in the certificate that the 
NFS
rm> server can check for.

 I do not think it is a good idea to use a certificate with an
 embedded secret for authentication and/or authorization.

 In the case that the client offers a certificate upon establishing a
 TLS connection for authentication purpose, the authenticity will be
 checked on the server usually by using the CA certificate which was
 used to issue the client certificate.  The CA cert must be put to
 somewhere the NFS server can read.

 The CA cert is secret.  So if the NFS server can check the client
 certificate by the CA certificate, it means the NFS server can
 trust the client.  I think no additional information is required.

 Authorization such as which mount point can be mounted by using the
 client cert can be implemented by using the CN field or other X.509
 attributes, of course.  It can be just a clear text.

 I think this is one of the most reliable and straightforward ways
 because in most cases both NFS servers and the clients are under the
 sysadmin's control.

rm> Now, I'm not sure, but I don't think this certificate can be created via
rm> a trust authority such that it would "verify". However, the server can
rm> look for the "secret" in the certificate and allow the mount based on that.

 In the way described above, to use TLS client authentication, the NFS
 server admin has to have a certificate which allows to sign another
 certificate.  This means that the admin must be a CA or trusted
 authority.

 In practice, one can generate a self-signed certificate by using
 openssl(1) and use it as its CA certificate.  He can issue
 certificates signed by it for the NFS clients, and put his CA
 certificate to somewhere the NFS server can read.

rm> Also, even if the NFS client/server have fixed IP addresses with well known
rm> DNS names, it isn't obvious to me how signed certificates can be acquired
rm> for them?
rm> (Lets Encrypt expects the Acme protocol to work and that seems to be
rm>  web site/http specific?)

 TLS certificates do not always have (or do not need to have) a domain
 name as an attribute.  Data in attributes are restricted depending on
 the purpose, so certificates issued by Let's Encrypt can have only
 domain names (CN or Subject Alternative Name), for example.  An
 example which is not supported by Let's Encrypt is a certificate for
 S/MIME email encryption which has an email address.

-- Hiroki


pgp4efev_ZHYw.pgp
Description: PGP signature

Re: acpiconf does not return proper information about the second battery

[Hiroki Sato]

Hi,

Mateusz Piotrowski <0...@freebsd.org> wrote
  in <22aa2ae6-088c-8d6c-8080-71a5db2ee...@freebsd.org>:

0m> Hello current,
0m>
0m> I've upgraded to r358233 recently (from a 13.0-CURRENT snapshot from
0m> late January).
0m>
0m> Since the upgrade, I cannot get full information about my second
0m> battery with acpiconf (I'm using Lenovo Thinkpad T480).
0m>
0m> The number of batteries is detected properly. It is just the details
0m> of the second one that are not available. Here are the outputs of
0m> acpiconf invocations:

 The cause should be my commit.  Could you send me off-list the result
 of the following?

 1. acpidump -dt

 2. An output of acpiconf which you had got before upgrading (if still
available)

-- Hiroki


pgpDbhhhNqeG8.pgp
Description: PGP signature

Re: The futur of the roff toolchain

[Hiroki Sato]

Kirk McKusick  wrote
  in <201705232013.v4nkdhn3066...@chez.mckusick.com>:

mc> Thanks for all your work on this project. As I still use roff for
mc> our book and for many of my presentations, it is a topic of interest
mc> to me. That said, I am fine with roff dropping out of base as I can
mc> easily enough bring it in from ports. And I am curious to try using
mc> heirloom doctools on our book to see if it works. We do some pretty
mc> evil things with diversions, so I can easily believe that it will
mc> not work. But it would be great if it does work, because the groff
mc> in base has some bugs that are annoying to work around.

 JFYI, I am working on porting/adjust roff macros used in D book to
 make them compatible with heirloom doctools in parallel with the
 translation work because heirloom doctools has better support of
 UTF-8 and pnon-English font set.  The modified MS macro and most of
 other small macros worked with some minor modifications though
 refer(1) in heirloom lacks flexibility in style specification.

-- Hiroki


pgpg4rniPEaAx.pgp
Description: PGP signature

Re: CURRENT [r309933] broke syslogd on IPv4 only system

[Hiroki Sato]

Hi,

Alex Deiter  wrote
  in :

al> Hello,
al>
al> Please take a look SVN r309933:

(snip)

al> Successfully tested on IPv4-only CURRENT r312856M.

 Thank you for your report.  r312921 should fix this problem.  Please
 let me know if you still find something wrong with the latest
 version.

-- Hiroki


pgp201AQK1OwO.pgp
Description: PGP signature

Re: 'make buildworld' failure

[Hiroki Sato]

hiren panchasara  wrote
  in <20170104180954.gv17...@strugglingcoder.info>:

hi> + hrs@
hi> On 01/04/17 at 12:43P, Oleg V. Nauman wrote:
hi> > ===> usr.sbin/inetd (all)
hi> > cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
hi> > B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=nehalem  -DLOGIN_CAP 
-DIPSEC -
hi> > g -MD  -MF.depend.inetd.o -MTinetd.o -std=gnu99 -fstack-protector-strong -
hi> > Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -
hi> > Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -
hi> > Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-
hi> > variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality
hi> > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-
hi> > arguments  -c /usr/src/usr.sbin/inetd/inetd.c -o inetd.o
hi> > /usr/src/usr.sbin/inetd/inetd.c:319:28: error: implicit declaration of
hi> > function 'satosin6' is
hi> >   invalid in C99 [-Werror,-Wimplicit-function-declaration]
hi> > IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
hi> >   ^
hi> > /usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 
'int' is
hi> > not a pointer
hi> > IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
hi> >     ^
hi> > /usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:266:4: note: expanded from
hi> > macro
hi> >   'IN6_IS_ADDR_V4MAPPED'
hi> > ((a)->__u6_addr.__u6_addr32[0] == 0 &&  \
hi> >   ^
hi> > /usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 
'int' is
hi> > not a pointer
hi> > IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
hi> >     ^
hi> > /usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:267:4: note: expanded from
hi> > macro
hi> >   'IN6_IS_ADDR_V4MAPPED'
hi> >  (a)->__u6_addr.__u6_addr32[1] == 0 &&  \
hi> >   ^
hi> > /usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 
'int' is
hi> > not a pointer
hi> > IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
hi> >     ^
hi> > /usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:268:4: note: expanded from
hi> > macro
hi> >   'IN6_IS_ADDR_V4MAPPED'
hi> >  (a)->__u6_addr.__u6_addr32[2] == ntohl(0x))
hi> >   ^
hi> > 4 errors generated.
hi> > *** Error code 1
hi> >
hi> >
hi> >
hi> > root@asus:/usr/src # svnlite info|grep Rev:
hi> > Last Changed Rev: 311250
hi> >
hi> > My current system revision is r310560
hi> >
hi> >  It possible that it is due to WITHOUT_INET6 defined in /etc/src.conf
hi>
hi> r310921 could be it.

 Thank you for the report and sorry for the breakage.  Should be fixed
 at r311354.

-- Hiroki


pgpuACXH4_4W8.pgp
Description: PGP signature

Re: syslogd no longer listens (or sends) on a network socket

[Hiroki Sato]

Michael Butler <i...@protected-networks.net> wrote
  in <da73919b-24bf-7ebf-3809-2220c087c...@protected-networks.net>:

im> On 12/19/16 12:12, Hiroki Sato wrote:
im> > Michael Butler <i...@protected-networks.net> wrote
im> >   in <d5c17fa6-ddd7-277f-6f92-ee8fb55cd...@protected-networks.net>:
im> >
im> > im> It appears that SVN r309925 and onward no longer opens a network
im> > im> socket unless the command-line explicitly contains "-b :syslog"
im> > :-(
im> > im>
im> > im> This also stops one syslog daemon forwarding to another (which is
im> > why
im> > im> I noticed).
im> > im>
im> > im> Was this an intentional behaviour change?
im> >
im> >  Sorry, it was broken due to another mismerge at r309933.  I fixed it
im> >  at r310278.  Can you try the latest one and let me know if the
im> >  problem still persists or not?
im>
im> No, it does not. "netstat -an -finet | grep 514" shows that it doesn't
im> listen on a UDP socket without adding "-b :syslog" to syslogd_flags in
im> /etc/rc.conf,

 Thank you for the report.  I misunderstood what was wrong and fixed
 it just now.  Please try r310310.

-- Hiroki


pgpHWw9jkbZNI.pgp
Description: PGP signature

Re: RFC: DTrace probes for debugging or testing in userland programs

[Hiroki Sato]

Adrian Chadd  wrote
  in :

ad> On 19 December 2016 at 16:04, Jordan Hubbard  
wrote:
ad> >
ad> > On Dec 19, 2016, at 12:27 PM, Adrian Chadd  wrote:
ad> >
ad> > So although I like the sentiment, I don't think using dtrace for
ad> > program logging is the right answer.  I like what apple did to wrap
ad> > the program logging stuff so people didn't just write their own
ad> > libraries (hi!) and so there's a unified-ish way to interact with
ad> > apple programs. I think we could do with that.
ad> >
ad> >
ad> > Thanks!
ad> >
ad> > We did a number of other things with ASL (Apple System Logger) which I 
miss
ad> > very much today and would hope to see in any FreeBSD equivalent:
ad> >
ad> > 1. We structured all log data into dictionaries, so every application 
and/or
ad> > subsystem within that application can add its own “tags” without squashing
ad> > other key information.  This also unified the character encoding format, 
so
ad> > some applications were no longer logging in ISO-Latin1, others in UTF-8 
and
ad> > yet others in SHIFT-JIS.
ad> >
ad> > 2.  There’s also a logging database, as one of the many possible “output
ad> > sinks”, so searches / queries are fast (and there’s an API for querying 
and
ad> > managing its contents).
ad> >
ad> > 3. We added client-side and server side logging filters, so you can “crank
ad> > an application up” or shut its mouth without having to make any code
ad> > changes.
ad> >
ad> > 4. It’s all thread-safe.
ad>
ad> Hm. Where's the ASL source hiding? I'm kinda hoping it's light weight
ad> enough to port over without porting a lot of other stuff, but I am
ad> also afraid it's Apple.. :)

 libsystem_asl at https://opensource.apple.com/source/syslog/syslog-349.1.1/?

-- Hiroki


pgpvxsYrhgSdj.pgp
Description: PGP signature

RFC: DTrace probes for debugging or testing in userland programs

[Hiroki Sato]

Hi,

 I am trying to rewrite userland programs (especially daemons) to
 support userland DTrace probes to make it possible to trace the
 behavior by using dtrace(1).  The purpose is to provide a consistent
 interface to enable/collect debug log and show internal states.  A
 lot of daemons define their own debug output function like dprintf()
 and there is no consistency of where to be recorded.

 I would like your comment about this change because I want to know
 whether this change (or direction) is acceptable or not.  I put an
 example by using syslogd at the following URL:

 (diff)
  https://people.freebsd.org/~hrs/syslogd_usdt.20161220-1.diff
 (tarball)
  https://people.freebsd.org/~hrs/syslogd_usdt.20161220-1.tar.gz

 You can try to compile a new syslogd, run it, and then attach
 dtrace(1) to the syslogd process by "dtrace -q -CI./
 -s ./syslogd_trace.d -p `pgrep syslogd`" in the same directory.

 Basically this change is invisible for normal users.  This includes
 some rough edges but I think it is sufficient to understand the
 concept.  I do not intend to commit this soon.

 Questions from me are the following:

  1. Where should foo_probes.d and foo_trace.d be installed?  And if
 they depend on foo.h, where should foo.h be?

  2. Is documenting probes into foo.8 reasonable?

 The details are as follows.

 * Rewrite example

  This rewrite is twofold.  First, simply replace a call of the
  logging function into DTrace USDT like this:

  (old) | dprintf("an error occurred, errno=%d\n", errno);

  (new) | FOO_LOG(LOG_ERR, "an error occurred, errno=%d\n", errno);

  And then if it involves a result of a specific operation, replace
  trace probes for the simple logging with dedicated ones:

  (old) | error = bind(s, res->ai_addr, res->ar_addrlen);
| if (error) {
| dprintf("bind failed, errno=%d\n", errno);
| close(s);
| return (-1);
| }

  (new)
| error = bind(s, res->ai_addr, res->ar_addrlen);
| if (error) {
| FOO_SOCK_BIND_FAILED(errno, s, res->ai_addr, res->ar_addrlen);
| close(s);
| return (-1);
| }
| FOO_SOCK_BIND_SUCCESS(s, res->ai_addr, res->ar_addrlen);

  and implement the functionality of the original log message in D
  script:

  | foo$target:::sock-bind-failed
  | {
  | printf("bind failed, errno=%d", arg0);
  | /* The other argN can be used to report in more detail. */
  | }

 * Additional files in the existing directory layout

  After this rewrite, the directory layout for a daemon "foo" will look
  like the following:

  | Makefile
  | foo.8
  | foo.c
  | foo.h
  | foo_probes.d
  | foo_trace.d

  foo_probes.d and foo_trace.d are added.  The former is the
  definition of USDT probes, and the latter is a D script example to
  reproduce the original debug log by dprintf() or something like
  that.  A section to describe what probes are available is added into
  foo.8.  One can trace the foo daemon using "dtrace -Cs foo_trace.d -p
  `pgrep foo`" on runtime, and also can create own script.

  foo.h may be added because foo_probes.d and foo_trace.d often require
  information of data structure used in foo.c.

 * Possible incompatible change

  A debug flag to activate additional logging is no longer necessary
  after this rewrite, so we can remove it (-d flag in the case of
  syslogd).  And dump of the internal state can be implemented as a
  SIGINFO handler.  In the syslogd example, SIGINFO dumps syslogd
  configuration and access control list.

-- Hiroki


pgpsvFjddX2bs.pgp
Description: PGP signature

Re: syslogd no longer listens (or sends) on a network socket

[Hiroki Sato]

Michael Butler  wrote
  in :

im> It appears that SVN r309925 and onward no longer opens a network
im> socket unless the command-line explicitly contains "-b :syslog" :-(
im>
im> This also stops one syslog daemon forwarding to another (which is why
im> I noticed).
im>
im> Was this an intentional behaviour change?

 Sorry, it was broken due to another mismerge at r309933.  I fixed it
 at r310278.  Can you try the latest one and let me know if the
 problem still persists or not?

-- Hiroki


pgpf4Oj4yUvUq.pgp
Description: PGP signature

Re: projects/ipfw: Consider using tcp/31982 in firewall_myservices.

[Hiroki Sato]

O. Hartmann ohart...@zedat.fu-berlin.de wrote
  in 20141020052804.7a5e1d50.ohart...@zedat.fu-berlin.de:

oh Having simply a number (the port) in rc.conf: firewall_myservices defined, 
I receive
oh during startup the message
oh
oh Consider using tcp/31982 in firewall_myservices.
oh
oh Doing so, ends up in a misconfiguration, because the rc.firewall script in 
/etc/ is
oh looking for 31982/tcp instead of the recommended tcp/31982.
oh
oh This is a typo.

 Oh, sorry.  Fixed in r273301.

-- Hiroki


pgpJuRzh_Cx4Q.pgp
Description: PGP signature

[CFT] multiple instance support in rc.d script

[Hiroki Sato]

[Please reply to freebsd-rc@]

Hi,

 I would like your feedback and testers of the attached patch.  This
 implements multiple instance support in rc.d scripts.  You can try it
 by replacing /etc/rc.subr with the attached one.

 More details are as follow.  Typically, an rc.d/foo script has the
 following structure and rc.conf variables:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable
   ...
   load_rc_command $name
   run_rc_command $*
   

   /etc/rc.conf:
   
   foo_enable=YES
   foo_flags=-f -l -a -g
   

 The above supports one instance for one script.  After replacing
 rc.subr, you can specify additional instances in rc.conf:

   /etc/rc.conf:
   
   foo_instances=one two

   foo_one_enable=YES
   foo_one_flags=-f -l -a -g

   foo_two_enable=YES
   foo_two_flags=-F -L -A -G
   

 $foo_instances defines instances by space-separated list of instance
 names, and rc.conf variables for them are something like
 ${name}_${instname}_enable.  The following command

  # service foo start

 starts foo_one and foo_two with the specified flags.  Instances can
 be specified in the following form:

  # service foo start:one

 or multiple instances in a particular order:

  # service foo start:two,one

 Basically, no change is required for the rc.d/foo script itself.
 However, there is a problem that default values of the instantiated
 variables are not defined.

 For example, if an rc.d/script uses $foo_mode, you need to define
 $foo_one_mode.  The default value of $foo_mode is usually defined in
 etc/defaults/rc.conf for rc.d scripts in the base system and :
 ${foo_mode:=value} idiom in scripts from Ports Collection.  So all
 of the variables should be defined for each instance, too.  As you
 noticed, this is not easy without editing the script itself.

 To alleviate this, set_rcvar() can be used:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable

   set_rcvar foo_enable YES Enable $name
   set_rcvar foo_program/tmp/test Command for $name
   ...
   load_rc_command $name
   run_rc_command $*
   

 The three arguments are varname, default value, and description.  If
 a variable is defined by set_rcvar(), default values instantiated
 variables will be set automatically---foo_one_program is set by
 foo_program if it is not defined.

 This approach still has another problem.  set_rcvar() is not
 supported in all branches, so a script using it does not work in old
 supported branches.  One solution which can be used for scripts in
 Ports Collection is adding both definitions before and after
 load_rc_command() until EoL of old branches like this:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable

   if type set_rcvar /dev/null 21; then
set_rcvar foo_enableYES Enable $name
set_rcvar foo_program   /tmp/test Command for $name
   fi
   ...
   load_rc_command $name

   # will be removed after all supported branches have set_rcvar().
   if ! type set_rcvar /dev/null 21; then
: ${foo_enable:=YES}
: ${foo_program:=/tmp/test}
for _i in $foo_instances; do
for _j in enable program; do
eval : \${foo_${_i}_enable:=\$foo_$_j}
done
done
   fi

   run_rc_command $*
   

 This is a bit ugly but should work fine.

 I am using this patch to invoke multiple named (caching
 server/contents server) and syslogd (local only/listens INET/INET6
 socket only) daemons.  While $foo_instances is designed as a
 user-defined knob, this can be applied to software which need to
 invoke multiple/different daemons which depend on each other in a
 script, too.

 I am feeling this patch still needs more careful review from others.
 Any comments are welcome.  Thank you.

-- Hiroki
Index: etc/rc.subr
===
--- etc/rc.subr	(revision 272976)
+++ etc/rc.subr	(working copy)
@@ -698,7 +698,10 @@
 #		start stop restart rcvar status poll ${extra_commands}
 #	If there's a match, run ${argument}_cmd or the default method
 #	(see below).
+#	_run_rc_command0() is the main routine and run_rc_command() is
+#	a wrapper to handle multiple instances.
 #
+#
 #	If argument has a given prefix, then change the operation as follows:
 #		Prefix	Operation
 #		--	-
@@ -755,6 +758,9 @@
 #
 #	${name}_nice	n	Nice level to run ${command} at.
 #
+#	${name}_pidfile	n	This to be used in /etc/rc.conf to override
+#${pidfile}.
+#
 #	${name}_user	n	User to run ${command} as, using su(1) if not
 #using ${name}_chroot.
 #Requires /usr to be mounted.
@@ -863,6 +869,57 @@
 #
 run_rc_command()
 {
+	local _act _instances _name _desc _rcvar
+
+	_act=$1
+	shift
+	eval _instances=\$${name}_instances
+
+	# Check if instance is specified, e.g. start:instance,
+	case ${_act%:*} in
+	$_act)	;;			# no instance specified
+	*)
+		_instances=$(echo ${_act#*:} | tr ,  )
+		_act=${_act%:*}
+	;;
+	esac
+
+	# Use 

Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory

[Hiroki Sato]

Ian FREISLICH i...@clue.co.za wrote
  in e1wgmte-nr...@clue.co.za:

ia Hiroki Sato wrote:
ia   Hm, how about the attached one?
ia 
ia   I think the cause is just a race when length of the sysctl's output
ia   is changed in kernel after the buffer allocation in userspace, not
ia   memory shortage.  Size of the routing table can quickly change.
ia
ia You are correct.  It's growing at about 9000 entries per second (I
ia wish it were faster).
ia
ia This is what the output looks like now.  I guess I'm not the average
ia case.

 Can you try the attached patch?  It will attempt to enlarge the
 buffer every retry.

-- Hiroki
Index: route.c
===
--- route.c	(revision 262313)
+++ route.c	(working copy)
@@ -69,6 +69,7 @@
 #include sysexits.h
 #include unistd.h
 #include err.h
+#include errno.h
 #include netstat.h

 #define	kget(p, d) (kread((u_long)(p), (char *)(d), sizeof (d)))
@@ -560,7 +561,7 @@
 	char *buf, *next, *lim;
 	struct rt_msghdr *rtm;
 	struct sockaddr *sa;
-	int fam = 0, ifindex = 0, size;
+	int fam = 0, ifindex = 0, size, count = 0;

 	struct ifaddrs *ifap, *ifa;
 	struct sockaddr_dl *sdl;
@@ -600,6 +601,7 @@

 	freeifaddrs(ifap);

+retry:
 	mib[0] = CTL_NET;
 	mib[1] = PF_ROUTE;
 	mib[2] = 0;
@@ -607,19 +609,27 @@
 	mib[4] = NET_RT_DUMP;
 	mib[5] = 0;
 	mib[6] = fibnum;
-	if (sysctl(mib, 7, NULL, needed, NULL, 0)  0) {
-		err(1, sysctl: net.route.0.%d.dump.%d estimate, af, fibnum);
+	if (sysctl(mib, nitems(mib), NULL, needed, NULL, 0)  0)
+		err(EX_OSERR, sysctl: net.route.0.%d.dump.%d estimate, af,
+		fibnum);
+	needed += PAGE_SIZE * (count + 1);
+	if ((buf = malloc(needed)) == NULL)
+		errx(EX_OSERR, malloc(%zd), needed);
+	if (sysctl(mib, nitems(mib), buf, needed, NULL, 0)  0) {
+		if (errno == ENOMEM  count++  20) {
+			warnx(Routing table grew, retrying);
+			sleep(1);
+			free(buf);
+			goto retry;
+		} else
+			err(EX_OSERR, sysctl: net.route.0.%d.dump.%d, af,
+			fibnum);
 	}
-
-	if ((buf = malloc(needed)) == 0) {
-		errx(2, malloc(%lu), (unsigned long)needed);
-	}
-	if (sysctl(mib, 6, buf, needed, NULL, 0)  0) {
-		err(1, sysctl: net.route.0.%d.dump.%d, af, fibnum);
-	}
 	lim  = buf + needed;
 	for (next = buf; next  lim; next += rtm-rtm_msglen) {
 		rtm = (struct rt_msghdr *)next;
+		if (rtm-rtm_version != RTM_VERSION)
+			continue;
 		/*
 		 * Peek inside header to determine AF
 		 */
@@ -632,6 +642,7 @@
 		}
 		p_rtentry_sysctl(rtm);
 	}
+	free(buf);
 }

 static void


pgpysH23oo8lh.pgp
Description: PGP signature

Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory

[Hiroki Sato]

Ian FREISLICH i...@clue.co.za wrote
  in e1wgkzk-gb...@clue.co.za:

ia Hi
ia
ia While recieving my routing table I used to be able to check how far
ia it got by counting the output netstat -rn.  It takes about 2 seconds
ia to recieve the routes from my route-server, but over a minute to
ia update the kernel routing table.
ia
ia I'm now getting this error until zebra completes route insertion.
ia
ia [firewall1.jnb1] ~ $ netstat -rn |wc -l
ia netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
ia1
ia [firewall1.jnb1] ~ $ netstat -rn |wc -l
ia   480446

 Perhaps does the attached patch fix this?

-- Hiroki
Index: usr.bin/netstat/route.c
===
--- usr.bin/netstat/route.c	(revision 262283)
+++ usr.bin/netstat/route.c	(working copy)
@@ -614,7 +614,7 @@
 	if ((buf = malloc(needed)) == 0) {
 		errx(2, malloc(%lu), (unsigned long)needed);
 	}
-	if (sysctl(mib, 6, buf, needed, NULL, 0)  0) {
+	if (sysctl(mib, 7, buf, needed, NULL, 0)  0) {
 		err(1, sysctl: net.route.0.%d.dump.%d, af, fibnum);
 	}
 	lim  = buf + needed;


pgpO9F0H0qp6s.pgp
Description: PGP signature

Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory

[Hiroki Sato]

Ian FREISLICH i...@clue.co.za wrote
  in e1wgltz-kf...@clue.co.za:

ia Hiroki Sato wrote:
ia  ia While recieving my routing table I used to be able to check how far
ia  ia it got by counting the output netstat -rn.  It takes about 2 seconds
ia  ia to recieve the routes from my route-server, but over a minute to
ia  ia update the kernel routing table.
ia  ia
ia  ia I'm now getting this error until zebra completes route insertion.
ia  ia
ia  ia [firewall1.jnb1] ~ $ netstat -rn |wc -l
ia  ia netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
ia  ia1
ia  ia [firewall1.jnb1] ~ $ netstat -rn |wc -l
ia  ia   480446
ia 
ia   Perhaps does the attached patch fix this?
ia
ia Sadly, not.

 Hm, how about the attached one?

 I think the cause is just a race when length of the sysctl's output
 is changed in kernel after the buffer allocation in userspace, not
 memory shortage.  Size of the routing table can quickly change.

-- Hiroki
Index: usr.bin/netstat/route.c
===
--- usr.bin/netstat/route.c	(revision 262283)
+++ usr.bin/netstat/route.c	(working copy)
@@ -69,6 +69,7 @@
 #include sysexits.h
 #include unistd.h
 #include err.h
+#include errno.h
 #include netstat.h

 #define	kget(p, d) (kread((u_long)(p), (char *)(d), sizeof (d)))
@@ -560,7 +561,7 @@
 	char *buf, *next, *lim;
 	struct rt_msghdr *rtm;
 	struct sockaddr *sa;
-	int fam = 0, ifindex = 0, size;
+	int fam = 0, ifindex = 0, size, count = 0;

 	struct ifaddrs *ifap, *ifa;
 	struct sockaddr_dl *sdl;
@@ -600,6 +601,7 @@

 	freeifaddrs(ifap);

+retry:
 	mib[0] = CTL_NET;
 	mib[1] = PF_ROUTE;
 	mib[2] = 0;
@@ -607,19 +609,24 @@
 	mib[4] = NET_RT_DUMP;
 	mib[5] = 0;
 	mib[6] = fibnum;
-	if (sysctl(mib, 7, NULL, needed, NULL, 0)  0) {
+	if (sysctl(mib, nitems(mib), NULL, needed, NULL, 0)  0)
 		err(1, sysctl: net.route.0.%d.dump.%d estimate, af, fibnum);
+	if ((buf = malloc(needed)) == NULL)
+		errx(2, malloc(%zd), needed);
+	if (sysctl(mib, nitems(mib), buf, needed, NULL, 0)  0) {
+		if (errno == ENOMEM  count++  20) {
+			warnx(Routing table grew, retrying);
+			sleep(1);
+			free(buf);
+			goto retry;
+		} else
+			err(1, sysctl: net.route.0.%d.dump.%d, af, fibnum);
 	}
-
-	if ((buf = malloc(needed)) == 0) {
-		errx(2, malloc(%lu), (unsigned long)needed);
-	}
-	if (sysctl(mib, 6, buf, needed, NULL, 0)  0) {
-		err(1, sysctl: net.route.0.%d.dump.%d, af, fibnum);
-	}
 	lim  = buf + needed;
 	for (next = buf; next  lim; next += rtm-rtm_msglen) {
 		rtm = (struct rt_msghdr *)next;
+		if (rtm-rtm_version != RTM_VERSION)
+			continue;
 		/*
 		 * Peek inside header to determine AF
 		 */


pgpQk6jd430IH.pgp
Description: PGP signature

Re: Using a swap file

[Hiroki Sato]

Rostislav Krasny rosti@gmail.com wrote
  in CANt7McGTBwintkopk=hevo5d4bvsyifwl_-q9uzna3pwbmm...@mail.gmail.com:

ro But I have no 'late' option in my /etc/fstab:
ro
ro root@saturn:~ # cat /etc/fstab
ro # DeviceMountpointFStypeOptionsDumpPass#
ro /dev/ada0s2a/ufsrw11
ro mdnoneswapsw,file=/swapfile00
ro
ro Then why 'swapon -a' (without -L) doesn't work? It's either buggy or 
confusing.

 After r255265 the option file= implies late.  It is because a
 file-backed swap space likely to be on a mounted filesystem after the
 swap line.

 I realized that that assumption was odd and confusing as you pointed
 out.  The user should specify a swap line with file= after the mount
 entry, and there is no problem with it.  I will fix it.

-- Hiroki


pgpHXbTi0H4Wb.pgp
Description: PGP signature

Re: Regression in 10.0-BETA1, mdconfig has changed its return code.

[Hiroki Sato]

Julian H. Stacey j...@berklix.com wrote
  in 201310230254.r9n2sld1067...@fire.js.berklix.net:

jh Regresssion in 10.0-BETA1, mdconfig -l -v return code changed from 0
jh to 255.  OK, its not specfied in manual, but has changed.
jh A test script I was using caught it:
jh http://www.berklix.com/~jhs/bin/sh/mdconfig_tst
jh Probably in next day or 2 I'll hack the C  send-pr.

 Does the attached patch fix it?

-- Hiroki
Index: sbin/mdconfig/mdconfig.c
===
--- sbin/mdconfig/mdconfig.c	(revision 256952)
+++ sbin/mdconfig/mdconfig.c	(working copy)
@@ -481,12 +481,18 @@
 		printf(\n);
 	/* XXX: Check if it's enough to clean everything. */
 	geom_stats_snapshot_free(sq);
-	if (((opt  OPT_UNIT)  (fflag == NULL)  ufound) ||
-	((opt  OPT_UNIT) == 0  (fflag != NULL)  ffound) ||
-	((opt  OPT_UNIT)  (fflag != NULL)  ufound  ffound))
-		return (0);
-	else
-		return (-1);
+	if (opt  OPT_UNIT) {
+		if (((fflag == NULL)  ufound) ||
+		((fflag == NULL)  (units != NULL)  ufound) ||
+		((fflag != NULL)  ffound) ||
+		((fflag != NULL)  (units != NULL)  ufound  ffound))
+			return (0);
+	} else if (opt  OPT_LIST) {
+		if ((fflag == NULL) ||
+		((fflag != NULL)  ffound))
+			return (0);
+	}
+	return (-1);
 }

 /*


pgpk_4KNOnPjY.pgp
Description: PGP signature

Re: RFC: support for first boot rc.d scripts

[Hiroki Sato]

Colin Percival cperc...@freebsd.org wrote
  in 525b258f.3030...@freebsd.org:

cp I've attached a very simple patch which makes /etc/rc:

cp +if ! [ -e /var/db/firstboot ]; then
cp +   skip=$skip -s firstboot
cp +fi

 At this stage, it is possible that /var/db does not exist because it
 is before rc.d/mountcritlocal.

-- Hiroki


pgpuB725TWmQM.pgp
Description: PGP signature

Problems with rc.d/jail change (Re: svn commit: r256256 - in head: . etc etc/defaults etc/rc.d share/man/man5 usr.sbin/jail)

[Hiroki Sato]

Remko Lodder re...@freebsd.org wrote
  in 4b2ecc28-4f63-448a-b99e-dc5215c5f...@freebsd.org:

re
re On Oct 11, 2013, at 4:12 PM, Steve Wills swi...@freebsd.org wrote:
re
re  I'm having the same issue.
re
re I am working with Hiroki to resolve this. So far his work seems to fix
re this, he will commit that as soon as we can reasonable think
re that this is OK (and it looks that way :))

 Let me summarize what I noticed so far:

  (1) A jail with jail_fdescfs_enable=YES fails to start.

  (2) A jail with multiple parameters in jail_parameters=... fails
  to start.

 (1) was fixed in r256385.  The attached patch should fix (2).  Please
 try it if you still have a problem.

 Jail configurations can be complex, so there may be some more cases
 which break the old behaviors.  Please send me your report if you
 have differences between before and after the rc.d/jail change.

-- Hiroki
Index: etc/rc.d/jail
===
--- etc/rc.d/jail	(revision 256385)
+++ etc/rc.d/jail	(working copy)
@@ -94,7 +94,7 @@
 #
 parse_options()
 {
-	local _j
+	local _j _p
 	_j=$1

 	_confwarn=0
@@ -234,7 +234,9 @@
 			\procfs ${_rootdir%/}/proc procfs rw 0 0\;
 		fi

-		echo 	${_parameters};
+		for _p in $_parameters; do
+			echo 	${_p%\;};
+		done

 		eval : \${jail_${_j}_mount_enable:=${jail_mount_enable:-NO}}
 		if checkyesno jail_${_j}_mount_enable; then


pgppWFigxE8N9.pgp
Description: PGP signature

CFT: rc.d/jail rewrite (was: jail configuration)

[Hiroki Sato]

[Please reply to freebsd-current@]

Hi,

 Can anyone who are using jail_* variables in rc.conf test the
 attached patch?

 On freebsd-arch@ there is a discussion about deprecating
 jail_jname_* variables in favor of jail.conf.  This rewrite is one
 to support the both in a backward compatible way.  I want to make
 sure if this does not break the existing configurations.

 The following is the entry in UPDATING:

+20131007:
+   The rc.d/jail script has been updated to support jail(8)
+   configuration file.  The jail_jname_* rc.conf(5) variables
+   for per-jail configuration are automatically converted to
+   /var/run/jail.jname.conf before the jail(8) utility is invoked.
+   This is transparently backward compatible.  See the below about some
+   incompatibilities.
+
+   These variables are now deprecated in favor of jail(8) configuration
+   file.  One can use rc.d/jail config jname command to generate
+   a jail(8) configuration file in /var/run/jail.jname.conf without
+   running the jail(8) utility.   The default pathname of the
+   configuration file is /etc/jail.conf and can be specified by
+   using $jail_conf or $jail_jname_conf variables.
+
+   Please note that jail_fdesc_enable and jail_procfs_enable are
+   not supported, and jail_devfs_ruleset accepts an integer at
+   this moment.  Please consider to use exec.fstab for the
+   additional mount and rewrite the ruleset name with an integer.

Dag-Erling Smørgrav d...@des.no wrote
  in 8638oerh39@nine.des.no:

de I didn't look at the patch very closely, but I see that you print a
de warning when you generate a configuration for an old-style jail while
de jail.conf exists.  I think you should *always* print that warning for
de every old-style jail so people will be reminded to convert.  We should
de also remove the examples from /etc/defaults/rc.conf and replace the
de documentation for jail_${_j}_* in rc.conf(5) with a short paragraph that
de says they are for compatibility only.

 Thank you for your feedback.  The warning message is always displayed
 in rc.d/jail start, and rc.conf(5) and defaults/rc.conf are updated
 in this patch.

-- Hiroki
Index: UPDATING
===
--- UPDATING	(revision 256090)
+++ UPDATING	(working copy)
@@ -31,6 +31,26 @@
 	disable the most expensive debugging functionality run
 	ln -s 'abort:false,junk:false' /etc/malloc.conf.)

+20131007:
+	The rc.d/jail script has been updated to support jail(8)
+	configuration file.  The jail_jname_* rc.conf(5) variables
+	for per-jail configuration are automatically converted to
+	/var/run/jail.jname.conf before the jail(8) utility is invoked.
+	This is transparently backward compatible.  See the below about some
+	incompatibilities.
+
+	These variables are now deprecated in favor of jail(8) configuration
+	file.  One can use rc.d/jail config jname command to generate
+	a jail(8) configuration file in /var/run/jail.jname.conf without
+	running the jail(8) utility.   The default pathname of the
+	configuration file is /etc/jail.conf and can be specified by
+	using $jail_conf or $jail_jname_conf variables.
+
+	Please note that jail_fdesc_enable and jail_procfs_enable are
+	not supported, and jail_devfs_ruleset accepts an integer at
+	this moment.  Please consider to use exec.fstab for the
+	additional mount and rewrite the ruleset name with an integer.
+
 20130930:
 	BIND has been removed from the base system.  If all you need
 	is a local resolver, simply enable and start the local_unbound
Index: etc/rc.d/jail
===
--- etc/rc.d/jail	(revision 256090)
+++ etc/rc.d/jail	(working copy)
@@ -8,81 +8,138 @@
 # BEFORE: securelevel
 # KEYWORD: nojail shutdown

-# WARNING: This script deals with untrusted data (the data and
-# processes inside the jails) and care must be taken when changing the
-# code related to this!  If you have any doubt whether a change is
-# correct and have security impact, please get the patch reviewed by
-# the FreeBSD Security Team prior to commit.
-
 . /etc/rc.subr

 name=jail
 rcvar=jail_enable

-start_precmd=jail_prestart
 start_cmd=jail_start
+start_postcmd=jail_warn
 stop_cmd=jail_stop
+config_cmd=jail_config
+console_cmd=jail_console
+status_cmd=jail_status
+extra_commands=config console status
+: ${jail_conf:=/etc/jail.conf}
+: ${jail_program:=/usr/sbin/jail}
+: ${jail_consolecmd:=/bin/sh}
+: ${jail_jexec:=/usr/sbin/jexec}
+: ${jail_jls:=/usr/sbin/jls}

-# init_variables _j
-#	Initialize the various jail variables for jail _j.
+need_dad_wait=
+
+# extact_var jail name param num defval
+#	Extract value from ${jail_$jail_$name} or ${jail_$name} and
+#	set it to $param.  If not defined, $defval is used.
+#	When $num is [0-9]*, ${jail_$jail_$name$num} are looked up and
+#	$param is set by using +=.
+#	When $num is YN or NY, the value is interpret as boolean.
+extract_var()
+{
+	

HEADS UP: s/time_second/time_uptime/ in sys/netinet6

[Hiroki Sato]

Hi,

 I just wanted to let you know that data structures in sys/netinet6
 now uses time_uptime instead of time_second.  This should not be
 user-visible, but if you notice there is something wrong with IPv6
 after r253970, please let me know.  Please do not forget to update
 rtsold(8), rtadvd(8), and ndp(8) together when you compile a new
 kernel.

-- Hiroki
---BeginMessage---
Author: hrs
Date: Mon Aug  5 20:13:02 2013
New Revision: 253970
URL: http://svnweb.freebsd.org/changeset/base/253970

Log:
  - Use time_uptime instead of time_second in data structures for
PF_INET6 in kernel.  This fixes various malfunction when the wall time
clock is changed.  Bump __FreeBSD_version to 141.

  - Use clock_gettime(CLOCK_MONOTONIC_FAST) in userland utilities.

  MFC after:1 month

Modified:
  head/sys/netinet6/icmp6.c
  head/sys/netinet6/in6.c
  head/sys/netinet6/in6.h
  head/sys/netinet6/ip6_forward.c
  head/sys/netinet6/ip6_id.c
  head/sys/netinet6/ip6_mroute.c
  head/sys/netinet6/nd6.c
  head/sys/netinet6/nd6_rtr.c
  head/sys/sys/param.h
  head/usr.sbin/ndp/ndp.c
  head/usr.sbin/rtadvctl/rtadvctl.c
  head/usr.sbin/rtadvd/config.c
  head/usr.sbin/rtadvd/rrenum.c
  head/usr.sbin/rtadvd/rtadvd.c
  head/usr.sbin/rtadvd/rtadvd.h
  head/usr.sbin/rtadvd/timer.c
  head/usr.sbin/rtadvd/timer.h
  head/usr.sbin/rtadvd/timer_subr.c
  head/usr.sbin/rtadvd/timer_subr.h
  head/usr.sbin/rtsold/dump.c
  head/usr.sbin/rtsold/rtsol.c
  head/usr.sbin/rtsold/rtsold.c
  head/usr.sbin/rtsold/rtsold.h

Modified: head/sys/netinet6/icmp6.c
==
--- head/sys/netinet6/icmp6.c   Mon Aug  5 19:42:03 2013(r253969)
+++ head/sys/netinet6/icmp6.c   Mon Aug  5 20:13:02 2013(r253970)
@@ -1931,8 +1931,8 @@ ni6_store_addrs(struct icmp6_nodeinfo *n
ltime = ND6_INFINITE_LIFETIME;
else {
if (ifa6-ia6_lifetime.ia6t_expire 
-   time_second)
-   ltime = 
htonl(ifa6-ia6_lifetime.ia6t_expire - time_second);
+   time_uptime)
+   ltime = 
htonl(ifa6-ia6_lifetime.ia6t_expire - time_uptime);
else
ltime = 0;
}

Modified: head/sys/netinet6/in6.c
==
--- head/sys/netinet6/in6.c Mon Aug  5 19:42:03 2013(r253969)
+++ head/sys/netinet6/in6.c Mon Aug  5 20:13:02 2013(r253970)
@@ -523,12 +523,12 @@ in6_control(struct socket *so, u_long cm
/* sanity for overflow - beware unsigned */
lt = ifr-ifr_ifru.ifru_lifetime;
if (lt-ia6t_vltime != ND6_INFINITE_LIFETIME 
-   lt-ia6t_vltime + time_second  time_second) {
+   lt-ia6t_vltime + time_uptime  time_uptime) {
error = EINVAL;
goto out;
}
if (lt-ia6t_pltime != ND6_INFINITE_LIFETIME 
-   lt-ia6t_pltime + time_second  time_second) {
+   lt-ia6t_pltime + time_uptime  time_uptime) {
error = EINVAL;
goto out;
}
@@ -632,12 +632,12 @@ in6_control(struct socket *so, u_long cm
/* for sanity */
if (ia-ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) {
ia-ia6_lifetime.ia6t_expire =
-   time_second + ia-ia6_lifetime.ia6t_vltime;
+   time_uptime + ia-ia6_lifetime.ia6t_vltime;
} else
ia-ia6_lifetime.ia6t_expire = 0;
if (ia-ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) {
ia-ia6_lifetime.ia6t_preferred =
-   time_second + ia-ia6_lifetime.ia6t_pltime;
+   time_uptime + ia-ia6_lifetime.ia6t_pltime;
} else
ia-ia6_lifetime.ia6t_preferred = 0;
break;
@@ -1140,7 +1140,7 @@ in6_update_ifa(struct ifnet *ifp, struct
ia-ia_ifa.ifa_addr = (struct sockaddr *)ia-ia_addr;
ia-ia_addr.sin6_family = AF_INET6;
ia-ia_addr.sin6_len = sizeof(ia-ia_addr);
-   ia-ia6_createtime = time_second;
+   ia-ia6_createtime = time_uptime;
if ((ifp-if_flags  (IFF_POINTOPOINT | IFF_LOOPBACK)) != 0) {
/*
 * XXX: some functions expect that ifa_dstaddr is not
@@ -1167,7 +1167,7 @@ in6_update_ifa(struct ifnet *ifp, struct
}

/* update timestamp */
-   ia-ia6_updatetime = time_second;
+   ia-ia6_updatetime = time_uptime;

/* set prefix mask */

Re: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918

[Hiroki Sato]

Sam Fourman Jr. sfour...@gmail.com wrote
  in caoff+z1tpbbkuge2rerqaphdmpkocbfxz-bf9agvhgq4j56...@mail.gmail.com:

sf could someone help me figure out why this machine kernel paniced?
sf I have a full crashdump file if needed,
sf this machine is configured as a Firewall and wifi hostap running pf in a
sf small office

...

sf #7  0x809937a8 in in6_tmpaddrtimer (arg=0xfe00170fc0b6) at
sf /usr/src/sys/netinet6/in6_ifattach.c:935
sf #8  0x8085140a in softclock_call_cc (c=0x81325210,
sf cc=0x8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674

 Can you try to update the kernel to r253950 or later?  This is
 probably because one of my recent commits broke IPv6 temporary
 address timer on non-IPv6 interfaces.

-- Hiroki


pgpSizRfnM0Ys.pgp
Description: PGP signature

Re: NMI on shutdown

[Hiroki Sato]

Sean Bruno sean_br...@yahoo.com wrote
  in 1374942794.1431.37.camel@localhost:

se :-)  I just spent the week looking at something that looks like this on
se my Dell machines.  In my testing the NMI EISA problem seems to be coming
se from the fact that IPMI pokes at both the ACPI and ISA interfaces to the
se IPMI controller resulting in an attempt to create /dev/ipmi0
se and /dev/ipmi1.
se
se Somewhere in the recent past (affects 9 as well) the ACPI and ISA IPMI
se device nodes where children of the same parent and
se ipmi_isa.c::ipmi_isa_identitfy() would see the ACPI attachment and do
se nothing.  Now the two interfaces have different parents in the device
se tree.
se
se On bce(4) based systems, even if not using IPMI, this seems to
se crash/confuse older version of the management firmware and yield results
se similar to what you see.
se
se I've just commited a tested fix from Yahoo on this that Peter and I
se worked out.  see svn R 253708

 Hmm, in my case the symptom does not depend on ipmi(4) (ipmi.ko was
 not loaded).  I tried the patch in r253708 on stable/9 in both cases
 of loading the ipmi.ko or not loading it, but there was no
 difference.

 Did NMI happen on you box only when ipmi.ko was loaded?

-- Hiroki


pgpXSynOzLDPB.pgp
Description: PGP signature

NMI on shutdown

[Hiroki Sato]

Hi,

 The following log messages are displayed on a box where I am testing
 stable/9.  It occurs only when trying to shutdown the box:

 | Waiting (max 60 seconds) for system process `vnlru' to stop...done
 | Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
 | Waiting (max 60 seconds) for system process `syncer' to stop...
 | Syncing disks, vnodes remaining...2 2 0 0 done
 | All buffers synced.
 | Uptime: 8d2h4m58s
 | NMI ISA 30, EISA 0
 | NMI ISA 20, EISA 0
 | NMI ... going to debugger
 | NMI ... going to debugger
 | NMI ISA 20, EISA 0
 | NMI ISA 30, EISA 0
 | NMI ... going to debugger
 | NMI ... going to debugger
 | NMI ISA 20, EISA 0
 ...
 | timeout stopping cpus
 | [ thread pid 11 tid 100016 ]
 | Stopped at  acpi_cpu_c1+0x6:leave
 | db timeout stopping cpus
 | timeout stopping cpus
 | [ thread pid 11 tid 100015 ]
 | Stopped at  acpi_cpu_c1+0x6:leave
 | db timeout stopping cpus
 | timeout stopping cpus

 Once these are displayed, a power cycle is required to recover.
 Shutdown sometimes works, and sometimes not.  DDB prompt does not
 work because it does not accept entered characters properly.  And,
 this symptom seems not specific to stable/9.

 This may be a hardware specific issue, but where should I start to
 debug this from?

-- Hiroki


pgpNAB4RqeDZn.pgp
Description: PGP signature

Re: CFT: cloned_interfaces and gifconfig in rc.d/netif

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130722.024513.95685108976349294@allbsd.org:

hr Hi,
hr
hr  The attached patch allows rc.d/netif to create IFs in
hr  $cloned_interfaces when interface name(s) is specified.  For example,
hr  when the following lines are in rc.conf:
hr
hr   cloned_interfaces=bridge0 bridge1
hr   ifconfig_bridge0=...
hr   ifconfig_bridge1=...
hr
hr  The following commands create the interfaces and destroy them.
hr
hr   # /etc/rc.d/netif start bridge0 bridge1
hr   # /etc/rc.d/netif stop bridge0 bridge1
hr
hr  netif cloneup/clonedown does this without the patch, but it cannot
hr  configure the interfaces and does not support clean teardown.
hr
hr  Also, routines which handle $gif_interfaces are merged into ones for
hr  $cloned_interfaces.  ifconfig_gifN and other variants did not work
hr  with gif interfaces defined in $gif_interfaces.  The patch solves
hr  this issue.
hr
hr  Basically there should be no functionality regression for the
hr  existing configurations.  Can anyone who are using $gif_interfaces
hr  and/or $cloned_interfaces test this?  I would like to know if there is
hr  regression or not.

 A revised version based on feedback which I received in private
 emails is attached.  This includes rc.conf(5) change explaining the
 new variables.  The following is a brief description of the changes:

-
- Reimplement gif_interfaces as a variant of $cloned_interfaces.
  Newly-configured systems should use $cloned_interfaces.

- Call clone_{up,down}() in rc.d/netif {start,stop}.

- Add rc.d/netif clear.  The clear argument is basically equivalent to
  stop but it does not call clone_down().

- Add ifname:sticky keyword into $cloned_interfaces.  If :sticky is
  specified, the interface will not be destroyed in rc.d/netif stop.

- Add cloned_interfaces_sticky={YES,NO}.  This variable globally sets
  :sticky keyword above for all interfaces.  The default value is NO.


-- Hiroki
- Reimplement gif_interfaces as a variant of $cloned_interfaces.
  Newly-configured systems should use $cloned_interfaces.

- Call clone_{up,down}() in rc.d/netif {start,stop}.

- Add rc.d/netif clear.  The clear argument is basically equivalent to
  stop but it does not call clone_down().

- Add ifname:sticky keyword into $cloned_interfaces.  If :sticky is
  specified, the interface will not be destroyed in rc.d/netif stop.

- Add cloned_interfaces_sticky={YES,NO}.  This variable globally sets
  :sticky keyword above for all interfaces.  The default value is NO.

MFC after:  3 days

Index: etc/network.subr
===
--- etc/network.subr	(revision 253520)
+++ etc/network.subr	(working copy)
@@ -660,6 +660,11 @@ ipv4_down()
 	IFS=$_ifs
 	for _inet in $inetList ; do
 		# get rid of extraneous line
+		case $_inet in
+		)		break ;;
+		inet\ *)	;;
+		*)		continue ;;
+		esac
 		[ -z $_inet ]  break

 		_inet=`expr $_inet : '.*\(inet \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*'`
@@ -1192,12 +1197,23 @@ ifscript_down()
 #
 clone_up()
 {
-	local _prefix _list ifn
+	local _prefix _list ifn ifopt _iflist _n tmpargs
 	_prefix=
 	_list=
+	_iflist=$*

 	# create_args_IF
 	for ifn in ${cloned_interfaces}; do
+		# Parse ifn:ifopt.
+		OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS
+		case $_iflist in
+		|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn)	;;
+		*)	continue ;;
+		esac
+		# Skip if ifn already exists.
+		if ${IFCONFIG_CMD} $ifn  /dev/null 21; then
+			continue
+		fi
 		${IFCONFIG_CMD} ${ifn} create `get_if_var ${ifn} create_args_IF`
 		if [ $? -eq 0 ]; then
 			_list=${_list}${_prefix}${ifn}
@@ -1204,6 +1220,39 @@ clone_up()
 			[ -z $_prefix ]  _prefix=' '
 		fi
 	done
+	if [ -n $gif_interfaces ]; then
+		warn \$gif_interfaces is obsolete.  Use \$cloned_interfaces instead.
+	fi
+	for ifn in ${gif_interfaces}; do
+		# Parse ifn:ifopt.
+		OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS
+		case $_iflist in
+		|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn)	;;
+		*)	continue ;;
+		esac
+		# Skip if ifn already exists.
+		if ${IFCONFIG_CMD} $ifn  /dev/null 21; then
+			continue
+		fi
+		case $ifn in
+		gif[0-9]*)
+			${IFCONFIG_CMD} $ifn create
+		;;
+		*)
+			_n=$(${IFCONFIG_CMD} gif create)
+			${IFCONFIG_CMD} $_n name $ifn
+		;;
+		esac
+		if [ $? -eq 0 ]; then
+			_list=${_list}${_prefix}${ifn}
+			[ -z $_prefix ]  _prefix=' '
+		fi
+		tmpargs=$(get_if_var $ifn gifconfig_IF)
+		eval ifconfig_${ifn}=\tunnel \$tmpargs\
+	done
+	if [ -n ${_list} ]; then
+		echo Created clone interfaces: ${_list}.
+	fi
 	debug Cloned: ${_list}
 }

@@ -1213,11 +1262,29 @@ clone_up()
 #
 clone_down()
 {
-	local _prefix _list ifn
+	local _prefix _list ifn ifopt _iflist
 	_prefix=
 	_list=
+	_iflist=$*

-	for ifn in ${cloned_interfaces}; do
+	: ${cloned_interfaces_sticky:=NO}
+	if checkyesno cloned_interfaces_sticky; then
+		return 1
+	fi
+	for ifn in ${cloned_interfaces} ${gif_interfaces}; do
+		# Parse ifn:ifopt.
+		OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS

CFT: cloned_interfaces and gifconfig in rc.d/netif

[Hiroki Sato]

Hi,

 The attached patch allows rc.d/netif to create IFs in
 $cloned_interfaces when interface name(s) is specified.  For example,
 when the following lines are in rc.conf:

  cloned_interfaces=bridge0 bridge1
  ifconfig_bridge0=...
  ifconfig_bridge1=...

 The following commands create the interfaces and destroy them.

  # /etc/rc.d/netif start bridge0 bridge1
  # /etc/rc.d/netif stop bridge0 bridge1

 netif cloneup/clonedown does this without the patch, but it cannot
 configure the interfaces and does not support clean teardown.

 Also, routines which handle $gif_interfaces are merged into ones for
 $cloned_interfaces.  ifconfig_gifN and other variants did not work
 with gif interfaces defined in $gif_interfaces.  The patch solves
 this issue.

 Basically there should be no functionality regression for the
 existing configurations.  Can anyone who are using $gif_interfaces
 and/or $cloned_interfaces test this?  I would like to know if there is
 regression or not.

-- Hiroki
Index: etc/network.subr
===
--- etc/network.subr	(revision 253520)
+++ etc/network.subr	(working copy)
@@ -660,6 +660,11 @@
 	IFS=$_ifs
 	for _inet in $inetList ; do
 		# get rid of extraneous line
+		case $_inet in
+		)		break ;;
+		inet\ *)	;;
+		*)		continue ;;
+		esac
 		[ -z $_inet ]  break

 		_inet=`expr $_inet : '.*\(inet \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*'`
@@ -1192,12 +1197,17 @@
 #
 clone_up()
 {
-	local _prefix _list ifn
+	local _prefix _list ifn _iflist _n tmpargs
 	_prefix=
 	_list=
+	_iflist=$*

 	# create_args_IF
 	for ifn in ${cloned_interfaces}; do
+		case $_iflist in
+		|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn)	;;
+		*)	continue ;;
+		esac
 		${IFCONFIG_CMD} ${ifn} create `get_if_var ${ifn} create_args_IF`
 		if [ $? -eq 0 ]; then
 			_list=${_list}${_prefix}${ifn}
@@ -1204,6 +1214,30 @@
 			[ -z $_prefix ]  _prefix=' '
 		fi
 	done
+	if [ -n $gif_interfaces ]; then
+		warn \$gif_interfaces is obsolete.  Use \$cloned_interfaces instead.
+	fi
+	for ifn in ${gif_interfaces}; do
+		case $_iflist in
+		|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn)	;;
+		*)	continue ;;
+		esac
+		case $ifn in
+		gif[0-9]*)
+			${IFCONFIG_CMD} $ifn create
+		;;
+		*)
+			_n=$(${IFCONFIG_CMD} gif create)
+			${IFCONFIG_CMD} $_n name $ifn
+		;;
+		esac
+		if [ $? -eq 0 ]; then
+			_list=${_list}${_prefix}${ifn}
+			[ -z $_prefix ]  _prefix=' '
+		fi
+		tmpargs=$(get_if_var $ifn gifconfig_IF)
+		eval ifconfig_${ifn}=\tunnel \$tmpargs\
+	done
 	debug Cloned: ${_list}
 }

@@ -1213,11 +1247,16 @@
 #
 clone_down()
 {
-	local _prefix _list ifn
+	local _prefix _list ifn _iflist
 	_prefix=
 	_list=
+	_iflist=$*

-	for ifn in ${cloned_interfaces}; do
+	for ifn in ${cloned_interfaces} ${gif_interfaces}; do
+		case $_iflist in
+		|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn)	;;
+		*)	continue ;;
+		esac
 		${IFCONFIG_CMD} -n ${ifn} destroy
 		if [ $? -eq 0 ]; then
 			_list=${_list}${_prefix}${ifn}
@@ -1224,6 +1263,9 @@
 			[ -z $_prefix ]  _prefix=' '
 		fi
 	done
+	if [ -n ${_list} ]; then
+		echo Destroyed clone interfaces: ${_list}.
+	fi
 	debug Destroyed clones: ${_list}
 }

@@ -1347,32 +1389,6 @@
 	done
 }

-# gif_up
-#	Create gif(4) tunnel interfaces.
-gif_up()
-{
-	local i peers
-
-	for i in ${gif_interfaces}; do
-		peers=`get_if_var $i gifconfig_IF`
-		case ${peers} in
-		'')
-			continue
-			;;
-		*)
-			if expr $i : 'gif[0-9][0-9]*$' /dev/null 21; then
-${IFCONFIG_CMD} $i create /dev/null 21
-			else
-gif=`${IFCONFIG_CMD} gif create`
-${IFCONFIG_CMD} $gif name $i
-			fi
-			${IFCONFIG_CMD} $i tunnel ${peers}
-			${IFCONFIG_CMD} $i up
-			;;
-		esac
-	done
-}
-
 # ng_fec_create ifn
 #	Configure Fast EtherChannel for interface $ifn. Returns 0 if
 #	FEC arguments were found and configured; returns !0 otherwise.
Index: etc/rc.d/netif
===
--- etc/rc.d/netif	(revision 253505)
+++ etc/rc.d/netif	(working copy)
@@ -60,18 +60,15 @@
 		# disable SIGINT (Ctrl-c) when running at startup
 		trap : 2

-		# Create cloned interfaces
-		clone_up
-
 		# Create Fast EtherChannel interfaces
 		fec_up
+	fi

-		# Create IPv6--IPv4 tunnels
-		gif_up
+	# Create cloned interfaces
+	clone_up $cmdifn

-		# Rename interfaces.
-		ifnet_rename
-	fi
+	# Rename interfaces.
+	ifnet_rename $cmdifn

 	# Configure the interface(s).
 	network_common ifn_start
@@ -101,6 +98,9 @@
 	# Deconfigure the interface(s)
 	network_common ifn_stop

+	# Destroy cloned interfaces
+	clone_down $cmdifn
+
 	if [ -f /etc/rc.d/routing -a -n $cmdifn ] ; then
 		for _if in $cmdifn; do
 			/etc/rc.d/routing stop any $_if


pgpTrmINvZNat.pgp
Description: PGP signature

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Hiroki Sato]

Michael Grimm trash...@odo.in-berlin.de wrote
  in 4c07217dc9200841dfd065a6d5284...@mx1.enfer-du-nord.net:

tr On 2013-07-12 6:56, Hiroki Sato wrote:
tr  Kevin Oberman rkober...@gmail.com wrote
trin can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com:
tr  rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote:
tr  rk
tr  rk  On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm 
tr  rk  trash...@odo.in-berlin.de wrote:
tr  rk 
tr  rk   Will that patch make it into 9.2? If I am not mistaken, that patch 
isn't
tr  rk  in stable yet.
tr  rk 
tr  rk 
tr  rk  I would also like to see this patch hit 9.x sooner than later. It's 
so
tr  rk  painful when someone forgets to fix the alias numbering on servers 
with
tr  rk  many, many IPv4 and IPv6 addresses...
tr  rk 
tr  rk
tr  rk Please, please, please, please, ...!
tr  rk
tr  rk Freeze is only two days away, so time for 9.2 is almost over and I 
can see
tr  rk no good reason NOT to get this done.
tr   r252015 was merged to stable/9 today.
tr
tr Thanks! This is highly appreciated. A first glance at network.subr tells me 
that
tr much more has been modified/simplified regarding alias definitions, great.

 Please let me know if the existing configurations and/or the new
 formats do not work.  The following is a summary of the supported
 rc.conf variables, FYI:

Hiroki Sato h...@freebsd.org wrote
  in 201306200229.r5k2tnfr085...@svn.freebsd.org:

hr   A summary of the supported ifconfig_* variables is as follows:
hr
hr# IPv4 configuration.
hrifconfig_em0=inet 192.168.0.1
hr# IPv6 configuration.
hrifconfig_em0_ipv6=inet6 2001:db8::1/64
hr# IPv4 address range spec.  Now deprecated.
hripv4_addr_em0=10.2.1.1-10
hr# IPv6 alias.
hrifconfig_em0_alias0=inet6 2001:db8:5::1 prefixlen 70
hr# IPv4 alias.
hrifconfig_em0_alias1=inet 10.2.2.1/24
hr# IPv4 alias with range spec w/o AF keyword (backward compat).
hrifconfig_em0_alias2=10.3.1.1-10/32
hr# IPv6 alias with range spec.
hrifconfig_em0_alias3=inet6 2001:db8:20-2f::1/64
hr# ifconfig_IF_aliases is just like ifconfig_IF_aliasN.
hrifconfig_em0_aliases=inet 10.3.3.201-204/24 inet6 
2001:db8:210-213::1/64 inet 10.1.1.1/24
hr# IPv6 alias (backward compat)
hripv6_ifconfig_em0_alias0=inet6 2001:db8:f::1/64
hr# IPv6 alias w/o AF keyword (backward compat)
hripv6_ifconfig_em0_alias1=2001:db8:f:1::1/64
hr# IPv6 prefix.
hripv6_prefix_em0=2001:db8::/64

-- Hiroki


pgphvaD2aj_hG.pgp
Description: PGP signature

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Hiroki Sato]

Kevin Oberman rkober...@gmail.com wrote
  in can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com:

rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote:
rk
rk  On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm 
rk  trash...@odo.in-berlin.de wrote:
rk 
rk   Will that patch make it into 9.2? If I am not mistaken, that patch isn't
rk  in stable yet.
rk 
rk 
rk  I would also like to see this patch hit 9.x sooner than later. It's so
rk  painful when someone forgets to fix the alias numbering on servers with
rk  many, many IPv4 and IPv6 addresses...
rk 
rk
rk Please, please, please, please, ...!
rk
rk Freeze is only two days away, so time for 9.2 is almost over and I can see
rk no good reason NOT to get this done.

 r252015 was merged to stable/9 today.

-- Hiroki


pgpwhHHP9UTVY.pgp
Description: PGP signature

Re: chroots/jails in jails

[Hiroki Sato]

Julian Elischer jul...@freebsd.org wrote
  in 51dc0054.2040...@freebsd.org:

ju I'm making a build system for a project which creates a chroot in
ju which to do some of the building to avoid base-system contamination
ju (yeah I know lots of people do that).
ju the trick is that my test system is itself, a jail.
ju So I can not mount /dev in the chroot.
ju
ju I can not predict where a build will occur so I can not pre-mount the
ju devfs from outside the jail. (users may fire off builds in different
ju locations)
ju
ju Does anyone have any solution to this problem?
ju
ju We have hierarchical jails, but no way of allowing the parent jail to
ju give the child jail a devfs.
ju
ju Has anyone looked at what it would take to make devfs jail friendly?
ju
ju I'm guessing that the jail would have to get some devfs-rule parameter
ju and that mount_devfs or it's in-kernel parts would have to know what
ju to do..
ju
ju seems like there should be someone out there who has hit this.. (and
ju solved it?)

 Allowing to mount devfs inside hierarchical jails should work like
 the following:

 # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 children.max=10 
path=/ name=j1 persist
 # jexec j1 /bin/tcsh
 # mkdir /tmp/dev1
 # mount -t devfs devfs /tmp/dev1
 # jail -c allow.mount.devfs=1 allow.mount=1 enforce_statfs=1 path=/ name=j2 
persist
 # jexec j2 /bin/tcsh
 # mkdir /tmp/dev2
 # mount -t devfs devfs /tmp/dev2

-- Hiroki


pgpWirjqA6819.pgp
Description: PGP signature

Re: network.subr (r252360) changes break ifconfig_aliasX

[Hiroki Sato]

Ian FREISLICH i...@clue.co.za wrote
  in e1utcrl-00054r...@clue.co.za:

ia Hi
ia
ia I can't figure out how to use rc.conf to configure my interfaces
ia after these recent charges.  My use case is that I have interfaces
ia to configure but I don't need to put an IP address on them.  I do
ia need to change the MAC address though.

 Please try r252426.

-- Hiroki


pgpPp9RCG9oqY.pgp
Description: PGP signature

Proposal: multi-instance and self-contained rc.d script

[Hiroki Sato]

 the section of run_rc_command() in the rc(8) manual page.

CONFIGURATION VARIABLES
 The following rc.conf(5) variables are supported.  To show all of the
 supported variables and the default values, use rcvar argument:

 routed_enable (bool) Set to ``YES'' to start the routed(8) daemon
   at boot time.

 routed_flags  (str) Specify command line flags to the routed(8)
   daemon.

SEE ALSO
 rc.conf(5), rc(8), routed(8)

HISTORY
 The routed script appeared in FreeBSD 8.0.

AUTHORS
 This manual page was written by Hiroki Sato h...@freebsd.org.

FreeBSD 10.0   January 26, 2012   FreeBSD 10.0
Index: etc/rc.d/routed
===
--- etc/rc.d/routed	(revision 252378)
+++ etc/rc.d/routed	(working copy)
@@ -13,6 +13,10 @@ name=routed
 rcvar=routed_enable
 desc=network RIP and router discovery routing daemon

+set_rcvar enable	NO
+set_rcvar program	/sbin/routed
+set_rcvar flags		-q
+
 set_rcvar_obsolete router_enable routed_enable
 set_rcvar_obsolete router routed_program
 set_rcvar_obsolete router_flags	routed_flags
Index: etc/rc.subr
===
--- etc/rc.subr	(revision 252378)
+++ etc/rc.subr	(working copy)
@@ -54,6 +54,21 @@ JID=`$PS -p $$ -o jid=`
 #	functions
 #	-

+# set_rcvar [var] [defval]
+#	Define rc.conf variable.
+#
+set_rcvar()
+{
+	case $# in
+	0)	echo $name
+	;;
+	1)	eval rcvars=\${rcvars# } $1\
+	;;
+	2)	eval rcvars=\${rcvars# } $1\
+		eval ${rcvar%_enable}_${1}_defval=\$2\
+	;;
+	esac
+}
 # set_rcvar_obsolete oldvar [newvar] [msg]
 #	Define obsolete variable.
 #	Global variable $rcvars_obsolete is used.
@@ -570,6 +585,39 @@ check_startmsgs()
 #
 run_rc_command()
 {
+	local _act _instances _inst _name _desc _rcvar
+
+	_act=$1
+	shift
+	eval _instances=\DEFAULT \$${name}_instances\
+	_name=$name
+	_desc=$desc
+	_rcvar=$rcvar
+
+	# Use reverse order for stop.
+	case $_act in
+	*stop)	_instances=$(reverse_list $_instances) ;;
+	esac
+
+	for _inst in $_instances; do
+		case $_inst in
+		DEFAULT)
+			name=$_name
+			desc=$_desc
+			rcvar=$_rcvar
+		;;
+		*)
+			name=${_name}_${_inst}
+			eval desc=\$_desc\${${_name}_${_inst}_desc+:\ }\$${_name}_${_inst}_desc\
+			rcvar=${_rcvar%_enable}_${_inst}_enable
+		;;
+		esac
+		_run_rc_command0 $_act $@
+	done
+}
+
+_run_rc_command0()
+{
 	_return=0
 	rc_arg=$1
 	if [ -z $name ]; then
@@ -823,47 +871,25 @@ $command $rc_flags $command_args
 			;;

 		rcvar)
-			echo -n # $name
-			if [ -n $desc ]; then
-echo  : $desc
-			else
-echo 
-			fi
+			echo # $name${desc+: }${desc}
 			echo #
 			# Get unique vars in $rcvar
-			for _v in $rcvar; do
-case $v in
-$_v\ *|\ *$_v|*\ $_v\ *) ;;
-*)	v=${v# } $_v ;;
-esac
+			v=
+			for _v in $(uniqlist ${rcvar%_enable} $rcvars $_rc_namevarlist); do
+if [ $_v = instances ]; then
+	continue
+fi
+v=${v# } ${name}_$_v
 			done

 			# Display variables.
 			for _v in $v; do
-if [ -z $_v ]; then
+eval __v=\$$_v
+eval _defval=\$${_v}_defval
+if [ -z $__v -a $__v = $_defval ]; then
 	continue
 fi
-
-eval _desc=\$${_v}_desc
-eval _defval=\$${_v}_defval
-_h=-
-
-eval echo \$_v=$$_v
-# decode multiple lines of _desc
-while [ -n $_desc ]; do
-	case $_desc in
-	*^^*)
-		echo # $_h ${_desc%%^^*}
-		_desc=${_desc#*^^}
-		_h= 
-		;;
-	*)
-		echo # $_h ${_desc}
-		break
-		;;
-	esac
-done
-echo #   (default: \$_defval\)
+echo ${_v}=\$__v\${_defval:+\	# (default: \$_defval\)}
 			done
 			echo 
 			;;
@@ -1004,11 +1030,55 @@ run_rc_script()
 }

 #
+# uniqlist
+#	Return a list with duplicate words removed.
+#
+uniqlist()
+{
+	local v _v
+
+	v=
+	for _v in $@; do
+		case $v in
+		$_v\ *|\ *$_v|*\ $_v\ *) ;;
+		*)	v=${v# } $_v ;;
+		esac
+	done
+	echo $v
+}
+
+#
 # load_rc_config name
 #	Source in the configuration file for a given name.
 #
 load_rc_config()
 {
+	local _instances _inst _name _k _v
+
+	_name=$1
+	_load_rc_config0 $_name
+
+	eval _instances=\$${_name}_instances
+
+	for _inst in $_instances; do
+		_load_rc_config0 ${_name}_${_inst}
+
+		# Set default values by using $name.
+		for _k in $(uniqlist $rcvars $_rc_namevarlist); do
+			if [ $_k = instances ]; then
+continue
+			fi
+			eval : \${${_name}_${_inst}_${_k}=\$${_name}_${_k}}
+			eval : \${${_name}_${_inst}_${_k}_defval=\$${_name}_${_k}_defval}
+#			eval echo DEBUG ${_name}_${_inst}_${_k}=\$${_name}_${_inst}_${_k}
+		done
+#		eval echo DEBUG ${rcvar%_enable}_${_inst}_enable=\$${rcvar%_enable}_${_inst}_enable
+		eval : \${${rcvar%_enable}_${_inst}_enable=\$${rcvar}}
+	done
+}
+
+_load_rc_config0()
+{
 	local _name _rcvar_val _var _defval _v _msg _new
 	_name=$1
 	if [ -z $_name ]; then
@@ -1034,10 +1104,10 @@ load_rc_config()
 	fi

 	# Set defaults if defined.
-	for _var in $rcvar; do
-		eval _defval

Re: RFC: swapon(8) vnode-backed md and gbde/geli encryption support

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130623.035356.644417021040610458@allbsd.org:

hr Hi,
hr
hr  I created a patchset to add support of automatic generation of
hr  vnode-backed md(4) devices and gbde/geli geom providers to swapon(8)
hr  via /etc/fstab.  We already have equivalent functionality by using
hr  rc.d scripts.  This simplifies rc.d scripts and fixes a race between
hr  mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab.

 A slightly revised patch is attached.  I will commit this today.

-- Hiroki
- Add vnode-backed swap space specification support.  This is enabled when
  device names md or md[0-9]* and a file option are specified in
  /etc/fstab like this:

  mdnoneswapsw,file=/swap.bin   0   0

- Add GBDE/GELI encrypted swap space specification support, which
  rc.d/encswap supported.  The /etc/fstab lines are like the following:

  /dev/ada1p1.bde   noneswapsw  0   0
  /dev/ada1p2.eli   noneswapsw  0   0

  .eli devices accepts aalgo, ealgo, keylen, and sectorsize as options.

  swapctl(8) can understand an encrypted device in the command line
  like this:

  # swapctl -a /dev/ada2p1.bde

- -L flag is added to support late option to defer swapon until
  rc.d/mountlate runs.

- rc.d script change:

rc.d/encswap - removed
rc.d/addswap - just display a warning message if  is defined.
rc.d/swap1 - renamed to rc.d/swap
rc.d/swaplate - newly added to support late option

These changes alleviate a race condition between device creation/removal
and swapon/swapoff.

MFC after:  1 week


Index: sbin/swapon/swapon.c
===
--- sbin/swapon/swapon.c	(revision 252094)
+++ sbin/swapon/swapon.c	(working copy)
@@ -41,35 +41,51 @@ static char sccsid[] = @(#)swapon.c	8.1 (Berkeley
 #include sys/cdefs.h
 __FBSDID($FreeBSD$);

+#include sys/param.h
+#include sys/types.h
+#include sys/mdioctl.h
 #include sys/stat.h
-#include sys/param.h
 #include sys/sysctl.h
+#include sys/wait.h
 #include vm/vm_param.h

 #include err.h
 #include errno.h
+#include fcntl.h
+#include fnmatch.h
 #include fstab.h
+#include libgen.h
+#include libutil.h
+#include limits.h
+#include paths.h
+#include stdarg.h
 #include stdio.h
 #include stdlib.h
 #include string.h
 #include unistd.h
-#include fcntl.h
-#include libutil.h

 static void usage(void);
-static int swap_on_off(char *name, int ignoreebusy);
+static const char *swap_on_off(char *, int, char *);
+static const char *swap_on_off_gbde(char *, int);
+static const char *swap_on_off_geli(char *, char *, int);
+static const char *swap_on_off_md(char *, char *, int);
+static const char *swap_on_off_sfile(char *, int);
 static void swaplist(int, int, int);
+static int run_cmd(int *, const char *, ...) __printflike(2, 3);

 static enum { SWAPON, SWAPOFF, SWAPCTL } orig_prog, which_prog = SWAPCTL;

+static int qflag;
+
 int
 main(int argc, char **argv)
 {
 	struct fstab *fsp;
+	const char *swfile;
 	char *ptr;
 	int ret;
 	int ch, doall;
-	int sflag = 0, lflag = 0, hflag = 0, qflag = 0;
+	int sflag = 0, lflag = 0, late = 0, hflag = 0;
 	const char *etc_fstab;

 	if ((ptr = strrchr(argv[0], '/')) == NULL)
@@ -82,7 +98,7 @@ main(int argc, char **argv)

 	doall = 0;
 	etc_fstab = NULL;
-	while ((ch = getopt(argc, argv, AadghklmqsUF:)) != -1) {
+	while ((ch = getopt(argc, argv, AadghklLmqsUF:)) != -1) {
 		switch(ch) {
 		case 'A':
 			if (which_prog == SWAPCTL) {
@@ -116,6 +132,9 @@ main(int argc, char **argv)
 		case 'l':
 			lflag = 1;
 			break;
+		case 'L':
+			late = 1;
+			break;
 		case 'm':
 			hflag = 'M';
 			break;
@@ -145,6 +164,7 @@ main(int argc, char **argv)
 	argv += optind;

 	ret = 0;
+	swfile = NULL;
 	if (etc_fstab != NULL)
 		setfstab(etc_fstab);
 	if (which_prog == SWAPON || which_prog == SWAPOFF) {
@@ -154,27 +174,37 @@ main(int argc, char **argv)
 	continue;
 if (strstr(fsp-fs_mntops, noauto))
 	continue;
-if (swap_on_off(fsp-fs_spec, 1)) {
+if (which_prog != SWAPOFF 
+strstr(fsp-fs_mntops, late) 
+!late)
+	continue;
+swfile = swap_on_off(fsp-fs_spec, 1,
+fsp-fs_mntops);
+if (swfile == NULL) {
 	ret = 1;
-} else {
-	if (!qflag) {
-		printf(%s: %sing %s as swap device\n,
-		getprogname(),
-		which_prog == SWAPOFF ? remov : add,
-		fsp-fs_spec);
-	}
+	continue;
 }
+if (!qflag) {
+	printf(%s: %sing %s as swap device\n,
+	getprogname(),
+	(which_prog == SWAPOFF) ?
+	remov : add, swfile);
+}
 			}
 		}
 		else if (!*argv)
 			usage();
 		for (; *argv; ++argv) {
-			if (swap_on_off(*argv, 0)) {
+			swfile = swap_on_off(*argv, 0, NULL);
+			if (swfile == NULL) {
 ret = 1;
-			} else if (orig_prog == SWAPCTL) {
+continue;
+			}
+			if (orig_prog == SWAPCTL) {
 printf(%s: %sing %s as swap device\n,
-getprogname(), which_prog == SWAPOFF ? remov : add

Re: RFC: swapon(8) vnode-backed md and gbde/geli encryption support

[Hiroki Sato]

Scot Hetzel swhet...@gmail.com wrote
  in cacdu+f-oupnckg+mjgfdopbt43xmrly19lmezlqgz_xu9yy...@mail.gmail.com:

sw The only thing I see is that you are hard coding the geli_swap_flags
sw (i.e. -e aes -l 256 -s 4096 -d) into swapon.  It would be better to
sw have swapon read the /etc/fstab file to get these values:
sw
sw /dev/ada1p2.elinoneswap
sw sw,ealgo=aes,keylen=256,sectorsize=4096  0 0
sw /dev/ada2p2.elinoneswapsw  0 0
sw
sw What you could do is that if no options are specified in the swap
sw file, swapon would then use default values for ealgo=aes, keylen=256
sw and sectorsize=4096.

 Thank you for your feedback.  These options are implemented in the
 attached patch.

-- Hiroki
- Add vnode-backed swap space specification support.  This is enabled when
  device names md or md[0-9]* and a file option are specified in
  /etc/fstab like this:

  mdnoneswapsw,file=/swap.bin   0   0

- Add GBDE/GELI encrypted swap space specification support, which
  rc.d/encswap supported.  The /etc/fstab lines are like the following:

  /dev/ada1p1.bde   noneswapsw  0   0
  /dev/ada1p2.eli   noneswapsw  0   0

  .eli devices supports aalgo, ealgo, keylen, and sectorsize as options.

  swapctl(8) can understand an encrypted device in the command line
  like this:

  # swapctl -a /dev/ada2p1.bde

- -L flag is added to support late option to defer swapon until
  rc.d/mountlate runs.

- rc.d script change:

rc.d/encswap - removed
rc.d/swap1 - renamed to rc.d/swap
rc.d/swaplate - newly added to support late option

These changes alleviate a race condition between device creation/removal
and swapon/swapoff.

MFC after:  2 weeks


Index: sbin/swapon/swapon.c
===
--- sbin/swapon/swapon.c	(revision 252094)
+++ sbin/swapon/swapon.c	(working copy)
@@ -41,35 +41,51 @@ static char sccsid[] = @(#)swapon.c	8.1 (Berkeley
 #include sys/cdefs.h
 __FBSDID($FreeBSD$);

+#include sys/param.h
+#include sys/types.h
+#include sys/mdioctl.h
 #include sys/stat.h
-#include sys/param.h
 #include sys/sysctl.h
+#include sys/wait.h
 #include vm/vm_param.h

 #include err.h
 #include errno.h
+#include fcntl.h
+#include fnmatch.h
 #include fstab.h
+#include libgen.h
+#include libutil.h
+#include limits.h
+#include paths.h
+#include stdarg.h
 #include stdio.h
 #include stdlib.h
 #include string.h
 #include unistd.h
-#include fcntl.h
-#include libutil.h

 static void usage(void);
-static int swap_on_off(char *name, int ignoreebusy);
+static const char *swap_on_off(char *, int, char *);
+static const char *swap_on_off_gbde(char *, int);
+static const char *swap_on_off_geli(char *, char *, int);
+static const char *swap_on_off_md(char *, char *, int);
+static const char *swap_on_off_sfile(char *, int);
 static void swaplist(int, int, int);
+static int run_cmd(int *, const char *, ...) __printflike(2, 3);

 static enum { SWAPON, SWAPOFF, SWAPCTL } orig_prog, which_prog = SWAPCTL;

+static int qflag;
+
 int
 main(int argc, char **argv)
 {
 	struct fstab *fsp;
+	const char *swfile;
 	char *ptr;
 	int ret;
 	int ch, doall;
-	int sflag = 0, lflag = 0, hflag = 0, qflag = 0;
+	int sflag = 0, lflag = 0, late = 0, hflag = 0;
 	const char *etc_fstab;

 	if ((ptr = strrchr(argv[0], '/')) == NULL)
@@ -82,7 +98,7 @@ main(int argc, char **argv)

 	doall = 0;
 	etc_fstab = NULL;
-	while ((ch = getopt(argc, argv, AadghklmqsUF:)) != -1) {
+	while ((ch = getopt(argc, argv, AadghklLmqsUF:)) != -1) {
 		switch(ch) {
 		case 'A':
 			if (which_prog == SWAPCTL) {
@@ -116,6 +132,9 @@ main(int argc, char **argv)
 		case 'l':
 			lflag = 1;
 			break;
+		case 'L':
+			late = 1;
+			break;
 		case 'm':
 			hflag = 'M';
 			break;
@@ -145,6 +164,7 @@ main(int argc, char **argv)
 	argv += optind;

 	ret = 0;
+	swfile = NULL;
 	if (etc_fstab != NULL)
 		setfstab(etc_fstab);
 	if (which_prog == SWAPON || which_prog == SWAPOFF) {
@@ -154,27 +174,37 @@ main(int argc, char **argv)
 	continue;
 if (strstr(fsp-fs_mntops, noauto))
 	continue;
-if (swap_on_off(fsp-fs_spec, 1)) {
+if (which_prog != SWAPOFF 
+strstr(fsp-fs_mntops, late) 
+!late)
+	continue;
+swfile = swap_on_off(fsp-fs_spec, 1,
+fsp-fs_mntops);
+if (swfile == NULL) {
 	ret = 1;
-} else {
-	if (!qflag) {
-		printf(%s: %sing %s as swap device\n,
-		getprogname(),
-		which_prog == SWAPOFF ? remov : add,
-		fsp-fs_spec);
-	}
+	continue;
 }
+if (!qflag) {
+	printf(%s: %sing %s as swap device\n,
+	getprogname(),
+	(which_prog == SWAPOFF) ?
+	remov : add, swfile);
+}
 			}
 		}
 		else if (!*argv)
 			usage();
 		for (; *argv; ++argv) {
-			if (swap_on_off(*argv, 0)) {
+			swfile = swap_on_off(*argv, 0, NULL);
+			if (swfile == NULL) {
 ret = 1;
-			} else if (orig_prog == SWAPCTL) {
+continue;

Re: revision 252095: kerenl fails to compile: nfs_clstate.c:5160:33: error: format specifies type 'long long' but the argument has type 'uint64_t'

[Hiroki Sato]

hiren panchasara hiren.panchas...@gmail.com wrote
  in calcpeug98bmk5hh58xwpr4d39vgptpotfsjnej-1phk5vm2...@mail.gmail.com:

hi On Jun 22, 2013 6:09 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
hi 
hi 
hi  Just for notice.
hi 
hi  The most recent sources fail to compile a kernel successfully:
hi
hi http://svnweb.freebsd.org/changeset/base/252074
hi
hi This change is the culprit.

 The attached patch should fix it.

-- Hiroki
Index: sys/fs/nfsclient/nfs_clstate.c
===
--- sys/fs/nfsclient/nfs_clstate.c	(revision 252096)
+++ sys/fs/nfsclient/nfs_clstate.c	(working copy)
@@ -77,6 +77,7 @@
  * until they succeed or an unmount/recovery occurs.
  * (Since we are done with them, they do not need to be recovered.)
  */
+#include machine/_inttypes.h

 #ifndef APPLEKEXT
 #include fs/nfs/nfsport.h
@@ -5156,9 +5157,9 @@
 			lyp-nfsly_fhlen, 0, flp-nfsfl_off, len,
 			lyp-nfsly_lastbyte, lyp-nfsly_stateid,
 			NFSLAYOUT_NFSV4_1_FILES, 0, NULL, cred, p, NULL);
-			NFSCL_DEBUG(4, layoutcommit err=%d off=%qd len=%qd 
-			lastbyte=%qd\n, error, flp-nfsfl_off, len,
-			lyp-nfsly_lastbyte);
+			NFSCL_DEBUG(4, layoutcommit err=%d off=% PRIu64
+			 len=% PRIu64 lastbyte=% PRIu64 \n, error,
+			flp-nfsfl_off, len, lyp-nfsly_lastbyte);
 			if (error == NFSERR_NOTSUPP) {
 /* If not supported, don't bother doing it. */
 NFSLOCKMNT(nmp);


pgpllmbhAQuOY.pgp
Description: PGP signature

RFC: swapon(8) vnode-backed md and gbde/geli encryption support

[Hiroki Sato]

Hi,

 I created a patchset to add support of automatic generation of
 vnode-backed md(4) devices and gbde/geli geom providers to swapon(8)
 via /etc/fstab.  We already have equivalent functionality by using
 rc.d scripts.  This simplifies rc.d scripts and fixes a race between
 mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab.

 More specifically, the following specification will be supported:

 /dev/ada1p1.bdenoneswapsw  0 0
 /dev/ada1p2.elinoneswapsw  0 0
 md noneswapsw,file=/swap.bin   0 0
 md10   noneswapsw,file=/swap10.bin 0 0
 md12   noneswapsw,file=/usr/swap12.bin,late0 0

 Currently, rc.d/swap1, rc.d/encswap handles entries with FSTAB_SW and
 then rc.d/addswap for additional swap space specified in rc.conf.
 The rc.d/addswap script runs before NETWORKING, so it is difficult to
 add a swap space by using a file via NFS on a diskless client.  The
 late keyword in /etc/fstab will give more flexibility in such a
 case.

 So, the changes to rc.d scripts are the following:

  rc.d/encswap - (removed)
  rc.d/swap1 - rc.d/swap
  rc.d/swaplate - (added)

 rc.d/addswap is not removed in the patchset, but is it still
 necessary?  I do not think using combination of rc.d scripts to
 support md(4) device generation for swap spaces is robust, and I
 believe /etc/fstab is sufficient for the same functionality.

 Any comments are welcome.  Thank you.

-- Hiroki
- Add vnode-backed swap space specification support.  This is enabled when
  device names md or md[0-9]* and a file option are specified in
  /etc/fstab like this:

  mdnoneswapsw,file=/swap.bin   0   0

- Add GBDE/GELI encrypted swap space specification support, which
  rc.d/encswap supported.  The /etc/fstab lines are like the following:

  /dev/ada1p1.bde   noneswapsw  0   0
  /dev/ada1p2.eli   noneswapsw  0   0

  swapctl(8) can understand an encrypted device in the command line
  like this:

  # swapctl -a /dev/ada2p1.bde

- -L flag is added to support late option to defer swapon until
  rc.d/mountlate runs.

- rc.d script change:

rc.d/encswap - removed
rc.d/swap1 - renamed to rc.d/swap
rc.d/swaplate - newly added to support late option

These changes alleviate a race condition between device creation/removal
and swapon/swapoff.

MFC after:  2 weeks


Index: sbin/swapon/swapon.c
===
--- sbin/swapon/swapon.c	(revision 252094)
+++ sbin/swapon/swapon.c	(working copy)
@@ -41,35 +41,51 @@ static char sccsid[] = @(#)swapon.c	8.1 (Berkeley
 #include sys/cdefs.h
 __FBSDID($FreeBSD$);

+#include sys/param.h
+#include sys/types.h
+#include sys/mdioctl.h
 #include sys/stat.h
-#include sys/param.h
 #include sys/sysctl.h
+#include sys/wait.h
 #include vm/vm_param.h

 #include err.h
 #include errno.h
+#include fcntl.h
+#include fnmatch.h
 #include fstab.h
+#include libgen.h
+#include libutil.h
+#include limits.h
+#include paths.h
+#include stdarg.h
 #include stdio.h
 #include stdlib.h
 #include string.h
 #include unistd.h
-#include fcntl.h
-#include libutil.h

 static void usage(void);
-static int swap_on_off(char *name, int ignoreebusy);
+static const char *swap_on_off(char *, int, char *);
+static const char *swap_on_off_gbde(char *, int);
+static const char *swap_on_off_geli(char *, int);
+static const char *swap_on_off_md(char *, char *, int);
+static const char *swap_on_off_sfile(char *, int);
 static void swaplist(int, int, int);
+static int run_cmd(int *, const char *, ...) __printflike(2, 3);

 static enum { SWAPON, SWAPOFF, SWAPCTL } orig_prog, which_prog = SWAPCTL;

+static int qflag;
+
 int
 main(int argc, char **argv)
 {
 	struct fstab *fsp;
+	const char *swfile;
 	char *ptr;
 	int ret;
 	int ch, doall;
-	int sflag = 0, lflag = 0, hflag = 0, qflag = 0;
+	int sflag = 0, lflag = 0, late = 0, hflag = 0;
 	const char *etc_fstab;

 	if ((ptr = strrchr(argv[0], '/')) == NULL)
@@ -82,7 +98,7 @@ main(int argc, char **argv)

 	doall = 0;
 	etc_fstab = NULL;
-	while ((ch = getopt(argc, argv, AadghklmqsUF:)) != -1) {
+	while ((ch = getopt(argc, argv, AadghklLmqsUF:)) != -1) {
 		switch(ch) {
 		case 'A':
 			if (which_prog == SWAPCTL) {
@@ -116,6 +132,9 @@ main(int argc, char **argv)
 		case 'l':
 			lflag = 1;
 			break;
+		case 'L':
+			late = 1;
+			break;
 		case 'm':
 			hflag = 'M';
 			break;
@@ -145,6 +164,7 @@ main(int argc, char **argv)
 	argv += optind;

 	ret = 0;
+	swfile = NULL;
 	if (etc_fstab != NULL)
 		setfstab(etc_fstab);
 	if (which_prog == SWAPON || which_prog == SWAPOFF) {
@@ -154,27 +174,37 @@ main(int argc, char **argv)
 	continue;
 if (strstr(fsp-fs_mntops, noauto))
 	continue;
-if (swap_on_off(fsp-fs_spec, 1)) {
+if (which_prog != SWAPOFF 
+strstr(fsp-fs_mntops, late) 
+!late)
+	continue;
+swfile = swap_on_off(fsp-fs_spec, 1,
+

request for your comments on release documentation

[Hiroki Sato]

Hi,

 I would like your comments on release notes for each release.
 Although I have been working on editing them for years, the workflow
 is still not optimal and sometimes delay of the preparation became an
 obstacle for release process.  I would like to improve it, but before
 that I would like to know what are desired of the contents which
 people think.

 Release Notes is just listing the changes between the two releases.
 It includes user-visible change (bugfix and/or UI change), new
 functionality, and performance improvement.  Minor changes such as
 one in kernel internal structure are omitted.  I always try to keep
 these series of relnotes items are correct and reasonably
 comprehensive, but this lengthy list may be boring and
 technically-correct descriptions can be cryptic for average users.

 So, my questions are:

 1. What do you think about current granularity of the relnotes items?
Too detailed, good, or too rough?  Currently, judgment of what is
included or not is based on user-visible, new functionality, or
performance improvement.  Applicable changes are included as
relnotes items even if the changes are small,

 2. Do you want technical details?  For example, just disk access
performance was improved by 50% or Feature A has been added.
This changes the old behavior because ..., and as a result, it
improves disk access performance by 50%.

 3. Is there missing information which should be in the relnotes?
Probably there are some missing items for each release, but this
question is one at some abstraction level.  Link to commit log and
diff, detailed description of major incompatible changes, and so
on.

 Although the other release documentations---Errata, Installation
 Notes, ReadMe, and Hardware Notes---also need some improvements,
 please focus on Release Notes only.  And you might think quality of
 English writing are not good, please leave that alone for now.

-- Hiroki


pgp8TpJHirj07.pgp
Description: PGP signature

Re: 10-CURRENT i386 memstick snapshots broken?

[Hiroki Sato]

Glen Barber g...@freebsd.org wrote
  in 20130608173411.gd13...@glenbarber.us:

gj On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:

gj Because the userland is 32-bit and the kernel is 64-bit, something
gj goes wrong, but interestingly not wrong enough that the script fails
gj entirely.  So, the paritions appear to be created, but in reality, they
gj are not.
gj
gj So, for the snapshots case, the solution is to write the memstick image
gj from outside of the chroot environment, which is easy to do because
gj I already do this for creating the VM disk images (interestingly for the
gj same reason as the memstick creation failure).

 I do not think there is a problem with cross building in chroot.
 allbsd.org is also generating i386 snapshots on an amd64 box in
 almost the same way as generate-release.sh, but the memstick images
 already generated were not broken as far as I can check.  Although I
 do not use generate-release.sh on it because I added another build
 world stage in chroot before cross compiling, the difference is
 small.

 What was exactly gone wrong in 32-bit binary on 64-bit kernel?

-- Hiroki


pgpa7n05DnipG.pgp
Description: PGP signature

Re: 10-CURRENT i386 memstick snapshots broken?

[Hiroki Sato]

Tim Kientzle t...@kientzle.com wrote
  in 926ef579-8ac9-4a98-8a81-4e978a627...@kientzle.com:

ti
ti On Jun 8, 2013, at 10:34 AM, Glen Barber wrote:
ti
ti  On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
ti  Has anyone else tried the i386 memstick and having the same problem?
ti 
ti 
ti  Hmm.  Thanks for the report.  I'll take a look at the logs for i386, but
ti  they are generated the same way as the amd64, so in theory should not
ti  have any noticable difference.
ti 
ti 
ti  For amd64 and i386, native binaries are built, and installed into
ti  scratch directories; for powerpc and powerpc64, I just use the amd64
ti  binaries, because I cannot directly use the chroot binaries for
ti  non-native architecture.
ti 
ti  The scripts chroot into the scratch directories, and run the real
ti  release builds.
ti
ti Have you tried using Crochet for this sort of thing?
ti
ti Since it was designed from the ground up for cross-building
ti bootable images, it should avoid these issues.
ti
ti The only fundamental limit right now is that Crochet uses
ti the host system to build the UFS filesystems, so it can't
ti build big-endian MIPS images on i386, for example.

 makefs does not work?  It can build BE FFS images on LE platforms.

-- Hiroki


pgpSfiguwNi65.pgp
Description: PGP signature

Re: need to download /boot/gptzfsboot for 10 (zfs 5000)

[Hiroki Sato]

Guido Falsi m...@madpilot.net wrote
  in 519b239e.4060...@madpilot.net:

ma On 05/21/13 09:32, Beeblebrox wrote:
ma  Hello.
ma  I made a small mistake and I need to re-write the gptzfsboot file for
ma  10-current zfs 5000 to my freebsd-boot gpt partition.
ma 
ma  I can't use mfsbsd's gptzfsboot because that is 9.1 and v28 zfs.
ma 
ma  Where can i download this file (without the complete 10.iso)?
ma 
ma
ma You can try here:
ma
ma https://pub.allbsd.org/FreeBSD-snapshots/
ma
ma and take the file from one of those snapshots.

 FYI, the whole directory tree of a snapshot can be found at the
 following, for example:

 
https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r250698-JPSNAP/stage/trees/

-- Hiroki


pgpycCzrcbFPi.pgp
Description: PGP signature

Re: -iface option to route(8) is broken

[Hiroki Sato]

Julian Elischer jul...@freebsd.org wrote
  in 50ec51a3.6020...@freebsd.org:

ju On 1/8/13 6:42 AM, Ian FREISLICH wrote:
ju  Hi
ju 
ju  Adding routes using the -iface option to route(8) doesn't work any
ju  more.  This was useful to select a specific interface for a route
ju  when the remote gateway has the same IP address.  Are there plans
ju  to restore this functionality?
ju
ju I agree.. thus was a crucial piece of functionality..
ju
ju who broke it?

 Oh, sorry, it seems I accidentally broke it in the previous commit.
 It should be fixed now.  Please let me know if it still does not
 work.

-- Hiroki


pgpc4BlRPFooR.pgp
Description: PGP signature

Re: FreeBSD daily snapshot build in allbsd.org temporarily down

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20121207.101917.103513550140980591@allbsd.org:

hr Hi all,
hr
hr  I received many emails asking why
hr  https://pub.allbsd.org/FreeBSD-snapshots/ is stopped working and when
hr  it will recover, so I just wanted to let you know that FreeBSD daily
hr  snapshot build in allbsd.org is temporarily down.  The reason why it
hr  is down is some local network issue and CVS-SVN migration of the
hr  build system.  The latter was solved already.  However, the former
hr  was unexpected and needed some time than I thought originally.

 The service has almost recovered.  Snapshots for i386, amd64, and
 pc98/i386 are being rebuilt now, and then ia64, sparc64, and powerpc
 will also be connected to the build queue soon.

 For stable/9 and later, Subversion repository is used and the build
 results are sorted by the revision numbers on each day.  For 8.X it
 still uses CVS via the make release target but will be switched to
 use Subversion shortly.

 Note that some local network performance issue still remains.  It
 seems due to traffic congestion around the border router which I do
 not have control of.  The transfer rate can become less than 100KB/s
 especially in 12:00-18:00 in JST.

 I will planning to add a custom build functionality by using the
 source trees under projects/ or user/ branch to this service.

-- Hiroki


pgpl3sZPjPZ17.pgp
Description: PGP signature

FreeBSD daily snapshot build in allbsd.org temporarily down

[Hiroki Sato]

Hi all,

 I received many emails asking why
 https://pub.allbsd.org/FreeBSD-snapshots/ is stopped working and when
 it will recover, so I just wanted to let you know that FreeBSD daily
 snapshot build in allbsd.org is temporarily down.  The reason why it
 is down is some local network issue and CVS-SVN migration of the
 build system.  The latter was solved already.  However, the former
 was unexpected and needed some time than I thought originally.

 The snapshot build will start again this weekend or early next week.
 Glen is offering similar snapshot ISO images and distfiles for amd64
 and i386 at https://snapshots.glenbarber.us/Latest/, so please visit
 his page if you need the latest snapshot right now.

-- Hiroki


pgpoOyHCswiWa.pgp
Description: PGP signature

RFC: sysctl -f filename

[Hiroki Sato]

Hi,

 I would like comments about the attached patch for sysctl(8) to add a
 new option -f filename.  It supports reading of a file with
 key=value lines.

 As you probably know, we already have /etc/sysctl.conf and it is
 processed by rc.d/sysctl shell script in a line-by-line basis.  The
 problem I want to fix is a confusing syntax of /etc/sysctl.conf.  The
 file supports a typical configuration file syntax but problematic in
 some cases.  For example:

  kern.coredump=1

 works well in /etc/sysctl.conf, but

  kern.coredump=1

 does not work.  Similarly, it is difficult to use whitespaces and #
 in the value:

  OK: kern.domainname=domain\ name\ with\ spaces
  NG: kern.domainname=domain name with spaces
  NG: kern.domainname=domain\ name\ including\ #\ character
  NG: kern.domainname=domain\ name\ including\ \#\ character

 The attached patch solves them, and in addition it displays an error
 message with a line number if there is something wrong in the file
 like this:

  % cat -n /etc/sysctl.conf
  ...
  10  kern.coredump=1
  11  kern.coredump2=1
  ...

  % /etc/rc.d/sysctl start
  sysctl: kern.coredump at line 10: Operation not permitted
  sysctl: unknown oid 'kern.coredump2' at line 11

  # /etc/rc.d/sysctl start
  kern.coredump: 1 - 1
  sysctl: unknown oid 'kern.coredump2' at line 11

 Any comments are welcome.

-- Hiroki
Index: sbin/sysctl/sysctl.8
===
--- sbin/sysctl/sysctl.8	(revision 243756)
+++ sbin/sysctl/sysctl.8	(working copy)
@@ -28,7 +28,7 @@
 .\	From: @(#)sysctl.8	8.1 (Berkeley) 6/6/93
 .\ $FreeBSD$
 .\
-.Dd January 17, 2011
+.Dd November 22, 2012
 .Dt SYSCTL 8
 .Os
 .Sh NAME
@@ -37,6 +37,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl bdehiNnoqx
+.Op Fl f Ar filename
 .Ar name Ns Op = Ns Ar value
 .Ar ...
 .Nm
@@ -80,6 +81,11 @@
 or
 .Fl n
 is specified, or a variable is being set.
+.It Fl f Ar filename
+Specify a file which contains a pair of name and value in each line.
+.Nm
+reads and processes the specified file first and then processes the name
+and value pairs in the command line argument.
 .It Fl h
 Format output for human, rather than machine, readability.
 .It Fl i
Index: sbin/sysctl/sysctl.c
===
--- sbin/sysctl/sysctl.c	(revision 243756)
+++ sbin/sysctl/sysctl.c	(working copy)
@@ -56,13 +56,16 @@
 #include stdio.h
 #include stdlib.h
 #include string.h
+#include sysexits.h
 #include unistd.h

+static const char *conffile;
 static int	aflag, bflag, dflag, eflag, hflag, iflag;
-static int	Nflag, nflag, oflag, qflag, xflag, warncount;
+static int	Nflag, nflag, oflag, qflag, xflag;

 static int	oidfmt(int *, int, char *, u_int *);
-static void	parse(char *);
+static int	parsefile(const char *);
+static int	parse(char *, int);
 static int	show_var(int *, int);
 static int	sysctl_all(int *oid, int len);
 static int	name2oid(char *, int *);
@@ -74,7 +77,7 @@
 {

 	(void)fprintf(stderr, %s\n%s\n,
-	usage: sysctl [-bdehiNnoqx] name[=value] ...,
+	usage: sysctl [-bdehiNnoqx] [-f filename] name[=value] ...,
 	   sysctl [-bdehNnoqx] -a);
 	exit(1);
 }
@@ -83,12 +86,13 @@
 main(int argc, char **argv)
 {
 	int ch;
+	int warncount = 0;

 	setlocale(LC_NUMERIC, );
 	setbuf(stdout,0);
 	setbuf(stderr,0);

-	while ((ch = getopt(argc, argv, AabdehiNnoqwxX)) != -1) {
+	while ((ch = getopt(argc, argv, Aabdef:hiNnoqwxX)) != -1) {
 		switch (ch) {
 		case 'A':
 			/* compatibility */
@@ -106,6 +110,9 @@
 		case 'e':
 			eflag = 1;
 			break;
+		case 'f':
+			conffile = strdup(optarg);
+			break;
 		case 'h':
 			hflag = 1;
 			break;
@@ -146,13 +153,15 @@
 		usage();
 	if (aflag  argc == 0)
 		exit(sysctl_all(0, 0));
-	if (argc == 0)
+	if (argc == 0  conffile == NULL)
 		usage();
-
 	warncount = 0;
+	if (conffile != NULL)
+		warncount += parsefile(conffile);
 	while (argc--  0)
-		parse(*argv++);
-	exit(warncount);
+		warncount += parse(*argv++, 0);
+
+	return (warncount);
 }

 /*
@@ -160,8 +169,8 @@
  * Lookup and print out the MIB entry if it exists.
  * Set a new value if requested.
  */
-static void
-parse(char *string)
+static int
+parse(char *string, int lineno)
 {
 	int len, i, j;
 	void *newval = 0;
@@ -173,17 +182,30 @@
 	int64_t i64val;
 	uint64_t u64val;
 	int mib[CTL_MAXNAME];
-	char *cp, *bufp, buf[BUFSIZ], *endptr, fmt[BUFSIZ];
+	char *cp, *bufp, buf[BUFSIZ], *endptr, fmt[BUFSIZ], line[BUFSIZ];
 	u_int kind;

+	memset(line, 0, sizeof(line));
+	if (lineno)
+		snprintf(line, sizeof(line),  at line %d, lineno);
 	bufp = buf;
-	if (snprintf(buf, BUFSIZ, %s, string) = BUFSIZ)
-		errx(1, oid too long: '%s', string);
+	if (snprintf(buf, BUFSIZ, %s, string) = BUFSIZ) {
+		warn(oid too long: '%s'%s, string, line);
+		return (1);
+	}
 	if ((cp = strchr(string, '=')) != NULL) {
 		*strchr(buf, '=') = '\0';
 		*cp++ = '\0';
 		while (isspace(*cp))
 			cp++;
+		/* Strip a pair of  or ' if any. */
+		switch (*cp) {
+		case '\':
+		case '\'':
+			if (cp[strlen(cp) - 1] == 

Re: RFC: sysctl -f filename

[Hiroki Sato]

Garrett Cooper yaneg...@gmail.com wrote
  in CAGH67wShpcmOKhc09+MP5c-AOm7EAPG+Gqv=j0prq0sgutz...@mail.gmail.com:

ya On Sat, Dec 1, 2012 at 2:10 PM, Garrett Cooper yaneg...@gmail.com wrote:
ya  Why change the tool when we can change the rc script to do the
ya  right thing? I have a patch I'm working on to resolve this (you hit an
ya  itch I've been meaning to scratch for a little while).
ya
ya This should work. I also refactored the script to get it down to
ya 80 columns. I've attached the debug output and the diff for the debug
ya version of the script.

 You will find out the following test case does not work (this is one
 of the test strings I used):

 kern.domainname=c$EDITOR.\\ hoge\ \\#hoge2\\$ \# h$$\#oge#

 The reason why I changed sysctl(8) was that the rc.d/sysctl script
 was too complex and slow even if it could support meta characters in
 shell script syntax.  I created several prototypes as script but
 noticed that keeping consistency was quite difficult and
 maintainability was poor due to tricky handling of variables.

 Although my patch in the previous email does not support meta
 characters completely, I still think it is more reasonable to
 implement this functionality on the sysctl(8) side.

-- Hiroki


pgpVk9C4QBA16.pgp
Description: PGP signature

Re: after upgrade, can't restart apache via cron

[Hiroki Sato]

Michael W. Lucas mwlu...@michaelwlucas.com wrote
  in 20121123031753.ga59...@bewilderbeast.blackhelicopters.org:

mw eval: setfib: not found
mw /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
mw
mw If I run /usr/local/etc/rc.d/apache22 restart from the command line, I
mw can restart httpd without trouble.
mw
mw Any thoughts?

 This was due to $PATH in the cron job as already pointed out, but
 this should not happen.  I attached a patch to use full-path for
 external commands in rc.subr.  If there is no objection to this
 change I will commit it.

-- Hiroki
Index: etc/rc.subr
===
--- etc/rc.subr	(revision 243327)
+++ etc/rc.subr	(working copy)
@@ -49,6 +49,18 @@
 IDCMD=if [ -x $ID ]; then $ID -un; fi
 PS=/bin/ps -ww
 JID=`$PS -p $$ -o jid=`
+CHROOT_CMD=/usr/sbin/chroot
+DEVFS_CMD=/sbin/devfs
+EGREP_CMD=/usr/bin/egrep
+GREP_CMD=/usr/bin/grep
+KLDSTAT_CMD=/sbin/kldstat
+KLDLOAD_CMD=/sbin/kldload
+LOGGER_CMD=/usr/bin/logger
+MDMFS_CMD=/sbin/mdmfs
+MOUNT_CMD=/sbin/mount
+NICE_CMD=/usr/bin/nice
+SETFIB_CMD=/usr/sbin/setfib
+SU_CMD=/usr/bin/su

 #
 #	functions
@@ -181,7 +193,7 @@
 			if $_ismounted; then
 :
 			else
-mount $_fs /dev/null 21
+${MOUNT_CMD} $_fs /dev/null 21
 			fi
 		)
 	done
@@ -726,17 +738,17 @@
 			check_startmsgs  echo Starting ${name}.
 			if [ -n $_chroot ]; then
 _doit=\
-${_nice:+nice -n $_nice }\
-${_fib:+setfib -F $_fib }\
-chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
+${_nice:+${NICE_CMD} -n $_nice }\
+${_fib:+${SETFIB_CMD} -F $_fib }\
+${CHROOT_CMD} ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
 $_chroot $command $rc_flags $command_args
 			else
 _doit=\
 ${_chdir:+cd $_chdir  }\
-${_fib:+setfib -F $_fib }\
+${_fib:+${SETFIB_CMD} -F $_fib }\
 $command $rc_flags $command_args
 if [ -n $_user ]; then
-_doit=su -m $_user -c 'sh -c \$_doit\'
+_doit=${SU_CMD} -m $_user -c 'sh -c \$_doit\'
 fi
 if [ -n $_nice ]; then
 	if [ -z $_user ]; then
@@ -953,7 +965,7 @@

 	_cmd=kill -$1 $rc_pid
 	if [ -n $_user ]; then
-		_cmd=su -m ${_user} -c 'sh -c \${_cmd}\'
+		_cmd=${SU_CMD} -m ${_user} -c 'sh -c \${_cmd}\'
 	fi
 	echo $_cmd
 }
@@ -1110,8 +1122,8 @@
 	exitval=$1
 	shift

-	if [ -x /usr/bin/logger ]; then
-		logger $0: ERROR: $*
+	if [ -x ${LOGGER_CMD} ]; then
+		${LOGGER_CMD} $0: ERROR: $*
 	fi
 	echo 12 $0: ERROR: $*
 	exit $exitval
@@ -1123,8 +1135,8 @@
 #
 warn()
 {
-	if [ -x /usr/bin/logger ]; then
-		logger $0: WARNING: $*
+	if [ -x ${LOGGER_CMD} ]; then
+		${LOGGER_CMD} $0: WARNING: $*
 	fi
 	echo 12 $0: WARNING: $*
 }
@@ -1137,8 +1149,8 @@
 {
 	case ${rc_info} in
 	[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
-		if [ -x /usr/bin/logger ]; then
-			logger $0: INFO: $*
+		if [ -x ${LOGGER_CMD} ]; then
+			${LOGGER_CMD} $0: INFO: $*
 		fi
 		echo $0: INFO: $*
 		;;
@@ -1155,8 +1167,8 @@
 {
 	case ${rc_debug} in
 	[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
-		if [ -x /usr/bin/logger ]; then
-			logger $0: DEBUG: $*
+		if [ -x ${LOGGER_CMD} ]; then
+			${LOGGER_CMD} $0: DEBUG: $*
 		fi
 		echo 12 $0: DEBUG: $*
 		;;
@@ -1320,7 +1332,7 @@
 			fi
 			eval $rulename=\$rulenum
 			debug found ruleset: $rulename=$rulenum
-			if ! /sbin/devfs rule -s $rulenum delset; then
+			if ! ${DEVFS_CMD} rule -s $rulenum delset; then
 _err=1
 break
 			fi
@@ -1331,7 +1343,7 @@
 			# other rules
 			if [ -n $rulecmd ]; then
 debug adding rule ($rulecmd)
-if ! eval /sbin/devfs rule -s $rulenum $rulecmd
+if ! eval ${DEVFS_CMD} rule -s $rulenum $rulecmd
 then
 	_err=1
 	break
@@ -1389,7 +1401,7 @@
 		return 1
 	fi
 	debug $_me: setting ruleset ($rs) on mount-point (${devdir#-m })
-	if ! /sbin/devfs $devdir ruleset $rs; then
+	if ! ${DEVFS_CMD} $devdir ruleset $rs; then
 		warn $_me: unable to set ruleset $rs to ${devdir#-m }
 		return 1
 	fi
@@ -1414,7 +1426,7 @@
 		return 1
 	fi
 	debug $_me: applying ruleset ($rs) to mount-point (${devdir#-m })
-	if ! /sbin/devfs $devdir rule -s $rs applyset; then
+	if ! ${DEVFS_CMD} $devdir rule -s $rs applyset; then
 		warn $_me: unable to apply ruleset $rs to ${devdir#-m }
 		return 1
 	fi
@@ -1438,14 +1450,14 @@
 		return 1
 	fi
 	debug $_me: mount-point is ($devdir), ruleset is ($rs)
-	if ! mount -t devfs dev $devdir; then
+	if ! ${MOUNT_CMD} -t devfs dev $devdir; then
 		warn $_me: Unable to mount devfs on $devdir
 		return 1
 	fi
 	if [ -n $rs ]; then
 		devfs_init_rulesets
 		devfs_set_ruleset $rs $devdir
-		devfs -m $devdir rule applyset
+		${DEVFS_CMD} -m $devdir rule applyset
 	fi
 	return 0
 }
@@ -1483,7 +1495,7 @@
 	if [ -n $3 ]; then
 		flags=$3
 	fi
-	/sbin/mdmfs $flags -s $1 md $2
+	${MDMFS_CMD} $flags -s $1 md $2
 }

 # Code common to scripts that need to load a kernel module
@@ -1512,16 +1524,16 @@
 	_mod=${_mod:-$1}
 	_loaded=false
 	if [ -n $_re ]; then
-		if kldstat -v | egrep -q -e $_re; then
+		if ${KLDSTAT_CMD} -v | ${EGREP_CMD} -q -e $_re; then
 	

Re: Tons of sa6_recoverscope: assumption failure on recent -current

[Hiroki Sato]

Andrey Chernov a...@freebsd.org wrote
  in 50a88d0e.1070...@freebsd.org:

ac On every IPv6 address of my card and router and every broadcast and
ac link-local scope addresses I see now:
ac kernel: sa6_recoverscope: assumption failure (non 0 ID): ipv6 address
ac 
ac What does it mean and why there are so many of them? I have plain local
ac net with IPv6 router, nothing unusual.
ac 
ac IPv6 continues to work despite of those failures.

René Ladan r...@freebsd.org wrote
  in 50a9e4d1.8000...@freebsd.org:

re I'm also seeing them when using a teredo-tunnel over an IPv4 router,
re r243234-amd64

 This warning message itself is not harmful actually, but my commit
 triggered it.  It should be fixed at r243235.  Can you let me know if
 this problem persists even at this revision or later?  Thank you.

-- Hiroki


pgpHXYXaI13TI.pgp
Description: PGP signature

Re: [head tinderbox] failure on mips64/mips

[Hiroki Sato]

Adrian Chadd adr...@freebsd.org wrote
  in CAJ-VmomeeoCtj=fjozceiacmytzwvzc8rtdpb8f29ttunkf...@mail.gmail.com:

ad On 17 November 2012 21:45, Hiroki Sato h...@freebsd.org wrote:
ad
ad  ad Fixed. Damn those pesky non-IPV6 belivers.
ad 
ad   Sorry, I was careless about this part.
ad
ad It's fine. :-) God, I so can't grill anyone for breaking the build,
ad given my  track record!
ad
ad I hope you didn't mind me quickly fixing that up?

 I did not mind at all.  Thank you for fixing it!

-- Hiroki


pgpmtc3NJszIj.pgp
Description: PGP signature

Re: [head tinderbox] failure on mips64/mips

[Hiroki Sato]

Adrian Chadd adr...@freebsd.org wrote
  in CAJ-VmonbG+6vhR=hzg7gnxvgco+1bmh8sk8dye5x0cs7ep2...@mail.gmail.com:

ad On 17 November 2012 18:35, FreeBSD Tinderbox tinder...@freebsd.org wrote:
ad
ad  cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 
--param large-function-growth=10 --param max-inline-insns-single=1  
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80001000 -mabi=64 
-march=mips64 -msoft-float -ffreestanding -Werror  /src/sys/net/rtsock.c
ad  cc1: warnings being treated as errors
ad  /src/sys/net/rtsock.c: In function 'sysctl_dumpentry':
ad  /src/sys/net/rtsock.c:1577: warning: unused variable 'i' 
[-Wunused-variable]
ad  *** [rtsock.o] Error code 1
ad
ad Fixed. Damn those pesky non-IPV6 belivers.

 Sorry, I was careless about this part.

-- Hiroki


pgpJQ52aBTVf9.pgp
Description: PGP signature

Re: svn commit: r238361 - head/sys/dev/usb

[Hiroki Sato]

Andrew Thompson thom...@freebsd.org wrote
  in cafaognrnlnphkjv793v49gtnvnte_rvs7ccz-cq5ztftfu9...@mail.gmail.com:

th On 12 July 2012 10:15, Adrian Chadd adr...@freebsd.org wrote:
th  Again, that just touched usb. So, how'd that affect non-USB wifi cloning?
th
th I guess cloning is first match wins and usb was incorrectly matching wlan*

 Yes, a greedier ifname matching rule can unintentionally win
 regardless of the interface type.

-- Hiroki


pgpnNBymLHclu.pgp
Description: PGP signature

Re: ifconfig create breaks between r238227 - r238290?

[Hiroki Sato]

David Wolfskill da...@catwhisker.org wrote
  in 20120709131957.gi1...@albert.catwhisker.org:

da Just finished updating from r238227 to r238290 on the head slice of my
da laptop, and was unable to make use of the wlan(4) NIC; I captured the
da following via cut/paste from ttyv0:
(snip)
da
da I glanced through the list of commits to head in that range, but
da didn't note anything glaringly obvious (yet).
da
da I hadn't tried a wired NIC on the laptop; I can, if there's anything
da likely to be of value in doing so.

 Gr, it may be due to my change of r238279.  I am investigating it.

-- Hiroki


pgp7OKgM7g6bN.pgp
Description: PGP signature

Re: ifconfig create breaks between r238227 - r238290?

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20120711.110203.744611964086256554@allbsd.org:

hr David Wolfskill da...@catwhisker.org wrote
hr   in 20120709131957.gi1...@albert.catwhisker.org:
hr
hr da Just finished updating from r238227 to r238290 on the head slice of my
hr da laptop, and was unable to make use of the wlan(4) NIC; I captured the
hr da following via cut/paste from ttyv0:
hr (snip)
hr da
hr da I glanced through the list of commits to head in that range, but
hr da didn't note anything glaringly obvious (yet).
hr da
hr da I hadn't tried a wired NIC on the laptop; I can, if there's anything
hr da likely to be of value in doing so.
hr
hr  Gr, it may be due to my change of r238279.  I am investigating it.

 Committed a fix as r238361.  Please try it.

-- Hiroki


pgpTqXxJ7neAD.pgp
Description: PGP signature

Re: [CFC/CFT] large changes in the loader(8) code

[Hiroki Sato]

Pawel Jakub Dawidek p...@freebsd.org wrote
  in 20120628230725.gb1...@garage.freebsd.pl:

pj PS. We are discussing two totally different things here:
pj 1. Is placing GPT on anything but raw disk violates the spec? I can
pjagree that it does and I'm happy with gpart(8) growing a warning.

 I agree that there is a sort of violation, but in practice most of
 implementations which use GPT can recognize the backup header as long
 as the primary one is not corrupted by using the alternative LBA
 field.

 One thing we have to consider is what happens when the primary header
 becomes broken.  In that case and if a GEOM metadata is placed at the
 end of the raw disk, GPT will be lost and it cannot recover by
 non-GEOM-aware software including BIOS and other OS.  Also, even for
 FreeBSD it causes a boot failure.  The modification which ae@
 proposes mitigates this case.  Of course, maybe BIOS or EFI will not
 recognize the corrupted header because the backup header is not
 located at the end.  In that case all of the partitions are not
 recognized and the FreeBSD does not boot.  This is the trade-off when
 we use GPT in a logical volume provided by GEOM.  In short, the risk
 is that backup header does not work as a backup when the primary is
 broken.  I agree that putting a warning about that is good and
 enough.  Whether this risk is acceptable or not depends on the
 sysadmin.  Also, we can describe the pros and cons in detail in a
 section of the handbook because I and wblock@ are working on updating
 it.

pj 2. How to do software mirroring. Besides trying really hard I'm not sure
pjwhat alternative are you proposing. Could you be more specific and
pjdescribe how gmirror should be implemented in your opinion?

 I do not think this topic is related to ae@'s change and this should
 be discussed in a separate thread.  His change aims to support a
 non-standard GPT header location in a quite limited situation, not
 actively promote such a configuration.  The issue of GPT+GEOM is not
 limited to gmirror.  Just putting GEOM::LABEL metadata causes the
 same issue.

-- Hiroki


pgp6Fd1NnM4r5.pgp
Description: PGP signature

Re: est man page

[Hiroki Sato]

Sean Bruno sean...@yahoo-inc.com wrote
  in 1339531057.42366.2.ca...@powernoodle.corp.yahoo.com:

se On Tue, 2012-06-05 at 14:13 -0700, Sean Bruno wrote:
se  On Tue, 2012-06-05 at 11:55 -0700, Sean Bruno wrote:
se
se
se
se allrighty, after some doc reviews by Glen, I've thwacked together a
se quick and dirty est(4).
se
se Any objections?
se
se http://people.freebsd.org/~sbruno/est_man.txt

 Looks good.  Attached a diff for some small fixes.

se view via:
se groff -S -P-h -Wall -mtty-char -man -Tascii est_man.txt | less

 % man $PWD/est_man.txt

 may be easier :)

-- Hiroki
--- est_man.txt.orig	2012-06-13 11:06:23.0 +0900
+++ est_man.txt	2012-06-13 11:39:12.0 +0900
@@ -23,6 +23,7 @@
 .\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\ SUCH DAMAGE.
 .\
+.\ $FreeBSD$
 .\
 .Dd June 12, 2012
 .Dt EST 4
@@ -36,7 +37,7 @@
 configuration file:
 .Bd -ragged -offset indent
 .Cd device cpufreq
-.Ep
+.Ed
 .Sh DESCRIPTION
 The
 .Nm
@@ -72,12 +73,12 @@
 .Sh DIAGNOSTICS
 .Bl -diag
 .It est%d: Enhanced SpeedStep Frequency Control on cpu%d
-.It \
+.Pp
 Indicates normal startup of this interface.
 .It est: CPU supports Enhanced Speedstep, but is not recognized.
 .It est: cpu_vendor GenuineIntel, msr 471c471c0600471c
 .It device_attach: est2 attach returned 6
-.It \
+.Pp
 Indicates all attempts to attach to this interface have failed.
 This usually indicates and improper BIOS setting restricting O/S
 control of the CPU speeds.  Consult your BIOS documentation for
@@ -87,12 +88,13 @@
 .Nm
 is only found on supported Intel CPUs.
 .Sh SEE ALSO
-.Xr cpufreq 4 ,
+.Xr cpufreq 4
 .Sh SUPPORT
 For general information and support,
 go to the Intel 64 and IA-32 Architectures Software Developer
 Manuals site.
 .Pa http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
+.Sh AUTHORS
 .Pp
 This manual page was written by
 .An Sean Bruno Aq sbr...@freebsd.org .
.\
.\ Copyright (c) 2012 Sean Bruno sbr...@freebsd.org
.\ All rights reserved.
.\
.\ Redistribution and use in source and binary forms, with or without
.\ modification, are permitted provided that the following conditions
.\ are met:
.\ 1. Redistributions of source code must retain the above copyright
.\notice, this list of conditions and the following disclaimer.
.\ 2. Redistributions in binary form must reproduce the above copyright
.\notice, this list of conditions and the following disclaimer in the
.\documentation and/or other materials provided with the distribution.
.\
.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\ ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\ SUCH DAMAGE.
.\
.\ $FreeBSD$
.\
.Dd June 12, 2012
.Dt EST 4
.Os
.Sh NAME
.Nm est
.Nd Enhanced Speedstep Technology
.Sh SYNOPSIS
To compile this capability into your kernel
place the following lines in your kernel
configuration file:
.Bd -ragged -offset indent
.Cd device cpufreq
.Ed
.Sh DESCRIPTION
The
.Nm
interface that provides support for the Intel Enhanced Speedstep Technology
.Pp
Note that the
.Nm
driver is automatically loaded by the
.Xr cpufreq 4
driver.
.Sh LOADER TUNABLES
The
.Nm
interface is intended to allow
.Xr cpufreq 4
to access and implement Intel Enhanced SpeedStep Technology via
.Xr acpi 4
and the acpi_perf interface accessors.
If the default settings are not optimal, the following sysctls can be
used to modify or monitor
.Nm
behavior.
.Bl -tag -width indent
.It hw.est.msr_info
Attempt to infer information from direct probing of the msr.
Should only be used in diagnostic cases.
.Pq default 0
.It hw.est.strict
Do not allow different cpus to be set to different frequencies.
It appears that this will only work on i386 systems.
.Pq default 0
.El
.Sh DIAGNOSTICS
.Bl -diag
.It est%d: Enhanced SpeedStep Frequency Control on cpu%d
.Pp
Indicates normal startup of this interface.
.It est: CPU supports Enhanced Speedstep, but is not recognized.
.It est: cpu_vendor GenuineIntel, msr 471c471c0600471c
.It device_attach: est2 attach returned 6
.Pp
Indicates all attempts to attach to this interface have failed.
This usually indicates and improper BIOS setting restricting O/S
control of the CPU speeds.  Consult your BIOS documentation for
more details.
.El
.Sh COMPATIBILITY
.Nm
is only found on supported Intel CPUs.
.Sh SEE ALSO
.Xr cpufreq 4
.Sh SUPPORT
For general 

CFR: backup GPT header support in pmbr and loader(8) (Re: Handbook mirroring section)

[Hiroki Sato]

[move from -doc@ to -current@]

Andrey V. Elsukov a...@freebsd.org wrote
  in 4fd05573.70...@freebsd.org:

ae On 06.06.2012 15:07, Hiroki Sato wrote:
ae  ae 1. When geom_mirror module is not loaded GEOM_PART will complain that 
the
ae  ae backup GPT header is not in the last LBA and partition table will be 
marked
ae  ae as CORRUPT. The recover operation will destroy the GEOM_MIRROR's 
metadata.
ae  ae
ae  ae 2. If primary GPT header or table become damaged, then gptboot will 
not
ae  ae detect GPT because the backup GPT header is not in the last LBA. So, 
the
ae  ae system will not boot.
ae 
ae   Thanks, I see.  Do you think the attached patch is too aggressive for
ae   the problem 2?  The value of altlba should be matched with one in the
ae   original secondary header when the primary header is corrupted and
ae   the secondary header is looked up in this way.
ae
ae Yes, i also have thought about this and this should work for most GEOM 
classes,
ae but i revised again PMBR code and it seems that it will not work anyway :)
ae Our PMBR doesn't use backup GPT header and table, and it doesn't verify
ae correctness of primary GPT.
ae
ae From the other side, there are three situations when we use GPT:
ae 1. FreeBSD is only one system on the disk and we use PMBR and gptboot to 
boot it.
ae
ae In case if we will fix PMBR your patch will help.

 I created the attached patchset for the loader and pmbr to support
 backup GPT header when the primary one is corrupted.  Can anyone test
 and/or review it?

 The pmbr program now checks the GPT signature, and if failed it tries
 to search the backup header from the last LBA.  When GEOM metadata is
 found at the last LBA, the second last will be checked.  The
 loader(8) program also supports the same algorithm to search the
 backup header.

ae 2. FreeBSD is no one on the disk, but we still use legacy boot method 
(PMBR+gptboot).
ae
ae I don't know what behavior have other systems when they detect invalid GPT 
(i.e.
ae when backup header is not in the last LBA).
ae
ae 3. We use UEFI (it is not work yet).
ae
ae Also i don't know what UEFI firmware will do with invalid GPT.

 I am investigating how Windows and other UEFI-based software
 recognize the backup header now.  Hopefully they use the alternative
 LBA field and do not unconditionally overwrite the last LBA for
 recovering.  Probably it is difficult to make UEFI recognize the
 backup header that is not located at the last LBA when the primary
 header is corrupted.

-- Hiroki
Index: common/gpt.c
===
--- common/gpt.c	(revision 236848)
+++ common/gpt.c	(working copy)
@@ -40,6 +40,7 @@
 #include gpt.h

 #define	MAXTBLENTS	128
+#define	GEOM_MAGIC	GEOM::

 static struct gpt_hdr hdr_primary, hdr_backup, *gpthdr;
 static uint64_t hdr_primary_lba, hdr_backup_lba;
@@ -345,8 +346,18 @@
 		altlba = hdr_primary.hdr_lba_alt;
 	} else {
 		altlba = drvsize(dskp);
-		if (altlba  0)
-			altlba--;
+		if (altlba  0) {
+			do {
+altlba--;
+/*
+ * Check GEOM metadata and decrement
+ * the altlba if found.
+ */
+if (drvread(dskp, secbuf, altlba, 1) != 0)
+	break;
+			} while (memcmp(secbuf, GEOM_MAGIC,
+sizeof(GEOM_MAGIC) - 1) == 0);
+		}
 	}
 	if (altlba == 0)
 		printf(%s: unable to locate backup GPT header\n, BOOTPROG);
Index: i386/pmbr/pmbr.s
===
--- i386/pmbr/pmbr.s	(revision 236848)
+++ i386/pmbr/pmbr.s	(working copy)
@@ -42,8 +42,9 @@
 		.set STACK,EXEC+SECSIZE*4	# Stack address
 		.set GPT_ADDR,STACK		# GPT header address
 		.set GPT_SIG,0
-		.set GPT_SIG_0,0x20494645
-		.set GPT_SIG_1,0x54524150
+		.set GPT_SIG_0,0x20494645	# EFI 
+		.set GPT_SIG_1,0x54524150	# PART
+		.set GEOM_MAGIC,0x4d4f4547	# GEOM
 		.set GPT_MYLBA,24
 		.set GPT_PART_LBA,72
 		.set GPT_NPART,80
@@ -52,6 +53,8 @@
 		.set PART_TYPE,0
 		.set PART_START_LBA,32
 		.set PART_END_LBA,40
+		.set DPBUF,PART_ADDR+SECSIZE
+		.set DPBUF_SEC,0x10		# Number of sectors

 		.set NHRDRV,0x475		# Number of hard drives

@@ -91,16 +94,40 @@
 		jb main.2			# Yes
 main.1: 	movb $0x80,%dl			# Assume drive 0x80
 #
-# Load the primary GPT header from LBA 1 and verify signature.
+# Load the GPT header and verify signature.  Try LBA 1 for the primary one and
+# the last LBA for the backup if it is broken.  Skip the LBAs if GEOM
+# metadata found at the backup location.
 #
-main.2:		movw $GPT_ADDR,%bx
+main.2:		call getdrvparams		# Read drive parameters
+		movb $1,%dh			# %dh := 1 (reading primary)
+main.2a:	movw $GPT_ADDR,%bx
 		movw $lba,%si
-		call read
+		call read			# Read header and check GPT sig
 		cmpl $GPT_SIG_0,GPT_ADDR+GPT_SIG
-		jnz err_pt
+		jnz main.2b
 		cmpl $GPT_SIG_1,GPT_ADDR+GPT_SIG+4
-		jnz err_pt
+		jnz main.2b
+		jmp load_part
+main.2b:	cmpb $1,%dh			# Reading primary?
+		je main.3			# Try backup if yes
+		cmpl $GEOM_MAGIC,GPT_ADDR	# GEOM sig at backup location?
+		jz main.3			# Skip GEOM metadata

Re: IPv6 accept_rtadv + bfe0

[Hiroki Sato]

John Hay j...@meraka.org.za wrote
  in 20111022193418.ga53...@zibbi.meraka.csir.co.za:

jh I can maybe just say, I have now upgraded various machines from 7.x or
jh 8.x to 9 and even though I have read the rc.conf manual I keep tripping
jh on the new IPv6 rc stuff.  Various being client, server and router /
jh firewall. It looks like ipv6_prefix_IF now needs an ifconfig_IF_ipv6 =
jh inet6 auto_linklocal otherwise it is ignored.

 This is intentional because $ifconfig_IF_ipv6 is designed as
 per-interface version of the old $ipv6_enable.  I added an explicit
 description about this to rc.conf(5).

jh In the rc.conf man page, in the ifconfig_interface_ipv6 section, it is
jh suggested to use ifconfig_interface_aliasn for aliases, but somewhere
jh else it says that that _aliasn is deprecated. What would be nice is
jh something like the ipv4_addrs_IF= variable.

 $ipv6_prefix_IF is the counterpart of $ipv4_addrs_IF.  It is limited
 to /64 prefixes, though.

 I didn't notice it said ifconfig_IF_aliasN was deprecated.  Although
 the man page explains the depreciation is due to a difficult behavior
 of _aliasN, if it is the reason, it is easy to support multiple lines
 in the variable like this:

 ifconfig_em0_aliases=
inet 192.168.0.1/32
inet 192.168.0.2/32
inet 192.168.0.3/32
 

jh The last paragraph in ifconfig_interface_ipv6, about inet6 accept_rtadv
jh should probably be closer to the begining, with some added sentence to
jh make it clear that it is probably what the normal client machine needs.

 Moved it to just after a normal GUA configuration example in rc.conf(5).

-- Hiroki


pgpnl7G7gkY3x.pgp
Description: PGP signature

Re: IPv6 accept_rtadv + bfe0

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4ea23c08.6060...@freebsd.org:

do On 10/19/2011 00:29, Hiroki Sato wrote:
do  Mattia Rossi mro...@swin.edu.au wrote
doin 4e9dfe11.2070...@swin.edu.au:
do 
do  mr So the _ipv6 bit doesn't take care of passing inet6 to ifconfig
do  mr automatically?
do 
do   No.  You always need to add the inet6 keyword wherever needed.
do
do That seems redundant, and contrary to how the IPv4 equivalents work. And
do obviously it's confusing to users. From what I can see looking at some
do 7.x and 8.x systems it also seems to be a POLA violation.
do
do Perhaps this is something that you should reconsider?

 I am still thinking that omitting an address family keyword before an
 address is a bad practice.

 Omitting inet keyword in ifconfig_IF and doing in ifconfing_IF_AF
 are different.  The former one uses ifconfig(8)'s default AF, and
 bz's experiments of noinet/noinet6 environment showed it was
 problematic.  For the latter a keyword has to be automatically
 prepended in the rc.d scripts if we want to do so.  For IPv6, having
 a non-null $ifconfig_IF_ipv6 means the interface is IPv6-capable and
 doesn't always involve address configuration
 (e.g. ifconfig_IF_ipv6=up is valid).  So, automatic prepending of
 inet6 breaks this.  Thus, both have a bad side effect.

 And I want to make ifconfig accept a command line for v4-v6 and/or
 v6-v4 tunneling as a p2p link like inet 10.1.1.1 2001:db8::1 for a
 specific type of interfaces in the future.  I am not sure if it will
 happen actually, but omitting an AF keyword and/or automatic
 prepending of the keyword make things difficult.

-- Hiroki


pgpCsla8j2XGv.pgp
Description: PGP signature

Re: IPv6 accept_rtadv + bfe0

[Hiroki Sato]

Johann Hugo jh...@meraka.csir.co.za wrote
  in 201110190845.17950.jh...@meraka.csir.co.za:

jh On Tuesday, October 18, 2011 11:16:57 pm Bjoern A. Zeeb wrote:
jh  On 18. Oct 2011, at 20:00 , Johann Hugo wrote:
jh   Hi
jh  
jh   The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually 
do
jh   it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to
jh   ifconfig_bge0 in rc.conf it does nothing.
jh  
jh   grep bfe /etc/rc.conf
jh   ifconfig_bfe0=DHCP accept_rtadv
jh 
jh  ifconfig_bfe0=DHCP
jh  ifconfig_bfe0_ipv6=inet6 accept_rtadv
jh
jh That works, but what is the function of ipv6_activate_all_interfaces=YES 
in
jh rc.conf

 $ipv6_activate_all_interfaces has nothing to do with accept_rtadv and
 is not needed in most cases.  Please read rc.conf(5) for more
 details of the function.

-- Hiroki


pgpZwsbtIzyZH.pgp
Description: PGP signature

Re: About FreeBSD 9.0 release note

[Hiroki Sato]

Xin LI delp...@delphij.net wrote
  in 4e9dfd46.1040...@delphij.net:

de -BEGIN PGP SIGNED MESSAGE-
de Hash: SHA256
de
de On 10/18/11 15:07, Hiroki Sato wrote:
de  Hideki Yamamoto hyam...@gmail.com wrote in
de  CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com:
de 
de   hy Hi, hy hy Does someone know where is the draft of FreeBSD
de  9.0 release note? hy I would like to check if there is a
de  description about new functions hy about MLDv2 is included or
de  not. hy I think the below feature should be included in the
de  release note as hy IPv6 network is getting popular. hy hy
de  - hy MFC r200871: hy  Use
de  ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave
de  hy  with SSM MLDv2 by default. hy  This is current practice and
de  complies with RFC 4604, as well as being hy  required by
de  production IPv6 networks in Japan. hy  The behaviour may be
de  disabled by setting the net.inet6.mld.use_allow hy  sysctl/tunable
de  to 0. hy -
de 
de  I am already working on the relnotes and the above will be
de  included as an improvement of the IPv6 stack.
de
de Can we have it somewhere (in the CVS or wiki) so we can work together
de on that?  This way also makes translation easier...

 Yes, I will put it to some shared workspace as soon as possible.  I
 know I should have taken an action more quickly, but I couldn't make
 it.  Sorry.

-- Hiroki


pgpD7KsyBgoyG.pgp
Description: PGP signature

Re: IPv6 accept_rtadv + bfe0

[Hiroki Sato]

Mattia Rossi mro...@swin.edu.au wrote
  in 4e9dfe11.2070...@swin.edu.au:

mr So the _ipv6 bit doesn't take care of passing inet6 to ifconfig
mr automatically?

 No.  You always need to add the inet6 keyword wherever needed.

mr Does passing two options work, or do I have to pass them separately?
mr E.g.:
mr
mr ifconfig_bfe0_ipv6=inet6 accept_rtadv -ifdisable

 This should work.

-- Hiroki


pgpc4XjXAHbfz.pgp
Description: PGP signature

Re: About FreeBSD 9.0 release note

[Hiroki Sato]

Hideki Yamamoto hyam...@gmail.com wrote
  in CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com:

hy Hi,
hy
hy Does someone know where is the draft of FreeBSD 9.0 release note?
hy I would like to check if there is a description about new functions
hy about MLDv2 is included or not.
hy I think the below feature should be included in the release note as
hy IPv6 network is getting popular.
hy
hy -
hy MFC r200871:
hy  Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave
hy  with SSM MLDv2 by default.
hy  This is current practice and complies with RFC 4604, as well as being
hy  required by production IPv6 networks in Japan.
hy  The behaviour may be disabled by setting the net.inet6.mld.use_allow
hy  sysctl/tunable to 0.
hy -

 I am already working on the relnotes and the above will be included
 as an improvement of the IPv6 stack.

-- Hiroki


pgpooCpg10Xx0.pgp
Description: PGP signature

Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES

[Hiroki Sato]

Thomas Steen Rasmussen tho...@gibfest.dk wrote
  in 4e9aa874.5070...@gibfest.dk:

th On 14.10.2011 10:26, Thomas Steen Rasmussen wrote:
th  On 14-10-2011 10:09, Hiroki Sato wrote:
th   Thanks.  There is no problem with the source address selection.
th
th I don't understand this comment. I would say that I do
th have problems with the source address selection -
th otherwise it would be preferring ipv6, right ?

 I mean the address selection is working properly.  Your problem is
 because the default ipv6_prefer policy prefers IPv4 addresses when
 the source IPv6 addr is in 2002::/16, the destination IPv6 address is
 not in the same prefix, and IPv4 addresses can be used for the both.
 It is not a bug of the selection mechanism.

 The ipv6_prefer policy is defined in RFC 3484 2.1 and this policy
 chooses a src IPv6 addr in 2002::/16 only if the dest addr is also in
 the same prefix.  You can remove the special rule for 2002::/16 by
 putting the following lines as /etc/ip6addrctl.conf and reboot the
 system:

 ::1/128  50  0
 ::/0 40  1
 #2002::/16   30  2
 ::/9620  3
 :::0:0/9610  4

 By installing the above, IPv6 address will be preferred even if it is
 in 2002::/16.

 I am still not sure why there is a difference between 8.X and 9.X on
 your box because the code is almost the same.  I guess no policy was
 installed when you used an 8-stable system.

-- Hiroki


pgpdWwDjVjkUo.pgp
Description: PGP signature

Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES

[Hiroki Sato]

Thomas Steen Rasmussen tho...@gibfest.dk wrote
  in 4e97cffc.5020...@gibfest.dk:

th On 14.10.2011 02:52, Hiroki Sato wrote:
th   Can you please send me the results of the following commands:
th
th Please see the output below each command. I forgot to
th mention that the ipv6 uplink is a 6to4 tunnel, as you can
th see below from the 2002: prefix.

 Okay, what is the result of the following?

 % telnet www.freebsd.org 80  /dev/null

-- Hiroki


pgpooG9YS30qO.pgp
Description: PGP signature

Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES

[Hiroki Sato]

Thomas Steen Rasmussen tho...@gibfest.dk wrote
  in 4e97d9f3.4020...@gibfest.dk:

th On 14.10.2011 08:14, Hiroki Sato wrote:
th  telnet www.freebsd.org 80  /dev/null
th [tykling@tykburk ~]$ telnet www.freebsd.org 80  /dev/null
th Trying 69.147.83.34...
th Connected to red.freebsd.org.
th Escape character is '^]'.
th Connection closed by foreign host.

 Thanks.  There is no problem with the source address selection.  The
 last questions are:

 % route get -inet www.freebsd.org
 % route get -inet6 www.freebsd.org
 % netstat -nrf inet6
 % ndp -r

 I guess the second one returns route: writing to routing socket: No
 such process on your box.  Is it correct?

-- Hiroki


pgpR2d1AI6IIl.pgp
Description: PGP signature

Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES

[Hiroki Sato]

Thomas Steen Rasmussen tho...@gibfest.dk wrote
  in 4e9766c0.1020...@gibfest.dk:

th Hello list,
th
th I just upgraded my home workstation to 9.0-beta3 amd64. It seems
th like my web browsers are preferring ipv4 over ipv6 after the upgrade,
th I tested Firefox and Opera. After digging into rc.conf(5) I found this bit:
th
th  If ``AUTO'' is specified, it attempts to read a file
th  /etc/ip6addrctl.conf first.  If this file is found,
th  ip6addrctl(8) reads and installs it.  If not found, a policy
th  is automatically set according to
th  ipv6_activate_all_interfaces variable; if the variable is set
th  to ``YES'' the IPv6-preferred one is used.  Otherwise
th  IPv4-preferred.
th
th  The default value of ip6addrctl_enable and ip6addrctl_policy
th  are ``YES'' and ``AUTO'', respectively.
th
th I already have ipv6_activate_all_interfaces=YES in /etc/rc.conf
th so ip6addrctl_policy _should_ be ip6addrctl_policy if I am reading
th this correctly. But my browsers still prefer ipv4. Is this a bug, or
th do the manpage need updating ?

 Can you please send me the results of the following commands:

 % ifconfig

 % grep ^ipv6 /etc/rc.conf

 % grep ipv6= /etc/rc.conf

 % ip6addrctl show

 # /bin/sh -x /etc/rc.d/ip6addrctl start

-- Hiroki


pgp9Ararm4uMe.pgp
Description: PGP signature

RFC: /etc/pccard_ether triggered by usbus

[Hiroki Sato]

Hi,

 I would like your comments about adding NOT operator into string
 match rule in devd.conf.  The reason is as follows.

 After the USB packet filter was added, devctl attach notifications
 from an IFT_USB interface like !system=IFNET subsystem=usbus0
 type=ATTACH trigger a default rule for interface initialization in
 devd.conf.  Although it is harmless in most cases, it would be great
 if we can filter out the notifications because it can result in a
 slower booting.  However, the devd supports no NOT operator in a
 string match.

 The attached patch is to add the ! operator into the match
 sub-statement.  For example,

  match bus pccard[0-9]+

 matches the content of bus against a regex pccard[0-9]+.  The !
 operator like the following

  match bus !pccard[0-9]+

 inverts the logic.

 I am still not sure if this is the best approach but I could not find
 another way.  Filtering out it in if_attach() or adding a new
 variable like configurable=yes in the notification looks overkill
 to me.

 Any comments/suggestions?

-- Hiroki
Index: etc/devd.conf
===
--- etc/devd.conf	(revision 225668)
+++ etc/devd.conf	(working copy)
@@ -38,6 +38,7 @@
 #
 notify 0 {
 	match system		IFNET;
+	match subsystem	!usbus[0-9]+;
 	match type		ATTACH;
 	action /etc/pccard_ether $subsystem start;
 };
Index: sbin/devd/devd.hh
===
--- sbin/devd/devd.hh	(revision 225668)
+++ sbin/devd/devd.hh	(working copy)
@@ -92,6 +92,7 @@
 private:
 	std::string _var;
 	std::string _re;
+	bool _inv;
 	regex_t _regex;
 };

Index: sbin/devd/devd.cc
===
--- sbin/devd/devd.cc	(revision 225668)
+++ sbin/devd/devd.cc	(working copy)
@@ -251,7 +251,14 @@
 	: _var(var)
 {
 	_re = ^;
-	_re.append(c.expand_string(string(re)));
+	if (!c.expand_string(string(re)).empty() 
+	c.expand_string(string(re)).at(0) == '!') {
+		_re.append(c.expand_string(string(re)).substr(1));
+		_inv = 1;
+	} else {
+		_re.append(c.expand_string(string(re)));
+		_inv = 0;
+	}
 	_re.append($);
 	regcomp(_regex, _re.c_str(), REG_EXTENDED | REG_NOSUB | REG_ICASE);
 }
@@ -268,10 +275,13 @@
 	bool retval;

 	if (Dflag)
-		fprintf(stderr, Testing %s=%s against %s\n, _var.c_str(),
-		value.c_str(), _re.c_str());
+		fprintf(stderr, Testing %s=%s against %s, invert=%d\n,
+		_var.c_str(), value.c_str(), _re.c_str(), _inv);

 	retval = (regexec(_regex, value.c_str(), 0, NULL, 0) == 0);
+	if (_inv == 1)
+		retval = (retval == 0) ? 1 : 0;
+
 	return retval;
 }



pgpCnMydnPFSv.pgp
Description: PGP signature

Re: fsid change of ZFS?

[Hiroki Sato]

Hi Rick,

Rick Macklem rmack...@uoguelph.ca wrote
  in 468764384.310026.1314219682612.javamail.r...@erie.cs.uoguelph.ca:

rm It sounds like people have agreed that this is a reasonable solution.
rm If hrs@ can confirm that testing shows it fixes the original problem
rm (the ZFS file handles don't change when it's loaded at different times),
rm I'll pass it along to re@.

 I am sorry for the delay, but I tried the patch on several boxes and
 it worked fine:

 [old (fixed array) patch]
 % lsvfs
 Filesystem   Num  Refs Flags
  --- - ---
 ufs2 3
 oldnfs15 0 network
 zfs7 4 jail, delegated-administration
 nfs6 1 network
 cd9660 1 0 read-only
 procfs 3 0 synthetic
 devfs  4 1 synthetic
 msdosfs5 0

 [new (hash-based) patch]
 Filesystem   Num  Refs Flags
  --- - ---
 ufs   53 3
 oldnfs77 0 network
 zfs  222 4 jail, delegated-administration
 nfs   58 0 network
 cd9660   189 0 read-only
 procfs 2 0 synthetic
 devfs113 1 synthetic
 msdosfs   50 0

 [new patch, different loading order of kld modules]
 Filesystem   Num  Refs Flags
  --- - ---
 ufs   53 3
 zfs  222 4 jail, delegated-administration
 cd9660   189 0 read-only
 procfs 2 0 synthetic
 devfs113 1 synthetic
 msdosfs   50 0
 nfs   58 0 network

 Thanks a lot for the patch.  I think it should be committed before
 9.0R is released.

 Even for 8-STABLE this is useful but there is a problem that it will
 make an incomptibility of the fsid calculation between 8.N and
 8.(N+1).  What do you think about adding a loader tunable (something
 like vfs.fsidhash) to control this and making it disable by default?
 It would help sysadmins who will try a upgrade from 8.X to 9.X in the
 future, I think.

-- Hiroki


pgpqylKNsLgiT.pgp
Description: PGP signature

Re: fsid change of ZFS?

[Hiroki Sato]

Rick Macklem rmack...@uoguelph.ca wrote
  in 468764384.310026.1314219682612.javamail.r...@erie.cs.uoguelph.ca:

rm Pawel Jakub Dawidek wrote:
rm  On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
rm   On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
rmWell, doesn't this result in the same issue as the fixed table?
rmIn other words, the developer has to supply the suggested byte
rmfor
rmfsid and make sure that it doesn't conflict with other suggested
rmbyte
rmvalues or suffer the same consequence as forgetting to update the
rmfixed
rmtable. (ie. It just puts the fixed value in a different place,
rmfrom what
rmI see, for in-tree modules. Also, with a fixed table, they are all
rmin
rmone place, so it's easy to choose a non-colliding value?)
rm   The reason for my proposal was Pawel note that a porter of the
rm   filesystem
rm   should be aware of some place in kern/ where to register, besides
rm   writing
rm   the module.
rm 
rm  Well, he has to be aware, but we should do all we can to minimize the
rm  number of place he needs to update, as it is easy to forget some.
rm 
rm  I agree with Rick that what you proposed is similar to fixed table of
rm  file system names and I'd prefer to avoid that. If we can have
rm  name-based hash that produces no collision for in-tree file systems
rm  and
rm  know current 3rd party file systems plus collision detection for the
rm  future then it is good enough, IMHO. And this is what Rick proposed
rm  with
rm  his patch.
rm 
rm Ok, here is the list of file system names I've been checking and there
rm haven't been any collisions (either hash function). If you know of other
rm well known file type names, please email and I'll add them to the list
rm and check for collisions again.
rm
rm cd9660
rm ufs
rm procfs
rm devfs
rm msdosfs
rm nfs
rm xfs
rm reiserfs
rm tmpfs
rm hpfs
rm ntfs
rm ext2fs
rm udf
rm zfs
rm afs
rm
rm and here is my current rendition of the patch. (I took Gleb's suggestion
rm and switched to fnv_32_str(). I'll leave it that way unless there is a
rm collision after adding any names people post to the above list.)
rm
rm It sounds like people have agreed that this is a reasonable solution.
rm If hrs@ can confirm that testing shows it fixes the original problem
rm (the ZFS file handles don't change when it's loaded at different times),
rm I'll pass it along to re@.

 Thank you!  I will try the latest patch by Saturday.

-- Hiroki


pgpaTZdSmz5WW.pgp
Description: PGP signature

Re: fsid change of ZFS?

[Hiroki Sato]

Kostik Belousov kostik...@gmail.com wrote
  in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:

ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
ko  On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
ko   Pawel Jakub Dawidek wrote:
koOn Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
ko Ok, I'll admit I wasn't very fond of a fixed table that would
ko inevitably
ko get out of date someday, either.
ko
ko I didn't think hashing for the cases not in the table was worth the
ko effort,
ko but doing a hash instead of a table seems reasonable.
ko
ko I see that ZFS only uses the low order 8 bits, so I'll try and come
ko up
ko with an 8bit hash solution and will post a patch for testing/review
ko soon.
ko
ko I don't think the vfs_sysctl() is that great a concern, given that
ko it
ko appears to be deprecated already anyhow. (With an 8bit hash,
ko vfs_typenum
ko won't be that sparse.) I'll also make sure that whatever hash I use
ko doesn't collide for the current list of file names (although I will
ko include
ko code that handles a collision in the patch).
ko   
koSounds great. Thanks!
ko   
ko   Here's the patch. (Hiroki could you please test this, thanks, rick.)
ko   ps: If the white space gets trashed, the same patch is at:
ko  http://people.freebsd.org/~rmacklem/fsid.patch
ko 
ko  The patch is fine by me. Thanks, Rick!
ko
ko Sorry, I am late.
ko
ko It seems that the probability of the collisions for the hash is quite high.
ko Due to the fixup procedure, the resulting typenum will depend on the order
ko of the module initialization, isn't it ? IMO, it makes the patch goal not
ko met.

 I tried the following two experiments (the complete results are
 attached) to confirm the probability:

 1. [fsidhash1.txt]
well-known vfc_name and the names [a-z]fs (# of names is 36)
with no fix-up recalculation.

 2. [fsidhash2.txt]
well-known vfc_name and the names [a-z][a-z]fs (# of names is 710)
with no fix-up recalculation.

 There is no collision in the case 1.  And when [a-z][a-z]fs are
 included the average number of the collided names in the same hash
 value is 4.43 (i.e. 160 different hash values are generated, the
 theoretical best number is (710 entries / 256 buckets) = 2.77).

 At least, vfc_names we currently have in our kernel code have no
 collision, fortunately.  As you noticed [a-z][a-z]fs is an
 impractical data set and these results cannot explain the
 characteristics for all possible and practical vfc_names, so whether
 this hash is reasonable or not depends on how we think of them.
 Comments or other better idea?

-- Hiroki
0x09 = tfs
0x0b = tmpfs
0x0f = ifs
0x1f = xfs
0x24 = mfs
0x2a = bfs
0x39 = qfs
0x3b = msdosfs
0x3f = ffs
0x45 = ntfs
0x4e = ufs
0x54 = jfs
0x64 = yfs
0x69 = nfs
0x6f = cfs
0x7e = rfs
0x81 = devfs
0x84 = gfs
0x87 = ext2fs
0x89 = procfs
0x94 = vfs
0x99 = kfs
0x9c = hpfs
0xa1 = cd9660
0xa9 = zfs
0xae = ofs
0xb4 = dfs
0xc3 = sfs
0xca = hfs
0xcb = reiserfs
0xd9 = wfs
0xdf = lfs
0xe5 = afs
0xf4 = pfs
0xfa = efs
0xfe = udf
0x00 = awfs, difs, infs, nsfs, qefs, sxfs, vjfs
0x02 = owfs
0x03 = emfs, jrfs, mdfs, rifs, wnfs
0x05 = fqfs, smfs
0x06 = alfs, icfs, kvfs, nhfs, xrfs
0x08 = jgfs, wcfs
0x09 = bpfs, ebfs, gufs, lzfs, olfs, tfs, tqfs, yvfs
0x0b = aafs, tmpfs, zzfs
0x0c = ctfs, fffs, hyfs, kkfs, ppfs, sbfs, uufs, xgfs
0x0e = dxfs, qtfs
0x0f = befs, gjfs, ifs, lofs, oafs, tffs, vyfs, ykfs
0x11 = hnfs, ujfs
0x12 = cifs, msfs, pefs, rxfs, zofs
0x14 = ldfs
0x15 = dmfs, irfs, nwfs, qifs, vnfs
0x18 = eqfs, hcfs, jvfs, mhfs, rmfs, wrfs, zdfs
0x1a = fufs, sqfs
0x1b = apfs, dbfs, igfs, kzfs, nlfs, vcfs, xvfs
0x1d = jkfs
0x1e = btfs, effs, gyfs, opfs, rbfs, tufs, wgfs, yzfs
0x1f = xfs
0x20 = aefs, nafs
0x21 = cxfs, fjfs, kofs, ptfs, sffs, uyfs, xkfs
0x24 = bifs, gnfs, lsfs, mfs, oefs, qxfs, tjfs, yofs
0x26 = hrfs
0x27 = cmfs, kdfs, mwfs, pifs, unfs, zsfs
0x2a = bfs, dqfs, gcfs, ivfs, lhfs, qmfs, vrfs, ydfs
0x2c = cbfs
0x2d = eufs, hgfs, jzfs, mlfs, rqfs, ucfs, wvfs, zhfs
0x2f = fyfs
0x30 = atfs, dffs, ikfs, npfs, qbfs, sufs, vgfs, xzfs
0x33 = bxfs, ejfs, jofs, mafs, otfs, rffs, tyfs, wkfs
0x36 = aifs, fnfs, ksfs, nefs, pxfs, sjfs, xofs
0x39 = bmfs, grfs, jdfs, lwfs, oifs, qfs, tnfs, ysfs
0x3b = msdosfs
0x3c = cqfs, fcfs, hvfs, khfs, pmfs, urfs, xdfs, zwfs
0x3f = bbfs, dufs, ffs, ggfs, izfs, llfs, qqfs, tcfs, vvfs, yhfs
0x42 = eyfs, hkfs, mpfs, pbfs, rufs, ugfs, wzfs, zlfs
0x43 = cffs
0x45 = axfs, djfs, iofs, lafs, ntfs, qffs, syfs, vkfs
0x48 = enfs, jsfs, mefs, oxfs, rjfs, wofs, zafs
0x4b = frfs, idfs, kwfs, nifs, snfs, xsfs
0x4c = amfs
0x4e = bqfs, gvfs, jhfs, omfs, trfs, ufs, wdfs, ywfs
0x4f = ecfs
0x51 = abfs, cufs, fgfs, hzfs, klfs, pqfs, scfs, uvfs, xhfs
0x54 = bffs, dyfs, gkfs, jfs, lpfs, obfs, qufs, tgfs, vzfs, ylfs
0x57 = hofs, kafs, mtfs, pffs, ryfs, ukfs, zpfs
0x58 = cjfs
0x5a = dnfs, isfs, lefs, nxfs, qjfs, vofs
0x5b = yafs

Re: fsid change of ZFS?

[Hiroki Sato]

Gleb Kurtsou gleb.kurt...@gmail.com wrote
  in 20110824150235.GA46460@tops:

gl On (24/08/2011 21:34), Hiroki Sato wrote:
gl  Kostik Belousov kostik...@gmail.com wrote
glin 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
gl 
gl  ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
gl  ko  On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
gl  ko   Here's the patch. (Hiroki could you please test this, thanks, 
rick.)
gl  ko   ps: If the white space gets trashed, the same patch is at:
gl  ko  http://people.freebsd.org/~rmacklem/fsid.patch
gl  ko 
gl  ko  The patch is fine by me. Thanks, Rick!
gl  ko
gl  ko Sorry, I am late.
gl  ko
gl  ko It seems that the probability of the collisions for the hash is quite 
high.
gl  ko Due to the fixup procedure, the resulting typenum will depend on the 
order
gl  ko of the module initialization, isn't it ? IMO, it makes the patch goal 
not
gl  ko met.
gl 
gl   I tried the following two experiments (the complete results are
gl   attached) to confirm the probability:
gl 
gl   1. [fsidhash1.txt]
glwell-known vfc_name and the names [a-z]fs (# of names is 36)
glwith no fix-up recalculation.
gl 
gl   2. [fsidhash2.txt]
glwell-known vfc_name and the names [a-z][a-z]fs (# of names is 710)
glwith no fix-up recalculation.
gl 
gl   There is no collision in the case 1.  And when [a-z][a-z]fs are
gl   included the average number of the collided names in the same hash
gl   value is 4.43 (i.e. 160 different hash values are generated, the
gl   theoretical best number is (710 entries / 256 buckets) = 2.77).
gl Could you run the same test with fnv_32_buf()? Collision rate is likely
gl to be lower.

 The results by fnv_32_str() are attached.  The number of the
 collisions reduced but this time there were four collisions in the
 well-known ones + [a-z]fs case though no collision within the
 well-known names.

 The generated hash values for the case 2 was 235, so the rate is
 3.02.  This is certainly better than hash32_str().

-- Hiroki
0x0d = yfs
0x13 = mfs
0x19 = procfs
0x1a = kfs
0x30 = bfs
0x34 = ufs
0x3a = gfs
0x40 = sfs, udf
0x56 = jfs
0x5a = ntfs
0x5d = ext2fs
0x61 = devfs
0x6f = hpfs
0x75 = hfs
0x7a = pfs
0x7b = ofs
0x7c = dfs
0x81 = wfs
0x88 = msdosfs
0xa0 = cd9660
0xa1 = lfs, xfs
0xa8 = cfs, tfs
0xbf = tmpfs
0xc0 = afs
0xc2 = reiserfs
0xc6 = ifs
0xc8 = ffs, rfs
0xec = qfs
0xed = zfs
0xee = efs
0xef = nfs
0xf4 = vfs
0x01 = mcfs, prfs, xufs
0x02 = iafs, jifs, kpfs, xifs
0x04 = bzfs, dbfs, ehfs, ewfs, klfs, yhfs
0x05 = ycfs
0x06 = dyfs, ecfs, ipfs, qdfs, qpfs
0x07 = pnfs, ywfs
0x08 = qofs, xafs
0x09 = bmfs, iffs, iyfs, kdfs, pufs, vffs
0x0a = imfs
0x0b = bffs, dmfs
0x0c = idfs, yofs
0x0d = adfs, nmfs, pafs, vqfs, yfs
0x0e = aifs, qwfs
0x0f = hafs, nffs, vzfs
0x10 = zafs
0x11 = wcfs
0x12 = zjfs
0x13 = mfs, nqfs, wwfs
0x14 = nefs, vcfs
0x15 = bkfs
0x16 = clfs, zifs
0x17 = njfs, zrfs
0x18 = ocfs, owfs, tvfs, wdfs
0x19 = fefs, procfs, tbfs, vwfs, zffs
0x1a = fnfs, fqfs, kfs
0x1b = gofs, ryfs
0x1d = fzfs, rmfs, rrfs, skfs
0x1e = odfs, tqfs
0x1f = lvfs, oofs, oxfs, rffs, tzfs
0x20 = eefs, gwfs, kmfs, tmfs, xcfs
0x21 = ulfs, yqfs
0x22 = fbfs, hrfs, mtfs, qifs, sxfs, xjfs
0x23 = dofs, sdfs, ssfs, ugfs
0x24 = etfs, kofs, usfs, uxfs
0x25 = kqfs, ljfs, mkfs, opfs, pcfs
0x26 = jrfs, pwfs, qxfs
0x27 = ghfs
0x28 = hjfs, xvfs
0x29 = hufs, ikfs, jpfs, ksfs, slfs
0x2a = byfs, jefs, khfs, ukfs
0x2b = brfs, dhfs, jnfs, ytfs
0x2c = defs, hwfs, msfs
0x2d = apfs, qlfs
0x2e = pdfs, pifs, vefs
0x2f = befs, cgfs, hmfs, iwfs, jlfs, vnfs
0x30 = bfs, bjfs, jwfs
0x31 = csfs, cxfs
0x33 = alfs, axfs, vyfs
0x34 = ufs
0x35 = acfs, jcfs, vvfs
0x36 = awfs, bcfs, vbfs
0x37 = wkfs
0x38 = tofs
0x3a = fmfs, gfs
0x3b = nvfs
0x3c = nbfs, rqfs
0x3d = tgfs, tsfs, zwfs
0x3e = wlfs, zzfs
0x3f = fkfs, wgfs, znfs
0x40 = dvfs, gcfs, sfs, thfs, udf, wpfs
0x41 = fwfs
0x42 = pzfs, rwfs, udfs
0x43 = dgfs, lgfs, sgfs
0x44 = rkfs
0x45 = dnfs, llfs, lsfs, ogfs
0x46 = lxfs, pkfs, wxfs
0x47 = dqfs, eofs, gdfs, xofs
0x48 = dzfs, pbfs, upfs, xdfs, xpfs
0x49 = qcfs
0x4a = dsfs, pvfs, rcfs
0x4b = exfs, jzfs, mhfs, ohfs
0x4c = esfs, gpfs, ylfs
0x4d = qtfs, ygfs
0x4e = hbfs, hofs, ihfs
0x4f = bhfs, hvfs, icfs, uvfs
0x50 = bwfs, ktfs, mnfs, stfs
0x51 = ejfs
0x53 = itfs
0x54 = qffs, vkfs, vtfs
0x56 = bofs, cofs, jfs, jkfs
0x57 = iofs, yjfs
0x59 = qrfs
0x5a = atfs, ntfs, vsfs
0x5b = akfs
0x5d = ccfs, chfs, ctfs, ext2fs, zlfs, zxfs
0x5e = fvfs, wzfs
0x60 = nsfs, rjfs, wsfs
0x61 = devfs, ftfs, nofs, nxfs
0x62 = agfs, fjfs, xbfs
0x63 = ojfs
0x64 = grfs, kgfs, rhfs, rvfs, tkfs, wofs, zcfs, ztfs
0x65 = lofs, ttfs
0x66 = fhfs, gffs
0x67 = mgfs, ngfs, svfs, xsfs
0x68 = fsfs, sbfs
0x69 = ppfs, rtfs, zkfs
0x6a = jxfs, rofs, uhfs
0x6b = dkfs, elfs, kkfs, mefs, mpfs, ucfs
0x6c = omfs, txfs, yxfs
0x6d = egfs, fgfs, pgfs, ysfs
0x6e = gufs, gxfs, kbfs, plfs, uafs, xgfs
0x6f = hpfs
0x70 = myfs, qkfs, sqfs, uzfs
0x71 = epfs, jtfs, kxfs
0x72 = mbfs, ydfs
0x73 = hgfs, hsfs
0x74 = ekfs, ykfs
0x75 = cvfs, hfs, qsfs

Re: fsid change of ZFS?

[Hiroki Sato]

Rick Macklem rmack...@uoguelph.ca wrote
  in 920337541.272757.1314192294772.javamail.r...@erie.cs.uoguelph.ca:

rm Kostik Belousov wrote:
rm  On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
rm   On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
rmPawel Jakub Dawidek wrote:
rm On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
rm  Ok, I'll admit I wasn't very fond of a fixed table that would
rm  inevitably
rm  get out of date someday, either.
rm 
rm  I didn't think hashing for the cases not in the table was
rm  worth the
rm  effort,
rm  but doing a hash instead of a table seems reasonable.
rm 
rm  I see that ZFS only uses the low order 8 bits, so I'll try and
rm  come
rm  up
rm  with an 8bit hash solution and will post a patch for
rm  testing/review
rm  soon.
rm 
rm  I don't think the vfs_sysctl() is that great a concern, given
rm  that
rm  it
rm  appears to be deprecated already anyhow. (With an 8bit hash,
rm  vfs_typenum
rm  won't be that sparse.) I'll also make sure that whatever hash
rm  I use
rm  doesn't collide for the current list of file names (although I
rm  will
rm  include
rm  code that handles a collision in the patch).
rm
rm Sounds great. Thanks!
rm
rmHere's the patch. (Hiroki could you please test this, thanks,
rmrick.)
rmps: If the white space gets trashed, the same patch is at:
rm   http://people.freebsd.org/~rmacklem/fsid.patch
rm  
rm   The patch is fine by me. Thanks, Rick!
rm 
rm  Sorry, I am late.
rm 
rm  It seems that the probability of the collisions for the hash is quite
rm  high.
rm  Due to the fixup procedure, the resulting typenum will depend on the
rm  order
rm  of the module initialization, isn't it ? IMO, it makes the patch goal
rm  not
rm  met.
rm Well, the about 15 file system types currently in FreeBSD don't collide.
rm (At least with the patch I posted. I'll test it again with hash  0xff;.)
rm
rm Also, since the collision results in the second one using the next higher
rm value (usually, until you get something like 50+ file system types), it 
works
rm for those cases unless the order that these 2 file systems call 
vfs_register()
rm is reversed. (The likelyhood of this reversal is lower than the likelyhood
rm of vfs_register() just being called in a different order, I think?)
rm
rm Since it now changes whenever a different kernel config or different module
rm loading order is used and there aren't a lot of complaints, I think usually
rm works is good enough. However, it doesn't matter to me, so I'll let others
rm decide.
rm
rm Yet another option is to go back to what hrs@ originally suggested, which
rm was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't
rm conflict with any assigned vfc_typenum values, since they start at 1 and
rm 255 would also probably be safe, since its unlikely there ever will be
rm 255 different file system types.) The problem with this is no future FS
rm can use the same trick.

 My opinion is using a hash function which occurs no collision in the
 well-known names is sufficient for our purpose because the number of
 file systems on a running system is small anyway and not changed
 frequently in most cases.  I am not sure which function is best;
 fnv_32_str() seemed better against a large data set but it is not
 likely to have 30 file systems, for example.

-- Hiroki


pgp5gcbSw2jiZ.pgp
Description: PGP signature

Re: fsid change of ZFS?

[Hiroki Sato]

Hi Rick,

Rick Macklem rmack...@uoguelph.ca wrote
  in 59520805.118597.1313885734529.javamail.r...@erie.cs.uoguelph.ca:

rm Hiroki, could you please test the attached patch.
rm
rm One problem with this patch is that I don't know how to create a fixed
rm table that matches what systems would already have been getting.
rm (I got the first 6 entries by booting a GENERIC i386 kernel with a
rm  printf in vfs_init(), so I suspect those don't change much, although
rm  I'm not sure if ZFS will usually end up before or after them?)
rm
rm Do you guys know what ZFS gets assigned typically? (I realize that
rm changes w.r.t. when it gets loaded, so the question also becomes
rm do you know how it typically gets loaded so the table can have
rm that vfc_typenum value assigned to it?)
rm Maybe you could boot a system with a printf like:
rm
rm printf(%s, %d\n, vfc-vfc_name, vfc-vfc_typenum);
rm
rm just after vfc-vfc_typenum = maxvfsconf++; in vfs_init() and
rm then look in dmesg after booting, to see what your tables look like?
rm (Without the attached patch installed.)
rm
rm Thanks, rick
rm ps: The patch is also at
rm  http://people.freebsd.org/~rmacklem/fsid.patch for anyone on
rm the list interested (if the attachment doesn't make it through.
rm
rm
rm rick

 Yes, we can think the typical number of zfs is 7 on GENERIC.

 However, I checked vfc_typenum in three boxes around me by using the
 attached patch for lsvfs(1), but the results were not consistent:

 Machine A (8-STABLE)
 |
 |Filesystem   Num  Refs Flags
 | --- - ---
 |msdosfs1 0
 |procfs 2 0 synthetic
 |devfs  3 4 synthetic
 |cd9660 4 0 read-only
 |nfs5 2 network
 |ufs6 6

 Machine B (HEAD with newnfs complied)
 |
 |Filesystem   Num  Refs Flags
 | --- - ---
 |msdosfs1 0
 |ufs2 5
 |nfs3 0 network
 |cd9660 4 0 read-only
 |procfs 5 0 synthetic
 |devfs  6 1 synthetic
 |zfs7 1 jail, delegated-administration
 |

 Machine C (HEAD with oldnfs compiled)
 |
 |Filesystem   Num  Refs Flags
 | --- - ---
 |ufs1 3
 |msdosfs3 0
 |procfs 4 0 synthetic
 |devfs  5 1 synthetic
 |oldnfs 6 0 network
 |cd9660 7 0 read-only
 |zfs8 4 jail, delegated-administration
 |nfs9 1 network

 I guess the ordering is timing-dependent and consistent only in the
 same box.

 The result of the Machine C was changed like the following after
 applying the patch.  It worked as expected:

 |Filesystem   Num  Refs Flags
 | --- - ---
 |ufs2 3
 |oldnfs15 0 network
 |zfs7 4 jail, delegated-administration
 |devfs  4 1 synthetic
 |msdosfs5 0
 |nfs6 0 network
 |cd9660 1 0 read-only
 |procfs 3 0 synthetic

 Hmm, based on these results it looks difficult to assign the same
 number to each file system.  Anyway, not fixing them is worse, so we
 may have to accept this as a small upgrade bump in 9.0R.

-- Hiroki
Index: usr.bin/lsvfs/lsvfs.1
===
--- usr.bin/lsvfs/lsvfs.1	(revision 225066)
+++ usr.bin/lsvfs/lsvfs.1	(working copy)
@@ -2,7 +2,7 @@
 .\ Garrett A. Wollman, September 1994
 .\ This file is in the public domain.
 .\
-.Dd March 16, 1995
+.Dd August 22, 2011
 .Dt LSVFS 1
 .Os
 .Sh NAME
@@ -36,6 +36,8 @@
 .Fl t
 option to
 .Xr mount 8
+.It Num
+the filesystem type number.
 .It Refs
 the number of references to this VFS; i.e., the number of currently
 mounted file systems of this type
Index: usr.bin/lsvfs/lsvfs.c
===
--- usr.bin/lsvfs/lsvfs.c	(revision 225066)
+++ usr.bin/lsvfs/lsvfs.c	(working copy)
@@ -17,9 +17,9 @@
 #include stdlib.h
 #include string.h

-#define FMT %-32.32s %5d %s\n
-#define HDRFMT %-32.32s %5.5s %s\n
-#define DASHES  - ---\n
+#define FMT %-32.32s %3d %5d %s\n
+#define HDRFMT %-32.32s %3s 

Re: fsid change of ZFS?

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20110819.002046.908756241495481148@allbsd.org:

hr Hi,
hr
hr  I have experienced Stale NFS file handle issue when switching
hr  between oldnfs and newnfs on a CURRENT box (NFS server exporting ZFS
hr  mountpoints).  The cause was that fsid was changed in the following
hr  conditions and not in the NFS subsystem itself, but I am wondering if
hr  these are expected behavior...
hr
hr  First, I tried the following configurations of NFS and ZFS, and saw
hr  if fsid of the same mountpoint (a mounted ZFS dataset) changed or
hr  not by using statfs(2):
hr
hr  compile opts   kld module  fsid[0:1]   kld 
loaded by
hr  

hr  NFSSERVER+NFSCLIENTzfs 865798fa:8346ef02   loader
hr
hr  NFSSERVER+NFSCLIENTzfs 865798fa:8346ef07   
kldload(8)
hr
hr  NFSSERVER+NFSCLIENT+
hr  NFSD+NFSCL zfs 865798fa:8346ef03   loader
hr
hr  NFSSERVER+NFSCLIENT+
hr  NFSD+NFSCL zfs 865798fa:8346ef08   kldload(8)
hr
hr  NFSSERVER+NFSCLIENTnfsd+nfscl+zfs  865798fa:8346ef08   loader
hr  


 Ah, I found why this happened:

   /*
* The fsid is 64 bits, composed of an 8-bit fs type, which
* separates our fsid from any other filesystem types, and a
* 56-bit objset unique ID.  The objset unique ID is unique to
* all objsets open on this system, provided by unique_create().
* The 8-bit fs type must be put in the low bits of fsid[1]
* because that's where other Solaris filesystems put it.
*/
   fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
   ASSERT((fsid_guid  ~((1ULL56)-1)) == 0);
   vfsp-vfs_fsid.val[0] = fsid_guid;
   vfsp-vfs_fsid.val[1] = ((fsid_guid32)  8) |
   vfsp-mnt_vfc-vfc_typenum  0xFF;

 Since the vfc_typenum variable is incremented every time a new vfs is
 installed, loading order of modules that call vfs_register() affects
 ZFS's fsid.

 Anyway, possibility of fsid change is troublesome especially for an
 NFS server with a lot of clients running.  Can zeroing or setting a
 fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful?

-- Hiroki


pgpV3vmW4Frcl.pgp
Description: PGP signature

Re: fsid change of ZFS?

[Hiroki Sato]

Rick Macklem rmack...@uoguelph.ca wrote
  in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:

rm Hiroki Sato wrote:
rm  fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm  ASSERT((fsid_guid  ~((1ULL56)-1)) == 0);
rm  vfsp-vfs_fsid.val[0] = fsid_guid;
rm  vfsp-vfs_fsid.val[1] = ((fsid_guid32)  8) |
rm  vfsp-mnt_vfc-vfc_typenum  0xFF;
rm 
rm  Since the vfc_typenum variable is incremented every time a new vfs is
rm  installed, loading order of modules that call vfs_register() affects
rm  ZFS's fsid.
rm 
rm  Anyway, possibility of fsid change is troublesome especially for an
rm  NFS server with a lot of clients running. Can zeroing or setting a
rm  fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful?
rm 
rm  -- Hiroki
rm Well, the problem is that the fsid needs to be unique among all mounts.
rm The vfs_typenum field is used to try and ensure that it does not end up
rm the same value as a non-ZFS file system.
rm
rm (A) I think making that field a fixed constant should be ok, if the function
rm checks for a conflict by calling vfs_getvfs() to check for one.
rm See vfs_getnewfsid() for how this is done. (There is a mutex lock that
rm needs to be held while doing it.) Alternately, if ZFS can call 
vfs_getnewfsid()
rm instead of doing its own, that might be nicer?
rm
rm (B) Another way to fix this would be to modify vfs_register() to look up
rm file systems in a table (by vfc_name) and used a fixed, assigned value
rm from the table for vfc_typenum for entries found in the table. Only do
rm the maxvfsconf++ when there isn't an entry for the fstype in the table.
rm (VFS_GENERIC can be set to the size of the table. That's what happened
rm  in the bad old days when vfsconf was a table built at kernel config time.)
rm
rm If you guys think (B) is preferred, I could come up with a patch. I don't
rm know enough about ZFS to do (A).

rm Oh, and I think other fs types will suffer the same fate, except that
rm they usually avoid it, because they are compiled into the kernel and
rm the assignment of vfs_typenum happens in the same order--same value.

 Yes, using vfs_getnewfsid() does not solve the issue.

 I noticed that Solaris looked up a fixed array vfssw[] exactly for
 the purpose.  I think a table like it is a good solution for fixing
 fsid for each file system.

-- Hiroki


pgpn7hZbYSoTB.pgp
Description: PGP signature

fsid change of ZFS?

[Hiroki Sato]

Hi,

 I have experienced Stale NFS file handle issue when switching
 between oldnfs and newnfs on a CURRENT box (NFS server exporting ZFS
 mountpoints).  The cause was that fsid was changed in the following
 conditions and not in the NFS subsystem itself, but I am wondering if
 these are expected behavior...

 First, I tried the following configurations of NFS and ZFS, and saw
 if fsid of the same mountpoint (a mounted ZFS dataset) changed or
 not by using statfs(2):

 compile opts   kld module  fsid[0:1]   kld loaded by
 
 NFSSERVER+NFSCLIENTzfs 865798fa:8346ef02   loader

 NFSSERVER+NFSCLIENTzfs 865798fa:8346ef07   kldload(8)

 NFSSERVER+NFSCLIENT+
 NFSD+NFSCL zfs 865798fa:8346ef03   loader

 NFSSERVER+NFSCLIENT+
 NFSD+NFSCL zfs 865798fa:8346ef08   kldload(8)

 NFSSERVER+NFSCLIENTnfsd+nfscl+zfs  865798fa:8346ef08   loader
 

 The fsid seems to depend on the module loading order of ZFS.  Even on
 a running system, the following procedure changed the fsid, for
 example:

  1. Boot with a kernel with NFSSERVER+NFSCLIENT.

  2. Load zfs.ko and opensolaris.ko by loader.

  3. Check fsid of a ZFS mountpoint -- 865798fa:8346ef02

  4. Unload zfs.ko and opensolaris.ko, and then do zfs umount -a.

  5. Load zfs.ko and opensolaris.ko by kldload(8), and do zfs mount -a.

  6. Check fsid of the same mountpoint -- 865798fa:8346ef08

 Is this by design or not?  While testing the above configurations,
 fsid of a UFS mountpoint was not changed (as expected).

-- Hiroki


pgpwjCMvEskbj.pgp
Description: PGP signature

daily snapshots updated (Was: Re: Where to download latest FreeBSD snapshots)

[Hiroki Sato]

Test Rat ttse...@gmail.com wrote
  in 86y5z1ymyi@gmail.com:

tt Can you add architecture name to HEAD snapshots? It often saves time
tt checking whether snapshot is suitable for testing months after being
tt dowloaded.

 Thank you for your feedback.  While I have received various ideas and
 am still working on them, I recently added changes for the followng:

 1. Use $TARGET and $TARGET_ARCH in ISO image names.  Now it is like
the following:

FreeBSD-9.0-HEAD-20110809-JPSNAP-i386-i386-bootonly.iso

Also, SHA-256 checksum files have been added in the same
directory.

 2. Use a clean build environment.  This should fix an iso9660 format
breakage issue in makefs(8).

 3. The uncompressed tree of the release tarballs is added under the
trees/ directory.

 Currently, snapshots of 7 platforms are being built natively.

-- Hiroki


pgpY8PRqoq4gw.pgp
Description: PGP signature

Re: 8th July snapshot: bsdinstall not creating homedir

[Hiroki Sato]

Bruce Cran br...@cran.org.uk wrote
  in a23d9339-458e-4a2d-8bdc-4ef1d283f...@cran.org.uk:

br I've installed FreeBSD snapshots a couple of times this week. With
br Virtualbox 4.1 on both Windows and OS X with a 20GB disk I've found
br the installer forgets to create the homedir - /home doesn't exist, so
br when you get placed at / when logging in.  Unfortunately
br pub.allbsd.org seems to be queued up so I've not been able to try any
br more recent snapshots (should the snapshot ISOs be labelled with
br -release.iso)?

 Sorry, due to a hardware trouble on Saturday some of the snapshots
 had to be removed.  It recovered already and generating ones as of
 July 21-24 now, FYI.

-- Hiroki


pgpY7YAUqjneU.pgp
Description: PGP signature

daily snapshot build

[Hiroki Sato]

Hi,

 Just wanted to let you know that daily snapshot builds from the HEAD
 source tree are available again at
 http://pub.allbsd.org/FreeBSD-snapshots/.  Currently i386 and amd64
 build have been recovered.  Although it was down for a while due to
 hardware failure, it is recovering now including other archs.  The
 snapshot builds can also be found via ftp://ftp.allbsd.org/pub or
 rsync://rsync.allbsd.org/freebsd-snapshots/.  I hope these help for
 testing purpose.

 Please note that it may be unstable this week because temporary network
 access outage (for a short time) is planned on Friday.

-- Hiroki



pgpMJ0BhEmUTp.pgp
Description: PGP signature

Re: [RFC] ifconfig description support in rc.d

[Hiroki Sato]

Hi,

pluknet pluk...@gmail.com wrote
  in aanlktintgji3vzrb8xuuqhwp+7ydvhtd7ynp0mmv0...@mail.gmail.com:

pl On 27 August 2010 00:09, Doug Barton do...@freebsd.org wrote:
pl  On 08/26/2010 12:53 PM, pluknet wrote:
pl 
pl  [cc'ing current@ as rc@ looks too quite]
pl 
pl  Hi.
pl 
pl  Since ifconfig has grown to label interfaces with
pl  ifconfig $ifname description foobar, what about
pl  to give it more life and store i/face descriptions
pl  semi-permanently, so they will survive between reboots?
pl 
pl  This patch adds a functionality to rc.d to label
pl  interfaces at boot time.
pl 
pl  Comments are welcome.
pl 
pl  This seems like a good addition, thanks. Please also write a patch for
pl  rc.conf.5 to describe this new functionality and I'll be happy to commit 
it.
pl 
pl Xin Li helped me with updating rc.conf.5 (thanks!).
pl It's included in attached patch.
(snip)
pl  +       # ifconfig_IF_descr
pl  +       for _if in `ifconfig -l`; do

 I think using ifconfig -l here is not a good idea.  Setting a
 description for each interface in a function invoked by ifn_start()
 would be better.

 This is beacuse the netif script can be run not only at boottime but
 also via devd or by hand for a specific interface.  So, if the
 ifnet_descr is there, /etc/rc.d/netif start IF does not make it
 run.  Since the description is a per-interface property,
 /etc/rc.d/netif start IF should set one, and /etc/rc.d/netif stop
 IF should clear one, IMHO.

 Also, ifconfig -l is not compatible with $network_interfaces, so
 you need to use list_net_interface() for that purpose instead (if you
 move ifnet_descr() into ifn_start() it is useless, though).

-- Hiroki



pgpvMmS5Le8b3.pgp
Description: PGP signature

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Hiroki Sato]

Gordon Tetlow gor...@freebsd.org wrote
  in aanlktikw3j5hbrz0gjpbab=8urfnkgjm069i8ennx...@mail.gmail.com:

go On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow gor...@tetlows.org wrote:
go
go  All,
go 
go  I sat down and rewrote the man tools from a relatively old codebase to a
go  single shell script. My original motivation was to allow multiple
go  configuration files so port installations did not have to mess with
go  /etc/manpath.config (like perl for example) when needing to manipulate the
go  manpath. After looking at the existing code, I figured I could rewrite it 
as
go  a shell script relatively easily.
go 
go  Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
go  /usr/bin/whatis)
go  
http://people.freebsd.org/~gordon/man.shhttp://people.freebsd.org/%7Egordon/man.sh
go 
go  Features of the new code:
go 
go  1. BSD licensed (old code is GPL).
go  2. Imports configuration from /usr/local/etc/man.d/*.conf and 
/etc/man.conf
go  (purposefully changed the manpath.config file since it is a different
go  syntax).
go  3. Allows ports to override the toolset used to display the manpage based
go  on language. This was done to try to merge the functionality of the
go  japanese/man port into the base system as much as possible.
go 
go  I've tried to make this mirror the functionality, directory search order,
go  and arguments as the current base implementation.
go 
go  This brings me to my next point. I need some testers willing to try this
go  out. It would be particularly great if I could get some foreign language
go  testers with localized manpage installations. If something doesn't work 
the
go  way you expect, please contact me and I can help debug it (using man -ddd
go  whatever will generally give me the debug information I need).
go 
go  Thanks,
go  Gordon
go 
go
go I did some additional testing with the japanese/man-doc port and found the
go following was necessary:

 Great, I will test it and get back to you!

-- Hiroki


pgpQyXyxPu4Qz.pgp
Description: PGP signature

Re: IPv6 configuration in rc.d

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bcb6a14.5040...@freebsd.org:

do   # ifconfig gif0 create
do   # ifconfig gif0 up
do
do Your statement is literally true, in this case the network.subr stuff
do has no control because it isn't run. That was the same for the old
do code as it is for the new code.

 No, in this case devd(8) invokes rc.d/netif as it is created.  The
 old code does ifconfig inet6 -ifdisabled before it becomes up
 when ipv6_prefer=YES, and the new code always does ifconfig inet6
 ifdisabled when no ifconfig_gif0_ipv6 line, respectively.

do Note that IPv6 link-local addresses (those that start with fe80::) will
do be automatically configured whenever possible.  You may need to remove
do IPv6 link-local addresses manually using ifconfig(8) ...

 No, the ifdisabled flag set via devd(8) prevents this.

do   IPv4 people hates that gif0 has an IPv6 link-local (and IPv6
do   communication itself),
do
do People who don't want v6 at all compile it out of the kernel, and the
do whole problem goes away. The project made a decision a long time ago to
do ship with v6 in GENERIC, so this is not a new issue.

 No, the auto link-local addr assignment was turned to off by default
 some years ago for this reason.  This was a secteam's decision after
 IPv6 was included in GENERIC.  This is an issue for both IPv4 and
 IPv6 people.

do   and IPv6 people hates that it needs an
do   additional step to enable it (ifconfig inet6 -ifdisabled in this
do   case).  gif (and other cloned interfaces) can be created by a program
do   (a ppp script, for example), so we cannot prepare $ifconfig line in
do   rc.conf in advance.
do
do Why not? There is no reason you can't have ifconfig_* lines for
do interfaces that are not always configured, I do it all the time.

 Because the interface identifier cannot always be known in advance.

 For example, IPv6 tunnel server/client which accept an incoming
 connection and establish a gif tunnel between the two create a lot of
 gif interfaces on demand, and the created gif interfaces must be
 ready for IPv6 without ifconfig -ifdisabled if the sysadmin wants
 IPv6.  The net/dtcp{,client} in the ports collection is one of the
 typical applications.  This situation is also common in a
 linkup/linkdown scripts for PPP(IPV6CP).  Having all possible
 interface names in rc.conf is not practical even if the number of
 interfaces is small.  IPv6 people (including me) surely want a knob
 for -ifdisabled on interfaces with no $ifconfig line in rc.conf if
 an interface has the ifdisabled flag.  Without it, such kind of
 programs do not work.

 Of course we can fix the programs to always use -ifdisabled, but the
 ifdisabled flag should not become popular for users.  I reluctantly
 designed the ifdisabled flag only for IPv4 people who hate a
 link-local addr, in order to make IPv6 enabled by default as much as
 possible with minimal impact to them as well as IPv6 people.  This is
 *the reason* why I improved the ifdisabled flag and used it in the
 rc.d scripts.  This has no compatibility with other KAME-derived
 implementation, and for IPv6 people it is nothing but an annoying
 obstacle.

 The ifdisabled flag never disables the IPv6 functionality, and it can
 make various wired situations for IPv6 people because the
 functionality is enabled but the communication including the critical
 ones is disabled.  It can be used only as a seatbelt for IPv4 people;
 not as a generic way to disable IPv6 on an interface.  My design was
 discussed with ex-KAME members last year and we all agreed that the
 ifdisabled flag should not be abused in a way other than that.  You
 can see the difference between disabling the functionality and
 disabling the communication if you read sys/netinet6*.

 Anyway, if we will go ahead with to use IPv6 please do ifconfig
 inet6 -ifdisabled first or please always add the interface name to
 rc.conf as the current implementation does, I will revert my changes
 which added support of the ifdisabled flag into ifconfig before
 BSDCan.  This flag is just needed to solve the issues I explained in
 this and previous emails.  If my concerns are just an illusion,
 removing the flag makes the world much simpler.

do Are you theorizing here, or do you have actual examples? If you can find
do actual examples of here is something that used to work, but now it does
do not then we can work on a solution. I am not necessarily opposed to the
do idea of automatically creating link-local addresses for cloned
do interfaces, but it's impossible for me to code against something I don't
do have in front of me. :)

 See tunnel server/client programs like what I described above and/or
 try to build an L2TP over UDP concentrator which uses IPV6CP +
 DHCPv6-PD.

-- Hiroki


pgpwpyd3Z4xFT.pgp
Description: PGP signature

Re: IPv6 configuration in rc.d

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bca2b55.9000...@freebsd.org:

do   I strongly disagree with this because some IPv6
do   applications depend on link-local address automatically added on
do   cloned interfaces
do
do Can you please give a configuration example that would create the
do scenario you are describing with the current code? And assuming that you

 We now have no control for whether a link-local address is
 automatically added or not when simply doing the following:

 # ifconfig gif0 create
 # ifconfig gif0 up

 IPv4 people hates that gif0 has an IPv6 link-local (and IPv6
 communication itself), and IPv6 people hates that it needs an
 additional step to enable it (ifconfig inet6 -ifdisabled in this
 case).  gif (and other cloned interfaces) can be created by a program
 (a ppp script, for example), so we cannot prepare $ifconfig line in
 rc.conf in advance.  In short, if we have no knob to control this and
 put ifdisabled onto interfaces with no $ifconfig_IF_ipv6 line by
 default, people always needs ifconfig inet6 -ifdisabled for such
 dynamically created interfaces.

 This was the reason why $ipv6_prefer=YES did ifconfig inet6
 -ifdisabled on interfaces with no $ifconfig_IF_ipv6 line and
 ipv6_prefer was NO by default.  There are third party programs that
 use the above example to establish IPv6-over-IPv4 tunnel.  The
 requirement of -ifdisabled will be very frustrating for IPv6
 people.

 I admit two meanings (src addr selection and -ifdisabled) in one
 $ipv6_prefer variable is suboptimal, but at that time I thought
 factoring out them was rather troublesome.  While my goal was to
 eliminate/factor such a opaque flag completely, this is the one
 unresolved.  I still have no solution about this.

do And as I said above, this makes no sense. Clean, consistent UI design
do mandates that each knob have a specific, well defined function. As an
do example of why what you're suggesting is a bad idea, how would a user
do specify that they want link-local addresses on an interface, but they do
do NOT want the other effect of ipv6_prefer (the ip6addctrl settings)?

 I think that is a reasonable question.  It was a loose end of the
 changes last year; I did not want to add additional knob to solve the
 problem explained above, so I decided to keep it coupled with the
 link-local thing until we get a solution.  IMO, the src addr
 selection is supposed to be controlled by $ip6addrctl_* prefixed
 variables, and $ipv6_prefer should be removed in the long-term.

do   Also, source address selection has to be IPv4-preferred by default.
do   Why did you change this?  I disagree with this.  I want IPv6 enabled
do   by default, but we are not ready for IPv6 is preferred when the
do   both are available for various reasons.
do
do Two reasons, in roughly equal importance. First, it has always been true
do that if IPv6 configuration is enabled IPv6 transport is preferred.
do Changing that now would be a POLA violation. Second, (as I stated
do previously) if the user takes the proactive step to configure IPv6 it is
do entirely reasonable to assume that they also want it to be tried first.

 In the default configuration (no rc.conf), there is no
 ifconfig_IF_ipv6 line.  If we take this as no configuration for IPv6,
 should IPv6-preferred be disabled in this case?

do FWIW, I've been using IPv6 on FreeBSD for about 6 years now, and other
do than the very occasional glitch on the content-provider side it's been
do smooth sailing. Given that the default has been the equivalent of
do ipv6_prefer=yes all that time, I don't see any problem with leaving it
do that way, and as I said above I think defaulting it to off would be the
do wrong decision. It's probably also worth pointing out that in the case
do of ipv6_prefer=yes and no IPv6 configured on an external interface, the
do _prefer knob is moot.

 For IPv4 people, performance regression will be noticeable.
 IPv6-preferred src addr selection means ::1 is always used for
 localhost.  On my box, IPv6 loopback is 25-30% slower than IPv4
 counterpart.  Whether this is critical or not depends on the
 application, but forcing IPv4-only people to use IPv6 loopback does
 not look a smart choice to me until we solve this problem though I
 love to see IPv6-preferred by default.

do   That behavior was intentional.
do
do I'm sorry to hear you say that, as I was hoping that it was simply an
do honest mistake on your part. To be clear, ipv6_prefer should control
do one, and only one thing, the behavior of rc.d/ip6addctrl. Overloading it
do in any way, and more importantly overloading it to require that it be on
do for any IPv6 configuration to occur at all is not acceptable. There
do _must_ be a way for users to configure IPv6 for their external
do interfaces and also have it not be preferred.
do
do Regardless of how you intended it at the time, adding an ipv6_prefer
do knob to control the behavior of rc.d/ip6addctrl is a good idea, and a
do valuable addition to FreeBSD. 

Re: svn commit: r206408 - in head: etc etc/defaults etc/rc.d share/man/man5

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bc8ee88.6000...@freebsd.org:

do  or if the
do  commit hadn't happed in the middle of a discussion that died with
do  this.
do
do I took from the discussion the few things that we had achieved some form
do of consensus on, and chose to drop the rest of the topics that I had
do severe disagreements about. I also followed up to the list regarding
do this, and my reasons for dropping out.

 No, you changed the meaning of $ipv6_prefer, which does not agree
 with one of the results of discussion.  When ipv6_prefer=YES,
 ifdisabled flag must be cleared on all interfaces.  The reason is to
 enable automatic link-local address assignment without manual
 configuration.

 I explained again and again, the ifdisabled flag is *not for*
 disabling IPv6 on an interface as opposed to the name.  In rc.d
 scripts this is used for controlling link-local address assignment.
 Your change removed the logic in no $ifconfig_IF_ipv6 case, and it is
 not a consensus.  I strongly disagree with this because some IPv6
 applications depend on link-local address automatically added on
 cloned interfaces and at the same time IPv4 people do not like the
 link-local address.  We need a knob to control that, and the default
 should be no link-local when no ifconfig_IF_ipv6, and all
 interfaces have a link-local address when $ipv6_prefer=YES.  For all
 scenarios I can think of this is the least-worst.

 Also, source address selection has to be IPv4-preferred by default.
 Why did you change this?  I disagree with this.  I want IPv6 enabled
 by default, but we are not ready for IPv6 is preferred when the
 both are available for various reasons.

do  So usually we seem to use the upper case pseudo arguments like DHCP,
do  SYNCDHCP, WPA, .. in combination with an actual command to start apart
do  from ifconfig.  Now RTADV does not do that but it passes accept_rtadv or
do  -accept_rtadv to ifconfig. So if you need a command alias for that it
do  should probably be in ifconfig and discussed separately.
do
do I understand your argument, but I don't agree with it. The one thing
do that there was actually strong consensus on was that the IPv6
do configuration should have feature-parity with IPv4. Given that we have
do easy to use knobs to enable things like DHCP and WPA that users are
do already familiar with it made sense to me to introduce the same types of
do knobs for RA. This is in anticipation of also adding support for DHCPV6
do at some point in the future. From a user interface standpoint it does
do not make sense to have one form of IPv6 configuration to require an
do ifconfig statement, and another to have a knob.
do
do Furthermore:
do 1. I explicitly included support for the existence of [-]accept_rtadv in
do ifconfig_IF_ipv6 so if you or anyone else prefers that method of
do configuration it's available to you.
do 2. Just because RTADV doesn't start something apart from ifconfig now
do doesn't mean it won't or can't in the future. Specifically I'd like to
do see this knob turn on rtsold as well. (Even if I thought your argument
do above was valid, which I do not.)

 So please add that after you implement it and RTADV is not equivalent
 to accept_rtadv.  I cannot understand why we need to add it now.  At
 this moment, having two keywords makes nothing easy.

 Invoking rtsold (and/or dhclient) when receiving RAs are not so
 simple.  Did you really try that?  I personally lean to having a
 userland daemon to handle RA options including RDNSS and O-flag.  If
 you want direction for extending rc.d scripts to handle them, please
 show the concrete implementation first as David Horn did.  I think
 this is not a simple one like just adding a keyword and careful
 consideration is needed before implementing it.

do It did not. Previous to the introduction (and overloading) of the
do ipv6_prefer knob if you enabled IPv6 support with ipv6_enable it was
do preferred. With the code just prior to my change in order to configure
do IPv6 for an interface at all it was necessary to set ipv6_prefer to on,
do which meant that there was no way to have IPv6 configured but not have
do it be preferred.

 That behavior was intentional.  Please keep it disabled by default.
 I disagree with decoupling seatbelt for link-local addr assignment
 from IPv6-preferred source address selection.  The IPv6-preferred
 source address selection is troublesome for IPv4-only people, and for
 IPv6-people the seatbelt for link-local addr is troublesome.  I
 designed $ipv6_prefer as a knob for this trade-off.

-- Hiroki


pgpW03Tnuoi30.pgp
Description: PGP signature

Re: ipv6_enable

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bb95564.1070...@freebsd.org:

do On 04/04/10 02:41, Hiroki Sato wrote:
do  Kevin Oberman ober...@es.net wrote
doin 20100404053352.e6f751c...@ptavv.es.net:
do 
do  ob The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
do  ob see no reason not to use them to enable or disable functionality 
whether
do  ob it involves a script in rc.d or not. The idea is to have a clear,
do  ob obvious way to enable or disable functionality. I see nothing in 
Hiroki's
do  ob proposal that is nearly as clear and to the point as 'ipv6_enable'.
do 
do   Another reason I lean to not using xxx_enable is that an rc.d knob
do   cannot control enabling/disabling the IPv6 functionality actually.
do   It was true even when we were using the network_ipv6 script.
do
do But that's equally true of how you're using ipv6_prefer. :)  You've
do basically just moved the overloading of 2 of the 3 previous functions of
do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3
do functions into different knobs.

 No, the current ipv6_prefer=NO has nothing to do with disabling IPv6.
 It is just related to source address selection and a seatbelt for
 IPv4-only people.  I do not think I just moved the old functions.

 Let me explain how these changes happened.  As I explained earlier, I
 added $ipv6_prefer to *enable IPv6 by default*.  IPv6 needs some
 configuration even if you do not use IPv4 when the kernel supports
 it, and skipping all of IPv6 configuration in the old
 rc.d/network_ipv6 script caused another problems.  So, I thought it
 was possible to enable IPv6 by default and initialize the
 functionality with reasonable default parameters.  This parameters
 included disable ACCEPT_RTADV by default, which is one of the
 topics we are discussing now.

 After I moved the initialization outside of the $ipv6_enable, then I
 noticed that the rest which should be inside of the $ipv6_enable is
 IPv6 GUA address assignments and routing settings only.  Here I
 stepped further; I changed the disabling feature of $ipv6_enable into
 whether an IPv6 address is assigned or not.  That was the whole
 story.

 The old rc.d/network_ipv6 had a lot more for IPv6 configuration in
 the $ipv6_enable conditional clause and ipv6_enable=NO meant to
 disable them, too.  This is a big difference.  The new ipv6_enable in
 your patch is not the same in this regard.

 Well, I can understand and agree that people want a handy knob to
 disable IPv6.  I think it is more constructive for this discussion to
 be more specific what should be disabled, then.  I am still not sure
 what you and other people mean by disable IPv6.

 My opinion is ipv6_enable=NO should mean disabling IPv6
 functionality completely.  I do not want to call a knob just to
 ignore ifconfig_IF_ipv6 lines as ipv6_enable as well as do not want
 to disable IPv6 functionality completely by default.  So I am
 interested in what people want more precisely.

-- Hiroki


pgp4tjGEbjwmU.pgp
Description: PGP signature

Re: ipv6_enable

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bb95564.1070...@freebsd.org:

do On 04/04/10 02:41, Hiroki Sato wrote:
do  Kevin Oberman ober...@es.net wrote
doin 20100404053352.e6f751c...@ptavv.es.net:
do 
do  ob The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
do  ob see no reason not to use them to enable or disable functionality 
whether
do  ob it involves a script in rc.d or not. The idea is to have a clear,
do  ob obvious way to enable or disable functionality. I see nothing in 
Hiroki's
do  ob proposal that is nearly as clear and to the point as 'ipv6_enable'.
do 
do   Another reason I lean to not using xxx_enable is that an rc.d knob
do   cannot control enabling/disabling the IPv6 functionality actually.
do   It was true even when we were using the network_ipv6 script.
do
do But that's equally true of how you're using ipv6_prefer. :)  You've
do basically just moved the overloading of 2 of the 3 previous functions of
do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3
do functions into different knobs.

 No, the current ipv6_prefer=NO has nothing to do with disabling IPv6.
 It is just related to source address selection and a seatbelt for
 IPv4-only people.  I do not think I just moved the old functions.

 Let me explain how these changes happened.  As I explained earlier, I
 added $ipv6_prefer to *enable IPv6 by default*.  IPv6 needs some
 configuration even if you do not use IPv4 when the kernel supports
 it, and skipping all of IPv6 configuration in the old
 rc.d/network_ipv6 script caused another problems.  So, I thought it
 was possible to enable IPv6 by default and initialize the
 functionality with reasonable default parameters.  This parameters
 included disable ACCEPT_RTADV by default, which is one of the
 topics we are discussing now.

 After I moved the initialization outside of the $ipv6_enable, then I
 noticed that the rest which should be inside of the $ipv6_enable is
 IPv6 GUA address assignments and routing settings only.  Here I
 stepped further; I changed the disabling feature of $ipv6_enable into
 whether an IPv6 address is assigned or not.  That was the whole
 story.

 The old rc.d/network_ipv6 had a lot more for IPv6 configuration in
 the $ipv6_enable conditional clause and ipv6_enable=NO meant to
 disable them, too.  This is a big difference.  The new ipv6_enable in
 your patch is not the same in this regard.

 Well, I can understand and agree that people want a handy knob to
 disable IPv6.  I think it is more constructive for this discussion to
 be more specific what should be disabled, then.  I am still not sure
 what you and other people mean by disable IPv6.

 My opinion is ipv6_enable=NO should mean disabling IPv6
 functionality completely.  I do not want to call a knob just to
 ignore ifconfig_IF_ipv6 lines as ipv6_enable as well as do not want
 to disable IPv6 functionality completely by default.  So I am
 interested in what people want more precisely.

-- Hiroki


pgpB7qA06TOsk.pgp
Description: PGP signature

Re: ipv6_enable

[Hiroki Sato]

John Hay j...@meraka.org.za wrote
  in 20100405083056.ga8...@zibbi.meraka.csir.co.za:

jh These questions actually start more questions for me. :-) Maybe we should
jh also think from the user perspective and list a few use cases and what a
jh user need to put in rc.conf to make that work?
jh
jh Your normal desktop/notebook user on a ipv6 radv network, what does he
jh need to do to have his machine ipv6 usable?

 Given that it is 9-CURRENT and the box has 1 NIC (fxp0), add the
 following line to rc.conf:

 ifconfig_fxp0_ipv6=accept_rtadv

jh A network server that does not accept radv, what should its ipv6 config
jh in rc.conf look like?

 ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64

jh What about a server that accept radv (so that it can get router info)
jh and have fixed addresses for it services?

 ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64 accept_rtadv

jh A router kind of box, what should it look like?

 Given that the box has 2 NICs (fxp0 and fxp1), add the following lines
 to rc.conf:

 ipv6_gateway_enable=YES
 ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64
 ifconfig_fxp1_ipv6=inet6 2001:db8:2::1/64

 And, no ifconfig_IF_ipv6 line means no IPv6 configuration for the IF.

 After my changes committed last September, the existence of
 ifconfig_IF_ipv6 is used as a flag for whether IPv6 is enable or not
 on that interface.

-- Hiroki


pgpNptkehlRmA.pgp
Description: PGP signature

Re: ipv6_enable

[Hiroki Sato]

Kevin Oberman ober...@es.net wrote
  in 20100404053352.e6f751c...@ptavv.es.net:

ob The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
ob see no reason not to use them to enable or disable functionality whether
ob it involves a script in rc.d or not. The idea is to have a clear,
ob obvious way to enable or disable functionality. I see nothing in Hiroki's
ob proposal that is nearly as clear and to the point as 'ipv6_enable'.

 Another reason I lean to not using xxx_enable is that an rc.d knob
 cannot control enabling/disabling the IPv6 functionality actually.
 It was true even when we were using the network_ipv6 script.

 I agree that the idea to use $xxx_enable is clear, but I think it is
 better not to use it because it cannot make the functionality
 enable/disable completely in this IPv6 case.  To use IPv6, please
 add an IPv6 GUA to the interface makes everything simple.  If we
 really need a knob for enable/disable, $ipv6_enable is the best.
 However, if it cannot disable actually, $xxx_enable is just a
 confusing name.  I added $ipv6_prefer and removed $ipv6_enable
 because of this reason.

 I have seen a lot of people who are trying to add an IPv6 address to
 use IPv6 but do not notice they have ipv6_enable=NO.  The trouble
 is that it actually works with some incomplete configurations.  I
 want to get rid of such a possibility.  Especially issues of an
 interface has an IPv6 GUA and no link-local address and sysadmins
 who want IPv4 only do not notice an IPv6 link-local address can do L3
 communication.  The current default settings are not the best, but a
 result of trade-off.

ob  Have you ported any of those changes to FreeBSD? There is a lot of talk
ob  currently about a near-term future when internal networks are v6-only,
ob  and all communication with v4 networks happen over some kind of
ob  translation layer. I'm not sure whether I like those ideas or not, but I
ob  think it would be great for FreeBSD to be in a leadership role here.
ob
ob I hate the idea. I want a end-to-end network that can be trivially
ob subordinated to the control of any entity and allows for the innovation
ob that an end-to-end network allows. I also fear the stability of massive
ob carrier grade NAT systems. There is a huge amount of state required for
ob CGN and if something goes wrong, it goes VERY wrong.

 My goal is for eliminating implicit IPv4 dependency and make the
 world AF-neutral wherever possible, not eliminating IPv4.  Something
 like changes to rc.d/netoptions in HEAD is a good example.

ob   do 2. ipv6_network_interfaces should be set to AUTO, the same way that 
it
ob   do is for IPv4.
ob  
obI agree with this change, but I am still not sure if we should have
ob$ipv6_network_interfaces itself.
ob 
ob  I think it's useful because people may want to configure some interfaces
ob  for v6 and not others.
ob
ob I agree with Doug, here, though I think its use will be very limited.
ob (But maybe I will be wrong.)

 I agree with the usefulness, but we can implement this functionality
 with no $ipv6_network_interfaces.  For example, $network_interfaces
 is for all IFs and AFs, ifconfig_DEFAULT_AF=IGNORE is per-AF, and
 ifconfig_IF_AF=IGNORE is per-AF+IF.

 I think it is not necessary to have a global knobs for a specific AF
 because we already have a per-AF knob for each IF as described above.
 The reason why we have ipv6_* knobs equivalent to ones for IPv4 is
 that the ipv6_-prefixed knobs were used in KAME to separate the
 IPv6 knobs from the existing IPv4 ones.  As I explained, I want to
 merge the duplicates in AF-neutral manner.  Not want to eliminate the
 existing functionality itself.

obFor IPv4 we do not invoke dhclient by default.
ob 
ob  I think this is an apples and oranges comparison. IPv6 has a lot of
ob  similarities to IPv4, but they have a lot of differences as well. As I
ob  said above (for better or worse) RA is fundamental to the design and
ob  implementation of IPv6, and for almost all users it will be necessary in
ob  order to get IPv6 connectivity up.
ob
ob I agree with Doug. This is one of the few areas where IPv4 and IPv6 are
ob really different. While I don't agree that accepting RTADV should be the
ob default, the IPv4 comparison is really not relevant.

 No, my intension is not to compare IPv4 and IPv6 here.  We have never
 enable L3 address autoconfiguration without explicit configuration
 before.  This is reasonable and should be kept for IPv6, too.

-- Hiroki


pgpJqChyz6dtF.pgp
Description: PGP signature

Re: ipv6_enable

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bb7e224.6020...@freebsd.org:

do As we've discussed previously, you and I have a lot of disagreement on
do some of these principles. I'm going to outline my responses in some
do detail, however I'm also interested in what others have to say since I'd
do ultimately like to see some consensus from the community on how this
do should be configured.

 Yes, I agree that it is good to have discussion with more people.

do I'm just about the biggest rc.d purist there is, and even I don't agree
do with this. :)  I also disagree with your idea that the original design
do of rc.d scripts didn't intend for concepts like this.

 Sorry for the noise.  This involves my preference and was a different
 story.  Please ignore this for IPv6 discussion for the moment.

do   Second, if people need a way to disable IPv6 protocol, they have
do   already the way; no IPv6 configuration in /etc/rc.conf.  If you need
do   a handy way for on-and-off, separating the IPv6 configuration from
do   rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into
do   /etc/rc.conf should be enough, for example.
do
do Even if I agreed with this idea (and I don't necessarily have strong
do DISagreement with it) the knob has existed since the beginning of IPv6
do support in FreeBSD, and shouldn't be removed lightly. Personally I find
do it handy to be able to configure things in rc.conf and turn them on and
do off with one knob without having to comment or uncomment a bunch of stuff.

 I didn't removed it *lightly*.  My motivation for that is I want to
 enable IPv6 by default without making trouble for IPv4-only people.
 I also committed several kernel-level measures for people who want
 IPv4-only, IPv6-only, and the both to live without the knob at that
 time.

 Enabling/disabling IPv6 by using rc.d script was quite complex and
 the switching will be incomplete with no kernel support.  My
 conclusion for integration of the network_ipv6-netif changes was
 depend on if adding an GUA or not and it works fine for
 asynchronous invocation of rc.d/netif as well as needs no reboot for
 the switch (see another email for the whole story).  Some processing
 which were in network_ipv6 (calculating $rtsol_interface and so on)
 are intentionally removed thanks to this assumption.  If you want to
 go back to the old days and enable receiving RA by default, we must
 look into the whole process carefully again.

 If people want to disable IPv6 GUA assignment in per-AF manner, it
 should be done by per-AF global knobs for $ifconfig_* because the GUA
 assignment involves $ifconfig_* knobs only for the user as explained
 in another email.

 Let me summarize what I agree and disagree again:

 a. I agree that it is useful to have a knob for disabling all of
ifconfig_IF_ipv6 handling.  However, I disagree with using the
name ipv6_enable just for the purpose.  ipv6_enable=NO never
means disabling IPv6 functionality in the kernel, and it will
cause people tend to think IPv6 is disabled completely.

If we want to disable ifconfig_IF_AF lines in a handy manner,
implementing ifconfig_DEFAULT_AF is more consistent and where we
should go.  All of AF-specific parameters for an interface are in
$ifconfig_IF_AF, and having a global knob to define the default
for all interfaces are quite reasonable to me.  I do not want to
go back to AF-specific handling like ipv6_* wherever possible.

I think this policy is compatible with David Horn's suggestions.
ifconfig_DEFAULT_ipv6=DHCP for DHCPv6 by default,
ifconfig_DEFAULT_ipv6=accept_rtadv for SLAAC by default,
ifconfig_fxp0_ipv6=-accept_rtadv for no-SLAAC for fxp0, for
example (note that I do not stick to these keywords.  slaac
would also be a good candidate).  No concern for
conflicting/confusing with IPv4; this is orthogonal among AFs.  We
can support another new method by just adding a keyword.

Note that SLAAC and DHCPv6 are exclusive.  Combinations of
DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the
latter is rather popular).  This is one of the reasons I stick to
the per-IF/per-AF solution here.

 b. Disagree with disabling IPv6 by default.  I think there is no
technical and security reason to go back to the old days.

do   Also, we should not consider IPv6 as special.
do
do I wish that were so, but I disagree. I think we need to make it as easy
do as possible for users to take advantage of IPv6, but there are a lot of
do reasons why it is actually special. Primarily because unlike some of our
do other networking protocols it's on the cusp of being something that
do everyone will need someday, but isn't quite ready for prime time.

 IMO, at least for handling in rc.d scripts, it is not necessary to
 consider IPv6 as a special AF after I added AF-specific $ifconfig_*
 knobs, rc.d/netoptions changes, and so on.

 And, well, please let me suggest something for the further 

Re: ipv6_enable

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4bb70e1e.3090...@freebsd.org:

do 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
do on and off when INET6 is in the kernel. I think the value of this kind
do of knob is obvious, but I'd be happy to elaborate if that is necessary.

 There were reasons related to technical difficulty and inconsistency
 (and a bit my preference) to drop $ipv6_enable.

 First, we are overly abusing $xxx_enable knob even when no
 corresponding rc.d/xxx file.  I think $xxx_enable knob should be used
 only for rc.d/xxx whenever possible.  It is intuitive, and what the
 original design of rc.d scripts intended.  Although this would be
 another topic, it was one of the motivation for me to remove the
 knob.

 Second, if people need a way to disable IPv6 protocol, they have
 already the way; no IPv6 configuration in /etc/rc.conf.  If you need
 a handy way for on-and-off, separating the IPv6 configuration from
 rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into
 /etc/rc.conf should be enough, for example.

 After all, protocols cannot be disabled only by using rc.d scripts.
 If we really need the way to do that, we have to have kernel-level
 knobs like sysctl or ifconfig flag.  Also, we should not consider
 IPv6 as special.  Why we have to have $ipv6_enable while we don't
 have $ipv4_enable?  I am using INET6-only machines for years and the
 process removing the IPv4 dependency in the userland was really hard,
 but I believe no line for the protocol in /etc/rc.conf means no
 configuration is a policy which can be implemented and can work fine
 even there.

do 2. ipv6_network_interfaces should be set to AUTO, the same way that it
do is for IPv4.

 I agree with this change, but I am still not sure if we should have
 $ipv6_network_interfaces itself.  The current implementation is
 equivalent to always AUTO while the default value is set NONE (see
 ipv6if()). The reason I changed it to NONE simply because we need to
 extend list_net_interfaces() for per-AF listing first.  While I added
 some support for SLAAC, it is still not enough and not used yet.

 Setting $ipv6_network_interfaces (or $network_interfaces) to non-AUTO
 value is for narrowing down the interface list which the rc.d scripts
 handle, but I think this should be okay with non-AF-specific one only
 for the same reason as not having $ipv6_enable.

 Anyway, the current one is incomplete.  Changing to AUTO is
 harmless unless we do not use list_net_interfaces() to list
 interfaces for some kind of automatic configuration.

do 3. Each IPv6 interface (other than lo0) should be configured with rtsol
do by default, but manual configuration should still be possible.

 Why accepting RA and sending RS by default?  I object this because it
 is too problematic.  The KAME implementation does not care about
 receiving RAs from multiple networks and we cannot control the
 accept-or-not.  My patch for per-IF ACCEPT_RTADV handling was the
 first step, but still I can imagine cases which cause surprising
 results for sysadmins.

 My opinion is: receiving RA must be enabled only when explicitly
 specified.  If the box is a host with only one physical interface
 and there is no network configuration it might be good to send RS for
 SLAAC as the last resort, but it is still risky.  For IPv4 we do not
 invoke dhclient by default.

 This is not so simple.  A network interface can appears by cloning or
 adding a new NIC into the system, and then devd(8) invokes rc.d/netif
 via /etc/pccard_ether asynchronously.  If the kernel accepts RAs by
 default, these dynamically-added ones will also become RA-receiving
 interfaces.  Pseudo ifconfig flags like NORTADV don't work for them.

 Unconditionally accepting RAs is harmful, but we still have limited
 countermeasures.  While I recently added DEFROUTE_RTADV flag in my
 private branch /user/hrs/ipv6 as another step for that, I believe the
 disadvantages outweigh the positives at this moment.

-- Hiroki


pgpzjEuuWtIJz.pgp
Description: PGP signature

Re: panic with panic: kmem_malloc(4096): kmem_map too small...

[Hiroki Sato]

[EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

phk I only have 2G ram and that's what I have tested (extensively).  If we're
phk still broken for 2G ram, somebody needs to revist this.
phk 
phk One thing you can try is reduce the value of the
phksysctl kern.maxvnodes
phk 
phk If you set it to the same value as used for 2G (appros 13), I
phk think your machine should survive with 3G RAM.

 Thank you for the clarification.  I notice that the panic
 happens when numvnodes becomes more than about 185000.
 When kern.maxvnodes=13 (198799 by default) is specified,
 the system works fine under heavy loads during this week.

 Is anyone else suffering from it?  If it happens on all of 2GB
 systems, I think it should be solved (or described in relnotes)
 before the release.

-- 
| Hiroki SATO  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic with panic: kmem_malloc(4096): kmem_map too small...

[Hiroki Sato]

Hi,

[EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

phk In message 03a701c2b38c$8e3ad990$471b3dd4@dual, Willem Jan Withagen writes:
phk Which seems a problem sticking up it's head once so often.
phk I had it happen to me now 3 times over the last day. It just drops into the 
debugger.
phk And I've foun little extra info in the archive.
phk 
phk What dows this actually mean? Is something leaking in the kernel.
phk IF so how do I help it go away.
phk 
phk I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
phk Current is as of 28 dec...
phk 
phk Please try to move up to current as of today.  On Dec 29th I commited
phk code to make the desiredvnodes a limit rather than a vague suggestion
phk and that should solve your problem I hope.

 I also had kmem_malloc(4096): kmem_map too small: 275378176 total allocated
 several times on -current as of Jan 4th.  My -current box has 3GB memory,
 but when the memory size is explicitly specified as 2GB via MAXMEM option,
 the panic disappears (but I don't know why...).

-- 
| Hiroki SATO  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

panic: kmem_map too small

[Hiroki Sato]

Hi,
(B
(B I had "kmem_map too small" panic on 5.0-CURRENT/i386 as of Dec. 19 2002.
(B It often occurred when the machine was running under heavy system
(B loads (e.g. make -j20 release).
(B
(B |panic: kmem_malloc(4096): kmem_map too small: 275378176 total allocated
(B |cpuid = 2; lapic.id = 0100
(B |boot() called on cpu#2
(B |
(B |syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
(B |cpuid = 2; lapic.id = 0100
(B |boot() called on cpu#2
(B |Uptime: 13h56m30s
(B |Dumping 3071 MB
(B |ata0: resetting devices ..
(B
(B The machine's kernel is configured with the additional options: SMP and
(B APIC_IO (4 CPUs are detected).  The results of backtrace are:
(B
(B |(kgdb) bt
(B |#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
(B |#1  0xc02e498a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
(B |#2  0xc02e4c47 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
(B |#3  0xc032b882 in bwrite (bp=0xd5b8f728) at /usr/src/sys/kern/vfs_bio.c:796
(B |#4  0xc032bf39 in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1085
(B |#5  0xc0332f2e in cluster_wbuild (vp=0xc9c56258, size=16384, start_lbn=776, 
(B |len=4) at /usr/src/sys/kern/vfs_cluster.c:981
(B |#6  0xc032cf46 in vfs_bio_awrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1626
(B |#7  0xc043623a in ffs_fsync (ap=0xe785b548)
(B |at /usr/src/sys/ufs/ffs/ffs_vnops.c:258
(B |#8  0xc0435449 in ffs_sync (mp=0xc9963600, waitfor=2, cred=0xc5436e00, 
(B |td=0xc0549d00) at vnode_if.h:612
(B |#9  0xc0340bab in sync (td=0xc0549d00, uap=0x0)
(B |at /usr/src/sys/kern/vfs_syscalls.c:138
(B |#10 0xc02e456b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
(B |#11 0xc02e4c47 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
(B |#12 0xc044c46b in kmem_malloc (map=0xc083207c, size=4096, flags=0)
(B |at /usr/src/sys/vm/vm_kern.c:336
(B |#13 0xc045cd77 in page_alloc (zone=0xc542aa80, bytes=0, pflag=0x0, wait=0)
(B |at /usr/src/sys/vm/uma_core.c:798
(B |#14 0xc045ca71 in slab_zalloc (zone=0xc542aa80, wait=0)
(B |at /usr/src/sys/vm/uma_core.c:707
(B |#15 0xc045dd5e in uma_zone_slab (zone=0xc542aa80, flags=0)
(B |at /usr/src/sys/vm/uma_core.c:1486
(B |#16 0xc045df84 in uma_zalloc_bucket (zone=0xc542aa80, flags=0)
(B |at /usr/src/sys/vm/uma_core.c:1590
(B |#17 0xc045dc0f in uma_zalloc_arg (zone=0xc542aa80, udata=0x0, flags=0)
(B |at /usr/src/sys/vm/uma_core.c:1417
(B |#18 0xc02d8359 in malloc (size=7, type=0xc0553ba0, flags=0)
(B |at /usr/src/sys/kern/kern_malloc.c:182
(B |#19 0xc032e3aa in allocbuf (bp=0xd5e545e0, size=2048)
(B |at /usr/src/sys/kern/vfs_bio.c:2635
(B |#20 0xc032e16e in getblk (vp=0xcaaa2960, blkno=0, size=2048, slpflag=0, 
(B |slptimeo=0) at /usr/src/sys/kern/vfs_bio.c:2526
(B |#21 0xc0420b59 in ffs_balloc_ufs2 (vp=0xcaaa2960, startoffset=0, size=512, 
(B |cred=0xca0a6400, flags=65536, bpp=0xe785b9e0)
(B |at /usr/src/sys/ufs/ffs/ffs_balloc.c:643
(B |#22 0xc044313a in ufs_mkdir (ap=0xe785bbac)
(B |at /usr/src/sys/ufs/ufs/ufs_vnops.c:1580
(B |#23 0xc0444b48 in ufs_vnoperate (ap=0x0)
(B |at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
(B |#24 0xc0345cf9 in kern_mkdir (td=0xcb907e00, 
(B |path=0xe785bca8 "$BT<(B\205$Bgi(B\2160$B@\(B020$B[LS"(B, 
(B |segflg=3226816840, mode=448)
(B |at vnode_if.h:757
(B |#25 0xc0345a79 in mkdir (td=0x0, uap=0x0)
(B |at /usr/src/sys/kern/vfs_syscalls.c:2879
(B |#26 0xc049fe5c in syscall (frame=
(B |  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134618240,
(B |   tf_ebp = -1077937912, tf_isp = -410665612, tf_ebx = 134539164,
(B |   tf_edx = 134536188, tf_ecx = 672330072, tf_eax = 136,
(B |   tf_trapno = -1077938044, tf_err = 2, tf_eip = 671866435, tf_cs = 31,
(B |   tf_eflags = 514, tf_esp = -1077938052, tf_ss = 47})
(B |at /usr/src/sys/i386/i386/trap.c:1033
(B |#27 0xc0487dcd in Xint0x80_syscall () at {standard input}:141
(B |---Can't read userspace from dump, or kernel process---
(B
(B-- 
(B| Hiroki SATO  [EMAIL PROTECTED]
(B
(BTo Unsubscribe: send mail to [EMAIL PROTECTED]
(Bwith "unsubscribe freebsd-current" in the body of the message

Re: XML driver config file to replace LINT

[Hiroki Sato]

Nik Clayton [EMAIL PROTECTED] wrote
 in [EMAIL PROTECTED]:

 That being the case, it wouldn't be too hard to do
 
 commant lang="ja_JP.EUCjp".../comment
 
 comment lang="es_ES.ISO_8859-1".../comment
 
 and so on, would it?

 If so, translated comment field can be obsolete while the author's
 one is always up-to-date.  The comment field is edited by
 the original author, but translators are responsible for the others.
 Translation is not always done immediately.  So, I think
 a way is needed to indicate whether the translation is old or not.

 Or does loading Japanese text in to a non-Japanese aware editor scramble
 the text?

 Probably it is not a big problem for editors, but other tools are OK?
 A file including characters in various encodings may confuse them.

--
| Hiroki Sato/HRS [EMAIL PROTECTED]
|
|  [EMAIL PROTECTED](univ)
|[EMAIL PROTECTED](FreeBSD doc-jp Project)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: XML driver config file to replace LINT

[Hiroki Sato]

Nik Clayton [EMAIL PROTECTED] wrote
 in [EMAIL PROTECTED]:

 [ That schema is not set in stone, and certainly requires more work.  In
   particular, we probably need "lang" and "encoding" options on the
   comment element, to support comments in more than one language. ]
 
 LINT would then become a skeletal file for things which don't fit this
 sort of pattern, and the full LINT would be generated by a script which
 parsed the above and the skeletal file to generate the full LINT.

 I think it is difficult to maintain the files because few editors
 can handle various languages/encodings at the same time.
 So, especially for translators, it is better that the .xml files
 are separated on a encoding/language basis.

 However, separated .xml files according to encoding/language
 like FreeBSD Handbook also cause another problem.  If these files are
 used to create actual configuration files as not only doc or
 advisory purpose, translated .xml files but are not synchronized
 with English version can be more harmful.  For instance,
 the out-dated translation couldn't create an appropriate LINT, so
 non-English readers cannot know modifications in the original file.

 Thus, configuration items that don't need to translate should be common,
 and others such as description field that can be translated should be
 separated, and it is better that latter separated .xml
 files (i.e. translated one) have a additional marker that
 indicates whether a file is synch'ed with the original version or not.

Nik Clayton [EMAIL PROTECTED] wrote
 in [EMAIL PROTECTED]:

 The aim is that we have one file that describes the drivers -- this file
 will be used by us to keep the documentation up to date, but it will also
 be used by the system -- if the driver writer doesn't update this file then
 the system won't know about their driver, and won't build it.  They'll *have*
 to keep it up to date.

 One file...why?  A port in Ports Collection depends on some files
 not one file, but it works fine.  I think we can maintain more easily
 several small files than big one file.

--
| Hiroki Sato/HRS [EMAIL PROTECTED]
|
|  [EMAIL PROTECTED](univ)
|[EMAIL PROTECTED](FreeBSD doc-jp Project)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message