Re: Processes' FIBs
Kostik Belousov kostik...@gmail.com wrote:
The patch misses compat32 bits and breaks compat32 ps/top.
Right, thank you for pointing it out! I missed it because
I only have i386 for testing.
I've created new patch sets for releng8 and current. These
include compat32 support and an entry for the manual page.
Would someone with amd64 please test the compat32 part?
I've been using this code on i386 for a few days without
any problems.
I've attached the patch for current below. Both patch sets
are also available from this URL:
http://www.secnetix.de/olli/tmp/ki_fibnum/
Testing is easy: Apply the patch, rebuild bin/ps and kernel.
Make sure that your kernel config has options ROUTETABLES=16
so multiple FIBs are supported. Reboot. Open a shell with
setfib, e.g. setfib 3 /bin/sh (no root required), type
ps -ax -o user,pid,fib,command or something similar, and
verify that the shell process and its children are listed
with the correct FIB. When testing on amd64, use both the
native ps and an i386 binary.
Thank you very much!
Best regards
Oliver
--- sys/sys/user.h.orig 2011-11-07 22:13:19.0 +0100
+++ sys/sys/user.h 2012-01-17 11:33:59.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#defineKI_NSPARE_LONG 12
#defineKI_NSPARE_PTR 6
@@ -186,6 +186,7 @@
*/
charki_sparestrings[50];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- sys/kern/kern_proc.c.orig 2012-01-15 19:47:24.0 +0100
+++ sys/kern/kern_proc.c2012-01-17 12:52:36.0 +0100
@@ -836,6 +836,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
kp-ki_start = p-p_stats-p_start;
timevaladd(kp-ki_start, boottime);
PROC_SLOCK(p);
@@ -1121,6 +1122,7 @@
bcopy(ki-ki_comm, ki32-ki_comm, COMMLEN + 1);
bcopy(ki-ki_emul, ki32-ki_emul, KI_EMULNAMELEN + 1);
bcopy(ki-ki_loginclass, ki32-ki_loginclass, LOGINCLASSLEN + 1);
+ CP(*ki, *ki32, ki_fibnum);
CP(*ki, *ki32, ki_cr_flags);
CP(*ki, *ki32, ki_jid);
CP(*ki, *ki32, ki_numthreads);
--- sys/compat/freebsd32/freebsd32.h.orig 2011-11-11 08:17:00.0
+0100
+++ sys/compat/freebsd32/freebsd32.h2012-01-17 11:34:00.0 +0100
@@ -319,6 +319,7 @@
charki_loginclass[LOGINCLASSLEN+1];
charki_sparestrings[50];
int ki_spareints[KI_NSPARE_INT];
+ int ki_fibnum;
u_int ki_cr_flags;
int ki_jid;
int ki_numthreads;
--- bin/ps/keyword.c.orig 2011-09-29 08:31:42.0 +0200
+++ bin/ps/keyword.c2012-01-17 12:54:49.0 +0100
@@ -85,6 +85,7 @@
{etimes, ELAPSED, NULL, USER, elapseds, 0, CHAR, NULL, 0},
{euid, , uid, 0, NULL, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, 0, CHAR, NULL, 0},
{gid, GID, NULL, 0, kvar, KOFF(ki_groups), UINT, UIDFMT, 0},
{group, GROUP, NULL, LJUST, egroupname, 0, CHAR, NULL, 0},
--- bin/ps/ps.1.orig2011-11-22 22:53:06.0 +0100
+++ bin/ps/ps.1 2012-01-17 12:56:17.0 +0100
@@ -29,7 +29,7 @@
.\ @(#)ps.1 8.3 (Berkeley) 4/18/94
.\ $FreeBSD: src/bin/ps/ps.1,v 1.112 2011/11/22 21:53:06 trociny Exp $
.\
-.Dd November 22, 2011
+.Dd January 17, 2012
.Dt PS 1
.Os
.Sh NAME
@@ -506,6 +506,9 @@
minutes:seconds.
.It Cm etimes
elapsed running time, in decimal integer seconds
+.It Cm fib
+default FIB number, see
+.Xr setfib 1
.It Cm flags
the process flags, in hexadecimal (alias
.Cm f )
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Processes' FIBs
Bjoern A. Zeeb wrote:
On 11. Jan 2012, at 15:06 , Oliver Fromme wrote:
I'm currently looking at the source code of ps, but adding
a field for the FIB isn't as trivial as I thought because
ps only sees struct kinfo_proc (via sysctl kern.proc.*)
which doesn't contain the FIB. procstat does the same.
I'm currently trying to write a patch that copies p_fibnum
from struct proc to struct kinfo_proc (just like p_nice,
for example). Does that make sense? If so, does the patch
below look reasonable? (I've made it on a stable/8 system,
but it should apply to 9 and 10, too.)
I am not sure it makes too much sense in ps. It might make sense in
sockstat maybe?
Well, every process has a default FIB number (p_fibnum in
struct proc). It is a property of the process, just like
the nice value for example. So I think it makes sense for
ps to be able to display it if the user asks for it. This
is the piece of information that I need.
On the other hand, sockstat displays open sockets only.
Of course, an internet socket has a FIB number associated
with it, too, so sockstat could display it. But that
would be a completely different piece of information,
and it wouldn't solve the actual problem that I'm currently
facing.
Best regards
Oliver
--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.0 +0200
+++ ./sys/sys/user.h2012-01-11 15:35:50.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#defineKI_NSPARE_LONG 12
#defineKI_NSPARE_PTR 6
@@ -177,6 +177,7 @@
*/
charki_sparestrings[68];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.0 +0200
+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.0 +0100
@@ -775,6 +775,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
PROC_SLOCK(p);
rufetch(p, kp-ki_rusage);
kp-ki_runtime = cputick2usec(p-p_rux.rux_runtime);
--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.0 +0200
+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.0 +0100
@@ -90,6 +90,7 @@
NULL, 0},
{etime, ELAPSED, NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{ignored, , sigignore, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{inblk, INBLK, NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Processes' FIBs
Bjoern A. Zeeb wrote:
On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote:
On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote:
Is there a way to find out the default FIB number of a
process (from a shell script)? I've checked the
manpages of ps and procstat, but they don't mention
FIBs. I'm using stable/8, if that matters.
http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.html
Not sure about ps/et al, but you can do it according to that post. Nearly
2 years old now.
To be honest, I prefer not to fumble around in kernel memory
with kgdb in a shell script. Also, it requires root privilege
(setfib does not).
If you are thinking in terms of multiple forwarding information bases, yes
sysctl net.my_fibnum
Thanks. Would it make sense to document that in setfib(1)?
However, I need to find the default FIB number for arbitrary
processes, not necessarily for the calling process.
I'm currently looking at the source code of ps, but adding
a field for the FIB isn't as trivial as I thought because
ps only sees struct kinfo_proc (via sysctl kern.proc.*)
which doesn't contain the FIB. procstat does the same.
I'm currently trying to write a patch that copies p_fibnum
from struct proc to struct kinfo_proc (just like p_nice,
for example). Does that make sense? If so, does the patch
below look reasonable? (I've made it on a stable/8 system,
but it should apply to 9 and 10, too.)
Best regards
Oliver
--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.0 +0200
+++ ./sys/sys/user.h2012-01-11 15:35:50.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#defineKI_NSPARE_LONG 12
#defineKI_NSPARE_PTR 6
@@ -177,6 +177,7 @@
*/
charki_sparestrings[68];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.0 +0200
+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.0 +0100
@@ -775,6 +775,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
PROC_SLOCK(p);
rufetch(p, kp-ki_rusage);
kp-ki_runtime = cputick2usec(p-p_rux.rux_runtime);
--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.0 +0200
+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.0 +0100
@@ -90,6 +90,7 @@
NULL, 0},
{etime, ELAPSED, NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{ignored, , sigignore, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{inblk, INBLK, NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)
Pan Tsu wrote:
Oliver Fromme o...@lurza.secnetix.de writes:
[...]
To be honest, I don't think that loader takes so much time.
When you set autoboot_delay=-1 and beastie_disable=YES,
the time spent in loader is negligible. (I'm assuming that
you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait
for a keypress either. I think the default is to wait 3
seconds.)
Is BOOTWAIT still used? A quick grep in sys/boot shows nothing.
You're right, unfortunately.
boot0 still has a configurable timeout which is 10 seconds
by default. It can be configured via BOOT_BOOT0_TICKS in
make conf (default is 182 because the BIOS ticks run at
18.2 Hz).
However, the 3 seconds delay is hardcoded in boot2.c:
if (!keyhit(3*SECOND)) {
load();
I have no idea why it isn't configurable anymore. Is there
a reason for that? I'll write a patch unless anybody
objects.
Digging history, BOOTWAIT never made its way from sys/i386/boot
to sys/boot/i386 and was removed in r58284 around 11y ago.
11 years ago?!? Time to either update the documentation
or -- better yet -- bring the feature back, I would say.
Being able to shave 3 seconds off the boot time of a HTPC
(among others) is not negligible.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
I have stopped reading Stephen King novels.
Now I just read C code instead.
-- Richard A. O'Keefe
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best wrote: i just stumbled upon PR 144770, where a somebody seems to have mistaken the spindown value for minutes instead of seconds. so i really think we should have this warning in atacontrol! +1 from brucec, if i understood him correctly. another possibility would be of course changing the spindown value from seconds to minutes. imo this seems very reasonable, because measuring spindown time in seconds is too fine grained and not intuitive. just like specifying the 'shutdown -p XX' delay in microseconds would not be useful. ;) No, please don't. Changing the meaning of the value from seconds to minutes will break people's existing setups. I'm also against printing a warning for values less than 600. If I want to set the value to 300, I don't want to be slapped with a useless warning. Also note that 300 (and even much less) might be perfectly reasonable, depending on the kind of device! As a rule of thumb, the smaller a drive, the better it is optimized for many spin up/down cycles. For example, I've got a portable HDD mp3 player that contains a 1.8 disk. When playing an mp3 file, it spins up every 20 seconds or so, reads 500 KB, then spins down again. In my opinion, this is purely a documentation issue. If it is well-documented that the spindown value is given in seconds, then that should be sufficient. Supporting values like 5m or 1h would be fine, as long as a value without a letter still means seconds. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best wrote: but this will not solve the real issue: specifying 'atacontrol spindown 1s' WILL damage your hardware! You're making assumptions. I can very well imagine scenarios where 1s might make sense and will not damage the hardware, for example when there is no file system mounted from the disk in question. For several years I ran a BBS machine that ran off a memory disk. Every 24 hours it made a backup of its current state by writing a tar file to the raw device of a physical disk (there were no file systems mounted from that disk). Having a spindown time of 1s in such a context certainly wouldn't hurt. Best regards Oliver PS: Please allow me to copy a few things from my collection of quotes which fit very well here: UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot). -- Terry Lambert Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Bruce Cran wrote: I've just committed the patch to move the functionality into ada(4). Should it be reverted? It seems to me that ATA and SCSI devices are sufficiently different (from the code's point of view) that it makes sense to separate the functionality in the ada and da drivers. In other words, I think the commit is good. I'm biased, though. By the way, I also think it's better to issue a standby immediate command, not a sleep command. The former is reversible, i.e. the drive can spin up if required (for whatever reason), while the latter may require a hardware reset, according to the documentation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best wrote: On Wed Sep 15 10, Oliver Fromme wrote: Warren Block wbl...@wonkity.com wrote: [...] 8. Alexander Motin has an updated CAM version of the ATA system which will eventually replace the existing one. In -CURRENT, anyway. He was kind enough to look at my event handler. My understanding is that he is looking at implementing the head parking/standby mechanism in that new code. The patch below will work with the new CAM ATA driver (i.e. ada(4) disks). It adds a sysctl, so you can switch the spin-down off if you're going to just reboot: # sysctl kern.cam.ada.spindown_shutdown=0 i haven't tested your patch yet, but i don't think deciding whether to spin down the hdd should be decided merely from the sysctl value. It was the most simple and least intrusive way to introduce some means to switch it on and off. Of course there might be better ways to do it. You're welcome to submit your own patch. the hdd should spindown when a shutdown has been issued and not spindown, if a reboot has been issued. Right. That's why my shutdown wrapper script sets the sysctl to 0 when the -r option is present (I've got that wrapper script for ages, for different reasons). Also, there are cases where it is completely impossible to decide automatically whether the disks should be spun down or not. For example, if the admin issues a shutdown -h (halt), there's no way for the OS to know in advance whether the admin is going to switch the machine off or reboot to multi-user. So there must be a way for the user to forcibly enable/disable the spindown feature. I think a sysctl is the most appropriate way to do that, isn't it? Actually, my plan is to have a mask of two bits for the sysctl (the default value would be 3): - bit 0: enable (1) or disable (0) spindown - bit 1: automatic (1) or manual (0) setting With the default setting (i.e. bit 1 == 1), at shutdown time some facility would look at the reboot(2) howto flags and then set bit 0 to either 0 or 1. There are several ways where to handle that. For example, init(8) could be modified to pass the howto value to rc.shutdown (which could be useful for other purposes, too). Then a standard rc.d script could handle the spindown sysctl. The advantage of that solution would be maximum flexibility, because the actual logic is implemented in an rc.d script. deciding whether freebsd reboots or shuts down cannot be done from a script, since users might use the reboot or halt commands in which case (if i'm not mistaken) all shutdown scripts get skipped. Right, which is why it is a rather bad idea to use halt(8) or reboot(8), except in an emergency. Actually I think the manpages and handbook should strongly discourage it, and recommend to use shutdown(8) or init(8) instead, both of which send a signal to PID 1 by default, so rc.shutdown is executed properly. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Tijl Coosemans wrote: On Thursday 16 September 2010 10:41:07 Oliver Fromme wrote: Also, there are cases where it is completely impossible to decide automatically whether the disks should be spun down or not. For example, if the admin issues a shutdown -h (halt), there's no way for the OS to know in advance whether the admin is going to switch the machine off or reboot to multi-user. So there must be a way for the user to forcibly enable/disable the spindown feature. I think a sysctl is the most appropriate way to do that, isn't it? I would just spin down the disk in case of a halt. An unwanted spin down is harmless compared to an emergency shutdown and usually the intention is to power off rather than reboot. Is it? When I intend to power-off, I use shutdown -p, not shutdown -h. Quite often (but not always) when I halt a machine, I'm going to reboot to multi-user, not power off. In that case I certainly wouldn't want to spin the drives down and have them spun up immediately afterwards. I don't think that weartear caused by that procedure is completely insignificant (although it's certainly less of a problem than emergency unloads). For that reason I definitely want to have a way to disable the spindown function manually. Part of your patch modifies ada_shutdown. That function already gets the reboot(2) howto flags passed to it, so you could test for (howto (RB_HALT | RB_POWEROFF)) != 0 before issuing the STANDBY command. Right, good point. I didn't notice because the shutdown function in ad(4) doesn't get the howto flag, so I assumed (without checking) that ada(4) doesn't get it either. There's no need to make this more complicated with a sysctl that can override this in my opinion. I'm afraid I have to disagree (see above). Apart from that, there's nothing complicated at all about a sysctl. Also command2 should be command1 in this line: + if (cgd-ident_data.support.command2 ATA_SUPPORT_POWERMGT) Oops ... You're right. Thanks for pointing that out. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Tijl Coosemans wrote:
On Thursday 16 September 2010 16:10:22 Oliver Fromme wrote:
Tijl Coosemans wrote:
I would just spin down the disk in case of a halt. An unwanted spin
down is harmless compared to an emergency shutdown and usually the
intention is to power off rather than reboot.
Is it? When I intend to power-off, I use shutdown -p, not
shutdown -h. Quite often (but not always) when I halt a
machine, I'm going to reboot to multi-user, not power off.
Hmm, I suppose support for power off is ubiquitous nowadays. It used to
be that halt meant: bring the system in a state where we can safely cut
the power. In that case it makes sense to let halt spin down the disks.
If you intend to reboot why not explicitly reboot rather than halt?
For example, I use shutdown -h in order to swap disks that
are not hot-swappable, or other kind of hardware work that
can be done while the machine is switched on.
Of course, in that particular case the disk which is about
to be swapped out should be spun down, while the others
should not. But that's not a problem because I can use
atacontrol(8) and camcontrol(8) to spin down a specific
disk drive manually.
Also, to go from single to multi user mode you can just exit(1) the
shell.
Yes, of course, that's a different matter.
I've updated the patch for ada(4). It includes a bug fix
(command1 vs. command2) and uses the howto flags passed to
the shutdown function. Thanks again for pointing these out.
Best regards
Oliver
--- ata_da.c.orig 2010-05-23 18:16:33.0 +0200
+++ ata_da.c2010-09-16 17:21:10.0 +0200
@@ -42,6 +42,7 @@
#include sys/eventhandler.h
#include sys/malloc.h
#include sys/cons.h
+#include sys/reboot.h
#include geom/geom_disk.h
#endif /* _KERNEL */
@@ -79,7 +80,8 @@
ADA_FLAG_CAN_TRIM = 0x080,
ADA_FLAG_OPEN = 0x100,
ADA_FLAG_SCTX_INIT = 0x200,
- ADA_FLAG_CAN_CFA= 0x400
+ ADA_FLAG_CAN_CFA= 0x400,
+ ADA_FLAG_CAN_POWERMGT = 0x800
} ada_flags;
typedef enum {
@@ -180,6 +182,10 @@
#defineADA_DEFAULT_SEND_ORDERED1
#endif
+#ifndefADA_DEFAULT_SPINDOWN_SHUTDOWN
+#defineADA_DEFAULT_SPINDOWN_SHUTDOWN 1
+#endif
+
/*
* Most platforms map firmware geometry to actual, but some don't. If
* not overridden, default to nothing.
@@ -191,6 +197,7 @@
static int ada_retry_count = ADA_DEFAULT_RETRY;
static int ada_default_timeout = ADA_DEFAULT_TIMEOUT;
static int ada_send_ordered = ADA_DEFAULT_SEND_ORDERED;
+static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOWN_SHUTDOWN;
SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0,
CAM Direct Access Disk driver);
@@ -203,6 +210,9 @@
SYSCTL_INT(_kern_cam_ada, OID_AUTO, ada_send_ordered, CTLFLAG_RW,
ada_send_ordered, 0, Send Ordered Tags);
TUNABLE_INT(kern.cam.ada.ada_send_ordered, ada_send_ordered);
+SYSCTL_INT(_kern_cam_ada, OID_AUTO, spindown_shutdown, CTLFLAG_RW,
+ ada_spindown_shutdown, 0, Spin down upon shutdown);
+TUNABLE_INT(kern.cam.ada.spindown_shutdown, ada_spindown_shutdown);
/*
* ADA_ORDEREDTAG_INTERVAL determines how often, relative
@@ -665,6 +675,8 @@
softc-flags |= ADA_FLAG_CAN_48BIT;
if (cgd-ident_data.support.command2 ATA_SUPPORT_FLUSHCACHE)
softc-flags |= ADA_FLAG_CAN_FLUSHCACHE;
+ if (cgd-ident_data.support.command1 ATA_SUPPORT_POWERMGT)
+ softc-flags |= ADA_FLAG_CAN_POWERMGT;
if (cgd-ident_data.satacapabilities ATA_SUPPORT_NCQ
cgd-inq_flags SID_CmdQue)
softc-flags |= ADA_FLAG_CAN_NCQ;
@@ -1222,6 +1234,58 @@
/*getcount_only*/0);
cam_periph_unlock(periph);
}
+
+ if (ada_spindown_shutdown == 0 ||
+ (howto (RB_HALT | RB_POWEROFF)) == 0)
+ return;
+
+ DELAY(50);
+
+ TAILQ_FOREACH(periph, adadriver.units, unit_links) {
+ union ccb ccb;
+
+ /* If we paniced with lock held - not recurse here. */
+ if (cam_periph_owned(periph))
+ continue;
+ cam_periph_lock(periph);
+ softc = (struct ada_softc *)periph-softc;
+ /*
+* We only spin-down the drive if it is capable of it..
+*/
+ if ((softc-flags ADA_FLAG_CAN_POWERMGT) == 0) {
+ cam_periph_unlock(periph);
+ continue;
+ }
+
+ /* XXX Hide this behind bootverbose? */
+ xpt_print(periph-path, spin-down\n);
+
+ xpt_setup_ccb(ccb.ccb_h, periph-path, CAM_PRIORITY_NORMAL);
+
+ ccb.ccb_h.ccb_state = ADA_CCB_DUMP;
+ cam_fill_ataio(ccb.ataio,
+ 1,
+ adadone
Re: Summary: Re: Spin down HDD after disk sync or before power off
Warren Block wbl...@wonkity.com wrote:
[...]
8. Alexander Motin has an updated CAM version of the ATA system which
will eventually replace the existing one. In -CURRENT, anyway. He was
kind enough to look at my event handler. My understanding is that he is
looking at implementing the head parking/standby mechanism in that new
code.
The patch below will work with the new CAM ATA driver
(i.e. ada(4) disks). It adds a sysctl, so you can switch
the spin-down off if you're going to just reboot:
# sysctl kern.cam.ada.spindown_shutdown=0
This patch applies to stable/8, but I think it should
work with current, too (I haven't tried because I don't
have a machine running HEAD that has ada(4) disks).
Best regards
Oliver
--- ata_da.c.orig 2010-05-23 18:16:33.0 +0200
+++ ata_da.c2010-09-15 22:48:03.0 +0200
@@ -79,7 +79,8 @@
ADA_FLAG_CAN_TRIM = 0x080,
ADA_FLAG_OPEN = 0x100,
ADA_FLAG_SCTX_INIT = 0x200,
- ADA_FLAG_CAN_CFA= 0x400
+ ADA_FLAG_CAN_CFA= 0x400,
+ ADA_FLAG_CAN_POWERMGT = 0x800
} ada_flags;
typedef enum {
@@ -180,6 +181,10 @@
#defineADA_DEFAULT_SEND_ORDERED1
#endif
+#ifndefADA_DEFAULT_SPINDOWN_SHUTDOWN
+#defineADA_DEFAULT_SPINDOWN_SHUTDOWN 1
+#endif
+
/*
* Most platforms map firmware geometry to actual, but some don't. If
* not overridden, default to nothing.
@@ -191,6 +196,7 @@
static int ada_retry_count = ADA_DEFAULT_RETRY;
static int ada_default_timeout = ADA_DEFAULT_TIMEOUT;
static int ada_send_ordered = ADA_DEFAULT_SEND_ORDERED;
+static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOWN_SHUTDOWN;
SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0,
CAM Direct Access Disk driver);
@@ -203,6 +209,9 @@
SYSCTL_INT(_kern_cam_ada, OID_AUTO, ada_send_ordered, CTLFLAG_RW,
ada_send_ordered, 0, Send Ordered Tags);
TUNABLE_INT(kern.cam.ada.ada_send_ordered, ada_send_ordered);
+SYSCTL_INT(_kern_cam_ada, OID_AUTO, spindown_shutdown, CTLFLAG_RW,
+ ada_spindown_shutdown, 0, Spin down upon shutdown);
+TUNABLE_INT(kern.cam.ada.spindown_shutdown, ada_spindown_shutdown);
/*
* ADA_ORDEREDTAG_INTERVAL determines how often, relative
@@ -665,6 +674,8 @@
softc-flags |= ADA_FLAG_CAN_48BIT;
if (cgd-ident_data.support.command2 ATA_SUPPORT_FLUSHCACHE)
softc-flags |= ADA_FLAG_CAN_FLUSHCACHE;
+ if (cgd-ident_data.support.command2 ATA_SUPPORT_POWERMGT)
+ softc-flags |= ADA_FLAG_CAN_POWERMGT;
if (cgd-ident_data.satacapabilities ATA_SUPPORT_NCQ
cgd-inq_flags SID_CmdQue)
softc-flags |= ADA_FLAG_CAN_NCQ;
@@ -1222,6 +1233,57 @@
/*getcount_only*/0);
cam_periph_unlock(periph);
}
+
+ if (ada_spindown_shutdown == 0)
+ return;
+
+ DELAY(50);
+
+ TAILQ_FOREACH(periph, adadriver.units, unit_links) {
+ union ccb ccb;
+
+ /* If we paniced with lock held - not recurse here. */
+ if (cam_periph_owned(periph))
+ continue;
+ cam_periph_lock(periph);
+ softc = (struct ada_softc *)periph-softc;
+ /*
+* We only spin-down the drive if it is capable of it..
+*/
+ if ((softc-flags ADA_FLAG_CAN_POWERMGT) == 0) {
+ cam_periph_unlock(periph);
+ continue;
+ }
+
+ /* XXX Hide this behind bootverbose? */
+ xpt_print(periph-path, spin-down\n);
+
+ xpt_setup_ccb(ccb.ccb_h, periph-path, CAM_PRIORITY_NORMAL);
+
+ ccb.ccb_h.ccb_state = ADA_CCB_DUMP;
+ cam_fill_ataio(ccb.ataio,
+ 1,
+ adadone,
+ CAM_DIR_NONE,
+ 0,
+ NULL,
+ 0,
+ ada_default_timeout*1000);
+
+ ata_28bit_cmd(ccb.ataio, ATA_STANDBY_IMMEDIATE, 0, 0, 0);
+ xpt_polled_action(ccb);
+
+ if ((ccb.ccb_h.status CAM_STATUS_MASK) != CAM_REQ_CMP)
+ xpt_print(periph-path, Spin-down disk failed\n);
+
+ if ((ccb.ccb_h.status CAM_DEV_QFRZN) != 0)
+ cam_release_devq(ccb.ccb_h.path,
+/*relsim_flags*/0,
+/*reduction*/0,
+/*timeout*/0,
+/*getcount_only*/0);
+ cam_periph_unlock(periph);
+ }
}
#endif /* _KERNEL */
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister
Re: How to disallow logout
Aryeh Friedman wrote: In this case the admin and developer are the same person... namely at the clients request I am the only person allowed to work on the project and I just want to make it so I can't accidently do something like control-d or something like that and leave a plain text version of a project that has a very strict NDA laying around (liquidated damages of $250k)... the scenrio is we a are a team (each one of us is in diff city) of freelance CS people and all use the same server for all our development to make cooperation possible when needed (not in this case) have centralized backups, etc. and as mentioned on this one project the client has forced me to sign a NDA saying I can't even show the code to the other team members without the client's permission and thus am storing the repo using security/fuse-encfs, but since the version control system (devel/aegis) requires creating a development directory that is not encrypted I want to force/remind myself to checkin what ever I was working into the encrypted repo when I go home (it is a home office ;-)) at night or out to lunch If it's just a reminder to yourself, then I would simply remove the keybinding for ^D (or bind it to something else; the details depend on your login shell) and alias exit and logout to a script that checks the working directory of your version control system. If things have been checked in correctly, it logs you out, otherwise it prints a message and terminates, throwing you back to the shell prompt. Additionally, you could put the checked-out files on a geli-encrypted device and/or on a memory file system. That will make sure that there ist no unencrypted stuff left behind after a power-failure or crash. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: an alternative to powerpoint
Ivan Voras ivo...@freebsd.org wrote: On 07/13/10 06:15, Luigi Rizzo wrote: Have fun, it would be great if you could report how it works on fancy devices (iphone, ipad, androids...) For what it's worth, it doesn't work at all on Android :) (and the layout is messed up) It works pretty well on my Nexus One (Android 2.2) with the default browser. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Newbie question: kernel image a dynamically linked binary?
Hi,
Please don't crosspost to many lists. This topic is probably
suitable for hackers@ but not for the other lists.
Daniel Rodrick daniel.rodr...@gmail.com wrote:
I'm a newbie and coming from Linux background, and am trying to learn
FreeBSD now. The first thing I find a little confusing is that the
final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary:
$
$ pwd
/boot/kernel
$
$ file kernel
kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), not stripped
$
How can the kernel image use shared libraries? And which ones does it
use, if any?
Also, I cannot find out the libraries the image uses using the
traditional ldd command:
$ ldd kernel
kernel:
kernel: signal 6
$
ldd works by actually executing the binary with a special
flag for rtld(1). Compare:
$ ldd /bin/sh
/bin/sh:
libedit.so.7 = /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 = /lib/libncurses.so.8 (0x280bd000)
libc.so.7 = /lib/libc.so.7 (0x280fc000)
$ LD_TRACE_LOADED_OBJECTS=1 /bin/sh
libedit.so.7 = /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 = /lib/libncurses.so.8 (0x280bd000)
libc.so.7 = /lib/libc.so.7 (0x280fc000)
Of course you cannot execute the kernel (only the boot loader
knows how to load and boot the kernel), so ldd fails on the
kernel.
But you can use objdump(1) to list dynamic dependencies.
$ objdump -p /bin/sh | grep NEEDED
NEEDED libedit.so.7
NEEDED libncurses.so.8
NEEDED libc.so.7
$ objdump -p /boot/kernel/kernel | grep NEEDED
NEEDED hack.So
As far as I know, the kernel and all kernel modules need to
be dynamic binaries so the kernel linker works, which is
required for dynamically loading kernel modules.
So what is that hack.So object? It's just a dummy that's
required for technical reasons. You can see the details in
/sys/conf/kern.post.mk which contains this paragraph:
# This is a hack. BFD optimizes away dynamic mode if there are no
# dynamic references. We could probably do a '-Bforcedynamic' mode like
# in the a.out ld. For now, this works.
HACK_EXTRA_FLAGS?= -shared
hack.So: Makefile
: hack.c
${CC} ${HACK_EXTRA_FLAGS} -nostdlib hack.c -o hack.So
rm -f hack.c
Can some please throw some light?
I hope I did. :-)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure.
-- Eric Allman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Compiling kernel with gcc43 [SOLVED]
Mario Lobo l...@bsd.com.br wrote: [...] It's compiling right now. I'll post my findings and impressions on results and performance right after the next reboot. So, how is it going? Any benchmarks yet? I'm curious if the new gcc version will really make a significant difference. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov wrote: * Oliver Fromme (o...@lurza.secnetix.de) wrote: This is an excerpt from Solaris' mount_nfs(1M) manpage: File systems that are mounted read-write or that con- tain executable files should always be mounted with the hard option. Applications using soft mounted file systems may incur unexpected I/O errors, file corrup- tion, and unexpected program core dumps. The soft option is not recommended. FreeBSD's manual page doesn't contain such a warning, but maybe it should. (It contains a warning not to use soft with NFSv4, though, for different reasons.) Interesting, I'll try disabling it. However now I really wonder why is such dangerous option available (given it's the cause) at all, especially without a notice. Silent data corruption is possibly the worst thing to happen ever. I'm sorry for the confusion ... I do not think that it's the cause for your data corruption, in this particular case. I just mentioned the potential problems with soft mounts because it could cause additional problems for you. (And it's important to know anyhow.) However, without soft option NFS would be a strange thing to use - network problems is kinda inevitable thing, and having all processes locked in a unkillable state (with hard mounts) when it dies is not fun. Or am I wrong? Well, this is what happens if the network hangs: 1. With hard mounts (the default), processes that access NFS shares are locked for as long as the network is down. 2. With soft mounts, binaries can coredump, and many programs won't notice that write access just failed which leads to file corruption. Personally I definitely prefer the first. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov wrote: Oh, then I really misunderstood. If the curruption implied is like when you copy a file via NFS and the net goes down, and in case of soft mount you have half of a file (read: corruption), while with hard mount the copy process will finish when the net is back up, that's definitely OK and expected. Of course it depends what kinds of programs you run. If you run a database, it can become corrupted to the point that you can't start it anymore, so you have to restore it from the latest backup. Been there, done that. Another example, this happened to a friend of mine: After a network outage his Opera browser didn't work anymore. He had to remove his ~/.opera directory to get it working again (and he lost all his settings). His home directory was soft-mounted, but he removed the soft option after that incident. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysctl with regex?
Andrew Brampton wrote: Today I was writing a script to read all the dev.cpu.?.temperature sysctl OIDs. I was parsing them using a simple grep, but it occurred to me it might be better if sysctl supported some form of regexp. For example instead of typing: sysctl -a | grep dev.cpu.*.temperature I could write: sysctl dev.cpu.*.temperature which would display all the OIDs that match dev.cpu.*.temperature. This is better than grep because when I issue a sysctl -a the program retrieves many variables that I am not interested in (which later get filtered by grep). I'm not sure such a feature is really necessary. What's wrong with this approach? $ sysctl dev.cpu | grep temperature When you need that in a script, there's an even more elegant way to do it: NCPU=`sysctl -n hw.ncpu` OIDS=`jot -w dev.cpu.%d.temperature $NCPU 0` sysctl $OIDS There's no need to use sysctl -a. After all, the UNIX way of doing things is to combine the existing tools instead of duplicate features in many tools. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: System() returning ECHILD error on FreeBSD 7.2
Naveen Gujje gujjenav...@gmail.com wrote:
signal(SIGCHLD, SigChildHandler);
void
SigChildHandler(int sig)
{
pid_t pid;
/* get status of all dead procs */
do {
int procstat;
pid = waitpid(-1, procstat, WNOHANG);
if (pid 0) {
if (errno == EINTR)
continue; /* ignore it */
else {
if (errno != ECHILD)
perror(getting waitpid);
pid = 0;/* break out */
}
}
else if (pid != 0)
syslog(LOG_INFO, child process %d completed, (int) pid);
} while (pid);
signal(SIGCHLD, SigChildHandler);
}
There are several problems with your signal handler.
First, the perror() and syslog() functions are not re-entrant,
so they should not be used inside signal handlers. This can
lead to undefined behaviour. Please refer to the sigaction(2)
manual page for a list of functions that are considered safe
to be used inside signal handlers.
Second, you are using functions that may change the value of
the global errno variable. Therefore you must save its value
at the beginning of the signal handler, and restore it at the
end.
Third (not a problem in this particular case, AFAICT, but
still good to know): Unlike SysV systems, BSD systems do
_not_ automatically reset the signal action when the handler
is called. Therefore you do not have to call signal() again
in the handler (but it shouldn't hurt either). Because of
the semantic difference of the signal() function on different
systems, it is preferable to use sigaction(2) instead in
portable code.
And, in some other part of the code, we call system() to add an ethernet
interface. This system() call is returning -1 with errno set to ECHILD,
though the passed command is executed successfully. I have noticed that,
the problem is observed only after we register SigChildHandler. If I have a
simple statement like system(ls) before and after the call to
signal(SIGCHLD, SigChildHandler), the call before setting signal handler
succeeds without errors and the call after setting signal handler returns -1
with errno set to ECHILD.
Here, I believe that within the system() call, the child exited before the
parent got a chance to call _wait4 and thus resulted in ECHILD error.
I don't think that can happen.
But, for the child to exit without notifying the parent, SIGCHLD has to be
set to SIG_IGN in the parent and this is not the case, because we are already
setting it to SigChildHandler. If I set SIGCHLD to SIG_DFL before calling
system() then i don't see this problem.
I would like to know how setting SIGCHLD to SIG_DFL or SigChildHanlder is
making the difference.
The system() function temporarily blocks SIGCHLD (i.e. it
adds the signal to the process' signal mask). However,
blocking is different from ignoring: The signal is held
as long as it is blocked, and as soon as it is removed
from the mask, it is delivered, i.e. your signal handler
is called right before the system() function returns.
And since you don't save the errno value, your signal
handler overwrites the value returned from the system()
function. So you get ECHILD.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
What is this talk of 'release'? We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov amd...@amdmi3.ru wrote: I think I've reported that before, the I thought it's been fixed, however I still get data corruptions when writing on NFS volumes. Now I wonder - is nobody really using NFS, or do I have that much of uncommon setup, or this is some kind of local problem? NFS works fine for me. I'm using -stable, not -release, though. Client: 8.0-RELEASE i386 Server: 8.0-RELEASE amd64 mount options: nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd I recommend not using the soft option. This is an excerpt from Solaris' mount_nfs(1M) manpage: File systems that are mounted read-write or that con- tain executable files should always be mounted with the hard option. Applications using soft mounted file systems may incur unexpected I/O errors, file corrup- tion, and unexpected program core dumps. The soft option is not recommended. FreeBSD's manual page doesn't contain such a warning, but maybe it should. (It contains a warning not to use soft with NFSv4, though, for different reasons.) Also note that the nolockd option means that processes on different clients won't see each other's locks. That means that you will get corruption if they rely on locking. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: our little daemon abused as symbol of the evil
Dag-Erling Smørgrav wrote: Bernd Walter writes: There is no copyright in Germany. Yes, there is. Germany is signatory to the Berne convention. That's correct, of course. I think what Bernd actually meant is that Copyright is not the same as the German Urheberrecht. They have a lot in common, but there are also a few differences. The author can't even sell it, all he can do is sell the right to use it. I'm pretty sure there are provisions for work for hire. That's true. When you work as an employee, the Urheber- recht is assigned to the employer (the work is created on behalf of the company). When doing contract work, it depends on the type and wording of the contract. Commonly the author retains the Urheberrecht but grants exclusive all-encompassing rights to the client. But Bernd is right that you cannot sell your Urheberrecht in Germany. You can't even give it away for free. That's why public domain software doesn't exist in Germany. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: our little daemon abused as symbol of the evil
Ruben de Groot mai...@bzerk.org wrote: On Fri, Feb 05, 2010 at 08:05:10PM +0100, Julian H. Stacey typed: PS an undefended trade mark loses its right to further defence or some such, (I'm not a lawyer). It's not a trade mark, is it? It's copyrighted. That's a whole other set of laws. On the bottom of this page ... http://www.freebsd.org/art.html .. the text states that Marshall Kirk McKusick is the trademark holder for the BSD Daemon image. However, on another page (I don't have the URL right now) it says that Kirk owns the copyright of the daemon. I guess one of the web pages needs to be corrected, but I don't know which one. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Warren Block wrote: Oliver Fromme wrote: Alexander Best wrote: imo this patch takes good care of the problem. would be nice to have it in HEAD. No -- *Please* make sure that the disks are only spun down upon an actual power-off command (i.e. when reboot() is called with the RB_POWEROFF flag). In all other cases the disks should keep running. It's not good to have the disks spin down and then immediately spin up again on every reboot. Could you elaborate a little on why that's bad? It seems like it would be similar to a standby/resume action. While notebook disks are usually optimized to handle a high number of start/stop cycles, this isn't true for normal desktop or server disks, especially ones that are meant for continuous operation (24/7). This varies greatly between vendors and models, though. The point is that I defintitely wouldn't want to waste a start/stop cycle when it's not necessary. Also, it would be nice to have a way to disable the STANDBY command alltogether for people who don't want it. This could easily be implemented with a sysctl. Are there any other device drivers that differentiate the reboot and poweroff actions that could be used as inspiration or simply shamelessly copied in modifying ata-disk? I'm sorry, I don't know. If the ad_shutdown() function doesn't have easy access to the boot howto variable, maybe the information could be stored in a kenv variable? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Alexander Best wrote: imo this patch takes good care of the problem. would be nice to have it in HEAD. No -- *Please* make sure that the disks are only spun down upon an actual power-off command (i.e. when reboot() is called with the RB_POWEROFF flag). In all other cases the disks should keep running. It's not good to have the disks spin down and then immediately spin up again on every reboot. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Does getc(3) use the read(2) syscall?
Stefan Midjich sweh...@gmail.com wrote: I'm having trouble looking this function up in the source tree, the trail seems to end at __sys_read which has a bunch of prototypes but i can't find the actual function code. So my question is primarily, does getc use the read system call eventually? But i would also love it if someone could show me where __sys_read is defined. getc() works like this: 1. The getc() macro can be found in /usr/include/stdio.h, the getc() function (for threaded programs) can be found in src/lib/libc/stdio/getc.c. 2. getc() (both the macro and the function) use the __sgetc() macro defined in stdio.h. 3. The __sgetc() macro either returns a character directly from the buffer, or it calls the __srget() function to refill the buffer. All of the stdio functions can be found in src/lib/libc/stdio/*. 4. The __srget() function calls the __srefill() function, then returns a character from the newly refilled buffer. 5. The __srefill() function uses the _sread() function to perform the actual read operation. 6. The _sread() function uses the _read() method from the FILE struct. 7. The actual value of the _read() method depends on how the file was opened. If it's a standard file opened with fopen() or similar, then the _read() method is initialized to the __sread() function. 8. Finally, the __sread() function calls _read(). 9. _read() is simply an alias for the read() syscall; the definition is in src/lib/libc/include/namespace.h. So to answer you question: Yes, getc() uses the read() syscall. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Alexander Best alexbes...@wwu.de wrote: because of kern/140752 i looked through a discussion back in 2009 (http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027879.html) concerning freebsd's hdd spin down procedure. right now ATA_FLUSHCACHE is being used although the hitachi hdd specs referenced in the pr say that this will not cause proper load/unload and thus an emergency unload will occur which reduces the life expectancy of hdds dramatically (20.000 shutdowns vs. 600.000 shutdowns). unfortunately the discussion back then didn't come up with any sort of decision/patch. attached you'll find a very simple patch which issues ATA_STANDBY_IMMEDIATE instead of ATA_FLUSHCACHE during hdd spin down. A few comments ... First, you should not *replace* ATA_FLUSHCACHE. Rather, you should issue *both* commands, first ATA_FLUSHCACHE and then ATA_STANDBY_IMMEDIATE (maybe with a short delay between, just to be on the safe side). Second, you should make sure that ATA_STANDBY_IMMEDIATE is only used when a poweroff is requested, but not in other cases. Of course, ATA_FLUSHCACHE should *always* be sent. Finally, it would be nice if it is put under a sysctl or similar, so the feature can be switched on and off. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Above all, they contribute to the genetic diversity in the operating system pool. Which is a good thing. -- Ruben van Staveren, on the question which BSD OS is the best one. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Alexander Best alexbes...@wwu.de wrote: i believe the sound you hear is due to the emergency unload sequence. i'm not 100% sure, but i think after applying the patch the sound is gone. i recently replaced my old IDE hdd (which made a very loud click! during shutdown) with a new SATA hdd. the new one is very quiet and so it's not that easy to recognise any changes in the spin down procedure. There are hard disk drives that (still) have a reasonable auto-park feature and don't require a special command. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: limits for run away Firefox ?
Rick C. Petty wrote: On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: On 01/18/10 11:29, Oliver Fromme wrote: Doug Barton wrote: On 01/17/10 17:07, Julian H. Stacey wrote: Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core Sorry I don't have a solution to your actual problem, but a better way to deal with this is to do: ln -s /dev/null ~/firefox-bin.core I think not generating a core dump at all is better than writing 4 GB to /dev/null. A) The method I proposed is useful for other things too, and as you pointed out it can sometimes be difficult to track down all the ways a given thing is started. What about just adding the limit command to the /usr/local/bin/firefox script? That would guarantee any instantiation of firefox wouldn't dump core. Many users probably don't want any core dumps at all, so disabling them completely would be the best and easiest solution for them. This can be done globally (either with the sysctl or via /etc/login.conf) or per-user via ~/.login_conf. Then you don't have to track down the ways a given thing is started. B) If we're going to be snarky, it would be far better if it didn't need to dump core in the first place. :) I don't think that Oliver was at all snarky. The word snarky isn't even in my dictionary, so I can only guess what it means. Anyway, my suggestion was meant to be completely serious, without any irony or other undertone. I'm not a native English speaker, so maybe my words expressed a meaning that wasn't intended. In that case please allow me to apologize. But I agree that it would be nice to prevent ffox from segfaulting; Definitely. I agree, too. However, that's a lot more difficult than preventing core dumps being written. unfortunately this is one of those apps which segfaults a lot (for me at least). =) One of the reasons why I prefer Opera. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months. -- Cliff Sarginson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: User error or awk bug?
Garrett Cooper wrote:
David Wolfskill wrote:
How about:
d254(6.4-S)[10] echo | awk '{ gsub (/\/\/+/, /); print }'
/
d254(6.4-S)[11]
then?
This works very well. Is the expression quantifier operator [ `{'
] not supported in awk like perl, python, tcl, etc?
awk is quite old. It implements the historical behaviour
of egrep which did not support braces (this is mentioned
in the manual page). Braces are a relatively new feature
in egrep. They were probably never added to awk because
of compatibility issues with existing scripts.
By the way, you can use strings as regular expressions
so you don't have to enclose them in slashes. This saves
you from the ugly escaping with backslashes:
echo | awk '{gsub (/+, /); print}'
will do what you want. On the other hand, the typical
tool for simple search+replace tasks is sed:
echo | sed 's=//*=/=g'
By the way, when egrep parses brace expressions, it simply
translates them to standard expressions. So, when it sees
/{2,} it converts it to //+ before creating the DFA.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired.
-- Chris Torek
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: limits for run away Firefox ?
Doug Barton wrote: On 01/17/10 17:07, Julian H. Stacey wrote: Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core Sorry I don't have a solution to your actual problem, but a better way to deal with this is to do: ln -s /dev/null ~/firefox-bin.core I think not generating a core dump at all is better than writing 4 GB to /dev/null. Thus: alias firefox='/usr/bin/limits -c 0 /usr/local/bin/firefox3' solves the problem of not generating a core dump. Of course, if firefox is started by other means (e.g. through a desktop icon or a WM menu), the limits -c 0 command should be added there instead. By the way, if you don't want any coredumps at all, you can disable them globally with sysctl kern.coredump=0. Another part of the problem is that the firefox process grows that big at all. I suggest you watch the size of the process during normal operation (SIZE in top(1) or VSS in ps(1)), and then make an apropriate virtualmem size limit for the firefox process. This is the -v option to the limits(1) tool. HTH. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CPU user/kernel time given the PID
Jay Loden wrote: I'm working on FreeBSD support for a Python library called psutil for reading process information in a cross-platform fashion. Each platform-specific module is written in C, so the majority of the FreeBSD code is a C interface to various process information. I've been having some trouble working out how to get CPU user/kernel time for a given PID. I took a look at the source to top and ps but neither really helped since they don't seem to cover the info I was looking for (or I missed it). I'm not sure if there's a better way to go about this but I've been looking at sysctl and the kinfo_proc struct - is there somewhere more appropriate to retrieve this information? If the kinfo_proc struct is the way to go, then do I want to use ki_runtime, ki_swtime or something else, and does that mean there's no distinction between user/kern time for a process? If anyone has code samples or recommended docs to get me pointed in the right direction that would be great. ps(1) and top(1) both use ki_pctcpu, see the getpcpu() function in src/bin/ps/print.c and format_next_process() in src/usr.bin/top/machine.c As far as I know, there is no distinction between user- mode and kernel-mode CPU time per process. It should also be noted that the kernel's time cannot always be attributed to a certain userland process. I would even guess is that the majority of the CPU time spent in the kernel is not on behalf of a specific userland process. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to tear down a geom mirror?
Peter Steele wrote: Yes. The clear commands usually just zero-out the last sector of the underlying provider (doesn't matter if it's a drive, slice or something altogether different) so you don't have to do it manually. So, as a generic solution then I could just iterate through all slices of all drives and run gmirror clear on each, and run dd to clear the first sectors. What btw is in these first sectors? I use this command because I saw it being done in one of the gmirror tutorials. I understand what the gmirror clear command does, but what is the dd command clearing? It clears the MBR (slice table) and GPT or disklabel (partition table), if any. Depending on how many sectors you clear, it will also destroy the beginning the file system, e.g. the first UFS superblock. By the way, if you cannot use gmirror clear for any reason, you can also easily clear the last sector on any devices using the information from diskinfo. For example: DEV=/dev/ad0s1a set -- $(diskinfo $DEV) BLOCKSIZE=$2 MEDIASIZE=$4 LASTSEC=$(( $MEDIASIZE - 1 )) dd if=/dev/zero of=$DEV bs=$BLOCKSIZE seek=$(( $MEDIASIZE - 1 )) count=1 That's pretty much what gmirror clear /dev/ad0s1a does. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Octavian Covalschi wrote: I'm looking a way to spin down HDD just right before power off. Why? Because currently when I call shutdown -p now, HDD is powered off at it's full speed (7200.4) and as a result I hear a noise of stopping/spinning down of HDD, and _this_ concerns me as I'm afraid it can damage HDD. You don't have to spin down a disk before powering it off. The noise you hear is probably caused by the autopark feature of the drive. It is harmless. I've tried to use rc.shutdown, but the sync of disks wakes HDD again... Of course, upon halt or reboot the kernel will sync all file systems that have been mounted read+write. While searching for a solution, I noticed that reboot command/app _does_ spin down hdd right before it resets system power, I can hear how HDD is powered on after that... No, the reboot command doesn't do that. It's probably your BIOS that resets the devices. 2nd thing is I cannot find halt.c file, i wanted to take a look how it does it... although I'm up to date it's not not in /usr/src/sbin halt(8) is a hardlink to reboot(8). Look at src/sbin/reboot. By the way, the syncing does not happen in halt(8). At the time the kernel syncs the disks, no processes are running anymore, not even init(8). You can't do anything from userland at this point. If you want to insert a spin-down for your disks, you will have to modify the kernel. You have to install an event handler for shutdown_post_sync. See the boot() function in src/sys/kern/kern_shutdown.c for details about the kernel's shutdown sequence. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
Joerg Sonnenberger wrote: Oliver Fromme wrote: Octavian Covalschi wrote: I'm looking a way to spin down HDD just right before power off. Why? Because currently when I call shutdown -p now, HDD is powered off at it's full speed (7200.4) and as a result I hear a noise of stopping/spinning down of HDD, and _this_ concerns me as I'm afraid it can damage HDD. You don't have to spin down a disk before powering it off. The noise you hear is probably caused by the autopark feature of the drive. It is harmless. This is not true. Many hard disks don't like having to do an emergency shutdown as it affects the disk life time negatively. That's what happens if you poweroff the machine when the disks are still spinning. Can you point to any authoritative information (URL) about that claim, such as vendor specs, white paper or similar? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Alex Dupre wrote: Oliver Fromme ha scritto: The problem is related to the fact that a 64bit kernel cannot use VESA BIOS functions. You should be able to use standard VGA modes though, which don't require VESA support. Actually I cannot see any splash screen on amd64, at least on the machines I tried (most with ATI ES1000 cards), with a 320x200x8 bitmap. No problems with i386 (on the same machines). Yeah, my fingers were faster than my brain. The current syscons code cannot switch modes (no matter if VESA or standard VGA) if there is no BIOS support. It probably makes sense to let the boot loader set up graphics mode (including VESA support), so it is already active when the kernel comes up. Then the kernel will only have to deal with the frame buffer, not with the BIOS. That will work on both i386 and amd64 platforms. The only drawback is that the mode cannot be changed by the kernel once it is running, i.e. you have to stay in that mode till reboot. That solution requires support by the loader and by syscons. It is my plan to look into that, as soon as the basic graphics support in the loader is finished. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd [...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed. -- Bruce Eckel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Matt Dawson wrote: On Saturday 07 February 2009 18:59:43 Oliver Fromme wrote: In fact I have prepared a theme with beastie; here's a screen shot (preliminary): http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png Perfect. Clean, logical, concise, the three words I associate above all with FreeBSD. I would change all machines' loaders to this in a heartbeat, although others may have different ideas, which is where the space hopper comes in, I suppose. Nothing against the horned ball and your variant of the new graphics looks very neat and clean, but I'm used to having Beastie around. For some reason, this strikes the correct balance for me between nice graphics and too much bling. My personal tastes only, naturally. crawl That screenshot looks very professional. Well done, Oliver. Any chance of rolling another tarball with that theme for we traditionalists? Please? /crawl Good news: I don't have to roll another tarball for that, because this is quite easy to configure. Please download the existing tarball and follow the instructions that I posted. Please verify that it works. Then download the background image that contains beastie: http://www.secnetix.de/olli/FreeBSD/vloader/background/beastie.pcx Create a directory /boot/themes/beastie and save the image as beastie.pcx in that directory. Then create a text file themes.conf in the same directory, containing these lines: theme_background=/boot/themes/beastie/beastie.pcx theme_font=/boot/themes/default/stdfont theme_fgcolor=0 0 0 # black theme_bgcolor=255 255 255 # white theme_litcolor=255 64 32 # bright red theme_dimcolor=64 64 128 # dark bluish grey theme_options_xy=17 170 theme_actions_xy=17 281 Finally, change the beastie_theme line in /boot/loader.conf like this: beastie_theme=/boot/themes/beastie/theme.conf Done. Of course, you can also use your own image if you want to create one. Just make sure it's 640 x 480 pixels at 4 bit depth (16 colors maximum). I recommend to use ppmtopcx (from ports/graphics/netpbm), because I have used this extensively for testing with my PCX decoder. Also note that there should be appropriate palette entries for the text (e.g. black and white). The code will try to use the closest possible palette entry if there is no exact match for the given RGB values. There's ONE IMPORTANT THING I have to say: I cannot take credit for any of the artwork. I am not an artist. All of the graphics images where taken from the FreeBSD website. I only scaled and arranged it a little bit, adapted the palette etc. The only thing I created myself is the proportional font; the source code is here: http://www.secnetix.de/olli/FreeBSD/vloader/stdfont.txt Modifying the font or creating a completely new font is also very easy. There's a tool that compiles the text source code (like the one above) to binary format. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Software gets slower faster than hardware gets faster. -- Niklaus Wirth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS and Graphics support for /boot/loader
Paul Wootton wrote: Hi Oliver, This doesn?t work for me. I am booting off a ZFS mirror with GPT partitions (built from current on an amd64). I'm sorry, I've compiled this loader binary with the default options, which does not include ZFS support. Is there any change of a version of gloader but with ZFS support? I'll put it on my to-do list. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Software gets slower faster than hardware gets faster. -- Niklaus Wirth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Mike Meyer wrote: I'm curious - is there a reason that the numbers from the old screen have turned into function keys on this one? No. That screen shot is an old one. In the current code, the number keys are used as usual, no function keys. In fact, it is not possible to use function keys from the FORTH code without resorting to dirty hacks. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Share your knowledge. It is a way to achieve immortality. -- The Dalai Lama ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Danny Braniss wrote: just tried it via pxe: panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79 what changes are needed in pxeboot? The panic message means that the heap memory was corruped. It could be caused by a buffer overflow or similar. I'll try to look into it. When does that message appear? Could you provide a screen shot? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Alex Dupre wrote: Oliver Fromme ha scritto: Some of you might remember that I'm working on graphics support for our /boot/loader. Just a side question: are you going to improve also the splash(4) support? Graphical loader is great, but unfortunately on amd64 the boot splash screen is unusable. The problem is related to the fact that a 64bit kernel cannot use VESA BIOS functions. You should be able to use standard VGA modes though, which don't require VESA support. Anyway, there have been several ideas floating around to fix or work-around the VESA problem for amd64. One of them involves letting the loader prepare graphics mode (doing all the VESA stuff) and hand all the necessary information to the kernel, so the kernel only has to perform framebuffer access, but no VESA BIOS calls. It is my plan to try to look into that, but I would like to continue with the current work on the boot loader first. As soon as the graphics support in the loader is stable and finished, I can start thinking about how to interface that graphics support with the kernel's syscons driver (which is a very sensitive piece of code). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd File names are infinite in length, where infinity is set to 255 characters. -- Peter Collinson, The Unix File System ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Renato Botelho wrote: It worked here, on a 8.0-current i386 r188003, the only small thing is it show a red border when show the menu. Do you mean a red line at the top right corner? That problem has already been reported and fixed in my local source tree. There is a dmidecode output attached, just to give you some information about the bios. Thanks! Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot). -- Terry Lambert, FreeBSD-hackers mailing list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Renato Botelho wrote: Oliver Fromme wrote: Renato Botelho wrote: It worked here, on a 8.0-current i386 r188003, the only small thing is it show a red border when show the menu. Do you mean a red line at the top right corner? That problem has already been reported and fixed in my local source tree. Not exactly, it's a big red border on 4 sides of screen, something like there is a red background bigger than image and image is in front of it. I see. Is that an old CRT monitor (not a TFT display)? I think I have an idea what might be causing it. On CRT monitors, the border beyond the pixel area is set to the color of the first palette entry by default. The background PCX image happens to have red as the first palette entry. So you see a red border. In my tests I didn't notice the problem because I only tested with TFT displays and qemu. These don't have a visible border. The fix should be to set the border color to the same value as the background color (in this case that would be black). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Christian Gusenbauer wrote: Oliver Fromme wrote: Danny Braniss wrote: just tried it via pxe: panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79 what changes are needed in pxeboot? The panic message means that the heap memory was corruped. It could be caused by a buffer overflow or similar. I'll try to look into it. I got this some years ago when I played with FreeBSD 6.1. It has something to do with reading/parsing the loader.conf file. Inserting some dummy lines (comments etc.) into loader.conf solves it (at least that's a workaround). As I've never seen it again since 6.1 I thought it has already been fixed :-(. I think that's unrelated. That guard panic just means that the program has written beyond the memory that was allocated. Unfortunately it is difficult to find the piece of code responsible for that behaviour (especially when I can't reproduce the problem myself because I don't have a PXE- capable machine). It could be almost anywhere. In fact, the bug doesn't even have to be in the C code: FORTH supports (and even encourages) pointer arithmetic, too. This is real fun ... Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
pluknet pluk...@gmail.com wrote: Scott Long wrote: I think that this is really neat, you've done an impressive job with it good job. However, I do take issue with your criticism of the ASCII logo; I actually spent a decent amount of time designing the block text logo =-) I wish that there hadn't been moronic politics over the beastie logo, as that does look a lot better, even if it is text. And text is still required for serial consoles. Hey, then what's about that? ;) [...] I have to admit that I like Scott's text logo *much* better. Trying to render the horned ball logo with ASCII letters looks butt-ugly, IMHO. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
CFT: Graphics support for /boot/loader
Hello fellow hackers, Some of you might remember that I'm working on graphics support for our /boot/loader. Unfortunately, progress has been rather slow because of non-FreeBSD-related activity. Anyway, I have now prepared a tarball containing a loader binary for public testing. If you are eager to give it a try, please feel free to do so. It should work with any FreeBSD version on i386 and amd64 platforms. I have posted detailed instructions on the FreeBSD wiki: http://wiki.freebsd.org/OliverFromme/BootLoaderTest Any kind of feedback is welcome. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Scott Long wrote: Oliver Fromme wrote: [...] http://wiki.freebsd.org/OliverFromme/BootLoaderTest I think that this is really neat, you've done an impressive job with it good job. However, I do take issue with your criticism of the ASCII logo; I actually spent a decent amount of time designing the block text logo =-) I'm sorry, it wasn't my intention to disrespect your work. What I was trying to say is that ASCII graphics look old- fashioned in general. I wasn't actually picking on your rendition of the text logo in particular. Yeah, I noticed your smiley, but I agree that my wording on the wiki page was misleading, so I changed it. I wish that there hadn't been moronic politics over the beastie logo, as that does look a lot better, even if it is text. And text is still required for serial consoles. Absolutely. Text is also required for machines that aren't supported by the graphics code, or machines that don't have any graphics hardware at all. Don't worry, I'm not going to rip your ASCII logo out. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Julian Elischer wrote: BTW most of these things seem to have ESC drop out of graphics mode.. do you have something like that? (or maybe ESC should go to loader prompt...?) Good question. The screen layout isn't final, of course, and I'm open to suggestions. (Also, there will be a short descriptive text for the countdown and how to pause it.) I think it might make sense to provide an additional action using the Esc key that leaves graphics mode and displays the old text menu instead. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months. -- Cliff Sarginson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Doug Barton wrote: Oliver Fromme wrote: However, I think cmp wouldn't work here, because cmp only detects whether there is a difference between two files. In this case we need to know if one file is a subset of the other: For every hash there must be a .gz file, but it doesn't hurt if there are more files. So the list of hashes can be a subset of the list of .gz files, they don't have to be equal. Hrrmmm, that doesn't sound like a good thing to me. I would think that the hash list is pretty useless if it doesn't cover all the files. Right, that's why there should be a file for every entry in the hash list -- but not necessarily the other way around. I.e. I think freebsd-update should not abort if there are superfluous files. While I were at it, I skimmed through the cmp source and found a bug (or inefficiency): When the -s option is specified (i.e. silent, exit code only), it would be sufficient to terminate when the first difference is encountered. But it always compares the whole files. I'll try to make a patch to improve this. That would definitely be appreciated, I use cmp -s in several places in portmaster where that speed-up would make a non-trivial difference. If there is anything I can do to help please let me know. I was wrong, the -s option behaves correctly. Sorry for the confusion. I ended up in the wrong code path in the source (I was confused by the fact that the diffmsg() function never returns). Indeed, cmp(1) stops comparing the files as son as it finds the first differing byte, unless you use the -l or -x option. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Yoshihiro Ota wrote:
Oliver Fromme wrote:
It would be much better to generate two lists:
- The list of hashes, as already done (filelist)
- A list of gzipped files present, stripped to the hash:
(cd files; echo *.gz) |
tr ' ' '\n' |
sed 's/\.gz$//' filespresent
Note we use echo instead of ls, in order to avoid the
kern.argmax limit. 64000 files would certainly exceed that
limit. Also note that the output is already sorted because
the shell sorts wildcard expansions.
Now that we have those two files, we can use comm(1) to
find out whether there are any hashes in filelist that are
not in filespresent:
if [ -n $(comm -23 filelist filespresent) ]; then
echo -n Update files missing --
...
fi
That solution scales much better because no shell loop is
required at all.
This will probably be the fastest.
Are you sure? I'm not.
Only a benchmark can answer that. See below.
awk -F | '
$2 ~ /^f/{required[$7]=$7; count++}
END{FS=[/.];
while(find files -name *.gz | getline0)
if($2 in required)
if(--count=0)
exit(0);
exit(count)}' $@
I think this awk solution is more difficult to read and
understand, which means that it is also more prone to
introduce errors. In fact, there are several problems
already:
First, you didn't quote the *.gz wildcard, so it will
fail if there happens to be a file *.gz in the current
directory.
Second, the script makes assumptions about the format of
the hash strings, e.g. that they don't contain dots.
(Currently they only contain hex digits, AFAICT, but what
if the format changes in the future.)
Third, exit(count) is a bad idea, because exit codes are
truncated to 8 bits. If 256 files happen to be missing,
the script will seem to exit successfully.
All these flaws could be fixed, of course, but it will
introduce more complexity. The shell code using sort(1)
and comm(1) doesn't have those flaws and appears more
robust.
It verifies entries using hashtable instead of sort.
Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory.
I am not well aware how good awk's associate array is, though.
It is pretty simple. It's a hash list that starts with
50 buckets. The number of buckets is doubled (and all
entries re-hashed!) when the average number of elements
per bucket exceeds 2. The hash function is very simple,
it's just hash = hash * 31 + c for every character c
in the string, the result is modulo the current number
of buckets. Note that freebsd-update uses SHA256 hashes
which are fairly long (64 characters).
BTW, you can easily make benchmarks. The following command
will create 64000 files of the format %64x.gz. Be sure
to have enough free inodes on your file system (df -i).
jot -rw %08x 64000 0 20 | sed 's/.*/.gz/' | xargs touch
This took 2 minutes on my notebook (3 years old). I also
noticed that the first 47000 inodes were created very
quickly (about 5 seconds), but then the speed dropped down
suddenly to about 150 inodes per second for the rest of
the two minutes. CPU was 100% system according to top.
Removing the files is equally slow.
So there seems to be a limit of about 47000 inodes per
directory -- any more than that and it gets horribly
inefficient. Therefore it would probably be a good idea
to change freebsd-update to create subdirectories and
distribute the files among them. For example, make 16
subdirectories [0-9a-f] and put the files into them
according to the first digit of the hash. This will
probably boost performance noticeably.
Sorting those 64000 files is really *not* an issue. The
difference between ls and ls -f is only 0.2 seconds on
my notebook. When using ls -f | sort, sort(1) uses only
0.12 seconds of CPU time. This is negligible.
Next I made a simple test with awk within that directory:
awk 'BEGIN{while(find . -name \\*.gz | getline0)required[$1]=$1}'
That script (which does only half of the required work)
takes 4 seconds, reproducible. So I didn't bother to
write and test the full awk solution.
Bottom line: The awk solution is less robust, less readable,
and much slower.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
The most important decision in [programming] language design
concerns what is to be left out. -- Niklaus Wirth
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Doug Barton wrote:
Oliver Fromme wrote:
Yoshihiro Ota wrote:
Oliver Fromme wrote:
It would be much better to generate two lists:
- The list of hashes, as already done (filelist)
- A list of gzipped files present, stripped to the hash:
(cd files; echo *.gz) |
tr ' ' '\n' |
sed 's/\.gz$//' filespresent
Note we use echo instead of ls, in order to avoid the
kern.argmax limit. 64000 files would certainly exceed that
limit. Also note that the output is already sorted because
the shell sorts wildcard expansions.
Now that we have those two files, we can use comm(1) to
find out whether there are any hashes in filelist that are
not in filespresent:
if [ -n $(comm -23 filelist filespresent) ]; then
echo -n Update files missing --
...
fi
That solution scales much better because no shell loop is
required at all.
This will probably be the fastest.
Are you sure? I'm not.
I'd put money on this being faster for a lot of reasons.
I assume, with this you mean my solution to the slow
shell loop problem (not quoted above), not Yoshihiro Ota's
awk proposal?
test is a
builtin in our /bin/sh, so there is no exec involved for 'test -f',
but going out to disk for 64k files on an individual basis should
definitely be slower than getting the file list in one shot.
Correct.
There's no doubt that the current routine is not efficient. The cat
should be eliminated, the following is equivalent:
cut -f 2,7 -d '|' $@ |
(quoting the $@ won't make a difference here).
Right, technically it doesn't make a difference because the
file names are fixed and don't contain spaces. *But* then
it is better to use $*. Every time I see $@ without double
quotes I wonder if the author forgot to add them. It always
smells like a bug. Using $@ without quotes is pointless
because then it behaves exactly the same as $*.
I haven't seen the files we're talking about, but I can't help
thinking that cut | grep | cut could be streamlined.
Yes, it can. I already explained pretty much all of that
(useless cat etc.) in my first post in this thread. Did
you read it? My suggestion (after a small correction by
Christoph Mallon) was to replace the cat|cut|grep|cut
sequence with this single awk command:
awk -F | '$2 ~ /^f/ {print $7}' $@
For those not fluent with awk, it means this:
- Treat | as field separator.
- Search for lines where the second field matches ^f
(i.e. it starts with an f).
- Print the 7th field of those matching lines.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
In my experience the term transparent proxy is an oxymoron (like jumbo
shrimp). Transparent proxies seem to vary from the distortions of a
funhouse mirror to barely translucent. I really, really dislike them
when trying to figure out the corrective lenses needed with each of them.
-- R. Kevin Oberman, Network Engineer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Doug Barton wrote:
Oliver Fromme wrote:
I assume, with this you mean my solution to the slow
shell loop problem (not quoted above), not Yoshihiro Ota's
awk proposal?
I meant the solution using comm, sorry. (I forgot to mention that I
would probably use cmp here, but that's a personal preference.)
I see. No problem.
However, I think cmp wouldn't work here, because cmp only
detects whether there is a difference between two files.
In this case we need to know if one file is a subset of
the other: For every hash there must be a .gz file, but
it doesn't hurt if there are more files. So the list of
hashes can be a subset of the list of .gz files, they
don't have to be equal.
While I were at it, I skimmed through the cmp source and
found a bug (or inefficiency): When the -s option is
specified (i.e. silent, exit code only), it would be
sufficient to terminate when the first difference is
encountered. But it always compares the whole files.
I'll try to make a patch to improve this.
Yes, it can. I already explained pretty much all of that
(useless cat etc.) in my first post in this thread. Did
you read it?
Yes, I was attempting to agree with you. :)
OK, sorry. I misunderstood. :)
My suggestion (after a small correction by
Christoph Mallon) was to replace the cat|cut|grep|cut
sequence with this single awk command:
awk -F | '$2 ~ /^f/ {print $7}' $@
For those not fluent with awk, it means this:
- Treat | as field separator.
- Search for lines where the second field matches ^f
(i.e. it starts with an f).
- Print the 7th field of those matching lines.
Like I said, I haven't seen the files, but this looks good at first
blush. That said, the generation of the hash list file is just a drop
in the bucket. The real inefficiency in this function is the test -f
for 64k files, one at a time.
Yes, definitely.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
We will perhaps eventually be writing only small modules which are identi-
fied by name as they are used to build larger ones, so that devices like
indentation, rather than delimiters, might become feasible for expressing
local structure in the source language. -- Donald E. Knuth, 1974
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Hi,
I've Cc'ed Colin Percival, the author of freebsd-update.
Bert JW Regeer wrote:
Recently I decided it would be time to upgrade an older laptop that
was still running 6.2-RELEASE to a more recent release 7.1-RELEASE
[...]
Everything went well, including the kernel update. It was not until
after I rebooted and ran:
./freebsd-update.sh -f freebsd-update.conf install
That I started noticing something rather weird. It had been running
for a good 30 minutes before I started wondering what was going on.
top gave me nothing of value, other than that all of the time was
spent running sh, and that it was spending all of its time in system,
not user where I would have expected it. Thinking went wrong I stopped
the process and started it again.
After a ktrace and kdump I found the culprit in install_verify in the
freebsd-update utility, it would read one line, and then run stat on
one of the many files that was listed in /usr/upgrade/files/.
install_verify () {
# Generate a list of hashes
cat $@ |
That should be $@ with double quotes. $@ doesn't make
sense without the quotes. Apart from that, it's a typical
case of useless use of cat.
cut -f 2,7 -d '|' |
grep -E '^f' |
cut -f 2 -d '|' |
sort -u filelist
It's unclear why there are two cut commands. The 7th
field isn't used at all. Also, the -E option to grep
is superfluous here. Finally, using awk might be more
efficient than cut + grep.
So I would suggest to replace the whole pipe with this:
awk -F | '$2 ~ /^f/ {print $2}' $@ |
sort -u filelist
# Make sure all the hashes exist
while read HASH; do
if ! [ -f files/${HASH}.gz ]; then
echo -n Update files missing --
echo this should never happen.
echo Re-run '$0 fetch'.
return 1
fi
done filelist
# Clean up
rm filelist
}
running find /usr/upgrade/files/ | wc -l showed over 64000 files. So
what was happening here is that freebsd-update.sh is doing due
diligence in checking that all the files exist, however it uses the
built in test utility to do so. While in normal situations this may
not be that big of a deal since the changeset is likely to be small,
running stat on 64000 individual files in a loop is rather slow.
In my case I have just removed the offending code and hoped all went
well, however this is off course not an acceptable solution. I have
not yet come up with an acceptable way to fix the offending code,
hence my post to hackers. I am also not sure as to how I would file a
pr bug report for this situation, any guidance would be greatly
appreciated.
You are right, that loop doesn't scale very well. I'm not
surprised it is horribly slow with 64000 files on an old
laptop that probably has a disk that isn't too fast.
It would be much better to generate two lists:
- The list of hashes, as already done (filelist)
- A list of gzipped files present, stripped to the hash:
(cd files; echo *.gz) |
tr ' ' '\n' |
sed 's/\.gz$//' filespresent
Note we use echo instead of ls, in order to avoid the
kern.argmax limit. 64000 files would certainly exceed that
limit. Also note that the output is already sorted because
the shell sorts wildcard expansions.
Now that we have those two files, we can use comm(1) to
find out whether there are any hashes in filelist that are
not in filespresent:
if [ -n $(comm -23 filelist filespresent) ]; then
echo -n Update files missing --
...
fi
That solution scales much better because no shell loop is
required at all.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
Life is short (You need Python)
-- Bruce Eckel, ANSI C++ Comitee member, author
of Thinking in C++ and Thinking in Java
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd-update's install_verify routine excessive stating
Christoph Mallon wrote:
Oliver Fromme schrieb:
cut -f 2,7 -d '|' |
grep -E '^f' |
cut -f 2 -d '|' |
sort -u filelist
It's unclear why there are two cut commands. The 7th
field isn't used at all. Also, the -E option to grep
After the first cut the seventh field becomes the second:
Ah yes, you're right, of course.
My caffeine level was insufficient, I guess. :-)
So I would suggest to replace the whole pipe with this:
awk -F | '$2 ~ /^f/ {print $2}' $@ |
sort -u filelist
It should print $7, see above.
Right. Thanks for pointing it out.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
Whatever happened to the days when hacking started
at the cerebral cortex, and not at the keyboard?
-- Sid on userfriendly.org by Illiad, 2007-06-20
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?
Daniel O'Connor wrote: On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: this will make system trying to bind 32-bit libs to 64-bit program. it can't work rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. The same problem happens with the Linux run time linker - it merrily tries to link FreeBSD libraries to Linux binaries with predictable results.. You *can* link Linux libraries with FreeBSD binaries (and vice versa), if the library does not perform any syscalls, e.g. it is a pure computation library or similar. That said it would be really nice if it ignored incompatible libraries :) No. Please don't put such pseudo-cleverness into rtld. It wouldn't be an improvement, in fact it might break some working configurations. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb for linux-emulation
Martin Laabs wrote: Hans Petter Selasky wrote: No, you cannot use the linux libusb on FreeBSD. You need to use the FreeBSD compiled libusb. The USB kernel interfaces are quite different. OK - I see. I'm just trying to build a hermaphrodite library. Compile with linux but using the BSD ioctls. Is there a crosscompiler to compile linux binarys from freebsd? This would make the job much easier. Yes, I think you can use ports/devel/cross-gcc. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call function on sysctl value change
Matthew Jakeman wrote: I was wondering if it is possible to call a function when a sysctl value is changed. I have added a few sysctl int variables to the kernel and for some of these i only want certain values to be acceptable as input depending on some conditions. I would like to be able to call a function if possible, to validate the value entered via the sysctl command. Yes, you can do this with a PROC type sysctl. For example, look at sysctl_hlt_cpus() in sys/i386/i386/mp_machdep.c. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard? -- Sid on userfriendly.org by Illiad, 2007-06-20 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sockstress
This is the wrong mailing list, you should send this to the -security list. By the way, this kind of attack isn't really new (as far as I can tell from the few information that have been made public so far). One way to mitigate it is to limit the number of open connections per remote IP address; you can easily do that with PF or IPFW (limit option). Best regards Oliver Lukasz Jaroszewski [EMAIL PROTECTED] wrote: Hi, I am wondering about sockstres informations recently published. I cant really figure what new they could found. Do we have anything to worry about? ;-) http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html ``(...)Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it, Lee said.(...)'' ``(...)Lee said that when and _if_ specific vendors develop workarounds for the issues, they will release details of those issues.(...)'' Was FreeBSD team contacted? ;) -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Evren Yurtesen wrote: Shaun Amott wrote: On Tue, Oct 07, 2008 at 12:31:58AM +0300, Evren Yurtesen wrote: so FreeBSD could be supported also. As you can imagine, it is not only important that data can be restored when a box hardware failure etc. it is also important that data can be restored if deleted by accidents etc. While traditional backup programs provide this functionality, you cant really go back to 10 min or 1h ago, often they take daily backups and have to scan whole filesystem for changed files every time the backup is taken which stresses out the systems. This can (more or less) be achieved with snapshots: you can cheaply maintain old versions of the file system, and mount an old snapshot at any time. Hourly is about as fine-grained as you can expect though. The documentation says one cant do more than 20 snapshots. http://www.freebsd.org/doc/en/books/handbook/snapshots.html I wouldn't use UFS snapshots for this purpose. They have a few well-known disadvantages. However, ZFS snapshots should work very well for this. They're not limited to 20, and you can create them very quickly and with low overhead. You could create a new snapshot every 5 minutes if you want. Then you can use the zfs send command to produce a stream that contains the incremental differences between the snapshot and the previous snapshot, i.e. the stream represents the changes to the filesystem within the past five minutes (or whatever snapshot interval you choose). You can store that stream in a file, on backup medium, or send it with ssh to a different continent. Every once in a while you should make a full backup from a snapshot, of course. Basically it works like any other incremental backup mechanism, except that you can make the time interval between incremental backups very small (like five minutes in the above example), so you get a nearly continous backup solution. By the way, if you accidentally deleted something, you can of course simply copy it back from a snapshot. You can even revert the whole file system to a previous snapshot using the zfs rollback command. This is like going back in time. There is no need to touch your backups for that. These features are readily available right now on FreeBSD. You don't have to code anything. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Zaphod Beeblebrox wrote: Oliver Fromme wrote: However, ZFS does exist on FreeBSD, and I think it wouldn't be impossible to add similar features to ZFS. Possibly even as a ZFS module? This might be something better addressed at the ZFS project level --- but the next question is: does FreeBSD support ZFS modules? I'm sorry I don't know. But also see my other reply regarding ZFS snapshots ans zfs send. Another possibility would be to extend gjournal by adding time stamps to journal transactions and a possibility to feed the journal to a pipe, socket or whatever. And of course a client-side implementation that does something useful with the journal stream. This might even be a good SoC project. Now this interests me. Firstly, I thought that gjournal might only be responsible for the meta-data (but I'm happy to be wrong on this point). Nope, gjournal handles _all_ data, i.e. meta data and file contents. Secondly, is it a) sufficient and b) efficient to attempt to time-travel UFS with the gjournal log? I almost don't dare to mention DragonFly BSD again, but they do have a UFS journaling implementation that does exactly that: http://leaf.dragonflybsd.org/cgi/web-man?command=mountctl http://leaf.dragonflybsd.org/cgi/web-man?command=jscan However, I think the implementation was abandoned because it was obsoleted by the development of the HAMMER file system. But the basic functionality is there and works. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper. -- Ralf Hildebrandt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Dag-Erling Smørgrav wrote: Zaphod Beeblebrox [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: What really annoys me with this thread is that nobody has provided any information at all that would allow someone to understand what needs to be done and estimate how hard it would be. Well... I hinted that a hammer port would be sufficient (although they need to finish their replication design) and I hinted that the hammer approach may be graftable to ZFS. Both reasonably large effort-wise (but probably within the scope of a single developer with sufficient time). No... you're so far off the mark it's not even funny, especially when it's been repeatedly pointed out to you. This is not a file system, it's a backup system. It's not designed to survive a disk crash or an accidental file deletion, it's designed to survive a direct missile strike on your colo center. To quote Wikipedia, CDP is a service that captures changes to data to a separate storage location - emphasis on separate. FWIW, the HAMMER file system _does_ support replication to remote targets (thus separate). Unfortunately they call this feature mirroring, which is misleading at best. It's really rather a replication mechanism, much like the binlog of MySQL. It can be used for various purposes, including live mirroring, delayed mirroring, archiving, backup and point-in-time recovery. Well, of course, all of that doesn't help us at all because HAMMER doesn't exist on FreeBSD. However, ZFS does exist on FreeBSD, and I think it wouldn't be impossible to add similar features to ZFS. Another possibility would be to extend gjournal by adding time stamps to journal transactions and a possibility to feed the journal to a pipe, socket or whatever. And of course a client-side implementation that does something useful with the journal stream. This might even be a good SoC project. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd File names are infinite in length, where infinity is set to 255 characters. -- Peter Collinson, The Unix File System ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Rich Healey wrote: Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? There's nothing that replaces using either *good* passwords or *no* passwords at all (i.e. ssh keys instead). I completely agree with Jeremy Chadwick that using programs that change your packet filter rules automatically can be dangerous. I recommend against this. Especially it does not protect you if you have weak passwords. In fact it might open a hole that someone can successfully run a DoS attack against your machine by spoofing one of your own IP addresses, or the IP address of your upstream router, or DNS server, or whatever. If you're merely annoyed about the large amount of logging entries caused by the break-in attempts, a good solution is to move the sshd service from the standard port 22 to a different, non-standard port (e.g. 222 or whatever, but it should be a reserved port, i.e. less than 1024 which is the default high limit for the reserved port range). Most attackers are just script kiddies that use automated software that tries only port 22. You can put an entry in ~/.ssh/config on your client machines so you don't even have to remember to specify the port number when ssh'ing to your server. Alternatively you can configure sshd to listen on port 22 *and* an alternate port, and block port 22 for everything except a few known-good addresses or networks. That way you don't have to do anything special when connecting from any of your usual clients, but you can still connect from anywhere else if necessary by using the non-standard port. Of course, the non-standard port trick is *not* a security measure. It only makes your machine a little bit more invisible to script kiddies and prevents them from filling your log files. It might also give you a very small advance in case of zero-day attacks. It does *not* help against weak passwords or lazyness to patch known holes, or other kinds of operator failure. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Ollivier Robert wrote:
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this; you'll
need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush global)
That one is very effective.
It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial. :-(
It is marginally better to use one of those tools
that parse the logs for failed ssh logins, and use
that information to block addresses. In order to
abuse that, and attacker would have to spoof a full
TCP connection setup plus initial SSH conversation,
which is far from trivial.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
Perl will consistently give you what you want,
unless what you want is consistency.
-- Larry Wall
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Pierre Riteau wrote:
Oliver Fromme wrote:
Ollivier Robert wrote:
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this;
you'll need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush
global)
That one is very effective.
It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial. :-(
This is not true. pf.conf(5) says:
For stateful TCP connections, limits on established connections (connec-
tions which have completed the TCP 3-way handshake) can also be enforced
per source IP.
Thanks for the correction. I prefer IPFW most of the time,
therefore I wasn't aware of this detail.
Because the 3-way handshake ensures that the source address is not being
spoofed, more aggressive action can be taken based on these limits.
s/not being spoofed/more difficult to spoofe/ ;-)
Still, detecting the break-in attempts on application layer
(e.g. auth log file) is better than on TCP layer.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
It combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable. It combines the power of C
with the readability of PostScript.
-- Jamie Zawinski, when asked: What's wrong with perl?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Bill Moran wrote: In response to Oliver Fromme [EMAIL PROTECTED]: Pierre Riteau wrote: Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. It depends a lot on the environment, for example whether the attacker has access (or can somehow get access) to the server's uplink and trace packets. This can happen if the server is located with many other servers on the same network, which is often the case for co-location or so-called root servers. Of course, if the network is regarded secure, then you are right. Spoofing a TCP handshake would be very difficult in that case. (I try to avoid the word impossible. Nothing is impossible, especially in the security business.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What file on FreeBSD acts like autoexec.bat?
Mike Price [EMAIL PROTECTED] wrote: What file on FreeBSD acts like autoexec.bat? Also please leave the full path% The file that probably comes closest is /etc/rc.local (you have to create it, it doesn't exist by default). Actually FreeBSD's rc system allows much more flexible scripting ... If you're interested, start by reading the rc(8) manual page. But if you only need some simple commands executed upon every boot, just put them in /etc/rc.local and you're done. Note, however, that you have to use sh(1) shell command syntax, not COMMAND.COM syntax. ;-) By the way, the file that corresponds to config.sys on a FreeBSD system is /etc/rc.conf (see the rc.conf(5) manual page for details). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
Danny Braniss wrote: Grr, there goes binary search theory out of the window, So far I have managed to pinpoint the day that the changes affect the throughput: 18/08/08 00:00:00 19/08/08 00:00:00 (I assume cvs's date is GMT). now would be a good time for some help, specially how to undo changes, my knowledge of csup/cvs are close to zero. So you've nailed to down to this 24-hour window: http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18p=/stable/7 I'm afraid that r181822 by rwatson is the most likely candidate that might be causing the regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimantal question about md's
Michael Schuh wrote: Clearly the Writeprocess of writeing data to an mirror is totally ended, as all mirrordevices are written. But for the read the kernel uses the faster device..and there it could be an advantage.i m thinking. And yes i think it could be an advantage, if the RAMed mirror is very fast, we have only to wait for the first initialization, all the ongoing reads go to the ramdisk, all writes goes to both devices. I think it would be completely sufficient to use a normal device and let the kernel cache the data. This is much better because the kernel dynamically adapts the cache size to the workload and memory requirements. If you use an unusual asymmetric mirror setupt with a physical disk and a memory disk (swap-backed), the machine will have to start paging as soon as the requirements of your processes grow beyond what's available. This will be very slow, of course. For example (a little bit simplified): Say there's a spike in web accesses so you get many processes that want to allocate memory. If you run out of free memory, the kernel will drop some pages that contain cached data and re-use them. If the cached data is used later, the kernel will re-read it from the disk. On the other hand, if you use a memory disk, you effectively reduce the amount of memory available by the size of that disk. If a process wants to allocate memory now, the kernel can't simply drop any pages used by the memory disk -- it has to write them to the swap area first. It is obvious that the performance is worse. And of course, the kernel will still try to cache the file system data (the VFS code doesn't care that the file system is on a gmirror with one half on a memory disk). So the cache and the memory disk fight for RAM at the same time. Basically you would be wasting RAM and losing performance. if i have enough ram in the box, it is possible to say: Hi kernel use plase 8 Gigs of ram for buffering the directory abc on the disk directaccesABC ??? i think not. The kernel will basically use all available RAM for caching and buffering. This works especially well for static web content. There are a few sysctl variables to influence the behaviour, but it's usually better not to touch them. I get the impression that you're trying to solve a problem that doesn't exist. If you think you _do_ have a problem, please provide some evidence, such as output from iostat, gstat, vmstat and so on. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS w/failing drives - any equivalent of Solaris FMA?
Karl Pielorz wrote: Recently, a ZFS pool on my FreeBSD box started showing lots of errors on one drive in a mirrored pair. The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on each controller). One of the drives started picking up a lot of errors (by the end of things it was returning errors pretty much for any reads/writes issued) - and taking ages to complete the I/O's. However, ZFS kept trying to use the drive - e.g. as I attached another drive to the remaining 'good' drive in the mirrored pair, ZFS was still trying to read data off the failed drive (and remaining good one) in order to complete it's re-silver to the newly attached drive. Having posted on the Open Solaris ZFS list - it appears, under Solaris there's an 'FMA Engine' which communicates drive failures and the like to ZFS - advising ZFS when a drive should be marked as 'failed'. Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything on the system tell ZFS This drives experiencing failures rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears to be the case). In the end, the failing drive was timing out literally every I/O - I did recover the situation by detaching it from the pool (which hung the machine - probably caused by ZFS having to update the meta-data on all drives, including the failed one). A reboot bought the pool back, minus the 'failed' drive, so enough of the 'detach' must have completed. Did you try atacontrol detach to remove the disk from the bus? I haven't tried that with ZFS, but gmirror automatically detects when a disk has gone away, and doesn't try to do anything with it anymore. It certainly should not hang the machine. After all, what's the purpose of a RAID when you have to reboot upon drive failure. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months. -- Cliff Sarginson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extending find(1) to support -printf
Jeremy Chadwick wrote: On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: Also, some folks on #bsdports asked why I was bothering with this in the first place: mutt supports backticks to run shell commands inside of a muttrc file. See Building a list of mailboxes on the fly below: http://wiki.mutt.org/?ConfigTricks Note the find ... -printf '%h ' method. I can accomplish (just about) the same using `echo $HOME/Maildir/*`, but if I want to exclude an entry, I can't use | grep -v, because mutt doesn't support pipes within backticks. :-) Follow-up: mutt's backtick support does in fact respect pipes. My echo|grep -v was doing exactly what I requested: the grep -v was removing all output of the echo, since echo returned the results in a space-delimited format, not one per line. Hence, mailboxes was being executed without any arguments. Equally as frustrating, mutt's backtick support will only honour the first line of input. If a backticked command returns multiple lines, only the first is read; the rest are ignored. Well, you can convert back and forth between spaces and newlines with tr(1): echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' It's not pretty, but it should work. Note that ls(1) prints one file name per line, so you can simplify the above line like this: ls | grep -v whatever | tr '\n' ' ' By the way, I often use zsh in such cases. It supports extended globbing, for example, the wildcard expression *~*.(gz|bz2) matches all files _except_ the ones that end with .gz or .bz2. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temp files in /etc
Joshua Piccari wrote: I am setting up a few jails and I want them all to use the same /etc files (with the exception of the files related to the password files and databases), so I mounted a shared /etc folder as a nullfs with read-only permissions. The problem is that using utilities like pw or chpass create temporary files in /etc and that file system is mounted read-only. So is there a way to force any utilities that create temp files in /etc to use another location, something like /usr/local/etc for example? I had exactly the same problem. I wrote a small patch that solves it: http://www.secnetix.de/olli/FreeBSD/jail-passwd/ Please read the instructions.txt file first, then download the appropriate patch file. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kvm on amd64 - 6G?
Barry Boes wrote: With the advent of ZFS, Solaris users are devoting 30G or more to their ARC caches today. If FreeBSD 8 is going to up the KVM size, is there a reason to not increase the limit to something that will not be reached in the lifetime of 8? 100GB? I think Alan Cox recently increased the kmem limit in 8-current from 1.5 GB to 7 GB, and the default is 4.2 GB. http://svn.freebsd.org/viewvc/base?view=revisionrevision=180311 I don't know if this will be MFCed. It will not be in 7.1-Release; it's too late for that. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Boot loader + malloc
Hello, I've got a small question regarding $subject. I'm looking at this code snippet from src/sys/boot/i386/loader/main.c: #if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) heap_top = PTOV(memtop_copyin); memtop_copyin -= 0x30; heap_bottom = PTOV(memtop_copyin); #else heap_top = (void *)bios_basemem; heap_bottom = (void *)end; #endif setheap(heap_bottom, heap_top); If I understand correctly, the boot loader will use only low memory (i.e. below 0x10) for malloc by default. Extended memory is only used if bzip2 or firewire support are enabled (not default). Is this intentional? Would it make sense to toggle the default and always use extended memory, unless disabled? I'm asking because the upcoming graphics support requires a little bit of memory for fonts and images, but there's only less than about 80 KB left in low memory, which is insufficient except for very trivial things. The loader kept crashing on me in nasty ways because of that. In my p4 branch I modified the above #if to also use extended memory if LOADER_GRAPHICS_SUPPORT is defined, giving me 3 MB of memory to play with, which is plenty. Is that OK, or should I expect trouble? Any comments are appreciated. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot loader + malloc
Jordan Gordeev wrote: At present the amd64 kernel is loaded just above the first megabyte of physical memory. Yes, I know, and the standard i386 kernel is loaded at 4 MB, and the PAE kernel is loaded at 2 MB. It doesn't matter much, though. I have no idea if the loader uses malloc()/free() after the kernel is loaded though. Yes, it does. By default the loader loads the kernel first, then fires up the beastie menu which causes quite some malloc() activity. FICL uses malloc() internally for various things. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, in comp.lang.c++ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB key kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
Matthias Apitz wrote: Oliver Fromme wrote: Matthias Apitz wrote: I've updated usb/80361, see http://www.freebsd.org/cgi/query-pr.cgi?pr=80361 because I have the same problem as well that an USB key attaches fine when plugged in at boot time, but not later: I'm just wondering what happens if you enforce a rescan on the (virtual) SCSI bus. That is, after you have plugged in the USB stick and the problem occured, type camcontrol rescan 0. this did not helped; I tried it a lot of times; OK. also reading with dd(1) from /dev/da0 did not helped; I think reading from it isn't expected to help. The device needs to be opened for _writing_ so the GEOM layer assumes that the partition or slice table was modified and re-reads it from the media. Something like this should be sufficient: dd if=/dev/null of=/dev/da0 count=0 It openes the device for writing (this is important), but doesn't actually write anything to it. If that doesn't help, please try this patch: ... The problem is that this was a USB stick of a friend of me in which I have created a booting FreeBSD so he can make the installation of it in an eeePC; will try to get back this USB stick from him for further tests... OK. A little bit of background information: If a USB memory stick is detected fine during boot, but not when plugged into the running system, it usually indicates that the USB stick needs a longer delay to be ready for the CAM SCSI layer. The default delay is 200 ms. This might be too short for some USB sticks. The patch increases it to 2000 ms. If that still doesn't help, then there must be a completely different problem with your USB stick. In that case someone with more intimate knowledge of the USB code needs to help. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd cat man du : where Unix geeks go when they die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB key kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
Matthias Apitz wrote: I've updated usb/80361, see http://www.freebsd.org/cgi/query-pr.cgi?pr=80361 because I have the same problem as well that an USB key attaches fine when plugged in at boot time, but not later: I'm just wondering what happens if you enforce a rescan on the (virtual) SCSI bus. That is, after you have plugged in the USB stick and the problem occured, type camcontrol rescan 0. If that doesn't help, please try this patch: === --- src/sys/dev/usb/umass.c.orig2008-05-21 16:22:03.0 +0200 +++ src/sys/dev/usb/umass.c 2008-08-06 19:23:01.0 +0200 @@ -2690,7 +2690,7 @@ * completed, when interrupts have been enabled. */ - callout_reset(sc-cam_scsi_rescan_ch, MS_TO_TICKS(200), + callout_reset(sc-cam_scsi_rescan_ch, MS_TO_TICKS(2000), umass_cam_rescan, sc); } === Note that this patch is not a solution. It's purpose is to find out if the cause of your problem is the same as the one in PR usb/80361. If it is, the patch from the PR should be committed (it introduces a quirk for cases like this), and your USB stick should be added to the quirks list. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: restore of file system into USB key terrible slow
Matthias Apitz wrote: [...] I'm trying to restore a DUMP into an USB key; the DUMP was extracted from another USB key which I just want to colne this way; Note that dump/restore isn't a very fast method to clone a file system. Actually, a few years ago it was horribly slow, but it was improved somewhat. It's better now, but still not very fast. Personally I recommend to try cpdup (from ports/sysutils). You can simply type cpdup /src /dst and it will make an exact copy (except for sparse files). A nice feature of cpdup is that it doesn't copy files that already exist in the destination. Another way copy a directory tree is to use find+cpio: cd /src; find -d . | cpdio -dump /dst Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPG encryption of binary sample requested.
Julian Stacey wrote: [...] I'll have to install some other POP3 (or IMAP) server, Big choice: cd /usr/ports/mail; echo *pop* akpop3d cucipop freepops mdpop3d nullpop p5-vpopmail pecl-pop3 pop-before-smtp pop3gwd pop3lite pop3proxy pop3vscan popa3d popa3d-before-sendmail popcheck popclient popd popfile poppassd popper poppwd poppy popular qpopper solidpop3d teapop teapop-devel tpop3d vm-pop3d vpopmail vpopmail-devel wmmultipop3 wmpop3 wmpop3lb I'm a satisfied user of dovecot (ports/mail/dovecot) for several years. Installation was painless. Works with standard mailfolders, so you don't have to convert to maildir format if you don't want to. YMMV, of course. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error 1 lba 752976 while booting from USB key to install
Matthias Apitz wrote: so I cam up with the idea to boot from that USB key I have used to install 7.0-REL on that eeePC, i.e. the USB key works fine in any laptop; on the HP NAT 1000s storage system it says: FreBSD/i386 Default: 0:ad(0,a)/boot/kernel/kernel Hm. Strange. The boot0 code should load /boot/loader, not the kernel. (While it is possible to load the kernel directly under certain conditions, AFAIK, it is better to go the official way and let the bootloader do its job.) Have you modified the boot sequence on that USB stick in a special way? Please make sure that it contains the proper infrastructure, i.e. a /boot directory with the loader, a kernel subdirectory etc. If it still fails, I suggest you try a more recent version of FreeBSD. I don't know if it's related to your problem, but there has been a significant change in the boot loader code (so-called BTX) that fixes USB-booting on certain machines. You can either csup RELENG_7 and build a fresh /boot directory, or fetch it from the June snapshot. Then replace /boot/loader on your USB stick with the new one, and don't forget to re-install the bootblocks, too (bsdlabel -B). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error 1 lba 752976 while booting from USB key to install
Matthias Apitz wrote: I've created the USB key like this (more or less) and did not specified or changed anything in the boot-sequence: [...] and again: the USB key works fine in the eeePC 900 and other laptops I have; here is what is in /mnt/boot: [...] OK, that looks good. So it's probably the well-known BIOS access problem that was patched in FreeBSD's BTX code after 7.0-RELEASE. I suggest you try RELENG_7 or the June snapshot, as explained in my previous mail. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Life is short (You need Python) -- Bruce Eckel, ANSI C++ Comitee member, author of Thinking in C++ and Thinking in Java ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 with SSD reducing writes
Matthias Apitz wrote: Oliver Fromme wrote: You can get rid of an on-disk /var alltogether. Add these lines to /etc/rc.conf: varmfs=yes varsize=32m It will create a memory FS for /var of 32 MB (default). Thanks for the hint, but memfs is not so good because you will loose /var/db; I've created a symlink now from /var/log to /tmp/log and /tmp is memfs; It depends what you need from /var/db. In my case I didn't need anything from it, so losing it was OK. Another possibility is to create a static var directory somewhere (on flash memory), e.g. /svar, and write a small script or mtree file that creates symlinks from the memfs /var to the static /svar, e.g. /var/db - /svar/db. Yet another solution would be to use unionfs, or a skeleton .tar.gz file that contains initial things for memfs /var. There are many possibilities to choose from. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 with SSD reducing writes
Matthias Apitz wrote: I'd also like to get rid of 'lastlog' and 'wtmp' but even if the man page claims that they will not be created if they don't exist, they come up again and again; another candidate of not needed log is /var/log/Xorg.n.log ... You can get rid of an on-disk /var alltogether. Add these lines to /etc/rc.conf: varmfs=yes varsize=32m It will create a memory FS for /var of 32 MB (default). You could also mount some or all of your disk partitions read-only. That's what I do on my embedded FreeBSD-driven mp3 player (running from a CF card instead of hard disk), because it doesn't have to write anything anywhere. If you have any disk partitions that you mount read+write, be sure to enable soft-updates because it tends to reduce the number of physical write operations. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd FreeBSD is Yoda, Linux is Luke Skywalker -- Daniel C. Sobral ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: moving FreeBSD installation disk1 to an USB stick
Matthias Apitz [EMAIL PROTECTED] wrote: I'm preparing the installation of FreeBSD 7.0 on an Asus eeePC which has no CD/DVD drive for the installation (and I have no external CD driver with USB): http://www.laptoppen.nl/product-260-Asus-EEE-PC-900-Zwart.html My idea is to 'copy' somehow the FreeBSD 7.0 installation disk1 to an USB stick of 1 GByte; there is some kind of recipe how to put a boot-able system onto such an USB stick, like; http://groups.google.com/group/lucky.freebsd.questions/msg/5c759b1c87376b22 but this is not what I want; I want to boot the stick (of course) and run the 'sysinstall' having the complete disk1 on the stick; maybe it is an option making only the file system on the stick and the boot sector and fill in a dump of the file system of disk1, Yes, that should work. Just prepare the USB stick so it is bootable (fdisk(1), bsdlabel(8)), put a UFS file system on it (newfs(8)), then extract the contents of the disk1 ISO image onto the file system. You can use tar for that: # cd /mnt ; tar xf /tmp/disk1.iso with some minor changes that after booting it uses the USB as CD device? No, I don't think that's possible. And it's not necessary. sysinstall can install from a normal UFS partition. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Maximum memory allocation per process
Dinesh Nair wrote: for those of us who're booting off a stripped down freebsd and are not using the 4th routines, are the above to be set before 'load /kernel' or after 'load /kernel' ? It doesn't matter. The tunables are passed to the kernel when it is booted. In fact, the standard beastie.4th stuff loads the kernel before displaying the menu, so the settings happen after the kernel is loaded. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impact of having a large number of open file descriptors
Ivan Voras wrote: Im thinking again of the old idea of implementing poor man's file replication system using kqueue to monitor changes on files. It would be cool to have a kernel interface so you could attach to a mountpoint and receive a log of all activity on that file system. That's similar to what DragonFly's journaling feature does. Unfortunately the kqueue interface isn't capable of doing something like that ... So this is not an answer to your question, I'm afraid. One other question: do kqueue events coalesce in the sense that if N operations happen (like write()s), there can be N events passed to the kqueue (NOTE_WRITE)? The manpage says: Multiple events which trigger the filter do not result in multiple kevents being placed on the kqueue; instead, the filter will aggregate the events into a single struct kevent. While at it, will EVFILT_VNODE and NOTE_WRITE catch additional ways the file can be modified, meaning mmap()? A quick grep for NOTE_WRITE on the sys tree indicates that it doesn't. I'm not 100% sure though. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I translate IP to hostname in C
Bjoern A. Zeeb wrote: John Timony wrote: I am writing a c program in FreeBSD,and I can not translate a ip to hostname ,i wonder if there is a function to take this job... You mean like gethostbyaddr()? gethostbyaddr() is considered obsolete, I think. You should use getaddrinfo() instead, which is more flexible and easier to use, and it enables you to easily write code that is independent and agnostic of the address family (IPv4 vs. IPv6 vs. others). The manual page contains detailed example code. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The most important decision in [programming] language design concerns what is to be left out. -- Niklaus Wirth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
KAYVEN RIESE [EMAIL PROTECTED] wrote: Tom Evans wrote: I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. That list is too busy. I find I don't have to unsubscribe to hackers, and it doesn't seem as hard core to misinterpret what hackers are, than say ports or acpi Well, hackers usually means developers, i.e. people hacking on the FreeBSD code. Therefore I'm afraid I have to agree with Tom: Your questions should better go to the questions list. I realized that make delete-old and make delete-old-libs are both part of the cannonical, I guess because I am going RELENG_6_3 to RELENG_7 I always use make delete-old, as instructed in the /usr/src/UPDATING file, and it has never bitten me. Please have a look at that file; the important part starts at the section titled To rebuild everything. On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Nothing is impossible!, as Dr. Farnsworth from the Futurama series used to say. :-) But seriously ... I think going from 6.2 to 7.0 should work fine. However, the official notion is that updates across major versions have to be supported only for the latest stable release. Any other configurations might work, but it's not guaranteed. If it fails, you're not expected to complain or ask for help, but instead try the officially supported way (i.e. first update to the latest stable on your existing branch, then update across the major version boundary). If that still fails, you may complain and ask for help. Note that it is IMPORTANT to rebuild *all* of your ports when you update from 6.x to 7.x. (This holds true for any major version update.) If you don't do this, you will get library dependency collisions, i.e. port A uses libc.so.7 and depends on port B, but port B still links against the older libc.so.6. Things will break sooner or later. That's why you should rebuild *all* ports after updating to 7.x. (You can keep older ports only if you are absolutely sure that they are not part of any dependencies, and never will be.) In your previous mail you mentioned: Things work, but dmesg has errors, Would you please tell us what those errors are? We might be able to help you, but only if you tell us. and many ports fail and their makes Again: Please post messages and everything relevant to the problems. There are really people on these lists that are willing to help, but we need as much information as possible in order to be able to help. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with copytree code
Beech Rintoul wrote: This copytree code is from bsd.port.mk, and I've been asked to try and find a fix. This is very handy for installing a whole tree (like a web app) keeping everything intact. It wasn't designed to copy to a populated directory so it affects everything in that dir, not just what's being installed. We need to keep it's functionality, but a fix is more than I can come up with. Why don't you simply do the chown+chmod on the source tree instead of doing it afterwards on the target tree? I think that would solve the problem. By the way, cpio(1) does have the option -R to change owner and/or group on the target files, so you don't need to run chown(1) afterwards. Unfortunately there doesn't seem to be an option to set the permission modes, though. Finally, I recommend you use the -print0 option of find and the -0 option of cpio, so it will also work if there are any file names that contain spaces or other special characters. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trying (not) to crash with libpthread (6.3-RELEASE)
Mike [EMAIL PROTECTED] wrote:
Jille Timmermans wrote:
void
sigcatcher(int sig) {
printf([%p] signal %d\n, pthread_self(), sig);
printf(Test (probably) succeeded\n);
fflush(NULL);
success=1;
exit(0);
}
Take a look at the man page for sigaction(2). Here's an excerpt:
All functions not in the above lists are considered to be unsafe with
respect to signals. That is to say, the behaviour of such functions when
called from a signal handler is undefined. In general though, signal
handlers should do little more than set a flag; most other actions are
not safe.
Additionally, the success variable should be
declared as volatile sig_atomic_t.
By the way, this code ...
char *x=malloc(1);
[...]
x[666]=0;
.. does not necessarily cause a SIGSEGV. It may do so,
but it is not guaranteed. It may as well write into a
random memory area that happens to belong to your process,
too. The result is undefined, i.e. it could be anything.
If you need to send a SIGSEGV to yourself reliably, the
best way is to kill(getpid(), SIGSEGV).
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
File names are infinite in length, where infinity is set to 255 characters.
-- Peter Collinson, The Unix File System
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with find -prune...
Mike Meyer wrote: find -prune seems to not quite do what it says. At least, when delete is used. Here's an example tree (on 7.0-RELEASE, amd64 build): It behaves exactly as documented. I'll try to explain. bhuda% find /tmp/x -prune /tmp/x Hmm, it prints the root of the tree. That might be a bug; might not. It's not a bug: -prune prevents find(1) from descending *into* the directory, but the directory itself is still handled. bhuda% find /tmp/x -prune -o -print bhuda% Making the print conditional on not pruning, and we always prune. Ok, now let's look at what looks to me like a bug: bhuda% find /tmp/x -prune -o -delete find: /tmp/x/y: Permission denied Why on earth (or off it) is find trying to look at /tmp/x? Am I correct in assuming that this is a bug? The -delete primary implicitly assumes depth-first traversal (i.e. the -d option), because that's the only way you can delete a whole directory tree. However, when depth-first traversal is in effect, the -prune primary doesn't have any effect (for obvious reasons). It's documented in the manpage. In other words, the primaries -prune and -delete are mutual exclusive. It could be argued whether find(1) should print a warning in that case. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper. -- Ralf Hildebrandt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : The vkernel feature has certainly benefits, e.g. the fact : that you can attach to it with standard gdb and use the : familiar debugging facilities, which can attract more Can't you say qemu -s and attach gdb to that port as well? Good point. According to the manpage it would work, but I've never tried it myself. (I'm rather careful with the qemu manpage because it also contains a few things that only work on Linux.) For loader work (i.e. non-kernel), the good old printf debugging was sufficient for me so far. :) (Or maybe I was just lucky that my bugs were easy enough to fix, so that I didn't need other debugging facilities. I'll certainly keep qemu -s in mind.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Hi, Sorry for jumping in here, but I've seen several people talking about that 5 seconds to reboot thing ... Are you aware that a standard FreeBSD kernel also takes just 5 seconds to reboot within qemu? And that's even when _not_ using the kqemu accelerator module. I've used qemu a lot for debugging my /boot/loader stuff. It takes just about 1 second to get to the loader (i.e. from starting qemu on the command line to the loader menu popping up on the screen). Going single-user takes about 3 seconds. Going multi-user takes a little bit longer, depending on what stuff is enabled via rc.conf. The vkernel feature has certainly benefits, e.g. the fact that you can attach to it with standard gdb and use the familiar debugging facilities, which can attract more developers who wouldn't dare to touch the kernel otherwise. But the 5 seconds to reboot is not a unique feature; you can have that with qemu as well, and it's there today. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Graphic boot loader?
Jeremy Chadwick wrote: Igor_Z wrote: Does anybody know something about graphic boot loader? I mean how to make this? I know that some guy is did it, but how? That is the question! =) This is currently in development, as I understand it. The individual working on it is Oliver Fromme [EMAIL PROTECTED]. I'm sorry for the late reply, I'm currently swamped with work (not FreeBSD-related). It's true I'm working on the graphics support for the boot loader. Development is done in the P4 repository first. As soon as I have something for public test, I will post an RFT to the -current list. I plan to provide a .tar.gz that can simply be dropped in /boot, so everyone can participate in the test easily. It should work with both 8-current and 7-stable. I'm only asking for a little bit of patience, because my free time for working on this is currently very limited. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
Martin Laabs wrote: Preventing the physical access to the memory modules could be done with a light sensor or a simple switch at the computer case. Easily to circumvent, too. If you implement also a temperature- sensor near the memory-modules you could prevent cooling them down before removal. (You'd just overwrite the keys if the temperature falls i.e. below 10°C) Cool ... Then I won't be able to boot my laptop when I have to wait at the train station in winter ... Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Can the denizens of this group enlighten me about what the advantages of Python are, versus Perl ? python is more likely to pass unharmed through your spelling checker than perl. -- An unknown poster and Fredrik Lundh ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loader and ficl/Forth help
Jeremy Chadwick wrote: So I've finally gotten around to attempting a feature I mentionted back in June 2007: using ASCII line-drawing characters for the borders around beastie/fbsdlogo in frames.4th: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-June/020851.html I was hoping there might be some folks familiar with the existing Forth pieces in /boot who could help, since debugging this is incredibly difficult. This is my first time with Forth, which is probably where the true problem lies... There's a debugging aid called testmain so you can run Forth code interactively in multi-user mode for testing purposes. For details please read the thread starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/015387.html Personally I use qemu for testing loader things. I wrote a trivial script that updates a small disk image and then boot its in qemu, which only takes two or three seconds, so testing cycles are pretty short. My idea was to implement a loader_logo_lines loader variable, which you could set to ascii to achieve the desired effect -- but simultaneously retaining support for the PC98 character set, and the CP437 (IBM PC ANSI) set if the variable isn't defined, or is set to something it doesn't understand. I suggest you switch to ASCII characters automatically if the loader is running on comconsole (i.e. serial), and use CP437 it it is running on vidconsole (i.e. VGA). Then there will be no need to manually switch a variable. So far I've managed to crash loader(8) doing the below, with the message sh_el not found from ficl on the serial console, then either an infinite register dump or an automatic reboot. I moved the PC98 and CP437 line constants into routines named pc98_lines and cp437_lines repectively, and made one called ascii_lines. The main code piece I changed in frames.4th became this: s loader_logo_lines getenv dup -1 = if drop s arch-pc98 environment? if drop pc98_lines else drop cp437_lines then then 2dup s ascii compare-insensitive 0= if 2drop ascii_lines then 2drop cp437_lines I think the stack layout is not correct, particularly the drops aren't quite right in some branches of the if statements, I think. It's best to make a stack diagram on paper and go through all possible branches with it. The following snippet should work better, but I have't actually tried it myself, so it's just theory. s loader_logo_lines getenv dup -1 = if drop s arch-pc98 environment? if drop pc98_lines else cp437_lines then else s ascii compare-insensitive 0= if ascii_lines else cp437_lines then then Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loader and ficl/Forth help
Jeremy Chadwick wrote: I have a lot more reading to do on the subject of Forth. Stacks are hardly a new concept to me, but the conditions where Forth puts something onto the stack are. I've never worked with a language like this before (at least RPN doesn't frustrate me!). I've already found some reading material which should help. It also took me some time to get familiar with it. It's also somewhat non-trivial to find out what the FreeBSD- specific things do. For example, environment? picks a string from the stack and searches for that name in an internal dictionary of environment attributes. It leaves the result of the attribute on the stack and true if found, otherwise false. So, for the arch-* attributes there are three possible results: false(not found) false true (found, value is false) true true(found, value is true) The attribute arch-pc98 is special: If it is set, it is always true, and all the other arch-* are not set: s arch-pc98 environment? -- true true s arch-i386 environment? -- false s arch-ia64 environment? -- false s arch-powerpc environment? -- false In all other cases (i.e. non-pc98), arch-pc98 is not set, and all the others are set to either true or false. For example, in the case of i386: s arch-pc98 environment? -- false s arch-i386 environment? -- true true s arch-ia64 environment? -- false true s arch-powerpc environment? -- false true I don't know why it is that way. That inconsistency makes if-branches somewhat more complicated. Another thing to keep in mind is that getenv leaves two values on the stack if the name was found (a Forth string consists of two values: the actual string and its length). If not found, only one value is left on the stack (-1). 2dup and 2drop are suitable for strings. Sadly, the sh_el not found error still continues with this code -- but it does fix the crashing I was seeing. I believe the problem is that constants cannot be put inside of a function (functions being runtime things, not compile-time things). Since the original code used compile-time conditions ([if], etc.), it meant that only one declaration for sh_el, sv_el, etc. was made. Maybe you should declare these as variables (outside of functions) instead of constants, and only assign to them within the functions. That should work. And so on, ditto with adding variable sh_el, variable sv_el and others to the very top of frames.4th. This actually fixed the not found error, and now I'm stuck with Error: compile only! being induced by the dup -1 = if line. if is for compile mode, and [if] is for immediate mode. If you're not in a function definition, then you're not in compile mode. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /boot/loader graphics support extensibility
Marcel Moolenaar wrote: On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote: Yes, that'll work well for putting characters on the screen. But I don't think it is suitable for generic graphics operations, even (and especially) for drawing single pixels. True. What do you envision? How generic do you think we should make it? For me the difference between an abstraction solely based on bitblt and an abstraction that includes a couple more primitives is minimal. The key aspect is that we should not have to duplicate 1000 lines of code, of which less than 10% deals with the hardware. This, for example, is a problem with syscons and the keyboard- and video switch interfaces. The keyboard switch interface alone has 18 functions That's a bad abstraction, nothing else. Yes, I'm aware of the problem. All the screenshots that I've made so far use only three functions: Displaying PCX images, printing characters, and drawing filled rectangles (e.g. to clear the screen or parts of it). That's not really much. I'm inclined to implement specialized versions of these functions for each of the bitmap formats, which is currently just two: 4bit planar (16 colors) and 8bit linear (256 colors). Currently I also have implemented several other functions such as line drawing, filled triangles, circles etc., but I'm not sure if it's worth keeping them. I'll have to think about it a bit more. At the moment I don't plan to support modes with more than 8 bits (but of course if someone else wants to do it, that would be fine with me). Typically you can dither truecolor images to 8 bit at very good quality (with gimp, imagemagick, netpbm, whatever), so there's no need for hicolor or truecolor modes. It should also be pointed out that there are a lot of variants of bitmap formats, and different graphics hardware supports different subset of these: 15 bit hicolor (5-5-5), 16 bit hicolor (5-6-5), 24 bit truecolor, 32 bit true- color, and each of these with different component orders (RGB or BGR), resulting in at least eight different formats. You have to support them all, which is somewhat complicated (although not difficult). The situation might be completely different on non-VGA hardware, of course. I'm sorry, I should have been clearer, that gfx_rect() function draws a filled rectangle. I see. In that case it's a single bitblt operation :-) But how would it work in reality? I guess you have something like this in mind; please correct me if I'm wrong: - The Forth code calls the rectangle function. - The hardware-independend gfx_rect function allocates a sufficiently large temporary memory buffer, then draws the rectangle into it. - Then it calls the hardware-dependent bitblt function, which copies the contents from the temporary buffer to the graphics frame buffer. There are two problems that I can see with that approach (not mentioning performance): First, what will be the bitmap format of the temporary memory buffer? The first possibility would be to make it the same as the graphics frame buffer, so the bitblt function would just have to shovel bits (except that it might have to shift bits if the buffer's contents don't happen to have the right alignment already). But then we need multiple rectangle functions, one for every bitmap format supported, so the abstraction doesn't really buy us much. The second possibility is to make the temporary buffer independent from the bitmap format of the graphics mode, i.e. use a fixed format. In order to be able to support truecolor modes, that fixed format would have to be a truecolor format, too. So then the rectangle function would draw a 24bit or 32bit truecolor rectangle (even if the graphics mode is only 4 bit), and the bitblt function would have to convert it back to the actual bitmap format of the graphics mode, possibly having to do palette lookups. That is horribly inefficient, and there's no easy way for optimizations. The second problem is that some graphics functions need to work with masks. For example, the function that prints a character is supposed to overlay the background, i.e. _not_ clear the rectangular area that the character occupies (this is to allow things such as ligatures, accent characters, shadow, bold and outline effects etc). So the bitblt function would have to take two input bitmaps (one being the pixel source and one being the mask) and perform the neccessary logical operations, in addition to the shifting (which also applies to the mask), format conversion, palette lookup, ... Sure, all of that could be implemented, but I fear that it would be much more complicated and bloated in the end. The current rectangle function for 4bit planar modes is about 15 lines of C code (not counting comments). The PCX display function is basically a straight-forward loop of about 20 lines of C code. That's not really a huge amount. And I have to confess that I don't think it's too
Re: cool feature of dmesg.boot file
Bartosz Giza wrote: I have found quite interesting feature on one of router that lately i have taken to administer. What i knew was that file /var/run/dmesg.boot holds data from kernel buffer that is taken right after file system(s) are mounted. Lately i have found that one router writes to this file data from kernel buffer when system is going to reeboot. Below are few lines from this file. What you can see are lines from kernel right before reeboot. I have never seen before such lines in this file. And this is quite interesting. Could anyone tell me how can i achieve such funcionality on other systems ? I have tried to find on google about this but i couldn't find anything similar to this. Upon a reboot, the kernel is usually loaded to the same physical addresses in RAM where it was before, so the dmesg buffer will be at the same location, too (unless you built a new kernel, of course). So all the contents from before reboot are still there -- *IF* the system BIOS didn't clear the RAM. Then the old contents will end up in /var/run/dmesg.boot, too. You could try looking at your BIOS setup. Some have an option called Quick POST or similar. If you enable it, the BIOS will skip the RAM test (which is rather useless anyway) which clears the RAM. It might help, but it depends very much on your mainboard and BIOS. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cool feature of dmesg.boot file
Jeremy Chadwick wrote: Oliver Fromme wrote: Upon a reboot, the kernel is usually loaded to the same physical addresses in RAM where it was before, so the dmesg buffer will be at the same location, too (unless you built a new kernel, of course). So all the contents from before reboot are still there -- *IF* the system BIOS didn't clear the RAM. Then the old contents will end up in /var/run/dmesg.boot, too. You could try looking at your BIOS setup. Some have an option called Quick POST or similar. If you enable it, the BIOS will skip the RAM test (which is rather useless anyway) which clears the RAM. It might help, but it depends very much on your mainboard and BIOS. There is also kern.msgbuf_clear. However, this is a sysctl, which means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output after the OS had started. Bummer. It would be useful if there was a loader.conf variable which was the equivalent of msgbuf_clear. In fact, I'm wondering why the message buffer isn't cleared on shutdown/immediately prior to reboot... So you can see panic messages and other useful things that happened before the reboot. It's a _feature_, not a bug. Interesting tidbit: We have one production machine which when booted into single-user via serial console for a world install, retains all of the output from that single-user session even once rebooted and brought back into multi-user mode. This poses a substantial security risk, especially during the mergemaster phase (we can discuss why if anyone is curious). sysctl security.bsd.unprivileged_read_msgbuf=0 Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cool feature of dmesg.boot file
Jeremy Chadwick wrote: Oliver Fromme wrote: [...] Either way, it's a feature with major security implications. So, for those of us who are concerned about master.passwd changes via mergemaster being stuffed into msgbuf, how do we disable said feature? (Before answering, see below as well). sysctl security.bsd.unprivileged_read_msgbuf=0 No can do -- we have many users who look at dmesg for a reason: logging of coredumped binaries (kern.logsigexit=1), and if there were any signs of disk or network issues during that time. I've tried using that in the past and got significant flack from our userbase. If you'd like, I can have them chime in on this thread as validation. Using security.bsd.unprivileged_read_msgbuf=0 to solve said concern is an ineffective workaround in our case. I'm willing to bet others feel the same way. Personally I think that normal users shouldn't need to be able to see the kernel's message buffer. Of course there are certainly people who disagree. :-) How about allowing people access to /var/log/messages (it's world-readable by default). The kernel's messages such as signal exits will be there, too. It's much more useful anyway because it has timestamps, unlike dmesg. Of course you would have to set kern.log_console_output=0 so the mergemaster session does not get logged. By the way, it's possible to tell mergemaster to ignore master.passwd in single user mode on the console so it won't turn up at all. You can merge any changes that are necessary by running mergemaster -p before going to single-user mode. That's what I usually do. Maybe I should look into writing a patch that does in fact clear the buffer immediately before reboot, and tie it to a sysctl. Well, you could simply type sysctl kern.msgbuf_clear=1 right before you reboot. Or make a wrapper script for reboot (or a shell alias) so you don't have to remember. If you insist on writing a patch, then please make it default off. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code (taken from comp.lang.awk FAQ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /boot/loader graphics support extensibility
priority. I want to get the basic functionality done which will work with standard VGA and nothing else. There will be no VESA support at the beginning, or anything else. It's on my to-do list, but with lower priority. But I need to keep all those future enhancements in mind, even if they're not first priority, or otherwise it might become more difficult later on to add those features. I also want to avoid breaking the syntax of FICL words once they're established. That's why I have to think about all that now. The graphics world is one with many pitfalls, obstacles and controversies. I think it's best to get something basic off the ground first. I agree. Absolutely. I think performance is not a concern. Once you have the basic functionality, you'll also have a wishlist of things you want to do better; performance one of them in all likelyhood. Performance isn't my highest priority, but not the lowest either. I try to do things in a way so that they're not horribly inefficient. At the very least I try to do it in a way so that they can be made more efficient easily. I think we're finally moving into the 20th century :-) Even the 21st, I hope. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
