Re: FreeBSD onto An Intel Saber 8-Proc Server
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?
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
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
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
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.
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?
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
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?
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)
(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
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
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?
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
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
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
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 ?
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
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
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
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()
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
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.
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?)
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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 )
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 )
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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)
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)
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
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
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
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
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.....
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.....
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.....
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))
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))
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
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?
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
