Re: FreeBSD onto An Intel Saber 8-Proc Server

2002-02-07 Thread Andrzej Bialecki

 later!  All things look great until, after choosing NFS for installation
 preference, it does not see my standard Intel 10/100 NIC, and installation
 can go no further.

 If instead of NFS, I choose 'CD' (Using 4.5 taken from the freebsd.org's
 released ISO image) I am able to install up the system, but once rebooted
 (allow another 20:07), cannot see the NIC (i.e. doesn't show up in
ifconfig,
 even though it's built into the kernel.)

I can't offer any insights as for the SCSI adapters, but re: NIC - I've had
similar symptoms quite a few times with Intel motherboards, and usually the
cause was that the NIC was disabled in BIOS. FreeBSD could still see it, but
something was missing on the low level and any access to the card would lock
up the machine solid...

Best regards,

Andrzej

// 
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)


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



Re: Flow cache on FreeBSD?

2001-09-04 Thread Andrzej Bialecki

Deepak Jain wrote:
 
 Is there a way to provide functionality similar to ip flow cache stats on a
 FreeBSD router?
 
 Let me clarify, I am talking about being able to easily see groupings of
 traffic go through a FreeBSD box. So if a downstream customer is being
 attacked, a simple table in realtime [or near real-time] will show the
 attack characteristics [ip ranges, packet types, general number of packets,
 etc].?

Yes. Please go and find the NeTraMet package on the web - it should
compile cleanly on FreeBSD (if not the latest versions, then surely some
older - I used them some time ago). It's very configurable, and comes
with a lot of examples (among others, and XWindow application to watch
the flows in real-time).

-- 

Andrzej

// 
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)

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



Re: Finding MAC address of interface - programming question

2001-08-01 Thread Andrzej Bialecki

Michael VanLoon wrote:
 
  From: Chris Faulhaber [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, July 31, 2001 3:56 PM
 
  On Tue, Jul 31, 2001 at 03:56:40PM -0700, Michael VanLoon wrote:
   Please point me to a more appropriate forum if there is
  one.  I'm kinda out
   of my depth on this question.  Pseudo code is fine. :-)
  
   What I'm looking for is how to enumerate the network
  interfaces and get the
   Ethernet MAC address of one programmatically.  Can anyone
  point me in the
   right direction?
  
 
  /usr/src/sbin/ifconfig
 
 Thanks, I've already been looking at that. :-)
 
 The problem is, ifconfig does a lot of other stuff, and it's very poorly
 documented.
 
 I was hoping someone could give me some hints to speed my research.  Such as
 recommended places to look in the code, ioctl's used and/or sysctl's called.
 
 I'm happy to do most of the work myself, I'm just asking for some hints. :-)
 Much appreciated.

Take a look at /usr/src/release/picobsd/tinyware/ns. I went through the
same hoops some time ago... :-)

-- 

Andrzej

// 
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)

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



Re: picoBSD

2001-05-10 Thread Andrzej Bialecki

On Tue, 8 May 2001, Trimarchi Michael wrote:

 Where is the picoBSD source code ? Can i compile for ARM processor ?

1. /usr/src/release/picobsd
2. No (i.e. you could cross-compile the programs/libs, but I haven't seen
   the FreeBSD ARM kernel running yet.. :-)

-- 

Andrzej

// 
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)


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



Re: Getting ISA device settings from kernel

2001-04-03 Thread Andrzej Bialecki

On Fri, 30 Mar 2001, Graham Wheeler wrote:

 Hi all
 
 I had some code that worked on FreeBSD 3.4 to configure ISA devices.
 In order to get the ISA device settings, I used the kvm library, and
 started off by extracting the name lists for _isa_devtab_tty, 
 _isa_devtab_bio, and _isa_devtab_net.
 
 I used to just give up if kvm_nlist returned a non-zero number. On
 FreeBSD 4.2 this is happening. Checking the manpage, I see that this
 could be that there are invalid values, so I changed the check to 
 only give up of the return value is negative. The code now gets past the
 kvm_nlist, but fails on the first kvm_read that follows (which uses the
 n_value returned by kvm_nlist as the offset field).
 
 Is there a different mechanism in 4.2 to do the kind of stuff I'm 
 trying to do? Should the code still work?

libkvm is being gradually deprecated - you don't have to use it to do what
you want. Please take a look at the code in src/sbin/kget - it does
something very similar.

Andrzej

// 
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)



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



Re: Mounting a md as a root filesystem.

2000-11-07 Thread Andrzej Bialecki

On 7 Nov 2000, Dag-Erling Smorgrav wrote:

 Josef Karthauser [EMAIL PROTECTED] writes:
  # load -t md /filesystemfile
 
 Shouldn't that be 'load -t md_root'?

Actually, it's md_image or mfs_root (see /sys/dev/md/md.c:446). Both of
these are mentioned in md(4).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Kernel calls, are they documented somewhere?

2000-11-02 Thread Andrzej Bialecki

On Thu, 2 Nov 2000, G. Adam Stanislav wrote:

 I do have the source code, and I have studied it, but it is uncommented.
 And, it seems, not all of it is included. For example, there is a
 /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been
 unable to find the source code for open() in libc. There is an open.c

The source for this type of syscalls is made "on the fly" in
Makefile. Since normally you use /usr/obj for keeping built objects, the
source files like e.g. open.S end up there. For open.S it contains the
following:

#include "SYS.h"
RSYSCALL(open)

which is a macro expanding to an asm wrapper around the syscall.

(Mind  you, I'm not an asm expert by any means, I just happen to know how
the building process works.. :-)

 in /usr/src/lib/libstand/ but it makes no system calls. Actually, it
 looks like a system call (it assigns its own file descriptors to files
 it opens), but it does not behave like our kernel (since it returns -1
 on errors, while our kernel has been returning 2 in my tests when trying
 to open a non-existing file as O_RDONLY:

libstand is a very special animal - it's used only for providing BSD-like
interface in BTX (bootloader) environment. Never use it when you run
kernel. OTOH, it's very enlightening to look into it and see how you
implement "syscalls" on a bare hardware...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: US$100 prize for adding ESS Audiodrive support to pcm

2000-08-05 Thread Andrzej Bialecki

On Mon, 31 Jul 2000, Cameron Grant wrote:

  I have for a long time said to myself that I would take the documents
  available and
  hack together a pcm driver for the audio chip built into my Asus P5A
  machine,
  and never sat down and done it. So, rather than whine to myself about
  it, or whine
  about nobody else doing it, I'll put my money where my mouth is.
 
 interested persons will want to investigate sys/dev/sound/pci/solo.c (just
 committed) which is 98% there.  i'm stumped.

On a simmilar note: what about a driver for ESS Maestro 2E? I'm certainly
willing to pay twice as much ($200) for working sound in most of laptops
within my reach...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



RE: dlopen() and friends from a statically-linked binary?

2000-07-25 Thread Andrzej Bialecki

On Sat, 22 Jul 2000, Daniel O'Connor wrote:

 
 On 20-Jul-00 Raymond Wiker wrote:
Is it possible, at all, to use dlopen etc from a
  statically-linked executable? My experiments with FreeBSD-4.0 (see
  below) indicate that it's not possible.
 
 You can't do it from a statically linked binary, however you can create a
 dynamic executable with no external unresolved references.. I forget how though
 :-/

The same way it's done with the kernel nowadays.. Look into your
/sys/compile/WHATEVER/Makefile, and hack.c file there.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Kernel threads (RE: alphaworks 1.3 linux port)

2000-05-26 Thread Andrzej Bialecki

(I CC:'d to -hackers, perhaps someone can enlighten us wrt. the
availability of kernel threads..)

On Fri, 26 May 2000, Koster, K.J. wrote:

  
   Has anyone had a look at this? Reports are that it's a big 
   improvement over the BDown stuff. Anyone had a play yet?
 
 1.3 is a big improvement over 1.2.2 performancewise, at least on Windows.
 
 
  it works great under linux (redhat 6.1) but i wasn't able to 
  get it to run under linux emulation of freebsd 4.0.  if anyone
  figures it out, i'd love to hear how they did it.
 
 Could you elaborate on your attempts to get it running? Any error messages
 or irregular behaviour? What version of the linux port were you using?

As I wrote about two weeks ago, I tried to get it running on
relatively up-to-date 5.0-CURRENT. Alphaworks JVM uses native threads on
Linux, which (as far as I understand) are impossible to have right now,
either under Linux emulation or otherwise.

The error message was: sigaltstack: Cannot allocate memory, which after
looking up in the manpage led me to believe that perhaps Linux doesn't add
MINSIGSTKSZ by default to the stack size. Added it to linuxulator in
appropriate places (in linux_signal.c:linux_sigaltstack()), and it stopped
complaining, but started eating 100% CPU. At which point I gave up...

 Obviously, the matter is more complicated than that - that is, it was
shooting in the dark. I know I don't have kernel threads, I was just
curious where it would bomb out.. :-)

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: ATM adapter

2000-05-17 Thread Andrzej Bialecki

On Wed, 17 May 2000, Daniel Hilevich wrote:

 Hi,
 I'm looking to purchase an ATM adapter for my FreeBSD box. The two adapters
 specified in the "Integrating ATM networking into BSD" document (Adaptec
 ANA-59x0  efficient ENI-155) are no longer available.
 My needs are simple:
 -PCI/ISA ATM adapter.
 -Compatibility with the en0 driver (or any other driver that exists for
 FreeBSD).

The cards and the driver you mention is the old ATM implementation made by
Chuck Cranor (sp?). There is much newer and much more sophisticated
framework called HARP, which is part of FreeBSD beginning with, I think,
3.0-RELEASE. HARP supports (among others) Fore PCA-200e card which I
use. See the docs in /usr/share/examples/atm.

NOTE: this card requires loading a firmware each time it's initialized
(after reboot). The firmware has to be _exactly_ the version that is
mentioned in the HARP docs, because HARP drivers refer to locations in the
binary image..

Also, be sure to set proper encapsulation on both sides of your link
(e.g. LLC/SNAP).

Other than that, the card works perfectly ok for me.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: NFS attribute cache profiling sysctl variables

2000-04-16 Thread Andrzej Bialecki

On Sat, 15 Apr 2000, Zhihui Zhang wrote:

 
 I have two unrelated questions I can not figure out myself:

 (2) I am trying to display kernel profiling sysctl variables with sysctl
 -a or sysctl -A without success.  They are defined in subr_prof.c. Why
 sysctl command can not display them? I can use kgmon.

Many sysctls that return non-ascii or non-numeric values don't have any
special handlers in sysctl(8), so they are silently omitted from the
listing. However, you should see them with -A... You can also write a
trivial 10 line program to try and retrieve the values by calling
sysctlbyname (or sysctl if you know the OIDs).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: How to read a file from a device driver?

2000-03-19 Thread Andrzej Bialecki

On Fri, 17 Mar 2000, Alfred Perlstein wrote:

 * Matthew N. Dodd [EMAIL PROTECTED] [000317 21:22] wrote:
  On Fri, 17 Mar 2000, Gary T. Corcoran wrote:
   I'm trying to initialize a network device, and I'm trying to download
   code *into* my device from some binary system files.  There is no
   "user space" or user process, for that matter, to deal with at this
   point. I just want to (at this step) open a file(s) directly from my
   device driver, read the file(s), and download the relevant parts to my
   device.
  
  There isn't really any clean way of doing this so most drivers that need
  to load firmware usually compile them in.  :/
 
 Now that I think about it, with FreeBSD's ability to dynamically load
 and unload modules it would seem like using anything else would be
 pretty annoying unless there's something else we don't understand here.

I think if you combine the ability to load arbitrary chunks of data (from
within bootloader) as modules, with similar auto-loading as in the vfs
case, you'll have a good solution.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Getting CPU usage in FreeBSD

2000-03-12 Thread Andrzej Bialecki

On Sun, 12 Mar 2000, Jordan K. Hubbard wrote:

  I'm definitely for it... If I can get permission from Jordan, perhaps the
  attached patches can make it into upcoming release.
 
 I think it's a fine idea, I'm just not sure one day before release
 is the time to be talking about it.  It should have been raised
 before now. :(

I understand your concern. I don't think the sky will fall on our heads if
these patches will be integrated after the release. :-) They are more like
a convenience, not a must.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Getting CPU usage in FreeBSD

2000-03-12 Thread Andrzej Bialecki

On Sat, 11 Mar 2000, Kris Kennaway wrote:

 On Sun, 12 Mar 2000, Oliver Fromme wrote:
 
  Then look up the definition of kread() in the same file, and
  how the contents of cur.cp_time are used in the cpustats()
  function.  Note that "cur" is a "struct statinfo", which is
  defined in /usr/include/devstat.h.  The CPU states are defined
  in /usr/include/sys/dkstat.h.
 
 We probably should make this into a sysctl to divorce the binaries from
 having to read kvm.

I'm definitely for it... If I can get permission from Jordan, perhaps the
attached patches can make it into upcoming release.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 


Index: sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.25
diff -u -r1.25 sysctl.c
--- sysctl.c1999/11/22 08:43:00 1.25
+++ sysctl.c2000/03/12 15:35:12
@@ -46,6 +46,7 @@
 #endif /* not lint */
 
 #include sys/types.h
+#include sys/dkstat.h
 #include sys/stat.h
 #include sys/sysctl.h
 #include sys/resource.h
@@ -219,6 +220,29 @@
 /* These functions will dump out various interesting structures. */
 
 static int
+S_cpu_time(int l2, void *p)
+{
+   long *cpt=(long *)p;
+   double d,total;
+   int i;
+
+   total=0;
+   for(i=0;iCPUSTATES;i++)
+   total+=*(cpt+i);
+   d=100**(cpt+CP_USER)/total;
+   printf("{ user=%.0f%% ",d);
+   d=100**(cpt+CP_NICE)/total;
+   printf("nice=%.0f%% ",d);
+   d=100**(cpt+CP_SYS)/total;
+   printf("sys=%.0f%% ",d);
+   d=100**(cpt+CP_INTR)/total;
+   printf("intr=%.0f%% ",d);
+   d=100**(cpt+CP_IDLE)/total;
+   printf("idle=%.0f%% }",d);
+   return(0);
+}
+
+static int
 S_clockinfo(int l2, void *p)
 {
struct clockinfo *ci = (struct clockinfo*)p;
@@ -417,6 +441,7 @@
case 'S':
i = 0;
if (!strcmp(fmt, "S,clockinfo"))func = S_clockinfo;
+   else if (!strcmp(fmt, "S,cpu_time"))func = S_cpu_time;
else if (!strcmp(fmt, "S,timeval")) func = S_timeval;
else if (!strcmp(fmt, "S,loadavg")) func = S_loadavg;
else if (!strcmp(fmt, "T,dev_t"))   func = T_dev_t;


Index: kern_clock.c
===
RCS file: /home/ncvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.105
diff -u -r1.105 kern_clock.c
--- kern_clock.c2000/02/13 10:56:32 1.105
+++ kern_clock.c2000/03/12 15:35:44
@@ -105,6 +105,9 @@
 SYSCTL_STRUCT(_kern, KERN_BOOTTIME, boottime, CTLFLAG_RD,
 boottime, timeval, "System boottime");
 
+SYSCTL_OPAQUE(_kern, OID_AUTO, cpu_time, CTLFLAG_RD, cp_time,
+   sizeof(cp_time), "S,cpu_time", "CPU times");
+
 /*
  * Which update policy to use.
  *   0 - every tick, bad hardware may fail with "calcru negative..."



Re: Getting CPU usage in FreeBSD

2000-03-12 Thread Andrzej Bialecki

On Sun, 12 Mar 2000, Oliver Fromme wrote:

 Kris Kennaway [EMAIL PROTECTED] wrote in list.freebsd-hackers:
   On Sun, 12 Mar 2000, Oliver Fromme wrote:
Then look up the definition of kread() in the same file, and
how the contents of cur.cp_time are used in the cpustats()
function.  Note that "cur" is a "struct statinfo", which is
defined in /usr/include/devstat.h.  The CPU states are defined
in /usr/include/sys/dkstat.h.
   
   We probably should make this into a sysctl to divorce the binaries from
   having to read kvm.
 
 Sounds like a good idea.  But then again, vmstat.c uses kvm
 for about a dozen different things.  Shouldn't they all be
 made into sysctls then?  Just wondering...

Many of them can already be obtained via sysctl (e.g. vmtotal, proc
list). This is rather historical dependency, or one related to very rare
uses (like reading VM statistics from post mortem dump).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Is FreeBSD dead ?

2000-03-11 Thread Andrzej Bialecki

On Sat, 11 Mar 2000, Jordan K. Hubbard wrote:

 your fortune teller!  Otherwise, I'd say you're doing a lot more harm
 than good with this kind of speculation and have to seriously question
 your motives at this point.

(Well, I was going to stay away, but I can stand it no longer...)

Be sure all of you that there are many (majority?) people who regard this
merge as something very promising, giving us fantastic opportunities. If
you hear the voices of doom-sayers here, it's only because many other
people are so content that they just sit on a sofa, purring and thinking
of the possibilities...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Tuning TCP/IP Performance

2000-03-04 Thread Andrzej Bialecki

On Sat, 4 Mar 2000, Paul Robinson wrote:

 Hi,
 
 I've been trying to get TCP/IP performance as fast as possible by playing
 around with sysctl (playing in the net.inet area) and so on, and was
 wondering if there were any comprehensive resources on this that I've
 missed. Whenever I do a sysctl -d -a to get a list of descriptions, I get
 the following on 3.2-RELEASE:
 
 sysctl: sysctl name -1 1024 2: No such file or directory

Retrieval of descriptions is not implemented yet. I'm afraid you'll need
to resort to grepping through the source...

 
 Any idea as to what's going on here?
 
 Also, I seem to remember hearing about a method used on SunOS to send the
 first four bytes of the data payload back with the SYN ACK which gives the
 appearance of improved performance on benchmarks. Does anybody know as to
 whether this is possible under any version of FreeBSD? I'll move to 4.0 if
 I have to. :)

There was a recent discussion (about a month ago) on -current about
delayed ACKs. It's in the archives.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



SPY 1.0 released

2000-02-14 Thread Andrzej Bialecki

Hi,

The new version of SPY - a kernel module for monitoring syscalls - is
available for download from:

http://www.freebsd.org/~abial/spy/

Please read the README.txt supplied with the package. This module has been
tested only with FreeBSD 4.0 - it may require some minor changes to work
with other releases.

Summary of changes from the previous version:

* each syscall can be intercepted, and either monitored (with adjustable
level of details) or disabled based on process credentials

* setting of per-syscall monitoring/disable options has been implemented

* options now have symbolic names, rather than being binary masks.

* sysctl tunables now reside under kern.spy.* instead of creating their
own root category.

* a manpage - thank to Sheldon Hearn, who provided manified version of
README included in previous release - it was a good skeleton for the new
manpage.

As usually, comments and suggestions are welcome.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Kernel messages, msgbuf and syslog

2000-02-12 Thread Andrzej Bialecki

Hi,

I was wondering if there is any way currently to emit a message from
within kernel, so that syslogd can pick it up later on, but without
spoiling the standard message buffer. AFAIK, there is no way to do it
right now.

The reason I'm asking is that quite a few programs (most notably
ipfw) spit countless messages to kernel msgbuf, thus overwriting any other
important info.

Is there any interest among people to implement such feature?

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: General lameness regarding exec()

2000-02-04 Thread Andrzej Bialecki

On Fri, 4 Feb 2000, Michael Bacarella wrote:

 
 I patch my systems to log exec() calls because I think it's useful, but I
 really don't know how to go about making it a general contribution.
 
 Anyone like this idea? Any Suggestions for how I should really implement 
 it?

Have a look at:

http://www.freebsd.org/~abial/spy/README

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: downed IP addresses/redundancy

2000-01-29 Thread Andrzej Bialecki

On Sun, 30 Jan 2000, Joe Abley wrote:

 On Sat, Jan 29, 2000 at 01:19:53AM +, Tony Finch wrote:
  I'd be interested to know of a free implementation of VRRP for the BSD
  network stack.
 
 I started to look at this a while back, but started to flounder when
 I looked for an existing interface to allow me to source frames on
 a local ethernet with a userland-specified MAC address.
 
 Actually, I think I looked on OpenBSD, and can't remember whether I
 looked on FreeBSD too. If anybody has a good idea about how to send
 and receive frames on a local ethernet interface using one of several
 possible local MAC addresses (most user-specified) I can probably
 resurrect the code.

Mhmmm... I'm using the code developed by Bill Paul, to change MAC address
via special ioctl. It works just fine for me.

http://www.freebsd.org/~wpaul/setmac.tar.gz

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: aio_read crashing certain kernels.

2000-01-27 Thread Andrzej Bialecki

On Wed, 26 Jan 2000, Matthew Dillon wrote:

 This is an incredibly scary program! It's sending an iocb to aio_read 
 and then pops the stack and exits.  The act of exiting could very well
 scribble all over the iocb structure while the I/O is in progress and, 
 of course, then the program invalidates the stack and exits.

Even if that's the case, it's still a userland program that is able to
panic the system. So, no matter what the program does, it's still a bug in
the way we handle aio.


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Better fixit (was: Why was rsh removed from the fixit floppy?)

2000-01-24 Thread Andrzej Bialecki

On Sun, 23 Jan 2000, Kris Kennaway wrote:

 On Mon, 24 Jan 2000, Peter Jeremy wrote:
 
  On Fri, 21 Jan 2000 18:01:34 +0530, Greg Lehey [EMAIL PROTECTED] wrote:
  If you want a better fixit floppy, you should consider the new custom
  disk pair with PicoBSD ...  There's still space on there; what
  else could we put there?
  
  ssh or OpenSSH (though this might cause distribution problems - how did
  Jordan's visit to WC's Counsel go?)
 
 Unfortunately openssh is quite a bit bigger than the standard ssh, because
 openssl isn't exactly the slimmest crypto library in the world :-) But, it
 would definitely be a cool thing.

Feel invited to visit freebsd-small, where we discuss now future
directions for small floppy-based setups (which include installation disks
as well).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Learning the FreeBSD Kernel

2000-01-23 Thread Andrzej Bialecki

On Sun, 23 Jan 2000, Bill Maniatty wrote:

  Definately not an ethernet card. *g*
  Seems no-one can keep up with Bill Paul in that aspect. =)
 
 We probably could not compete :-), but we are interested in ethernet
 card drivers (at some point) and would like to learn.
  
  You could try usb devices and contact Nick Hibma for his expertise on
  that area.
 
 How mature is the USB driver technology?  If it is pretty preliminary
 we may wish to visit that later.  Please recall that we are on a learning
 curve here.

Another thing to consider (AFAIU the issues here, of course :-) is whether
to choose a device that sits directly on one of standard buses (like PCI
or ISA), or has intermediate bus abstraction layer in between (like
e.g. ppbus or usb). I would assume that learning the latter would take
more time.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Great FICL Hacks

2000-01-22 Thread Andrzej Bialecki

On Sat, 22 Jan 2000, Michael Kennett wrote:

 I've been playing around with the boot loader(8), which seems to be a
 very powerful piece of software. However I'm really only using the 'load',
 'unload', and 'boot' functions. I'd be interested in hearing about more
 powerful uses of this software.
 
 Are there any great hacks of FICL that people have done?

/usr/share/examples/bootforth. As well as, of course, /boot/*.4th .
It seems that currently Daniel Sobral is the best source to answer more
advanced questions...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: libelf and Elf Interface Routines

2000-01-14 Thread Andrzej Bialecki

On Fri, 14 Jan 2000, Josef Karthauser wrote:

 On Fri, Jan 14, 2000 at 08:34:15AM -0500, James Howard wrote:
  I was playing with a program written for Solaris to see if I could port it
  to FreeBSD (another learning experience thing;).  The program uses
  Solaris's libelf to talk to Elf files.  It does this quite extensively in
  fact.  Does FreeBSD provide a similar interface?  Poking around the man
  pages has revealed nothing but I wanted to ask before I gave up.  If no
  interface is currently provided, is there one currently being planned?
  
  Thank you, Jamie
 
 The elf(5) manual page may be a good place to start.  (It's on modern
 versions of FreeBSD).
 
 We don't have a libelf though.

Does libbfd provide the functionality you need? (see gdb sources).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: using vgl

1999-12-26 Thread Andrzej Bialecki

On Sat, 25 Dec 1999, Tim Tsai wrote:

 On Sat, Dec 25, 1999 at 01:07:50PM -0500, Brian Fundakowski Feldman wrote:
  On Sat, 25 Dec 1999, Tim Tsai wrote:
  
   I'm trying to do some work based on vgl but it appears that it is tied to
   syscons and any vgl programs must be started off a console.  Is there any
   way I can start a vgl program from a remote terminal (but have the output
   be displayed on the local VGA screen) without writing a proxy of some
   kind?

See the sources for libvgl. You can do it easily by changing jus a few
lines - the ioctl"s need to be executed on /dev/console instead of curent
vty.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Register a KLD module

1999-12-18 Thread Andrzej Bialecki

On Sat, 18 Dec 1999, Zhihui Zhang wrote:

 
 I have looked at the KLD examples and found out that they boils down to a
 DECLARE_MODULE() macro with the subsystem given as SI_SUB_DRIVERS. Is
 there any reason for using this particular SI_SUB_DRIVERS? I see another
 example at http://www.freebsd.org/~abial/ that uses SI_SUB_EXEC.
 
 Is this subsystem id really useful for KLDs? KLDs are loaded when we run
 the kldload command and the subsystem ids are sorted at boot time.

This is not quite true. The KLDs can be loaded by the bootloader.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Dynamic sysctls (Re: Per CPU timekeeping for SMP)

1999-12-17 Thread Andrzej Bialecki

On Fri, 17 Dec 1999, Arun Sharma wrote:

 I have also figured out how to dynamically register sysctl nodes.
 The trick is to basically malloc a sysctl_oid and fill in the right
 fields and calling sysctl_register_oid. The code is in a kernel
 module available from:
 
 http://sharmas.dhs.org/~adsharma/projects/freebsd/sysctl.tar.gz
 
 It really needs to go into the base kernel. Also, I think
 sysctl_register_long and its yet to be written friends (register_int)
 etc, need to go into kern_sysctl - so that others can reuse the code
 to dynamically create sysctl nodes.

I was thinking exactly about the same, and I was going to implement them
myself... IMO these patches should go to the tree - without them the work
that Mike Smith put into sysctl infrastructure is much less useful for
average Joe Kernel Hacker...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Dynamic sysctls (Re: Per CPU timekeeping for SMP)

1999-12-17 Thread Andrzej Bialecki

On Sat, 18 Dec 1999, Peter Wemm wrote:

 Andrzej Bialecki wrote:
  On Fri, 17 Dec 1999, Arun Sharma wrote:
  
   I have also figured out how to dynamically register sysctl nodes.
   The trick is to basically malloc a sysctl_oid and fill in the right
   fields and calling sysctl_register_oid. The code is in a kernel
   module available from:
   
   http://sharmas.dhs.org/~adsharma/projects/freebsd/sysctl.tar.gz
   
   It really needs to go into the base kernel. Also, I think
   sysctl_register_long and its yet to be written friends (register_int)
   etc, need to go into kern_sysctl - so that others can reuse the code
   to dynamically create sysctl nodes.
  
  I was thinking exactly about the same, and I was going to implement them
  myself... IMO these patches should go to the tree - without them the work
  that Mike Smith put into sysctl infrastructure is much less useful for
  average Joe Kernel Hacker...
 
 Err.. That was Doug Rabson (dfr) who fixed the sysctl stuff to finish
 making it dynamic.  sysctl_register_xxx() are wrappers around
 sysctl_register_oid(), but I guess it's ok to make some helper functions to
 make the existing functionality to make it easier to use.

Oh... My sincere apologies then for wrong attribution.

Anyway, I think this stuff (although it may seem redundant to you) is very
helpful. It takes some time to figure out how to untangle the SYSCTL_*,
SLIST_*, DATA_SET and linker sets (which are not really indispensable
here) to really learn how the dynamic sysctls work. These functions
provide useful and handy shortcuts. IMHO, of course.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Fwd: Re: kstat - an API for gathering kernel stats

1999-12-08 Thread Andrzej Bialecki

On Wed, 8 Dec 1999, Dan Seguin wrote:

 
 Is it possible to make nodes dynamically that are immutable from userland
 (even by root), but modifyable from the kernel?

Yes, of course. Just mark them as read-only (CTLFLAG_RD). You are free to
assign any value to them within the kernel. If it's more complex type
handled with SYSCTL_PROC (like eg. vm.zone sysctl) you still can decide
what value you return from kernel, and you can ignore any requests to
assign new values.

 
 On Mon, 29 Nov 1999, Andrzej Bialecki wrote:
 
  
  Yes. See for example linux emulator or my SPY module:
  
  http://www.freebsd.org/~abial/spy
  
  You can also create whole new branches, as the second example shows.
  
  Andrzej Bialecki
  
  //  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
  // ---
  // -- FreeBSD: The Power to Serve. http://www.freebsd.org 
  // --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 
 
 
 
 
 Dan SeguinTexar Software, Corporation.
 
 Visit us at the RSA Conference 2000, January 16-20, San Jose,  Booth # 1241
 
 
 
 


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Fwd: Re: kstat - an API for gathering kernel stats

1999-12-08 Thread Andrzej Bialecki

On Wed, 8 Dec 1999, Arun Sharma wrote:

 On Mon, Nov 29, 1999 at 10:09:35AM +0100, Andrzej Bialecki wrote:
   I was thinking about implementing SMP cpu stats using sysctl today and
   I have a question - can I create sysctl nodes dynamically ?
   
   i.e.
   
 for (cpu = 0; cpu  get_num_cpus(); cpu++) {
 /* create sysctl node here ? */
 }
  
  Yes. See for example linux emulator or my SPY module:
  
  http://www.freebsd.org/~abial/spy
  
  You can also create whole new branches, as the second example shows.
 
 Thanks - that was useful. However, I noticed that only the leaves 
 (SYSCTL_INT/LONG/STRING) etc can be dynamically created. But nodes
 can't be dynamically created. Am I correct ?

Erhm.. No.

Look closer at the SPY module. I create the whole branch from the root
level. In the standard system there is no such thing as "kld" node,
neither there is a "spy" node. I created both of them. Only then I created
a bunch of leaves (of course, nothing stops you from creating some more
leaves on each intermediate level, if you need them).

The same is with linux emulator. It creates "compat" node, then
"linux" node, and then a couple of sysctls.


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Fwd: Re: kstat - an API for gathering kernel stats

1999-11-29 Thread Andrzej Bialecki

On Sun, 28 Nov 1999, Arun Sharma wrote:

 
 [ For some reason, this post through muc.lists.freebsd.hackers gateway didn't
   show up on the mailing list. Forwarding it to the mailing list.. ]
 
 On Thu, 04 Nov 1999 20:38:50 -0800, Mike Smith [EMAIL PROTECTED] wrote:
   I don't see any examples in sys/modules. The SYSCTL_INT macros eventually
   expands to DATA_SET which puts certain data in a different ELF section.
  
  You don't do anything magic at all; it's handled invisibly by the 
  kernel linker.
 
 I was thinking about implementing SMP cpu stats using sysctl today and
 I have a question - can I create sysctl nodes dynamically ?
 
 i.e.
 
   for (cpu = 0; cpu  get_num_cpus(); cpu++) {
   /* create sysctl node here ? */
   }

Yes. See for example linux emulator or my SPY module:

http://www.freebsd.org/~abial/spy

You can also create whole new branches, as the second example shows.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Non-standard FFS parameters

1999-11-23 Thread Andrzej Bialecki

On Tue, 23 Nov 1999, Joe Greco wrote:

  On Fri, 8 Oct 1999, Matthew Dillon wrote:
  
   : 
   : Adjusting the bytes-per-inode (-i) specification in newfs should not 
   : pose a problem.
   :
   :IOW now you say it's ok to use very high values of -i... ;-) 
   :
   :Andrzej Bialecki
   
   No, I didn't say that.  My recommended maximum is still 262144.  Fsck 
   should be reasonably fast with that number and the filesystem should 
   still be able to maintain reasonable efficiency.
  
  Ok, I can live with that, I guess. Thanks a lot for your help!
 
 What's the recommended way to reduce the number of cylinder groups a bit?

...except manually changing the calculations in newfs/mkfs.c ? What values
are reasonable for large filesystems?

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



ANNOUNCE: SPY-0.1 - syscalls monitor

1999-11-22 Thread Andrzej Bialecki

Hi,

SPY allows you to monitor and/or selectively block syscalls on your
system. It could be used either as a safety monitoring device, policy
enforcement, or debugging tool. You can download the sources (NOTE:
-current only) from:

http://www.freebsd.org/~abial/spy-0.1.tgz

Excerpt of README follows:

-

This kernel module allows you to selectivly monitor and/or disable
execution of system calls (syscalls) on your system, and log detailed
info to syslog service.

It's sometimes desirable to monitor selected syscalls for security
reasons, or for debugging. For example, many security holes are
related to setuid/setgid programs. You can monitor and log all
attempts to use these syscalls. You can also disable certain syscalls
altogether, if you really know what you're doing...

Already existing tools (like ktrace(1) or truss(1)) can provide
much more detailed information, but they are more fit to tracing
single processes or process groups, and not setting overall system
policy (speaking of which: this module is an example of very primitive
auditing and policy enforcing device).

Features


Using SPY module you can set up your system to:

* log detailed info on execution of any selected syscall. In case of
  a few most important ones, there are specific handlers to log also
  the arguments of the syscall in understandable format. They are
  as follows:
execve, set*id, chdir, open, link, unlink, chmod, chown,
mkdir, rmdir

  (You are welcome to add others :-) Any syscall can be monitored, but
  in general case its arguments cannot be interpreted.

* set kind of information to be logged. You can restrict logging on
  a per syscall basis, with the following constraints (OR-ed):
- uid or gid
- superuser only
- all users except superuser
- combination of the above
  You can also adjust level of logging on a per syscall basis. There are
  three levels available:
- basic: logs minimum information sufficient to identify the
  syscall and process owner
- arg: logs also the arguments of the syscall, if possible
- full: logs all information available.

* disable selected syscalls, which prevents specified categories of
  users to use them at all, and any such attempt is logged.

By default the SPY module logs attempts to use execve syscall by
root owned processes, and setuid/setgid by any user owned process.
Default mode for other syscalls, used when you add them to monitoring,
is to log all uses with all arguments.

-


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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



Re: Non-standard FFS parameters

1999-10-07 Thread Andrzej Bialecki

On Wed, 6 Oct 1999, Matthew Dillon wrote:

 : test3:/root# newfs -i 262144 -f 8192 -b 65536 /dev/rvn1c
 : /dev/rvn1c: 83886080 sectors in 2560 cylinders of 1 tracks, 32768 sectors
 : 40960.0MB in 160 cyl groups (16 c/g, 256.00MB/g, 1024 i/g)

Running bonnie on the filesystem with these parameters results in
unkillable process sitting in getblk (it's the first phase of bonnie test
when they use putc() to create the file). It just sits there and doesn't
consume CPU. The OS is 3.3-R.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Non-standard FFS parameters

1999-10-07 Thread Andrzej Bialecki

On Thu, 7 Oct 1999, Matthew Dillon wrote:

 
 :
 :Running bonnie on the filesystem with these parameters results in
 :unkillable process sitting in getblk (it's the first phase of bonnie test
 :when they use putc() to create the file). It just sits there and doesn't
 :consume CPU. The OS is 3.3-R.
 :
 :Andrzej Bialecki
 
 Hmmm.  It's quite possible, 3.x's getnewbuf() code is pretty nasty.  I
 have a solution under test for 4.x (current).  There simply may not be
 anything that can be done for 3.x short of porting current's getnewbuf()
 code over, and doing so has been deemed too risky by DG due to all the
 collateral porting that would also have to be done.  I agree with that
 assessment, plus it's a huge amount of work that I don't have time to do
 at this late date.
 
 Try using a smaller block size, like 16K.  If that doesn't work then just
 stick with 8K I guess.  The kernel's clustering code should still make it
 reasonably efficient.

Yeah, I guess that's the only way to do it on 3.x... But how can I speed
up fsck then, since newfs will create millions of inodes I don't need
which will cause fsck to run for ages...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Non-standard FFS parameters

1999-10-06 Thread Andrzej Bialecki

On Tue, 5 Oct 1999, Matthew Dillon wrote:

 Mmmm.  I ran into problems in -current trying to use a block size of
 64K.  It should be relatively easy for me to track this down and fix
 it, but I don't know if there are other problems lying in wait.

IOW it may appear to run while eating your FS away No,thanks :-/

 :* what maximum value can I use for -i (bytes per inode) parmeter? I
 :aalready tried 16mln ...
 
 I wouldn't go that high.  Try 262144.  Here's an example:

Why? I only need a couple o hundred inodes on this fs..

 
 newfs -i 262144 -b 65536 -f 8192 /dev/rvn1c
 
 test3:/root# newfs -i 262144 -f 8192 -b 65536 /dev/rvn1c
 /dev/rvn1c: 83886080 sectors in 2560 cylinders of 1 tracks, 32768 sectors
 40960.0MB in 160 cyl groups (16 c/g, 256.00MB/g, 1024 i/g)

Well, yes, but you used non-standar blocksize which you yourself don't
recommend. With standard 8192/1024 this command creates millions of
inodes which I don't need - what's worse, they cause fsck to run for
hours instead of seconds.

 
 :* and finally, how th above choices affect the FS performance in my case?
 :
 :Thanks in advance for any insights!
 :
 :Andrzej Bialecki
 
 The higher the bytes per inode the fewer the inodes and the faster
 fsck will run if you have to recover the filesystem.  Too high a 
 bytes-per-inode will screw up the filesystem's ability to manage
 the cylinder groups, though.

Why? I thought this parameter describes (indirectly) only the total number
of inodes in the FS, which is otherwise set proportionally to FS size,
assuming it will be filled with very small files (2048B IIRC).

I suspect it might have something to do with the placement policy (which
CG to use to put additional blocks belonging to the file), but I don't see
any immediate connection...

 
 The higher the block size the fewer indirect blocks are required to 
 access a linear file, but as the block size increases the system's
 caching effectiveness will decrease.
 
 I would not use a block size greater then 64K, and I wouldn't specify
 a bytes-per-inode greater then 262144.
 
 There may be problems specifying larger block sizes, though nothing
 that we can't fix.

What kind of problems? Will it simply not work, or will it corrupt the
FS?

Thanks a lot for these comments!

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Non-standard FFS parameters

1999-10-05 Thread Andrzej Bialecki

Hi,

The system in question (3.3-stable) needs to use a large FS (ca. 40GB).
The defaults for such filesystem are ridiculous, given that it will hold
at most couple of hundred big data files. So, my question is:

* should I change the cpg (default 16) to some bigger value?
* is it safe to run production system with non-standard block and fragment
size (e.g. 32768 and 4096)?
* what maximum value can I use for -i (bytes per inode) parmeter? I
aalready tried 16mln ...
* and finally, how th above choices affect the FS performance in my case?

Thanks in advance for any insights!

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: what is devfs?

1999-09-22 Thread Andrzej Bialecki

On Mon, 20 Sep 1999, Julian Elischer wrote:

 as I explained a few days ago,
 MFS explodes because it synthesises a device vnode
 
 The synthesized vnode is someohow confused as to whether it's a devfs
 vnode or a UFS vnode.
 I can't remember the exact problem but it may have something to do with
 using it as a methid aof getting to teh strategy routine..
 I don't remember exaclty, but I think it may be possible to not do that
 any  more.

I discovered this the hard way when I tried to build picobsd floppy with
DEVFS. If you look in the archives, I think I posted the complete
backtrace.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: what is devfs?

1999-09-20 Thread Andrzej Bialecki

On Sun, 19 Sep 1999, Chuck Robey wrote:

 On Sun, 19 Sep 1999, Julian Elischer wrote:
 
  
  
  On Sun, 19 Sep 1999, Chuck Robey wrote:
  
   On Sat, 18 Sep 1999, Julian Elischer wrote:
   
DEVFS itself works fine however a subsystem it required to be a useful
abstraction was vandalised and stripped out by some people who "didn't get
it" and it has not yet been replaced by equivalent code.
   
   It seems more correct (to me) to state that there was a furious
   disagreement over whether or not to allow some memory of file permissions
   in devfs.  Since there was never any agreement, DEVFS has smoldered.  I
   think there's general agreement it would be a good thing to have, but that
   argument over how to keep user configurations must be handled.
  
  file permissions were not relevant to the code that was ripped out (the
  stackable disk partitionning layers) (called SLICE).
 
 But it was to the subject on the Subject: line, Julian.  We know what side
 you're on, but there are 2 sides to the argument.  Isn't there some way
 that it can be set up to *optionally* have permission persistence?

I was one of the early consumers of DEVFS/SLICE. It mostly worked then,
without any persistance. What Julian is saying is that there was some
point in time when the things worked as they should for the DEVFS, just
without keeping any persistance. The code which was removed had nothing to
do with the persistance either.

So, as it is now DEVFS doesn't work properly, but not because of the lack
of persistance or some disagreements on this issue - it's just missing the
SLICE code.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Multiple routes to the same destination

1999-09-20 Thread Andrzej Bialecki

On 20 Sep 1999, Ville-Pertti Keinonen wrote:

 
 [EMAIL PROTECTED] (Zhihui Zhang) writes:
 
  As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple
  routes to the same destination (identical key and mask). Does the radix
  tree code in FreeBSD - 4.0 has the same limitation?  I am wondering if
  there is already a solution for this? 
 
 How would the routing code use multiple routes?  You'd need additional
 rules to determine how to use them (e.g. round-robin for load
 balancing).

Or assign them a weight. When the link goes down, the routes attached to
this interface decrease in weight by NN. If there is any other route to
the same destination with greater weight, the packets are sent that way
instead.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



RE: Custom boot.flp

1999-09-14 Thread Andrzej Bialecki
On Tue, 14 Sep 1999, Marc Nicholas wrote:

 Doesn't the boot.flp actually use sysinstall and a custom init process?
 Therefore, you'd have to replace sysinstall with an init process of some
 sort...

No, sysinstall is THE custom init. Yes, you'd have to replace it with your
own init, if you really want to. You can take a look at
src/release/picobsd/tinyware/oinit. Or, you can take a look at scripting
abilities in sysinstall, if they are enough for your needs.

 Someone correct me if I'm talking out of my a.out ;-)

I thought you were an elf...

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



RE: CS Project

1999-09-10 Thread Andrzej Bialecki

On Thu, 9 Sep 1999, Daniel O'Connor wrote:

 
 On 09-Sep-99 Jason Young wrote:
   After some thought, I think the mount option idea is best. I hadn't
   thought of that before. One might want to apply different procfs
   security policies to different mounts of procfs, especially in a
   jail() situation. Good call.
 
 Yeah, you'd have to make sure procfs doesn't mind being mounted multiple times,
 something I'm not sure is true.

Also, don't forget about sysctl. kvm will defend itself with permissions
on /dev/kme, but sysctl is available for reading to anyone (see
src/release/picobsd/tinyware/sps to see what i mean).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



RE: CS Project

1999-09-10 Thread Andrzej Bialecki
On Thu, 9 Sep 1999, Daniel O'Connor wrote:

 
 On 09-Sep-99 Jason Young wrote:
   After some thought, I think the mount option idea is best. I hadn't
   thought of that before. One might want to apply different procfs
   security policies to different mounts of procfs, especially in a
   jail() situation. Good call.
 
 Yeah, you'd have to make sure procfs doesn't mind being mounted multiple 
 times,
 something I'm not sure is true.

Also, don't forget about sysctl. kvm will defend itself with permissions
on /dev/kme, but sysctl is available for reading to anyone (see
src/release/picobsd/tinyware/sps to see what i mean).

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



High Availability (Re: MAC takeover )

1999-09-08 Thread Andrzej Bialecki

On Tue, 7 Sep 1999, David Sharp wrote:

 
 The i82559 (fxp) hardware supports it.  I imagine most previous 
 versions of the chipset are also capable.  For the software,
 add an ioctl to fxp_ether_ioctl that changes the 
 fxp_init(sc).  Add your new ioctl to ifconfig and you should be done.

Thanks a lot! That's indeed a good news - as it happens I have quite a few
fxp on the shelves here...

Another issue: I was recently involved in a project which required HA
solutions (that's why I asked]. I gathered a lot of ideas and materials
(and perhaps some code if that company agrees to release it). Is ther
someone else here who is interested in these issues, and using FreeBSD for
that? We could start some info pages, howto's, and perhaps a mailing
list...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



High Availability (Re: MAC takeover )

1999-09-08 Thread Andrzej Bialecki
On Tue, 7 Sep 1999, David Sharp wrote:

 
 The i82559 (fxp) hardware supports it.  I imagine most previous 
 versions of the chipset are also capable.  For the software,
 add an ioctl to fxp_ether_ioctl that changes the 
 fxp_init(sc).  Add your new ioctl to ifconfig and you should be done.

Thanks a lot! That's indeed a good news - as it happens I have quite a few
fxp on the shelves here...

Another issue: I was recently involved in a project which required HA
solutions (that's why I asked]. I gathered a lot of ideas and materials
(and perhaps some code if that company agrees to release it). Is ther
someone else here who is interested in these issues, and using FreeBSD for
that? We could start some info pages, howto's, and perhaps a mailing
list...

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: The infamous dead alternate system clock

1999-09-07 Thread Andrzej Bialecki

On Tue, 7 Sep 1999, Andrzej Bialecki wrote:

 * does the problem affect anything else? I'm not at the console, so I
 can't be sure, but the machine appears to be very sluggish over the net.

It seems the sluggishness was caused by two Midnight commanders spinning
like crazy and eating 200% of CPU. But the original question still aplies.


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



The infamous dead alternate system clock

1999-09-07 Thread Andrzej Bialecki
Hi,

ASUS SMP motherboard (if it matters) with two Pentium IIIs, running SMP
kernel 3.3-RC. Running an UP kernel instead is not an option (i.e. I can
try it out, but I need both CPUs eventually).

Any ideas? I looked in the archives, and found Tor Egge's fix. So, here
are my questions:

* does the problem affect anything else? I'm not at the console, so I
can't be sure, but the machine appears to be very sluggish over the net.

* why this fix is a kludge? what bad consequences can I experience with
it, instead of the above?

I should add to this that I have something like 10 affected systems, soon
going to the production, so the answer is very important to me. In the
light of upcoming RELEASE I think this is also something worth
investigating.

Thanks!


Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: The infamous dead alternate system clock

1999-09-07 Thread Andrzej Bialecki
On Tue, 7 Sep 1999, Andrzej Bialecki wrote:

 * does the problem affect anything else? I'm not at the console, so I
 can't be sure, but the machine appears to be very sluggish over the net.

It seems the sluggishness was caused by two Midnight commanders spinning
like crazy and eating 200% of CPU. But the original question still aplies.


Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: dumps before init?

1999-09-06 Thread Andrzej Bialecki

On Mon, 6 Sep 1999, Ruslan Ermilov wrote:

 On Sat, Sep 04, 1999 at 05:39:01PM -0600, Warner Losh wrote:
  How does one  enable dumps before init?
  
  Warner
 
 According to the dumpon(8) manpage:
 
 The dump device can also be specified at kernel compile time using the
 ``dumps on'' clause in the kernel configuration file (see config(8)).
 This is useful when the kernel panics before multi-user mode is reached.
 Subsequent successful invocations of dumpon will override the compiled in
 value.

Hmmm... Wasn't this config line removed in -current? You can do it in
-stable, though.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: dumps before init?

1999-09-06 Thread Andrzej Bialecki
On Mon, 6 Sep 1999, Ruslan Ermilov wrote:

 On Sat, Sep 04, 1999 at 05:39:01PM -0600, Warner Losh wrote:
  How does one  enable dumps before init?
  
  Warner
 
 According to the dumpon(8) manpage:
 
 The dump device can also be specified at kernel compile time using the
 ``dumps on'' clause in the kernel configuration file (see config(8)).
 This is useful when the kernel panics before multi-user mode is reached.
 Subsequent successful invocations of dumpon will override the compiled in
 value.

Hmmm... Wasn't this config line removed in -current? You can do it in
-stable, though.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



MAC takeover

1999-09-02 Thread Andrzej Bialecki

Hi,

IIRC some time ago there was a vivid discussion about ability to
change/set MAC address of Ethernet cards. I'm faced with similar problem
right now: when building high-availability configuration it would be very
handy to do MAC takeover instead of IP takeover. So, my questions follow:

* which cards support it (that have FreeBSD drivers of course)?

* is there some way to set it (I couldn't find any code in the ifconfig
nor in the kernel)?

Thanks!

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



MAC takeover

1999-09-02 Thread Andrzej Bialecki
Hi,

IIRC some time ago there was a vivid discussion about ability to
change/set MAC address of Ethernet cards. I'm faced with similar problem
right now: when building high-availability configuration it would be very
handy to do MAC takeover instead of IP takeover. So, my questions follow:

* which cards support it (that have FreeBSD drivers of course)?

* is there some way to set it (I couldn't find any code in the ifconfig
nor in the kernel)?

Thanks!

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Please review: rc file changes

1999-09-01 Thread Andrzej Bialecki

On Sat, 28 Aug 1999, Matthew Dillon wrote:

 :I've never heard of that.  I've always found that two spaces
 : after end-of-sentence punctuation makes things easier to read!
 :
 :I vote for two spaces after the period before the start of a new sentence.
 :Even in the digital age, I've always found that the two spaces make

 I guess they don't teach manual typewriting classes any more :-)
 It *had* to be two spaces or you got seriously marked down!

Doesn't apply here in Europe. I vote against putting in too much
starsstripes dependent stuff... ;-)

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Please review: rc file changes

1999-09-01 Thread Andrzej Bialecki
On Sat, 28 Aug 1999, Matthew Dillon wrote:

 :I've never heard of that.  I've always found that two spaces
 : after end-of-sentence punctuation makes things easier to read!
 :
 :I vote for two spaces after the period before the start of a new sentence.
 :Even in the digital age, I've always found that the two spaces make

 I guess they don't teach manual typewriting classes any more :-)
 It *had* to be two spaces or you got seriously marked down!

Doesn't apply here in Europe. I vote against putting in too much
starsstripes dependent stuff... ;-)

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Possibility of increasing default MAXPARTITIONS from 8 to 16

1999-08-24 Thread Andrzej Bialecki

On Tue, 24 Aug 1999, Matthew Dillon wrote:

 I don't know about all of you, but for the last few years I've been
 running out of partitions!  It's even worse with today's big disks.

I know it's not the answer, it's just related question: do you know
perhaps of any initiatives (except XFS) that could significantly shorten
time it takes fsck to check big filesystems, let's say 64GB? As it is now,
it's almost unbearable. I naively thought softupdates would (almost)
eliminate the need to do fsck...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Possibility of increasing default MAXPARTITIONS from 8 to 16

1999-08-24 Thread Andrzej Bialecki

On Tue, 24 Aug 1999, Matthew Dillon wrote:

 :I know it's not the answer, it's just related question: do you know
 :perhaps of any initiatives (except XFS) that could significantly shorten
 :time it takes fsck to check big filesystems, let's say 64GB? As it is now,
 :it's almost unbearable. I naively thought softupdates would (almost)
 :eliminate the need to do fsck...
 :
 :Andrzej Bialecki
 
 Eventually Kirk is planning for softupdates to allow you to run a special 
 version of fsck in the background to clean up the block bitmap on a live 
 filesystem.  The time frame for this project is not known.
 
 Another possibility would be to mark individual cylinders clean/dirty
 to reduce the amount of work fsck must do on a normal filesystem.  It 
 would be a pretty hefty project for someone to take on, though.

Hmm.. If I understand you correctly:

* the ffs code would have to be modified to mark cylinder groups "dirty"
when there are writes to that CG.

* on unmount, after the buffers are flushed they would be marked
clean.

* on mount all "clean" flags in CGs would have to be ckecked (instead of
the single bit)

* fsck would have to be modified to recognize CG "clean" flag and prune
only those CGs.

Overall, doesn't sound _that_ complicated... but most probably I'm missing
something.


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Possibility of increasing default MAXPARTITIONS from 8 to 16

1999-08-24 Thread Andrzej Bialecki
On Tue, 24 Aug 1999, Matthew Dillon wrote:

 I don't know about all of you, but for the last few years I've been
 running out of partitions!  It's even worse with today's big disks.

I know it's not the answer, it's just related question: do you know
perhaps of any initiatives (except XFS) that could significantly shorten
time it takes fsck to check big filesystems, let's say 64GB? As it is now,
it's almost unbearable. I naively thought softupdates would (almost)
eliminate the need to do fsck...

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Possibility of increasing default MAXPARTITIONS from 8 to 16

1999-08-24 Thread Andrzej Bialecki
On Tue, 24 Aug 1999, Matthew Dillon wrote:

 :I know it's not the answer, it's just related question: do you know
 :perhaps of any initiatives (except XFS) that could significantly shorten
 :time it takes fsck to check big filesystems, let's say 64GB? As it is now,
 :it's almost unbearable. I naively thought softupdates would (almost)
 :eliminate the need to do fsck...
 :
 :Andrzej Bialecki
 
 Eventually Kirk is planning for softupdates to allow you to run a special 
 version of fsck in the background to clean up the block bitmap on a live 
 filesystem.  The time frame for this project is not known.
 
 Another possibility would be to mark individual cylinders clean/dirty
 to reduce the amount of work fsck must do on a normal filesystem.  It 
 would be a pretty hefty project for someone to take on, though.

Hmm.. If I understand you correctly:

* the ffs code would have to be modified to mark cylinder groups dirty
when there are writes to that CG.

* on unmount, after the buffers are flushed they would be marked
clean.

* on mount all clean flags in CGs would have to be ckecked (instead of
the single bit)

* fsck would have to be modified to recognize CG clean flag and prune
only those CGs.

Overall, doesn't sound _that_ complicated... but most probably I'm missing
something.


Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Anybody cobbled together a getpwent() that uses libradius?

1999-08-20 Thread Andrzej Bialecki

On Fri, 20 Aug 1999, Jaye Mathisen wrote:

 
 While whatever happens with PAM and LDAP, and all those great things, I
 would like to validate passwords via Radius...
 
 It would be most convenient if it was just in getpwent()...

I beg to differ. It's extremely easy to use pam_radius module. No changes
in sources - just edit /etc/pam.conf.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Anybody cobbled together a getpwent() that uses libradius?

1999-08-20 Thread Andrzej Bialecki

On Fri, 20 Aug 1999, Jaye Mathisen wrote:

 
 I completely missed that radius was working with pam.  A check of radius
 related stuff in the man pages didn't show anything related to PAM, and

...they are on their way - check RELENG_3, i.e. STABLE.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Anybody cobbled together a getpwent() that uses libradius?

1999-08-20 Thread Andrzej Bialecki
On Fri, 20 Aug 1999, Jaye Mathisen wrote:

 
 While whatever happens with PAM and LDAP, and all those great things, I
 would like to validate passwords via Radius...
 
 It would be most convenient if it was just in getpwent()...

I beg to differ. It's extremely easy to use pam_radius module. No changes
in sources - just edit /etc/pam.conf.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Anybody cobbled together a getpwent() that uses libradius?

1999-08-20 Thread Andrzej Bialecki
On Fri, 20 Aug 1999, Jaye Mathisen wrote:

 
 I completely missed that radius was working with pam.  A check of radius
 related stuff in the man pages didn't show anything related to PAM, and

...they are on their way - check RELENG_3, i.e. STABLE.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Saving system image to disk (NOT on a laptop)

1999-08-16 Thread Andrzej Bialecki

Hi,

To all you low-level kernel and bootloader hackers: what would it take to
save and restore a running system image (presumably from dedicated raw
partition) so that the system would continue where it left before reboot?

It doesn't sound that difficult to me - after all, laptops somehow do it -
but I know too little low-level stuff to try implementing it myself...

Any comments? Some code? ;-)


Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Saving system image to disk (NOT on a laptop)

1999-08-16 Thread Andrzej Bialecki
Hi,

To all you low-level kernel and bootloader hackers: what would it take to
save and restore a running system image (presumably from dedicated raw
partition) so that the system would continue where it left before reboot?

It doesn't sound that difficult to me - after all, laptops somehow do it -
but I know too little low-level stuff to try implementing it myself...

Any comments? Some code? ;-)


Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Create a dump image of kernel

1999-08-13 Thread Andrzej Bialecki

On Fri, 13 Aug 1999, Zhihui Zhang wrote:

 
 Can anyone tell me how to modify the config file to build a kernel that
 creates dump image whenever it panics. Currently I have to use dumpon
 command after system bootup.  But this command does not work when the
 panic happens during the bootup time, i.e., when you have no chance to
 issue the dumpon command. Thanks.

This is a common problem recently, it seems.. See my recent postings to
this group (or was it -current?).

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Create a dump image of kernel

1999-08-13 Thread Andrzej Bialecki
On Fri, 13 Aug 1999, Zhihui Zhang wrote:

 
 Can anyone tell me how to modify the config file to build a kernel that
 creates dump image whenever it panics. Currently I have to use dumpon
 command after system bootup.  But this command does not work when the
 panic happens during the bootup time, i.e., when you have no chance to
 issue the dumpon command. Thanks.

This is a common problem recently, it seems.. See my recent postings to
this group (or was it -current?).

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: your mail

1999-07-27 Thread Andrzej Bialecki

On Tue, 27 Jul 1999, Anders Vidmark wrote:

 Hi

Hej, :-)

 
 Im getting unreferenced inodes that fills up /.
 The box is running freebsd 2.2.6-release and sendmail 8.8.8
 Sendmails databases are rebuilt once every half hour.
 It seems like the unref. inodes comes from spammers.db and 
 domainalias.db.
 
 Is there a way to avoid this? Will it get better if I upgrade to 
 freebsd 3.2? upgrade sendmail?

This could be due to filesystem corruption, either because of crashes or
for some other reasons. You can try fsck -y on a quiet system (i.e. in
single-user mode).

2.2.6-R is ancient, and it contained well known security holes. The same
goes for your version of sendmail. You should definitely upgrade your
server. 3.2-STABLE is officially recommended version, but if you're afraid
of too many changes (ELF, bootloader, changed VM) you should at least
upgrade to the latest 2.2-STABLE.

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: your mail

1999-07-27 Thread Andrzej Bialecki
On Tue, 27 Jul 1999, Anders Vidmark wrote:

 Hi

Hej, :-)

 
 Im getting unreferenced inodes that fills up /.
 The box is running freebsd 2.2.6-release and sendmail 8.8.8
 Sendmails databases are rebuilt once every half hour.
 It seems like the unref. inodes comes from spammers.db and 
 domainalias.db.
 
 Is there a way to avoid this? Will it get better if I upgrade to 
 freebsd 3.2? upgrade sendmail?

This could be due to filesystem corruption, either because of crashes or
for some other reasons. You can try fsck -y on a quiet system (i.e. in
single-user mode).

2.2.6-R is ancient, and it contained well known security holes. The same
goes for your version of sendmail. You should definitely upgrade your
server. 3.2-STABLE is officially recommended version, but if you're afraid
of too many changes (ELF, bootloader, changed VM) you should at least
upgrade to the latest 2.2-STABLE.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: System unique identifier.....

1999-07-22 Thread Andrzej Bialecki
On Wed, 21 Jul 1999, Mike Smith wrote:

   That's not quite true. It wouldn't be too hard to modify existant files,
   but writing new ones/truncating would take a lot of work. It's still not
   a great idea to try to use a file on the FS for storage of persistent
   data. Wouldn't it be possible to have the kernel itself read in persistent
   data (in some form such as getenv?) to be written to disk? That way, the
   boot loader could pass it easily, and not have to worry about storage.
  
  This may sound like a heresy to you, but... Why don't use the Forth blocks
  for that?
 
 For what?  Saving parametric data?  That was always the plan, but the 
 last thing I think anyone wants to do is rewrite the ffs code in Forth.

Ugh.. No, of course not. The former, i.e. saving parameters. I'm still
sane, you know... :-)


Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: System unique identifier.....

1999-07-21 Thread Andrzej Bialecki

On Sun, 18 Jul 1999, Brian F. Feldman wrote:

 On Sun, 18 Jul 1999, Mike Smith wrote:
 
   Mike Smith wrote:

The loader will, at some stage in the future, grow a persistent data
store in which items like this can be saved.
   
   Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
   data storage?
  
  There is little or no chance that the loader will gain the ability to 
  write back to filesystems.  Some of them don't support it (eg. 
  iso9660), others may not (TFTP, NFS), and the code required for some of 
  them (especially UFS) would be problematically large.
 
 That's not quite true. It wouldn't be too hard to modify existant files,
 but writing new ones/truncating would take a lot of work. It's still not
 a great idea to try to use a file on the FS for storage of persistent
 data. Wouldn't it be possible to have the kernel itself read in persistent
 data (in some form such as getenv?) to be written to disk? That way, the
 boot loader could pass it easily, and not have to worry about storage.

This may sound like a heresy to you, but... Why don't use the Forth blocks
for that? They were invented for that purpose. We can create the files
beforehand (under normal OS operation), then from the bootloader we can
read and modify them - I suppose writing to a disk block is much easier
than through the filesystem layer...

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: System unique identifier.....

1999-07-21 Thread Andrzej Bialecki
On Sun, 18 Jul 1999, Brian F. Feldman wrote:

 On Sun, 18 Jul 1999, Mike Smith wrote:
 
   Mike Smith wrote:

The loader will, at some stage in the future, grow a persistent data
store in which items like this can be saved.
   
   Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
   data storage?
  
  There is little or no chance that the loader will gain the ability to 
  write back to filesystems.  Some of them don't support it (eg. 
  iso9660), others may not (TFTP, NFS), and the code required for some of 
  them (especially UFS) would be problematically large.
 
 That's not quite true. It wouldn't be too hard to modify existant files,
 but writing new ones/truncating would take a lot of work. It's still not
 a great idea to try to use a file on the FS for storage of persistent
 data. Wouldn't it be possible to have the kernel itself read in persistent
 data (in some form such as getenv?) to be written to disk? That way, the
 boot loader could pass it easily, and not have to worry about storage.

This may sound like a heresy to you, but... Why don't use the Forth blocks
for that? They were invented for that purpose. We can create the files
beforehand (under normal OS operation), then from the bootloader we can
read and modify them - I suppose writing to a disk block is much easier
than through the filesystem layer...

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Andrzej Bialecki

On Wed, 14 Jul 1999, John Nemeth wrote:

 On Jul 15,  2:40am, "Daniel C. Sobral" wrote:
 } Garance A Drosihn wrote:
 }  At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
 }   In which case the program that consumed all memory will be killed.
 }   The program killed is +NOT+ the one demanding memory, it's the one
 }   with most of it.
 }  
 }  But that isn't always the best process to have killed off...
 } 
 } Sure it is. :-) Let's see...
 
  This statement is absurd.  Only a comptetant admin can decide
 which process can be killed.  No arbitrary decision is going to be
 correct.
 
 }  It would be nice to have a way to indicate that, a la SIGDANGER.

How about assigning something like a class to process, which gives VM
 a hint which processes should be killed first without much thinking, and
which the last (or never)? In other words, let's say class 10 means
"totally disposable, kill whenever you want", and class 1 means "never try
to kill me". Of course, most processes would get some default value, and
superuser could "renice" them to more resistant class.

This way both sides of the discussion would be satisfied :-)

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Andrzej Bialecki
On Wed, 14 Jul 1999, John Nemeth wrote:

 On Jul 15,  2:40am, Daniel C. Sobral wrote:
 } Garance A Drosihn wrote:
 }  At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
 }   In which case the program that consumed all memory will be killed.
 }   The program killed is +NOT+ the one demanding memory, it's the one
 }   with most of it.
 }  
 }  But that isn't always the best process to have killed off...
 } 
 } Sure it is. :-) Let's see...
 
  This statement is absurd.  Only a comptetant admin can decide
 which process can be killed.  No arbitrary decision is going to be
 correct.
 
 }  It would be nice to have a way to indicate that, a la SIGDANGER.

How about assigning something like a class to process, which gives VM
 a hint which processes should be killed first without much thinking, and
which the last (or never)? In other words, let's say class 10 means
totally disposable, kill whenever you want, and class 1 means never try
to kill me. Of course, most processes would get some default value, and
superuser could renice them to more resistant class.

This way both sides of the discussion would be satisfied :-)

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: question about boot code

1999-06-01 Thread Andrzej Bialecki
On Tue, 1 Jun 1999, fretre wrote:

 1.  I try to learn something about boot code with version 3.0. I
 wander whether I can begin with biosboot?(/usr/src/sys/i386/
 boot/biosboot)

The 3.0 boot code is located in /usr/src/sys/boot

 2.  The initialized data will be loaded into memory after kernel
 text during boot stage. And where is the file that the
 initialized data is defined in? and
 3.  What's the file name?

If you mean the 'initialized kernel data', then it's stored in the file
/kernel itself (or whatever file you boot from) in section '.data' of the
ELF file.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: a two-level port system?

1999-05-31 Thread Andrzej Bialecki
On Mon, 31 May 1999, Taavi Talvik wrote:

 On Mon, 31 May 1999, Rasmus Kaj wrote:
 
   RW Alternatively, is it possible to have the port tree be essentially
   RW empty (perhaps just the makefile and category directories) and then
   RW just have it fetch the makefiles and make the directories on demand, 
  for
   RW the individal ports?
  Rationale for moving stuff elsewhere
  
   In my (recently updated) copy of /usr/ports there is 4819 files in
   */*/patches and 775 files other than md5 in */*/files. Scripts is
   another 270 directories containing 522 files.
  
   Moving this files to the ftp sites would not only mean 6000 less
   files to cvsup, but also 4300 less directories (assuming files/md5
   could be moved to pkg/ or the port directory).
  
  Comments, anyone?
 
 Moving these files to ftp requires good automatic means to keep
 ftp servers updated. However as of today there are no such means
 available. 
 
 CVSup is definitely easiest way to keep well defined collection
 of files up to date.

Folks, how about _admitting_ finally that our ports collection is a
database? We wouldn't need anything else than standard system tools to
maintain a ports.db file containing all that we want as DB records.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message