Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Alexander Leidinger alexan...@leidinger.net writes: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. [...] Index: kern/kern_dtrace.c [...] +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + [...] Index: kern/kern_lockstat.c [...] +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); Why description differs? ___ 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: broken INCLUDE in sys/conf/kern.pre.mk for opensolaris code?
Alexander Best arun...@freebsd.org writes: On Wed Feb 2 11, Anonymous wrote: -Wmissing-include-dirs (with -Werror) is there to catch such cases. Try to add it to CWARNFLAGS and see if universe build passes. Note, clang doesn't support it and it's broken in our gcc but there is a simple fix, unfortunately, under gplv3. could you point me to that gcc gplv3 fix? I can't reproduce the bug on /head anymore, e.g. unlike on 8.2-RC2. http://docs.freebsd.org/cgi/mid.cgi?20081021054625.GA66977 ___ 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: broken INCLUDE in sys/conf/kern.pre.mk for opensolaris code?
Alexander Best arun...@freebsd.org writes: On Wed Feb 2 11, Sergey Kandaurov wrote: On 6 January 2011 04:40, Alexander Best arun...@freebsd.org wrote: hi there, while building target buildkernel with 'clang -v' i noticed a lot of these lines: ignoring nonexistent directory /usr/subversion-src/sys/contrib/opensolaris/compat i checked sys/conf/kern.pre.mk and there's a line refering to a non-existing directory: # ... and OpenSolaris INCLUDES+= -I$S/contrib/opensolaris/compat Hi, I just removed that path in r218189. thanks a bunch. :) i might do a 'make universe' build at some point with clang -v in order to check, if there are more cases where non-existing include paths exist in the freebsd src. -Wmissing-include-dirs (with -Werror) is there to catch such cases. Try to add it to CWARNFLAGS and see if universe build passes. Note, clang doesn't support it and it's broken in our gcc but there is a simple fix, unfortunately, under gplv3. ___ 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: What does the FreeBSD/i386 ABI say about stack alignment?
Alexander Best arun...@freebsd.org writes: otaku% ./mplayer ~/filme/wiedhow.mkv MPlayer SVN-r32787-4.6.0 (C) 2000-2011 MPlayer Team 161 audio 350 video codecs Playing /home/arundel/filme/wiedhow.mkv. zsh: illegal hardware instruction (core dumped) ./mplayer ~/filme/wiedhow.mkv otaku% echo $? 132 just wanted to report that the issue i was having with mplayer vanished. so it seems this was in fact a bug in mplayer itself. Did you update lang/gcc46 recently? I've seen many similar bugs on *the* devel branch of GCC, i.e. gcc46 and before 4.5.0 release on gcc45. ___ 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: getting a list of open files versus PID nos.?
Bruce Cran br...@cran.org.uk writes: On Wed, 8 Dec 2010 14:54:57 -0800 Matthew Fleming mdf...@gmail.com wrote: This is what lsof is for. I believe there's one in ports, but I have never tried it. Is there any advantage to using lsof instead of fstat(1) (fstat -p pid)? procstat(1) can display actual files instead of inodes, e.g. $ procstat -f $(pgrep qemu) PID COMM FD T V FLAGSREF OFFSET PRO NAME 14300 qemu-system-x86_64 cwd v d - - - /home/holo 14300 qemu-system-x86_64 root v d - - - / 14300 qemu-system-x86_640 v c rw-- 6 3247126 - /dev/pts/4 14300 qemu-system-x86_641 v c rw-- 6 3247126 - /dev/pts/4 14300 qemu-system-x86_642 v c rw-- 6 3247126 - /dev/pts/4 14300 qemu-system-x86_643 p - rw---n-- 1 0 - - 14300 qemu-system-x86_644 p - rw---n-- 1 0 - - 14300 qemu-system-x86_645 v r rw--f--- 1 4294967296 - /b/blah.img 14300 qemu-system-x86_646 p - rw---n-- 1 0 - - 14300 qemu-system-x86_647 p - rw---n-- 1 0 - - 14300 qemu-system-x86_648 v r r---f--- 1 283918336 - /b/netbsd-amd64cd-201012060900Z.iso 14300 qemu-system-x86_649 s - rw---n-- 1 0 TCP ::. ::.0 14300 qemu-system-x86_64 10 s - rw---n-- 1 0 TCP :::127.0.0.1. :::127.0.0.1.26806 ___ 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: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc
Alexander Best arun...@freebsd.org writes:
diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc
index e358ed9..106c10e 100644
--- a/ObsoleteFiles.inc
+++ b/ObsoleteFiles.inc
@@ -13,6 +13,12 @@
#
# The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last.
#
+# Before you commit changes to this file please check, if any entries in
+# tools/build/mk/OptionalObsoleteFiles.inc can be removed. The following
+# command was proposed by Dmitry Morozovsky:
+# ( grep '+=' /usr/src/ObsoleteFiles.inc | sort -u ; \
+# grep '+=' /usr/src/tools/build/mk/OptionalObsoleteFiles.inc | sort -u) | \
+# sort | uniq -d
An easier way to check duplicates that understands `.if ${TARGET_ARCH}...'
$ make -V OLD_FILES -V OLD_LIBS -V OLD_DIRS \
-f Makefile.inc1 check-old \
| sed 'y/ /\n/' | sort | uniq -d
And there are a number of false positives
usr/include/c++/3.4/ext/demangle.h
usr/include/rune.h
usr/lib/libkse.so.1
usr/lib/libpcap.so.3
usr/lib/snmp_atm.so.3
usr/lib/snmp_mibII.so.3
usr/lib/snmp_netgraph.so.3
usr/lib/snmp_pf.so.3
usr/share/man/man3/exp10.3.gz
usr/share/man/man3/exp10f.3.gz
usr/share/man/man3/fgetrune.3.gz
usr/share/man/man3/fpsetsticky.3.gz
usr/share/man/man3/fputrune.3.gz
usr/share/man/man3/fungetrune.3.gz
usr/share/man/man3/gss_krb5_compat_des3_mic.3.gz
usr/share/man/man3/gss_krb5_copy_ccache.3.gz
usr/share/man/man3/mac_is_present_np.3.gz
usr/share/man/man3/mbmb.3.gz
usr/share/man/man3/mbrrune.3.gz
usr/share/man/man3/mbrune.3.gz
usr/share/man/man3/rune.3.gz
usr/share/man/man3/setinvalidrune.3.gz
usr/share/man/man3/setrunelocale.3.gz
usr/share/man/man3/sgetrune.3.gz
usr/share/man/man3/sputrune.3.gz
___
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: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc
Anonymous swel...@gmail.com writes:
Alexander Best arun...@freebsd.org writes:
diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc
index e358ed9..106c10e 100644
--- a/ObsoleteFiles.inc
+++ b/ObsoleteFiles.inc
@@ -13,6 +13,12 @@
#
# The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last.
#
+# Before you commit changes to this file please check, if any entries in
+# tools/build/mk/OptionalObsoleteFiles.inc can be removed. The following
+# command was proposed by Dmitry Morozovsky:
+# ( grep '+=' /usr/src/ObsoleteFiles.inc | sort -u ; \
+# grep '+=' /usr/src/tools/build/mk/OptionalObsoleteFiles.inc | sort -u) | \
+# sort | uniq -d
An easier way to check duplicates that understands `.if ${TARGET_ARCH}...'
$ make -V OLD_FILES -V OLD_LIBS -V OLD_DIRS \
-f Makefile.inc1 check-old \
| sed 'y/ /\n/' | sort | uniq -d
Nevermind. It's more important to check OptionalObsoleteFiles.inc when
files are re-introduced and thus removed from ObsoleteFiles.inc.
___
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
rtld + gold linker, cannot find entry symbol lf; defaulting to 00000000000034d0
I'm trying to compile dynamic linker with `gold' linker.
During build with normal ld(1) there is a warning
cc [...] -elf -o ld-elf.so.1
LOCALBASE/bin/ld: warning: cannot find entry symbol lf; defaulting to
34d0
While it doesn't seem to affect `ld' it does for `gold'. The binary produced
by `gold' segfaults, e.g.
# from /h...@215110
Core was generated by `sh'.
Program terminated with signal 11, Segmentation fault.
#0 .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33
33 xorq%rbp,%rbp # Clear frame pointer for
good form
(gdb) bt
#0 .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33
#1 0x0001 in ?? ()
#2 0x7fff0fe0 in ?? ()
#3 0x in ?? ()
So, is `-elf' intended or it can be removed?
%%
diff --git a/libexec/rtld-elf/amd64/Makefile.inc
b/libexec/rtld-elf/amd64/Makefile.inc
index b265a9d..4ecf82f 100644
--- a/libexec/rtld-elf/amd64/Makefile.inc
+++ b/libexec/rtld-elf/amd64/Makefile.inc
@@ -1,7 +1,5 @@
# $FreeBSD$
-CFLAGS+= -elf
-LDFLAGS+= -elf
# Uncomment this to build the dynamic linker as an executable instead
# of a shared library:
#LDSCRIPT= ${.CURDIR}/${MACHINE_CPUARCH}/elf_rtld.x
diff --git a/libexec/rtld-elf/i386/Makefile.inc
b/libexec/rtld-elf/i386/Makefile.inc
index b265a9d..4ecf82f 100644
--- a/libexec/rtld-elf/i386/Makefile.inc
+++ b/libexec/rtld-elf/i386/Makefile.inc
@@ -1,7 +1,5 @@
# $FreeBSD$
-CFLAGS+= -elf
-LDFLAGS+= -elf
# Uncomment this to build the dynamic linker as an executable instead
# of a shared library:
#LDSCRIPT= ${.CURDIR}/${MACHINE_CPUARCH}/elf_rtld.x
%%
___
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: [PATCH] update to the latest libedit version and remove libreadline deps
Anonymous swel...@gmail.com writes:
Anonymous swel...@gmail.com writes:
Baptiste Daroussin b...@freebsd.org writes:
[...]
You can find the patch against current here:
http://people.freebsd.org/~bapt/update-libedit.patch
$ make depend
/usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/vi.c vi.h.tmp
mv vi.h.tmp vi.h
/usr/src/lib/libedit/makelist: Permission denied
*** Error code 126
I guess HOST_SH is defined by build.sh on NetBSD.
libgdb doesn't build, too
Aww, a few more changes were needed to make buildworld happy.
%%
Index: ObsoleteFiles.inc
===
--- ObsoleteFiles.inc (revision 214854)
+++ ObsoleteFiles.inc (working copy)
@@ -14,6 +14,36 @@
# The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last.
#
+# : readline removed, ports should use devel/readline ;)
+OLD_FILES+=usr/include/readline/chardefs.h
+OLD_FILES+=usr/include/readline/keymaps.h
+OLD_FILES+=usr/include/readline/rlconf.h
+OLD_FILES+=usr/include/readline/rlstdc.h
+OLD_FILES+=usr/include/readline/rltypedefs.h
+OLD_FILES+=usr/include/readline/tilde.h
+OLD_FILES+=usr/lib/libhistory.a
+OLD_FILES+=usr/lib/libhistory_p.a
+OLD_FILES+=usr/lib/libreadline.a
+OLD_FILES+=usr/lib/libreadline_p.a
+OLD_FILES+=usr/share/info/history.info.gz
+OLD_FILES+=usr/share/info/readline.info.gz
+OLD_FILES+=usr/share/info/rluserman.info.gz
+OLD_FILES+=usr/share/man/man3/readline.3.gz
+OLD_FILES+=usr/share/man/man3/rlhistory.3.gz
+OLD_LIBS+=lib/libreadline.so.8
+OLD_LIBS+=usr/lib/libhistory.so
+OLD_LIBS+=usr/lib/libhistory.so.8
+OLD_LIBS+=usr/lib/libreadline.so
+.if ${TARGET_ARCH} == amd64
+OLD_FILES+=usr/lib32/libhistory.a
+OLD_FILES+=usr/lib32/libhistory_p.a
+OLD_FILES+=usr/lib32/libreadline.a
+OLD_FILES+=usr/lib32/libreadline_p.a
+OLD_LIBS+=usr/lib32/libhistory.so
+OLD_LIBS+=usr/lib32/libhistory.so.8
+OLD_LIBS+=usr/lib32/libreadline.so
+OLD_LIBS+=usr/lib32/libreadline.so.8
+.endif
# 20101101: headers moved to machine/ to x86/
.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == i386
OLD_FILES+=usr/include/machine/apicreg.h
Index: contrib/gdb/gdb/cli/cli-cmds.c
===
--- contrib/gdb/gdb/cli/cli-cmds.c (revision 214854)
+++ contrib/gdb/gdb/cli/cli-cmds.c (working copy)
@@ -21,7 +21,6 @@
#include defs.h
#include readline/readline.h
-#include readline/tilde.h
#include completer.h
#include target.h /* For baud_rate, remote_debug and remote_timeout */
#include gdb_wait.h /* For shell escape implementation */
Index: contrib/gdb/gdb/cli/cli-setshow.c
===
--- contrib/gdb/gdb/cli/cli-setshow.c (revision 214854)
+++ contrib/gdb/gdb/cli/cli-setshow.c (working copy)
@@ -18,7 +18,6 @@
Boston, MA 02111-1307, USA. */
#include defs.h
-#include readline/tilde.h
#include value.h
#include ctype.h
#include gdb_string.h
Index: contrib/gdb/gdb/event-top.c
===
--- contrib/gdb/gdb/event-top.c (revision 214854)
+++ contrib/gdb/gdb/event-top.c (working copy)
@@ -34,7 +34,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/top.c
===
--- contrib/gdb/gdb/top.c (revision 214854)
+++ contrib/gdb/gdb/top.c (working copy)
@@ -48,7 +48,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/tracepoint.c
===
--- contrib/gdb/gdb/tracepoint.c(revision 214854)
+++ contrib/gdb/gdb/tracepoint.c(working copy)
@@ -45,7 +45,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/tui/tui-io.c
===
--- contrib/gdb/gdb/tui/tui-io.c(revision 214854)
+++ contrib/gdb/gdb/tui/tui-io.c(working copy)
@@ -397,8 +397,6 @@ static void
tui_rl_display_match_list (char **matches, int len, int max)
{
typedef int QSFUNC (const void *, const void *);
- extern int _rl_qsort_string_compare (const void*, const void*);
- extern int _rl_print_completions_horizontally;
int count, limit, printed_len;
int i, j, k, l;
Index: gnu/lib/Makefile
===
--- gnu/lib/Makefile(revision 214854)
+++ gnu/lib/Makefile(working copy)
@@ -2,7 +2,7 @@
.include bsd.own.mk
-SUBDIR= csu libgcc libgcov libdialog libgomp libregex libreadline libssp
+SUBDIR= csu libgcc libgcov libdialog libgomp libregex libssp
# libsupc++ uses
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
Devin Teske dte...@vicor.com writes:
GLOBALS
# Global exit status variables
: ${SUCCESS:=0}
: ${FAILURE:=1}
Should this really be set to something other than 0 or 1 by the
end-user's environment? This would simplify a lot of return/exit
calls...
A scenario that I envision that almost never arises, but...
Say someone wanted to call my script but wanted to mask it to always return
with success (why? I dunno... it's conceivable though).
Example: (this should be considered ugly -- because it is)
FAILURE=0 sysrc foo reboot
Wouldn't this bork functions used inside a conditional?
: ${FAILURE:=1}
foo() { return ${FAILURE-1}; }
if ! foo; then
echo good
else
echo error
fi
$ test.sh
good
$ FAILURE=0 test.sh
error
I think only sysrc_set() is affected, though.
if sysrc_set $NAME ${1#*=}; then
echo - $( sysrc $NAME )
fi
$ sysrc hostname=blah
hostname: raphael.local
sysrc: cannot create /etc/rc.conf: permission denied
$ FAILURE=0 sh sysrc hostname=blah
hostname: raphael.local
sysrc: cannot create /etc/rc.conf: permission denied
- raphael.local
___
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: tiny patch to prevent head from closing pipes
Alexander Best arun...@freebsd.org writes: hi there, i just had subversion complain about a broken pipe while piping its output through awk straight to head [1]. i decided to add a switch to head which will tell it to never close a pipe unless the input has stopped [2]. You can do same with sh(1), e.g. $ svn log | (IFS=; while read li; do [ $((i+=1)) -le 10 ] echo $li; done) versus $ svn log | (IFS=; while read li [ $((i+=1)) -le 10 ]; do echo $li; done) ... svn: Write error: Broken pipe But I think subversion should there's probably a much more efficient way of discarding the input without closing the pipe unless the input ceased. it's just a 5 minute hack in order to see if people find the idea useful or not. ;) Can you give an example of usefulness that does not involve subversion? ___ 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: tiny patch to prevent head from closing pipes
Anonymous swel...@gmail.com writes: Alexander Best arun...@freebsd.org writes: hi there, i just had subversion complain about a broken pipe while piping its output through awk straight to head [1]. i decided to add a switch to head which will tell it to never close a pipe unless the input has stopped [2]. You can do same with sh(1), e.g. $ svn log | (IFS=; while read li; do [ $((i+=1)) -le 10 ] echo $li; done) Hmm, draining pipe with cat(1) would be more efficient $ svn log | (IFS=; while read li [ $((i+=1)) -le 10 ]; do echo $li; done; cat /dev/null) ___ 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: intel i5 - core? or core2?
Domagoj S. rank1see...@gmail.com writes:
8.1 RELEASE 32bit
# gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
As per: http://gcc.gnu.org/gcc-4.2/changes.html
core2 is supported
It's not! `core' and `core2' for -mtune/-march introduced since gcc43.
$ echo 'int main(){}' | gcc -xc - -o/dev/null -march=core
:1: error: bad value (core) for -march= switch
:1: error: bad value (core) for -mtune= switch
$ echo 'int main(){}' | gcc -xc - -o/dev/null -march=core2
:1: error: bad value (core2) for -march= switch
:1: error: bad value (core2) for -mtune= switch
Setting CPUTYPE to `core2' on amd64 will only add `sse3' to MACHINE_CPU,
even when the underlying compiler/assembler actually supports more
features, e.g. ssse3, sse4.1, etc., cf. conf/112997.
BTW, while clang in base (on /head) supports -march=core2 it's still
better to stick to -march=native, e.g. on my box
CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3177.07-MHz K8-class
CPU)
`native' on clang implies `penryn', not a `core2'. While `native' on
gcc45 implies `core2' + extra cflags[1].
[1] -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=6144
Setting CPUTYPE(for i386) to: nocona, core or core2, will at
the end, ALWAYS set CPUTYPE to: prescott, which again results in
set:
MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386
You can populate MACHINE_CPU directly, e.g.
CPUTYPE ?= native
MACHINE_CPU != echo ${MACHINE_ARCH}; ${CC} -E -dM -v -march=${CPUTYPE} -
/dev/null 21 \
| awk '/SSE|MMX/ !/MATH/ { FS=__; gsub(_,.,$$2); print
tolower($$2) }'
MACHINE_CPU += i486 i586 i686
Note sure how well it'll work for cross-arch compilation, though.
CPUTYPE?=native is nowhere mentioned in FreeBSD
That cruft in bsd.cpu.mk was written in pre-gcc4 days, i.e. when it
didn't support -march=native. Besides, if not maintained to accommodate
for newer gcc's from ports those aliases are more harmful than
useful. And not much code uses MACHINE_CPU in base anyway, only
libcrypto and libz.
___
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: intel i5 - core? or core2?
Atom Smasher a...@smasher.org writes: hardware: MACH: x86_64 (LENOVO, 4313CTO, ThinkPad T510) CPU: x86_64 (Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz) FreeBSD 8.1-RELEASE #0 (amd64) in /etc/make.conf i tried setting CPUTYPE=core but as soon as i start building things, lang/perl5.10 fails, complaining about core not being right. when i change the setting to CPUTYPE=core2 it builds fine. I'd suggest using CPUTYPE?=native and let the compiler decide what's best. Our pretty old gcc in base supports neither `core' nor `core2'. The `core2' is just an alias for `nocona'/`prescott' for amd64/i386. And `core' alias is available only for i386, cf. bsd.cpu.mk. is something wrong? i thought the i5 was core, not core2...? ___ 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: [PATCH] allow empty files creation with install
joris dedieu joris.ded...@gmail.com writes: This patch add a -t switch to install(3). This is a small feature for lazy sysadmins. before : touch /usr/home/foo/.history /usr/home/foo/.bash_history chown foo /usr/home/foo/.history /usr/home/foo/.bash_history chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history for f in .history .bash_history; do install -o foo -g foo -m 600 -f sappend /dev/null /usr/home/foo/$f done after : install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history /usr/home/foo/.bash_history Your example doesn't use `-t' option. ___ 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 way too slow
Atom Smasher a...@smasher.org writes:
http://smasher.org/tmp/zsh-bsd-sysctl-slow.png
is there a way to get this information that doesn't take so long?
If you only need sysctl values for fancy prompt then cache them inside
variables, e.g.
PROMPT='($hw_acpi_battery_life, $hw_acpi_battery_time,
$hw_acpi_battery_state) %# '
PERIOD=30
setopt promptsubst
periodic_functions+=(sysctl-to-var)
sysctl-to-var() {
set -- hw.acpi.battery.
for i in $(sysctl -N $@); do
eval ${i:gs/./_/:gs/%//}='$(sysctl -n $i)'
done
}
To not pollute global scope using one associative array for sysctls may
be better.
the same info is available on linux via /sys and /proc and on
comparable hardware, i can get the info about 100x faster.
thanks...
___
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: restricted kernel threads implementation from NetBSD via n
On 28-Jun-99 Matthew Dillon wrote: I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. I don't suppose someone could post an explanation of how kernel threads work could they? :) I sort of grasp the idea but I'm wondering what passes for context switches and stuff like that.. What does the switching between threads etc? Or am I completely off track? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: restricted kernel threads implementation from NetBSD via newconfig
In message [EMAIL PROTECTED] Julian Elischer writes: : now this is threads within the kernel, and not kernel support for user : threads right? Yes. That's right. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
On Mon, 28 Jun 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... To be more precise, it should be more like a rfork() like thing that doesn't change any resources except the stack, a process structure and processor context. Specifically, processor VMspace is basically left at whatever it is already at, and there is no 'signal' stuff or file descriptor table munging. We might even allow the MMU to be left unchanged too. julian Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel J. O'Connor" writ es: : I don't suppose someone could post an explanation of how kernel threads wor k : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner When I looked last time, it was effectively a callable interface to what we do from SYSINIT_KT(), ie: fork proc0, which runs in kernel space with it's own stack etc. kthread_create_deferred() is not really anything to do with those sort of threads. It's just a generic callback registration system that happens to be called after the basic processes have started so that proc0,1,2 etc are not disturbed. It's similar to the config_intrhook() stuff but is run later. You can probably cut/paste our SYSINIT_KT() code into some compatable function interfaces pretty easily to avoid yet another new file. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999, Matthew Dillon wrote: : it is extremely memory efficient. : :I guess you are talking about VMIO buffers where the pages are found and :registered into the buffer header during allocbuf(). When we do I/O on :VMIO buffers using conventional system call method, we specify UIO_NOCOPY :to instruct the uiomove() do not perform data copy. UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM interaction for I/O, it has nothing to do with the read() or write() syscall per say, nor is it related to the mmap code. : Programmers who use mmap() expect it to be as close to optimal as : possible. : :I write a program to test the mmap() today. It turns out that a user can :modify the part of the mmapped area that is within the system returned :area but not part of the user-specified area. : :As I understand it, there are two access paths to a file: conventional I/O :through read/write systems calls and memory-mapped I/O. Both of them :converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). :This should give us the opportunity to guard against illegal memory-mapped :I/O writes made by the user. They converge in the VMIO page cache. By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() and VOP_WRITE() just as read() and write() system call. :Maybe we can add some fields in the vm_object to record the real or :user-specifed area which can be passed to the vnode read and write :routine. In the vnode I/O routine, we should be able to limit the write to :only the orginal part of the area specified by the user. This practice :should not incur any performance loss. : :-Zhihui mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. This is a good point! I have never thought of it before. Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. Well, if you make a VM object map-entry-specific (not just "process-specific"; a single process may have multiple mappings of a file!), then the pages *can't* be shared, because pages are owned by the objects. The only reason you can share pages is because multiple map entries may reference the same object (the offset into the object being map-entry-specific). Put another way, it's not possible for this sentence to be true, at all: What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. ...since the presence of map-entry-specific objects would make the pages also map-entry-specific by definition. This, of course, would mean that VM objects themselves serve no purpose, so you could collapse it into "pages are owned by VM map entries", and do away with objects completely. However, that would be stupid. Anyhow, it's possible to have the semantics Zhihui suggested, but you have to give up an awful lot to get them. :-) -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
:Well, if you make a VM object map-entry-specific (not just "process-specific"; :a single process may have multiple mappings of a file!), then the pages :*can't* be shared, because pages are owned by the objects. The only reason :you can share pages is because multiple map entries may reference the same :object (the offset into the object being map-entry-specific). : :Put another way, it's not possible for this sentence to be true, at all: : : What you propose will not work because even if the VM object is : process-specific, the pages underlying the VM object are not. There's missing information. Remember that VM objects are recursive. That is, they stack in layers. So, in fact, you are sharing the same physical page for both a PRIVATE and SHARED mmap. A copy only occurs if you attempt to modify a page in a PRIVATE mmap. The underlying VM object is, ultimately, the file itself. That's what I meant. You are absolute correct about the high-level mapping occuring in the map-entry. For a shared map it is ultimately the same VM object. :This, of course, would mean that VM objects themselves serve no purpose, so :you could collapse it into "pages are owned by VM map entries", and do away :with objects completely. : :However, that would be stupid. : :Anyhow, it's possible to have the semantics Zhihui suggested, but you have to :give up an awful lot to get them. :-) : :-- Jason R. Thorpe [EMAIL PROTECTED] It really isn't possible without creating massive inefficiencies. It would be possible in a MULTICS system, but not in a UNIX system and not with most modern processors ( which do not have byte resolved variable-length page maps ). Not efficiently, anyway. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
: :By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() :and VOP_WRITE() just as read() and write() system call. Yes, but what they are doing is mapping the VMIO cache pages into the buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the VMIO cache pages. This is why NOCOPY is set -- because there is no need to copy the data from the buffer to the VMIO cache because the buffer IS the VMIO cache at that point in time. Confusing, eh? A normal read() or write() syscall always copies the data, because the uio buffer in that case is not VMIO cache but instead some location in the processor's memory. Even if this location were associated with an mmap(), it would almost certainly be to a different file so the copy must occur anyway. A lot of the apparent confusion in the code is due to the fact that the code did not originally implemented a unified buffer cache. It is being slowly cleaned up. :-Zhihui -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RPLd or rplboot
Has anyone ever seen an open implementation of RPL, remote program load ? Or at paper specification of it against which one could write such a beast ? http://www.freebsd/org/~msmith/documents/RPL BTW, did you get your box? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tuesday, 29 June 1999 at 12:18:07 +1000, Patryk Zadarnowski wrote: I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an "optional extension". I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? I'll sniff around and get back to you (read: I'll ask our local guru on PDP-11's and other ancient rituals, who told me about those in the first place.) l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Greg Lehey wrote: This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an "optional extension". I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. man 3 exec, I think. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I know about envp. What I want to know is the exact position of these variables on the stack. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. amol On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) In a nutshell, it appears to basically do an rfork. It then becomes like any other process that is interrupted in the kernel... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Connect and so on..
On Fri, 25 Jun 1999, Mike Smith wrote: static struct sockaddr_in servaddr; This needs to be a valid structure in USER space, not kernel. OK. I suspected as much. Question is: how do I open a connection from KERNEL space? You don't. If you're really desperate to do this, you'll have to patch _all_ of the system calls to work out whether they're being called from the kernel or from userspace. There's actually a lot of utility in this, as it makes calling them easier from ABI modules as well. If you're looking for a nice, relatively easy FreeBSD hacking project, there's one right there. Another argument to the syscall format... I remember we took the retval away (stuck it in proc) and now we could replace it with that. That's beside the point. He doesn't need to initiate the connection in userland, just pass in the context (user-space sockaddr_in) for it to use. The other mistake is he thinks this will make the whole thing atomic... I'm not so sure about that one. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote: And they are going to scream like mad if there isn't any. But in the end they start reading the code anyway, even if there is docu, because they don't trust anything but their own eyes and brain. ports system == really really large documentation about ports system == really really large (relatively) Anything else? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
As Matthew Jacob wrote ... Yes, you want the WWN to stay constant. That doesn't mean it should necessarily be the same physical box. Nor does it mean it should be a system that comes with a WWN assigned to by the manufacturer. Manufacturers have to register and 'get' a unique range they can assign to their products. How do you guarantee that your homegrown WWN is really unique? I think I'm confusing myself and people. I have a WWN. By definition it should be unique value. All I'm asking for is a kernel function to help me generate such a thing (despite what Eduardo says). On Fri, 25 Jun 1999, Wilko Bulte wrote: As Matthew Jacob wrote ... FYI: The Compaq HSG80 Fibrechannel RAID controllers have their WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet* into the HSG controller. This allows for easy hardware swap in case of hardware grief. Yes, if you want the WWN to stay constant. Well, you do. Especially when you are using things like zoning (like that Brocade switches can do) or when the host directly ties things to the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters that allow things like "target=foo lun=bar www="64bitnumber" in the Solaris /kernel/drv/sd.conf file And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
On Sat, 26 Jun 1999, Wilko Bulte wrote: As Matthew Jacob wrote ... Yes, you want the WWN to stay constant. That doesn't mean it should necessarily be the same physical box. Nor does it mean it should be a system that comes with a WWN assigned to by the manufacturer. Manufacturers have to register and 'get' a unique range they can assign to their products. How do you guarantee that your homegrown WWN is really unique? Witha a value in the top 4 bits that's not one of the currently defined authoritative values. I think I'm confusing myself and people. I have a WWN. By definition it should be unique value. All I'm asking for is a kernel function to help me generate such a thing (despite what Eduardo says). On Fri, 25 Jun 1999, Wilko Bulte wrote: As Matthew Jacob wrote ... FYI: The Compaq HSG80 Fibrechannel RAID controllers have their WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet* into the HSG controller. This allows for easy hardware swap in case of hardware grief. Yes, if you want the WWN to stay constant. Well, you do. Especially when you are using things like zoning (like that Brocade switches can do) or when the host directly ties things to the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters that allow things like "target=foo lun=bar www="64bitnumber" in the Solaris /kernel/drv/sd.conf file And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. You can boot off of fibre channel now- but not using a WWN. I want to see devfs fixed and using WWWs and/or device VPD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:00:41PM -0700, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. There is still one big problem left when the number of cylindergroups went over a usually 512 align. I hope to free enough time during the next weeks to remove some blocks and add some warnings in this case. With this problem you should check manualy for that condition because it will break the fs in such cases. All bugs should have been documented in the man-page. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Implementation of mmap() in FreeBSD
From the source code of mmap(), it seems to me that FreeBSD can not handle mmap() when the specified file range [offset, offset + length] does not align with memory page boundary. The mmap() automatically enlarges the mapped area on BOTH ends of the given range to a page boundary. In the following figure, the two X areas are not specified by the user, they are included because we do rounding on both ends. +---+--+-+-+ | X | | | X | +---+--+-+-+ ^ ^ ^ | | | page boundary page boundary page boundary Then a problem is what will happen if I read/write at the areas marked as X? What will happen if I write into the area marked by the right X and that area lies beyond the end of the file? According to the book by W. Richard Stevens, if we write to the area marked by the right X, the changes should not be reflected in the file (or expand the file). All these situations seem to me are not handled by FreeBSD mmap() code. I hope I am wrong. I also wonder why we can not add some information to the backing object, so that we can handle these situations. If these problems do exist, how hard it is to fix them? Any help or hint is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
Really? Couldn't the Port WWN change and the Node WWN stay constant? I mean, yes, for FC controllers that have WWN in the 0x2 range, the Node WWN is 0x20... and the Port is 0x22... but it seems like this is a soft relationship- you *could* have Port Node unique for each card, but then that requires all fabric clients to know (via some other arbitrary mechanism) that distinct WWNs are really the same 'box'. Existing FC RAID boxes have multiple controllers, each with a different WWN. The port WWN is derived from the Node WWN. The Node WWN is in the controller's PROM. In theory, when you swap one controller, the other controller could remember the old node WWN and give it to the new controller, but: If you swap both controllers, who's going to remember the old node WWNs? If you pull one controller from one box and stick it into another box, then plug in a replacement controller into the first box, if the replacement controller takes over the previous WWN, you could end up with two different devices with the same WWN. I agree that this would be chaos, but you're using implementation to argue architecture. I'm thinking of a SANs of FreeBSD/NetBSD/Linux/Solaris boxes running simultaneous target/initiator mode on Fibre Channel. I can use WWN info wired into a specific card (whether it's the Port or Node WWN is solely at my discretion when I fire up the f/w and tell it what it it is), or I can choose something different entirely as the source of a WWN. As long as it's guaranteed unique in this domain, it's an acceptable design. Sure. That's reasonable enough, but not necessarily a problem that needs solving. The LUN isn't interesting in that what you want a known Node WWN for (routed to via multiple Port WWNs) so that when you construct the addressing to some physical box you, and intervening FC switches, can get the frame there. Beyond that, multilevel LUN numbers seem adequate for *within box* addressing, and then whatever volume management software needs to look at Thing is, the LUN is reachable through both controllers, each has a different Node (and port) WWN. The FCP protocol layer should be addressing these entities by LUN WWN. This means that it is responsible for identifying the individual entities and establishing the mapping of LUN WWN to associated Node WWNs. For boxes that support LUN WWN Thus multipathing needs to be done both at the FCP layer to handle the LUN WWN - Node WWN mapping, as well as lower levels to deal with different routes to different ports. Now you could allow the Node WWN to migrate between different physical machines or controllers when handling failover, but if you did that you would be violating the spirit, if not the letter of the Fibre Channel specifications. This is a valid point- I'm going to mull about this some more then. Having said all that, I am a strong proponent of dumping all these silly WWNs in the trash and embedding a volume identifier in the disklabel itself. You really don't care all that much what device you're talking to most of the time. What you really want is your data, so label the data not the hardware. That's sct's (tweedie's) notion too. The answer to this is "Sometimes you *do* care about not only which specific one of N replicate data sets you have, and sometimes you even care about which path you took to get it". At any rate, the WWN issue is just one use of this identifier. While the idea of a unique system identifier may have merit, I don't think that generating node WWNs is an appropriate use for it. So, when are you gonna fix socal in Solaris to not use localetheraddr and a blind usage of hba instance (which has at least two level 2 bugs waiting to happen any day now) as a seed for cons'ed up WWNs? (*now* who's using implementation to argue architecture? :-;) -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
there are several greg lehey has been collecting them. julian On Fri, 25 Jun 1999, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
On Fri, 25 Jun 1999 15:55:03 -0600 Wes Peters [EMAIL PROTECTED] wrote: Are there enough bytes available in the BIOS NVRAM? That would do nicely as a place to store it. If you want this to be widely adoped across the free OS community (hell, even if you want both of FreeBSD's platforms to support it), you'd better come up with a less PC-centric place of storing this information. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
Matthew Jacob wrote: Whose BIOS NVRAM? The host system BIOS NVRAM. I thought we were looking for a per-host ID here, right? Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc. On the SPARC you can put it in the OpenBoot environment. I dunno about the Alpha. There's NVRAM and so on for a lot of machines. I'm thinking that the cleanest place to put this which would be common across all *BSD's would be: a) A base release 128 bit UUID generator. b) A step in kernel configuration that snags such a value and puts it in a place that sysctl can get at it. c) A utility that binary patches the kernel so that a change via sysctl is persistent. All of this is quite grotesque. If it was FreeBSD specific, then stuff in /boot and sysctl would be fine- but I'd like to see this be *BSD, not just FreeBSD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: Karl Denninger wrote: I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Granted. Perhaps we're seeing an artifact of NT's developers focussing on optimizing their system for good benchmark performance rather than good real-world performance. 'twill be interesting to see the offical report to find out where the various strengths and weaknesses really are. - mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the "optimized idle loop" that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, "when my box is running." So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that "so far freebsd is way ahead on the hassle factor" so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
I think it's been pretty well known since the beginning that FreeBSD SMP performance is nothing to cheer about. How does FreeBSD fare against NT or other systems on single processor systems? Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on "lower-end" hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this "diminished" configuration? We don't have any numbers for that yet, and we cheat a little (using a U2W controller and U2W external RAID unit). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the "one big kernel lock" problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. That's still a non-trivial task. :-) A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
From: Matthew Jacob [EMAIL PROTECTED] Date: 1999-06-24 15:03:56 -0700 To: [EMAIL PROTECTED] Subject: System unique identifier. Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. This could start a long discussion :-}. Some systems just take the IEEE MAC address from the motherboard, or that of the first interface it finds. Others use some algorithmic variation on that value, but it generally boils down to the same thing. For newer Intel boxes, you could just use the CPU chip... well, never mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of "it broke; I had to replace it; now what?". Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
synch primitives (was Re: Microsoft performance)
On Thu, 24 Jun 1999 20:14:19 CDT, Alfred Perlstein writes: I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. i'd really like to implement some of the basic solaris primitives: mutex, cv (condition variable), sema p/v. i sent a message to the smp list on this at one point but didn't get much of a response other than cranky noises about "super fine-grained locking isn't worth it". what i'd like to see is the groundwork laid for finER locking so that we can gradually break up the points of contention. mutex/cv/sema are intuitive and taught in every OS course; i don't feel "simple_lock" or "lockmgr" are desirable or adequate. i'm willing to work on it, but i can't get to it for at least a couple of months, so i'm hoping someone else wants to work on it too. aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex "groups", like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex "type" could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't "own" it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. -Alfred Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
On Tue, 22 Jun 1999, Jeroen Ruigrok/Asmodai wrote: I am not fingerpointing here, not am I willing to. I just want to ask all developers to try and document at least the basic ideas somewhere in a manpage in order to make it easier for others (like me) who want to get the documentation on the road. If you write man pages first time, it is quite close to clack magic. It would be really nice if someone comfortant with troff/nroff etc. would make Handbook page describing how to get started with it. Maybe even templates or script generating page sceletion and pointers to them under some handbook entry http://www.ee.freebsd.org/docproj/doc-set.html says, The [Documentation]Project does not really concern itself with these, since they are a part of the base system. best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. He said "commercial", not "toy". Given that I've just spent a very unhappy couple of weeks demonstrating that this "toy" you're referring to outperforms us by a factor of anything from 3 to 10 on a range of basic benchmarks, and has hundreds of developer-oriented books on the shelves in every major bookstore in the developed world, I think your position is perhaps slightly less than tenable here. But Mark illustrates my point perfectly; developers don't write documentation. That's what camp followers are for. So far, we have the ones that whine about the loot and throw mud at us when we march too slowly, but not enough of the ones that sew our banners, mend our pots and pans, or teach our version of the gospel to the heathens we subdue. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Tue, 22 Jun 1999 18:18:34 -0400, John Baldwin wrote: But if I want to log *all* connections to service foo, but not bar, I could not use tcpd for foo and and bar by itself and achieve that, so you are removing some configurability. If very few people use this extra configurability and if it is a pain to add it in, then I guess it's no real big deal. I used to pride myself in my communication skills, but I'm starting to doubt myself. :-) My concern is that what you want introduces duplicate functionality. I'm not denying that you can't do exactly the same things with inetd that you could with tcpd, but that's to be expected. So far, the mail that I've received which has requested per-case exclusion options has been motivated by two concerns: 1) Performance. I think we're all clear now that exclusion options will not introduce a significant performance gain. We've already scored our performance gain by obviating an exec on tcpd. 2) Logging. I understand that folks want to be able to have their logs look the same as they did when tcpd was in use. That's already not possible, since the wrapping-related messages you see come from inetd[pid] and not tcpd[pid]. I believe that you can have all the messages you used to get going to all the places it used to go, but now using different configuration. Now you should use the hosts_options(5) "severity" option to assign a syslog selector to the messages generated for a service and tune syslog.conf to get messages to the right log destinations. It's critical that folks understand that built-in wrapping in inetd is not the same as inetd passing the job of wrapping to a program called tcpd. Something different is happening in each case. It just so happens that the two cases share a common goal. When you say you want "functionality that exists with TCP wrappers", I think you mean "identical semantics to those used with tcpd". You can't have it, it's that simple. What you should be able to have is the same functionality as was available when using tcpd. I don't think the fact that you may need to set things up differently to achieve the same results as you had before isn't a serious problem, because you're doing a different thing now. Hopefully this clarifies what's going on in my head. :-) Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB scanners?
Where is this docu available?
this is a painful road in my experience. I suggest that you look at the
SANE web page and see if there are pointers to documentation.
HP has some documentation of the language (SCL ?) used by its SCSI
scanners but i don't know to what degree it applies to non-SCSI
units.
cheers
luigi
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
First International Workshop on Networked Group Communication
---+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [usb-bsd] Re: USB scanners?
What kind of devices do you see showing up?
Would be a great help to get some idea of what is needed for the various
devices. For mice the support is pretty much cooked, but for example
keyboards sometimes have an extra mouse port.
Interesting would be things like camera's (still as well as video),
scanners, fingerprint readers, modems, ethernet adapters, anything
really.
I have printouts for the following devices
-mice
-BTC keyboard
-3COM modem
-HP 2700 scanner
-Labtech speakers
-3COM ethernet iface
Or hubs with extra functions (like the Entrega ones).
Nick
Nick, do you need such info for generic hw as well ? I start seeing
USP peripherals around in the office and i can briefly borrow them
and run a quick dump on my 3.2 machine.
cheers
luigi
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
First International Workshop on Networked Group Communication
---+-
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NIS Question
Here's my situation: 1. I would like to set up NIS on my network. 2. I have one FreeBSD system(2.2.6) 3. I have many other flavors of Unix on this network 4. I would like the FreeBSD system to export it's passwd and group files to the other machines How do I achieve this? Do I just run ypserv ypbind? Any FAQ's around??? Thanx up front! Nick [EMAIL PROTECTED] Web Page: http://www.lopresti.dhs.org/users/nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between msync() and fsync()
You should first check out how msync/fsync work on something like solaris, since every time I've checked for the last five years or so no version of bsd has really got it working right (although netbsd + UVM may finally have it). To observe msync/fsync in action use tcpdump to watch a host as it does msync/fsync on an nfs-mounted file system. You can tell by the NFS packets what's actually going on. Be sure to do msync on partial mapped ranges, not simple msync's of the whole region, as well as on dirty pages, clean pages, etc. Obviously for clean pages you should see no traffic when the msync is called, and you should see traffic when the page is referenced again. I've never had this latter test work on freebsd, and lots of other os'es. The only OS it ever really worked correctly on is sunos/solaris. You can search old archives for a long message from me (ca. 1995?) about how msync doesn't work right on freebsd. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Wed, Jun 23, 1999 at 04:39:28PM +0930, Greg Lehey wrote: But Mark illustrates my point perfectly; developers don't write documentation. That's what camp followers are for. So far, we have the ones that whine about the loot and throw mud at us when we march too slowly, but not enough of the ones that sew our banners, mend our pots and pans, or teach our version of the gospel to the heathens we subdue. You can never get enough of them. And you don't get them by calling them "camp followers" either. You get them by supporting them. Documentation doesn't spring out of thin air. If (to pick an example) the new syscons stuff[1] is undocumented then someone's got to document it. Right now, that can only be done by the original developers. In three month's time we might have enough people who have written code with it that they could do it. And in a year's time we might have someone who's been diligently following the mailing lists and has managed to piece something together based on what they've soon. Or who has been forced to use this mass of undocumented code[2], worked out how it works, *and* taken the time to write the documentation. So, when do you want useful documentation? N [1] Chosen at random. I haven't looked at it, so have no idea how clear or easy to follow the syscons code is. [2] See footnote 1 again. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Connect and so on..
On Wed, 23 Jun 1999, Dan Seguin wrote:
Hi All.
I'm trying to create a system call that will burst a (pseudo) quick tcp
message out to a remote host every time that it is called. I've got the
system call all worked out as a kld, it loads and restores without a
hitch.
Good, you're mostly there then!
I use the calling proc's table as it is passed to the system call, and am
trying to call socket and connect as if the user process originally called
them one by one (from userland syscall 97 and 98). I seem to be getting
the correct behaviour from socket, but the connect call fails. After
DDB'ing and breaking on the call to connect, it appears to fail at copyin
with an EFAULT (invalid address). Call stack: copyin from getsockaddr from
connect. What am I missing here, and/or what incorrect assumptions have I
made? I'm including the actual system call function below.
copyin() is done to get the sockaddr from the connect call. A copyin() is a user-space
to kernel-space memory copy, so you have a problem in your code (I'll point out where
below).
Thanks!
Dan
P.S. I test the system call from userland with a small C prog that uses
syscall().
CODE starts
static int init_comms(p, uap)
struct proc *p;
register struct nosys_args *uap;
{
int sockfd1, stat;
struct socket_args socket_uap;
struct connect_args connect_uap;
static struct sockaddr_in servaddr;
This needs to be a valid structure in USER space, not kernel.
socket_uap.domain = PF_LOCAL;
socket_uap.type = SOCK_STREAM;
socket_uap.protocol = 0;
stat = socket(p, socket_uap);
if (stat)
return stat;
sockfd1 = p-p_retval[0];
bzero(servaddr, sizeof(servaddr));
servaddr.sin_family = AF_LOCAL;
servaddr.sin_port = htons(13);
servaddr.sin_len= sizeof servaddr;
if ( inet_aton((char *) "127.0.0.1", servaddr.sin_addr) = 0 )
This is a bogus cast. const char * to char *?
printf("\ninet_aton failed.\n");
So return EINVAL.
printf("\nservaddr: %x\n", servaddr.sin_addr.s_addr);
AHEM! Why??
/* Prints 17e */
Try using servaddr.sin_addr.saddr = 0;
connect_uap.s = sockfd1;
connect_uap.name = (caddr_t) servaddr;
That's the problem. It needs to point to (say) uap-servaddr;
connect_uap.namelen = sizeof servaddr;
stat = 0;
stat = connect(p, connect_uap);
printf("\nConnect Stat: %d\n", stat);
Take that out.
/* Prints 14 (EFAULT) */
return 0;
return stat instead. The standard is to use a variable named "error".
}
- Code Ends ---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Note that I haven't checked the correctness of the code other than a quick glance.
These errors are real, though.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too?(was: cvs commit: src/sys/isa sio.c))
On Wed, 23 Jun 1999, Nik Clayton wrote: [deleted cvs-all from the list of cc's, how'd it get there? On Wed, Jun 23, 1999 at 04:39:28PM +0930, Greg Lehey wrote: But Mark illustrates my point perfectly; developers don't write documentation. That's what camp followers are for. So far, we have the ones that whine about the loot and throw mud at us when we march too slowly, but not enough of the ones that sew our banners, mend our pots and pans, or teach our version of the gospel to the heathens we subdue. You can never get enough of them. And you don't get them by calling them "camp followers" either. But one thing I like is, although FreeBSD *does* try to appease user demands, it's controlled by programmers, not users, so if something is a technically extemely evil idea, no matter how the masses yell for it, it will NOT happen. We want to listen to our users, we don't want to disparage them, but we sure don't want to "sell our souls" to the masses either. FreeBSD is technical, and we want it to stay that way. If we can be smart and form something that everyone else likes, that's also very good, but not the first priority, I think. Making something we are all proud of, that's what keeps programmers here. +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Wed, Jun 23, 1999 at 11:24:03PM -0400, Brian F. Feldman wrote: On Wed, 23 Jun 1999, Garance A Drosihn wrote: At 4:39 PM +0930 6/23/99, Greg Lehey wrote: On Tuesday, 22 June 1999 at 23:52:25 -0700, Mike Smith wrote: [someone said] | [someone said] | Ok, so let's follow Microsoft's industry-leading documentation | standards. | | He said "commercial", not "toy". Given that I've just spent a very unhappy couple of weeks demonstrating that this "toy" you're referring to outperforms us by a factor of anything from 3 to 10 on a range of basic benchmarks, Really? This is so different from anything I've heard that I'm astounded. How about some details? I also found Mike's comment on performance interesting. I assume he's talking about system performance, and not documentation performance. Was this when testing WinNT-2000, or just the latest service pack on WinNT 4? s/interesting/unbelievable/g and you've got my reaction. This makes so little sense that I can't even imagine it. Me too. I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Its more stable too; the stability is a free "bonus" that comes at no extra charge :-). -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isasio.c)
On Wed, 23 Jun 1999, Greg Lehey wrote: There's a man page for it :-) mdoc.samples(7). Now tell me that that's not intuitive. Is it just me or does everyone get a (non-fatal) error as mdoc.samples(7) is formatted? The perfect man page for an error as well :-) Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
%Basically there are some applications and benchmarks for which FreeBSD uh, "benchmarks" only, until evidence is produced otherwise. Tuning for benchmarks has been around a long long time. People get worked up about this because the people who give out the money to buy the systems use benchmarks to decide whom to give the money to. It's really, really stupid to rely on generic benchmarks. But people do, anyway. So I guess whistle and some others should invest in tuning for the benchmarks. Like jupiter, eh? Or maybe Apple. But for the rest, I wouldn't panic. In fact, there's probably some interesting kernel architecture issues here. Let's hear them, now! If I wanted secrecy about architecture details there's a shitload less time consuming ways to do it then follow FreeBSD. Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP input processing bug
I think I've located a problem in TCP input processing...and it has been there for quite a while. It breaks half-open connection discovery for many cases since version 1.15 of netinet/tcp_input.c (committed by Garrett Wollman, which is why this is Cc'd to him), although that isn't where the (presumably) incorrect behavior was introduced. The half-open connection discovery problem can be reproduced easily, the conditions required are: - Machine A thinks it has an established connection with machine B - Machine B disagrees (it has crashed, the network has been down, maybe has been recently assigned the IP of another machine that disconnected unnicely etc., there are a lot of conditions that can cause this) - Machine B tries to connect to machine A using the same source port number as the half-open connection - Machine B selects a sequence number below the current window expected by machine A Machine B sends a SYN, but gets nothing as a reply (it should be getting an ACK), no matter how many times it tries. Machine A will keep the connection in an established state until it tries to send data (depending on the application, this may never happen) or is timed out by keepalives. This is particularly nasty if the boot procedure of machine B establishes a TCP connection to machine A - after a crash, it'll always try to use the same port number and never succeed. Basically, in the tcp_input function, just before ACK processing, when 'goto drop' is done if ACK isn't set, TF_ACKNOW might be set in tp-t_flags, but the ACK is never sent because tcp_output is never called. This can be fixed by checking for TF_ACKNOW in the drop: case and calling tcp_output if it is set. However, such a modification can change the behavior of a considerable number of cases so I think it needs careful verification. Anyone who knows the TCP code, please comment! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Brian F. Feldman wrote:
Date: Tue, 22 Jun 1999 01:08:04 -0400 (EDT)
From: Brian F. Feldman [EMAIL PROTECTED]
To: Kris Kennaway [EMAIL PROTECTED]
Cc: Peter Wemm [EMAIL PROTECTED], Jean-Marc Zucconi [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Peter Wemm wrote:
Ahh yes, I forgot that / was read-write for MFS boots. However:
#!/bin/sh
skip=18
if /usr/bin/tail +$skip $0 | gzip -cd /tmp/gztmp$$; then
chmod 700 /tmp/gztmp$$
prog="`echo $0 | sed 's|^.*/||'`"
if /bin/ln /tmp/gztmp$$ "/tmp/$prog" 2/dev/null; then
trap '/bin/rm -f /tmp/gztmp$$ "/tmp/$prog"; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ "/tmp/$prog") 2/dev/null
/tmp/"$prog" ${1+"$@"}; res=$?
else
trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2/dev/null
/tmp/gztmp$$ ${1+"$@"}; res=$?
fi
else
echo Cannot decompress $0; exit 1
fi; exit $res
This is the unpatched (insecure) version of gzexe (all the /tmp/gztmp$$'s),
but it's functionally the same.
Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd
crunched linked binary, how is it supposed to decompress itself? "sh" itself
is part of the crunched binary, so what is going to decode sh when sh itself
is a shell script?
Yes, that seems to be a problem - gzexe depends on those executables. However
it shouldn't be too hard to recode this decompressor in C to perform the same
job without any external dependencies. The question is whether that would be
easier than fixing the kernel to handle gzipped ELF binaries transparently -
almost certainly it would be.
How's what I attached?
[Context left in for cross-post to hackers]
Hmm..I don't have a deflate on my system. This should be linked static as
well, otherwise you need the runtime linker + libraries, and that has a 69k
overhead (when stripped). Possibly this could be optimized further..I don't
know if this is small enough to be useful however.
It's a proof of concept, it didn't need to be static. I don't have a program
to do deflate either. What I know is that you said it would be hard, but
it was not very hard to make a framework to do what gzexe does in C.
Mike's suggestion of a gzipped MFS image is probably best for things like boot
floppies.
Kris
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
-
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes."
-- Unknown
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Wed, 23 Jun 1999, Kris Kennaway wrote: On Tue, 22 Jun 1999, Brian F. Feldman wrote: Hmm..I don't have a deflate on my system. This should be linked static as well, otherwise you need the runtime linker + libraries, and that has a 69k overhead (when stripped). Possibly this could be optimized further..I don't know if this is small enough to be useful however. It's a proof of concept, it didn't need to be static. I don't have a program to do deflate either. What I know is that you said it would be hard, but it was not very hard to make a framework to do what gzexe does in C. Actually: The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. I said it would be easy(ier) :) FWIW, compiling libc.a and libz.a with -Os brings the overhead down to 67416 bytes per executable. Linked dynamically it's 4829 bytes (i.e. the other 62k is library code), so it doesn't look like there's much room for improvement. This sure seems like enough to replace a.out gzip support. Taking the compression/decompression routines out of the kernel would save memory and result in roughly the same amount of space being used. If we had a deflate program, this would work quite well =) Kris - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mysterious problem with 2.2.x binary on 3.1
Hi, I have a mysterious problem with running a 2.2.6 binary (dynamically linked) on a 3.1 box. The crazy thing is that it has worked flawlessly before. After doing a bit of development and compiling it again, I get segfaults when I try to run it on the 3.1 box. When I try it with an a.out gdb (ftp'ed from the 2.2.6 box) I get this: ./gdb web-ssql GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (gdb) r -v Starting program: /home/bowtie/web-ssql -v reading register eip (#8): Bad address. (gdb) (3.1) ldd web-ssql: ldd web-ssql web-ssql: -lcrypt.2 = /usr/lib/aout/libcrypt.so.2.0 (0x200a3000) -lm.2 = /usr/lib/aout/libm.so.2.0 (0x200b8000) -lc.3 = /usr/lib/aout/libc.so.3.1 (0x200d2000) (2.2.6) ldd web-ssql: web-ssql: -lcrypt.2 = /usr/lib/libcrypt.so.2.0 (0x200ab000) -lm.2 = /usr/lib/libm.so.2.0 (0x200ae000) -lc.3 = /usr/lib/libc.so.3.1 (0x200c8000) When I link the binary statically it works ok, but unfortunately I need it to be dynamically linked. Does anyone recognize this behaviour? And even better knows whats going on? Regards, Marc. Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial Console Wierdness
'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. your second problem sounds like it could be terminal sizing -- have you tried this with a default 80x24 window, set and exported TERM properly, etc? i was not able to get my console to work properly past 38400 baud; i am not sure why. 38400 has been just fine speed-wise for me, though, so i'm not that upset. :) (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) aaron On Tue, 22 Jun 1999 13:31:33 EDT, "Bill G." writes: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. o 9600 was rather slow, so I changed it to 115200, which worked, however I had a few problems with terminal display -- any output that scrolls down past the bottom of the screen gets 'garbled'. (IE, I run clear; ls -l / -- the first 23 lines look ok then it gets messed up). Same results from console mode of my client machine and from an xterm. I thought that 115200 might be too fast, so I slowed it down to 38400, but same trouble. I'm not sure if this occured at 9600. Any thoughts / ideas / suggestions would be appreciated. Thanks, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isasio.c)
On Tue, 22 Jun 1999, Hellmuth Michaelis wrote: From the keyboard of Nick Hibma: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. I know that it is current behaviour, much easier and obviously a commonly accepted thing that code, subsystem and/or changes are not and need not to be documented, but this is not a reason in itself for not changing this. Also, i think that the argument Mike and others use: "don't complain for a lack of things, contribute!" - which i use and used all the time - is not valid for this issue: at least i can't contribute because i don't understand things (now someone could argue, that i'm wrong here ...). The last thing i want is a flamewar on this topic and i don't write this because i want to piss onto someones shoes. And i don't write about a man page for "ls" or "more" but a fundamental change in FreeBSD's inner architecture. Writing software in one's spare time is a case of triage. When I have a day or two to spend working on FreeBSD, I have to make a choice on what most needs doing and if that is a choice between technical writing or designing an algorithm to fix the current limitations of driver detach and KLD unload, I don't think the technical writing is going to win. People must also bear in mind that the most important target release for this software is 4.0 which isn't scheduled until next year. I am certain that the documentation situation will improve before that release. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?]
I'm lofting this up on -hackers to get the attention of the ATAPI CD driver programmer -- Soren, you still around? Take a look at this. On Tue, 22 Jun 1999, Woody Carey wrote: Ok, here is some more information: Here is the behavior when there is no cd in the drive at bootup [reboot, actually] ^M^[[Kmyname# mount /cdrom cd9660: Input/output error myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 0 - 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked and here is the dmesg output and mount output with a cd in the drive at boot: myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked myname# mount /cdrom There was some success message on the console after this mount indicating success. It did not appear in this script output, obviously. Bizarre. That may be a driver bug or your drive is getting into an inconsistent state if it doesn't boot with a CD present. What brand/model of CD drive is it? Doug White Internet: [EMAIL PROTECTED]| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
* Mark Newton ([EMAIL PROTECTED]) [990622 17:38]: Hellmuth Michaelis wrote: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. Blah, this argument is, pardon my french, utter bullshit. If one looks at, the now deceased, DEC Unix and it's programmer's manuals, ye see what Hellmuth tries to put down with his statement. In fact I have a couple of those pdf/ps files printed out and they make for TOP CLASS programmer's material. Needless to say I hope to reach this level of excellence with the PDP as well... It's all a matter of time and effort and unfortunately not many care to take the time to document, but rather hack on. (And somewhere that's very understandable.) -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept no... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
* Mike Smith ([EMAIL PROTECTED]) [990622 17:38]: And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. No offence meant, but we can see how much of this has actually materialised. Hence I started the PDP =P Still going strong... Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. In fact, most Unix documentation is never written, being my original point. Which sucks given all the crap the same people tend to spew then about Microsoft being very closed about their internals. No documentation is worse than just a sparse manpage. The latter at least makes it more understanding for all without doing too much UTSL. And given the aspirations the Project has with regard to commercial support I find the silent encouragement of just hack and not document disturbing to say the very least. As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. And I did/am doing that with the PDP, which at it current rate of support (that is just me ;) whill be finished somewhere when FreeBSD 6.5 will be released or so, but I am not complaining about that =) I am not fingerpointing here, not am I willing to. I just want to ask all developers to try and document at least the basic ideas somewhere in a manpage in order to make it easier for others (like me) who want to get the documentation on the road. Thanks, -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept no... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2.2.7 + NBUF + NMBCLUSTERS
Hoi folx, I have a 2.2.7 system that runs out of mbuf clusters. maxuser 64 I've raised options NMBCLUSTERS=6144 options NBUF=3072 and that made it for a while. However the system is running a chatserver and a webserver of a customer and now it hits me again. Are there any problems in raising it to options NMBCLUSTERS=16384 options NBUF=8192 Does this combination make sense at all? (in the LINT file NBUF was half the value of NMBCLUSTERS, so I kept this). Thanks \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:[EMAIL PROTECTED] | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
On Tuesday, 22 June 1999 at 1:42:05 -0700, Mike Smith wrote:
And they might, too. phk has frequently expressed a desire to either
write documentation on existing systems, or at least help others do
so.
No offence meant, but we can see how much of this has actually
materialised.
None taken. But if it hasn't happened yet, it's not phk's fault. The
real problem is a general attitude: UTSL. Sure, a good hacker can get
by with the source, but good documentation makes for a smoother
project.
It has never happened that way (anywhere, on any project),
Of course it has. It's just uncommon in the FreeBSD environment. In
many large projects, you don't do any code until you have a clear
definition of what you're going to do.
It's uncommon in _most_ environments. Or perhaps tech writers exist
for some other purpose?
I don't know too many UNIX tech writers.
and it never will.
My father never had a computer, and his father never did, so I never
will have one. What an argument.
The circumstances aren't comparable.
Why not? In each case, you're resisting change.
Documentation is written after the fact, by someone else.
That's the worst kind of documentation. In fact, most UNIX
documentation is written by the authors. After the fact, admittedly.
In fact, most Unix documentation is never written, being my original
point.
That doesn't make it a desirable or unchangeable situation.
Hopefully the change of subject line and recipients will get some more
representative views on this subject.
Perhaps I should have been clearer; the sort of documentation that the
original set of plaintiffs were asking for is the mythical "describe
everything as it was, is and will be, and make it constantly
representative and up to date".
This clarifies your interpretation of the situation. In fact, I was
the "original plaintiff", and I wrote:
Nice to know there's a man page. But the real thing is that the
"right thing" to do needs to be documented somewhere. It would be
nice, for example, to have an overview of the design principles. Yes,
I know I'm asking for a lot here, but it would really help.
These are the same people that will complain about disparities
between any extant documentation and reality, as well as carp
incessantly about the lack of some form of documentation other than
what already exists ("why isn't there a permuted index?" "where's
the sanskrit translation?"
I think you're reading more into this than was stated.
"my cat can't read _this_!").
Put in a PR. cat should be able to read anything.
As always, complaining about the _lack_ of something is the wrong
approach for this project. Step up and fill the gap, or expose
yourself to criticism for failing to do so. There has to be a way
to make a verb from Brett Glass' name, but I'm sure you get the
point.
"To glass"?
Yes, I'm a firm believer in "if it's broke, fix it yourself". I'm
also not complaining about the current situation; it's probably too
late for that. But it would be really nice if we could cultivate this
concept of describing what you're doing while you're doing it.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes: : Granted, we can never think of reaching a commercial level on documentating : the internals/code which all the committers provide. I think that the documenation that Doug has written to date EXCEEDS so called commercial standards. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
