Re: CVS commit: src

2011-11-23 Thread Martin Husemann
On Wed, Nov 23, 2011 at 03:19:55AM +, Christos Zoulas wrote:
 He does not want to write atf tests. In my opinion non-atf tests is better
 than no tests.

IMHO non-atf tests are just as useless as the whole src/regress hierachy
always was. BUT: finding someone to pick this new tests up and embed them
in atf should be easy.

Martin


Re: CVS commit: src/sys/fs/union

2011-11-23 Thread Alan Barrett
My vote would be to remove [unionfs]; it doesn't work and the 
only reason it was ever brought in had to do with alleged 
locking improvements.


Is anyone using it?


I used to make heavy use of unionfs, and I had no problems.  (That 
was on a uniprocessor machine several years ago.)  I sometimes 
used five layers: a base set of sources; a unionfs layer for third 
party changes; a unionfs layer for my own changes; a unionfs layer 
for the obj directories; and a final unionfs layer for files 
created or changed at build time.  For example, I could easily 
blow away all the build products but keep the obj directories, 
by unmounting the top layer unionfs, removing the files in its 
backing store, and then re-mounting it.


Today, I'd use a smarter revision control system instead of the 
unionfs layers to manage the source files, but I might still want 
a unionfs layer to isolate changes made at build time.


I have not used unionfs in the past few years, but it would be a 
pity to lose this functionality.


--apb (Alan Barrett)


Re: CVS commit: src/sys/fs/union

2011-11-23 Thread J. Hannken-Illjes

On Nov 23, 2011, at 11:11 AM, Alan Barrett wrote:

 My vote would be to remove [unionfs]; it doesn't work and the only reason 
 it was ever brought in had to do with alleged locking improvements.
 
 Is anyone using it?
 
 I used to make heavy use of unionfs, and I had no problems.  (That was on a 
 uniprocessor machine several years ago.)  I sometimes used five layers: a 
 base set of sources; a unionfs layer for third party changes; a unionfs layer 
 for my own changes; a unionfs layer for the obj directories; and a final 
 unionfs layer for files created or changed at build time.  For example, I 
 could easily blow away all the build products but keep the obj directories, 
 by unmounting the top layer unionfs, removing the files in its backing store, 
 and then re-mounting it.
 
 Today, I'd use a smarter revision control system instead of the unionfs 
 layers to manage the source files, but I might still want a unionfs layer to 
 isolate changes made at build time.
 
 I have not used unionfs in the past few years, but it would be a pity to lose 
 this functionality.

Do you mean `union'?

`unionfs' was imported 2008/02/18 and was never enabled in any kernel config.

--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)



Re: CVS commit: src

2011-11-23 Thread Christoph Egger

On 11/23/11 11:47, Thor Lancelot Simon wrote:

Module Name:src
Committed By:   tls
Date:   Wed Nov 23 10:47:50 UTC 2011

Modified Files:
src/distrib/sets/lists/etc: mi
src/etc/defaults: rc.conf
src/etc/rc.d: Makefile
src/sbin/rndctl: rndctl.8 rndctl.c
src/sys/dev: rnd.c
src/sys/secmodel/securelevel: secmodel_securelevel.c
src/sys/secmodel/suser: secmodel_suser.c
src/sys/sys: kauth.h rnd.h
Added Files:
src/etc/rc.d: random_seed

Log Message:
Load entropy at system boot (only works at securelevel  1); save
at system shutdown.  Disable with random_seed=NO in rc.conf if desired.

Goes to some trouble to never load or save to network filesystems.

Entropy should really be loaded by the boot loader but I am still
sorting out how to pass it to the kernel.


How about passing it as a module similar to the multiboot technique?

Christoph


Re: CVS commit: src/sys/fs/union

2011-11-23 Thread Alan Barrett

On Wed, 23 Nov 2011, J. Hannken-Illjes wrote:

I used to make heavy use of unionfs, and I had no problems.  [...]

Do you mean `union'?


I mean mount -t union.


`unionfs' was imported 2008/02/18 and was never enabled in any kernel config.


No, I haven't used that one.  I didn't even know about it.

--apb (Alan Barrett)


Re: CVS commit: src

2011-11-23 Thread Paul Goyette

On Wed, 23 Nov 2011, Martin Husemann wrote:


On Wed, Nov 23, 2011 at 03:19:55AM +, Christos Zoulas wrote:

He does not want to write atf tests. In my opinion non-atf tests is better
than no tests.


IMHO non-atf tests are just as useless as the whole src/regress hierachy
always was. BUT: finding someone to pick this new tests up and embed them
in atf should be easy.


I'll have a go at atf-ifying this over the upcoming 4-day holiday 
weekend (at least, in US).



-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-


Re: CVS commit: src

2011-11-23 Thread Paul Goyette

On Wed, 23 Nov 2011, Paul Goyette wrote:


IMHO non-atf tests are just as useless as the whole src/regress hierachy
always was. BUT: finding someone to pick this new tests up and embed them
in atf should be easy.


I'll have a go at atf-ifying this over the upcoming 4-day holiday weekend (at 
least, in US).


Actually, this test is already atf-ready, so there's nothing to do!

Thanks, Aleksey.

The new assign_NF test case is part of the existing test program:

# cd /usr/tests/util/awk
# atf-run | atf-report
Tests root: /usr/tests/util/awk

t_awk (1/1): 6 test cases
assign_NF: Passed.
big_regexp: Passed.
end: Passed.
multibyte: Passed.
period: Expected failure: PR bin/42320: atf-check failed; see the output of 
the test for details
string1: Passed.

Test cases for known bugs:
t_awk:period: PR bin/42320: atf-check failed; see the output of the
  test for details

Summary for 1 test programs:
5 passed test cases.
0 failed test cases.
1 expected failed test cases.
0 skipped test cases.
#


Much ado about nothing


-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-


Re: CVS commit: src

2011-11-23 Thread Christos Zoulas
On Nov 23,  9:07am, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src

| On Wed, Nov 23, 2011 at 03:19:55AM +, Christos Zoulas wrote:
|  He does not want to write atf tests. In my opinion non-atf tests is better
|  than no tests.
| 
| IMHO non-atf tests are just as useless as the whole src/regress hierachy
| always was. BUT: finding someone to pick this new tests up and embed them
| in atf should be easy.

So we agree :-) regress tests are better than no tests.

christos


Re: CVS commit: src

2011-11-23 Thread Thor Lancelot Simon
On Wed, Nov 23, 2011 at 12:06:26PM +0100, Christoph Egger wrote:
 On 11/23/11 11:47, Thor Lancelot Simon wrote:
 Module Name: src
 Committed By:tls
 Date:Wed Nov 23 10:47:50 UTC 2011
 
 Modified Files:
  src/distrib/sets/lists/etc: mi
  src/etc/defaults: rc.conf
  src/etc/rc.d: Makefile
  src/sbin/rndctl: rndctl.8 rndctl.c
  src/sys/dev: rnd.c
  src/sys/secmodel/securelevel: secmodel_securelevel.c
  src/sys/secmodel/suser: secmodel_suser.c
  src/sys/sys: kauth.h rnd.h
 Added Files:
  src/etc/rc.d: random_seed
 
 Log Message:
 Load entropy at system boot (only works at securelevel  1); save
 at system shutdown.  Disable with random_seed=NO in rc.conf if desired.
 
 Goes to some trouble to never load or save to network filesystems.
 
 Entropy should really be loaded by the boot loader but I am still
 sorting out how to pass it to the kernel.
 
 How about passing it as a module similar to the multiboot technique?

Can't make one of those without an ELF toolchain, right?  The basic
idea's about right, but I actually need something less sophisticated in its
packaging -- a way to just give the kernel the address of blob-of-stuff
the bootloader's dropped into place for it, so the entropy pool code
can just take it and prime itself.

Thor


Re: CVS commit: src

2011-11-23 Thread Jared McNeill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


It doesn't have to be ELF, I do it now on x86 for splash images. From 
/boot I load a .png, .jpg, or .bmp and add it to the module list but mark 
it as BI_MODULE_IMAGE (instead of BI_MODULE_ELF). I can then grab the blob 
from the kernel -- see arch/x86/x86/x86_machdep.c:module_init_md()


On Wed, 23 Nov 2011, Thor Lancelot Simon wrote:

Can't make one of those without an ELF toolchain, right?  The basic
idea's about right, but I actually need something less sophisticated in its
packaging -- a way to just give the kernel the address of blob-of-stuff
the bootloader's dropped into place for it, so the entropy pool code
can just take it and prime itself.

Thor



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (NetBSD)

iQEcBAEBAgAGBQJOzVH9AAoJEKdMfxFXhnemlIUIALcDsuwTXTJ9LVuPZM+f/i4K
6z25M26KEz42EaqGGWa4iNY4vjS0hBPQFmnJFi9Eud+4RCmh469ClXp4g6yB/fSW
FgFZb5vEGCDto2AmPEyBWkz/g+hbG/+EvWmL12oHCYYh8wVIxN6VRo80LOq5M6Xb
v9nOBjgdiJ7ZuOlw00SK3dHSAoJkWY5/KevAN1UGmTNHfWtiNsgAJDQ5VBoDqNWl
U2J3IhPC9aSIjhavLOp0h4Nn5xnHq2ZxF1yQXdga7cddE8f2ru2vP2mdRFNOR/b3
qibTeQ5BRDS062UiiiLrhUIlOiS0S9vOD+MxCdd5aajvWnQPZK/6j3cH1+9jaZI=
=v/9x
-END PGP SIGNATURE-