Re: [patch] SUBDIR_OVERRIDE `optimization'
On Fri, Jul 09, 2010 at 07:56:37AM -0700, Garrett Cooper wrote:
(Let's try this again with the right email address)
Something simple that I noticed a while back when I was reviewing
the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the
conditional feature checks, which sets the value of SUBDIRS to the
user defined value. So instead of going through the conditionals, one
could just cut to the chase and set SUBDIRS to SUBDIRS_OVERRIDE,
otherwise detect the conditional directories to include in
Makefile.inc1.
Thanks!
-Garrett
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 209684)
+++ Makefile.inc1 (working copy)
@@ -41,6 +41,9 @@
# use that new version. And the new (dynamically-linked) /bin/sh
# will expect to find appropriate libraries in /lib and /libexec.
#
+.if defined(SUBDIR_OVERRIDE)
+SUBDIR= ${SUBDIR_OVERRIDE}
+.else
SUBDIR= share/info lib libexec
SUBDIR+=bin
.if ${MK_GAMES} != no
@@ -79,8 +82,6 @@
.endif
.endfor
-.if defined(SUBDIR_OVERRIDE)
-SUBDIR= ${SUBDIR_OVERRIDE}
.endif
.if defined(NOCLEAN)
SUBDIR_OVERRIDE is mainly for FreeBSD src/ builders (to quickly
check with buildworld a particular bit of a tree), and is thus
rarely used, so this change would be an optimization for the
uncommon case. Having said that, I don't mind if you commit it,
if you like.
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
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] usr.bin/elf2aout/elf2aout.1
On Fri, Feb 12, 2010 at 02:32:44PM +0100, Alexander Best wrote: hi there, just a small format correction. Committed to -CURRENT, except I didn't touch .Dd and fixed usage() as well. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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: POSIXfy readlink() call
On Mon, May 11, 2009 at 04:23:52PM -0400, John Baldwin wrote: On Monday 11 May 2009 2:58:14 pm Kostik Belousov wrote: On Mon, May 11, 2009 at 02:46:14PM -0400, John Baldwin wrote: On Monday 11 May 2009 2:33:09 pm Kostik Belousov wrote: On Mon, May 11, 2009 at 02:05:07PM -0400, John Baldwin wrote: On Friday 28 September 2007 10:39:56 pm Ighighi wrote: ^ Yes, I had this stuck in the back of my head from when it first appeared. The POXIX prototype for readlink(2) is: ssize_t readlink(const char *restrict path, char *restrict buf, size_t bufsize); It can't simply be corrected as it would change the ABI and thus requires a new system call, etc. However, do you really expect a symlink to be longer than 2^31 on a 64-bit machine? Yes, I agree that this is ABI change. Meantime, r176215 | ru | 2008-02-12 22:09:04 +0200 (Tue, 12 Feb 2008) | 5 lines Change readlink(2)'s return type and type of the last argument to match POSIX. Prodded by: Alexey Lyashkov I tried to convince ru@ that ABI breakage is not good, but has not succeeded. Ugh, is this only in HEAD? If so, I will back it out for 8.0. If this made it into a release then this is a far bigger mess. Oh, good, this is only in 8. I will fix this ASAP. I can just add the new syscall I guess. You need to symver the syscalls. It requires some ugly games with our syscall stubs, because gnu ld only honor .symver in the same object where the symbol is defined. I did prototyped this some time ago, by including a file with appropriate .symver from all stubs. So, after thinking about this out loud some more, it seems the ABI breakage would only be for 64-bit platforms that passed a -ve value as the buffer size. However, doing so would already either panic due to triggering an assertion, or result in otherwise undefined behavior and that making the new parameter unsigned actually results in the same undefined behavior in the non-panic case. For the record. I also suggest (re-)reading a thread http://lists.freebsd.org/pipermail/freebsd-current/2008-February/thread.html#83314 that resulted from the original commit where I try to make it clear that a scary ABI breakage Konstantin mentions is pure artificial. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set
Hi,
On Thu, Jan 01, 2009 at 11:42:12PM -0800, Doug Barton wrote:
In working on cross-platform support for mergemaster I came across the
following problem. I set MAKEOBJDIRPREFIX to be that of the temproot
environment, which works fine when you do not specify a TARGET_ARCH.
When you do specify TARGET_ARCH there is a conflict between
src/Makefile.inc1 and share/mk/bsd.obj.mk.
The former does this:
.if ${MACHINE} == ${TARGET} !defined(CROSS_BUILD_TESTING)
OBJTREE=${MAKEOBJDIRPREFIX}
.else
OBJTREE=${MAKEOBJDIRPREFIX}/${TARGET}
.endif
OBJTREE is a variable internal to Makefile.inc1; it's then assigned to
a MAKEOBJDIRPREFIX environment variable which make(1) understands and
uses to find the actual object directory.
however the latter does this:
.if defined(MAKEOBJDIRPREFIX)
CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
CANONICALOBJDIR is what we (BSD, FreeBSD) choose to be a canonical
object directory out of the list of possible object directories
make(1) understands; the list is documented in the manpage:
: 1. ${MAKEOBJDIRPREFIX}/`pwd`
: 2. ${MAKEOBJDIR}
: 3. obj.${MACHINE}
: 4. obj
: 5. /usr/obj/`pwd`
That is, 1 and 5.
There's no conflict between bsd.obj.mk and Makefile.inc1; the former
creates a canonical object directory with the default obj target,
${MAKEOBJDIRPREFIX}/`pwd` or /usr/obj/`pwd`, and Makefile.inc1 only
changes the value of MAKEOBJDIRPREFIX environment variable.
bsd.obj.mk doesn't (and shouldn't) know anything about OBJTREE which
is internal to Makefile.inc1.
When trying to install the stuff in src/etc/sendmail install(1) cannot
find the file because it is built in foo/obj but it's looking for it
in foo/obj/$target
You should set MAKEOBJDIRPREFIX to the same value for build and
install targets. If you set it only for the install target,
you'll get what you describe; let's see...
The simplest fix I found was to do the following in bsd.obj.mk:
Index: bsd.obj.mk
===
--- bsd.obj.mk(revision 186676)
+++ bsd.obj.mk(working copy)
@@ -43,7 +43,7 @@
.include bsd.own.mk
.if defined(MAKEOBJDIRPREFIX)
-CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
+CANONICALOBJDIR:=${OBJTREE}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
This change is plain wrong and shouldn't be committed.
However I would be happy with any solution that makes it work. It's
trivial to test with 'mergemaster -i -D/temp/dir/for/root -A arm'
The problem is that Makefile.inc1 sets MAKEOBJDIRPREFIX for world-
related targets specially, taking into account the value of ${TARGET},
to be able to use a single directory to build worlds for different
architectures.
mergemaster.sh uses obj and all targets which aren't cross-build
aware (don't take ${TARGET} into account) to build etc/ bits, and then
distribution target (which is cross-build aware) to install then.
The effect of this is that you end up with build and install targets
having different ideas of MAKEOBJDIRPREFIX. The fix is to use cross-aware
versions of obj and all targets:
%%%
Index: mergemaster.sh
===
RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.63
diff -u -p -r1.63 mergemaster.sh
--- mergemaster.sh 2 Jan 2009 00:37:59 - 1.63
+++ mergemaster.sh 4 Jan 2009 20:18:40 -
@@ -588,8 +588,8 @@ case ${RERUN} in
;;
esac
${MM_MAKE} DESTDIR=${TEMPROOT} ${ARCHSTRING} distrib-dirs
- MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} obj
SUBDIR_OVERRIDE=etc
- MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} all
SUBDIR_OVERRIDE=etc
+ MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} _obj
SUBDIR_OVERRIDE=etc
+ MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} everything
SUBDIR_OVERRIDE=etc
MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} \
DESTDIR=${TEMPROOT} distribution;} ||
{ echo '';
%%%
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
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: Creation of the NO_SSP build knob
On Fri, Sep 05, 2008 at 09:00:28AM +0200, Jeremie Le Hen wrote: Dag-Erling, On Thu, Sep 04, 2008 at 09:26:28PM +0200, Dag-Erling Sm?rgrav wrote: Jeremie Le Hen [EMAIL PROTECTED] writes: If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. But it will still not be possible to use WITH_SSP in src.conf or command-line. [...] Shouldn't we have a knob that overrides whatever the user says, only for internal use in the source tree? That was my original intent when asking if I could add NO_SSP. That's *exactly* what NO_* does. Just add SSP to that list and replace WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree. I've just tested it with NO_SSP and I can confirm it doesn't work despite the explicit comment above stating otherwise. By the way, the code is nearly identical between the supported options and the compat ones, I don't see how it could override the user settings: This is not the way the things were designed to work. http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html WITH_*/WITHOUT_* are for users, and MK_* are for makefiles. NO_*'s are mainly for backwards compatibility and (to the lesser extent) to support some of the makefile buzzwords like NO_MAN. There's no possibility to easily make what you want, i.e., disable SSP for some parts of the tree. Doing it for particular makefiles OTOH should be pretty easy, by starting a makefile with the following two lines: .include bsd.own.mk MK_SSP=no bsd.own.mk will set MK_SSP as per default (yes), then possibly reset it to no if a user set WITHOUT_SSP (either on a command line, in /etc/make.conf, or in environment), and then the second line will unconditionally reset it to no. This will work in the SSP case, but may not work in general because some options have dependencies. Fortunately, cases like this are rare. (There are several makefiles in the tree that already do this; grep ^MK_ to see them.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WITHOUT_INSTALLLIB blues
On Sun, Jun 29, 2008 at 01:42:11AM -0600, Warner Losh wrote: when setting WITHOUT_INSTALLLIB, make buildworld breaks with make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ usr/lib/libegacy.a. Stop Only set it for installworld. *nods* -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WITHOUT_INSTALLLIB blues
On Sun, Jun 29, 2008 at 02:54:03PM -0400, Scott Ullrich wrote: On Sun, Jun 29, 2008 at 3:42 AM, Warner Losh [EMAIL PROTECTED] wrote: when setting WITHOUT_INSTALLLIB, make buildworld breaks with make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ usr/lib/libegacy.a. Stop Only set it for installworld. Was this documented somewhere after the change? This bit me some time ago and I could not find it documented anywhere. If not can someone add it to /usr/src/UPDATING? It follows from the description of WITHOUT_INSTALLLIB in src.conf(5), but perhaps it's not very obvious. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using special CFLAGS for a single file without writing the rule
On Thu, Apr 24, 2008 at 06:04:15PM +0200, Jeremie Le Hen wrote:
Hi Ruslan, hi all,
I don't know if you followed the thread on -arch@, but the outcome is
basically that SSP should be disabled for a couple of files:
lib/csu/*
gnu/lib/csu/* (reported by antoine@, but I couldn't verify this one)
lib/libc/sys/stack_protector.c
sys/kern/stack_protector.c
Antoine Brodin supplied a patch for the kernel part:
+kern/stack_protector.c standard\
+ compile-with${NORMAL_C:N-fstack-protector*}
As for lib/csu/*, this is straightforward, I just have to set
WITHOUT_SSP in the Makefile.
The hardest one is lib/libc/sys/stack_protector.c. I endeavored to find
a way to compile a single file with ${CFLAGS:N-fstack-protector*}, but I
found no recipe but writing the whole rule for this file. I would
really like to avoid this solution so as to not override bsd.lib.mk
settings.
Considering your big experience with the build infrastructure, I suspect
you would have a solution.
Either by using a special rule, or through a hack similar to
the one found in the last two lines of libc/Makefile.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Make release fails on mdconfig
On Tue, Dec 04, 2007 at 08:43:29AM +0100, Marco Walraven wrote:
Hi All,
I have been doing some release builds overhere with success, however lately
the builds fail on mdconfig with the following error:
+ mdconfig -a -t vnode -f /R/stage/mfsroot/mfsroot
mdconfig: failed to load geom_md module: No such file or directory
+ MDDEVICE=
*** Error code 1
Looking at the chrooted environment I see that /boot/kernels
is not populated whereas in old builds it is.
No, it has never been populated.
If I install a kernel into the chrooted environment using
'make installkernel DESTDIR=/dir_to_chroot' and run a
'make rerelease' mdconfig happily accepts it and the make
release builds successfully. The kernel I run has support
for mdconfig; I can use memory disks without problems.
The md(4) driver is loaded if not present in the kernel
just before switching to a chroot, by make release:
: # Ensure md.ko is loaded if md(4) is not statically compiled into
: # the kernel
: -mdconfig 2/dev/null
: env -i /usr/sbin/chroot `dirname ${_MK}` /`basename ${_MK}`
Any clue why this fails in the first place ?
It's possible that your host system is running an older version
of FreeBSD kernel with version 1 of struct kld_file_stat,
while the release(7) procedure requires that /usr/obj be
populated with the output of a native ``make buildworld''
compiled from sources matching the currently running kernel.
^
Please fix that and try again. Following this requirement
solved a similar problem for a colleague here.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Netgraph ng_bridge status message missing last three values?
On Fri, Oct 19, 2007 at 09:50:35AM -0500, Guy Helmer wrote:
I'm diagnosing a system that uses the Netgraph ng_bridge node to bridge two
Ethernet segments and the system seems to stop passing traffic at
randomly-triggered points (somewhat annoying for a system half a world away
behind a very restrictive firewall :-)
I've installed a cron job to dump the Netgraph bridge status messages to a
log file every few minutes. However, I've found that the ng_bridge status
message looks like this:
ngctl msg bnet0: getstats 0
STATS=Rec'd response getstats (4) from [10]::
Args: { recvOctets=474229151 recvPackets=3322699 recvMulticast=128640
recvBroadcast=105813 recvUnknown=2372 xmitOctets=516954216
xmitPackets=2968420 xmitMulticasts=8 xmitBroadcasts=339 }
but to aid diagnosis I would really like to see several values that,
according to ng_bridge.h, are in the stats structure, including
recvRunts, recvInvalid, loopDrops, loopDetects, and memoryFailures. It
looks like all the code is there to report the values of these variables,
but I can't seem to find anything that is dropping these variables from
ngctl's output.
Struct members with zero values aren't shown.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Init.c, making it chroot
On Wed, Dec 27, 2006 at 09:27:24PM +0200, Erik Udo wrote: How can i make init chroot after executing /etc/rc, and executing /etc/rc again in the chrooted enviroment? Go look at the NetBSD init(8) that can do this, and bring us back a patch for this. Quote from the NetBSD init(8) manpage: : 2. Multi-user boot (default operation). Executes /etc/rc (see rc(8)). : If this was the first state entered (as opposed to entering here : after state 1), then /etc/rc will be invoked with its first argument : being `autoboot'. If /etc/rc exits with a non-zero (error) exit : code, commence single user operation by giving the super-user a : shell on the console by going to state 1 (single user). Otherwise, : proceed to state 3. : : If value of the ``init.root'' sysctl node is not equal to / at this : point, the /etc/rc process will be run inside a chroot(2) indicated : by sysctl with the same error handling as above. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpO7LdxYof4f.pgp Description: PGP signature
Re: vn_fullpath question.
On Mon, Nov 27, 2006 at 02:07:40PM +0200, Nikolay Pavlov wrote: Hi. I am trying to extend fstat utility, so that it can use name cache to recreate full path at least for text. I have found vn_fullpath function usefull in this case. I am newbe in C, so it could be stupid question, but could someone explaine what is struct thread *td in argument list of this function. Is this the thread which opened the vnode initially or it is the thread which searches for the vnode? i.e. fstat thread. In any case how i can get this *td structure? There's a vn_fullpath(9) manpage which should answer this. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpb1ni6jnw8i.pgp Description: PGP signature
Re: vn_fullpath question.
On Mon, Nov 27, 2006 at 05:37:12PM +0200, Nikolay Pavlov wrote: On Monday, 27 November 2006 at 18:20:03 +0300, Ruslan Ermilov wrote: On Mon, Nov 27, 2006 at 02:07:40PM +0200, Nikolay Pavlov wrote: Hi. I am trying to extend fstat utility, so that it can use name cache to recreate full path at least for text. I have found vn_fullpath function usefull in this case. I am newbe in C, so it could be stupid question, but could someone explaine what is struct thread *td in argument list of this function. Is this the thread which opened the vnode initially or it is the thread which searches for the vnode? i.e. fstat thread. In any case how i can get this *td structure? There's a vn_fullpath(9) manpage which should answer this. Yes i know about this man, but still not sure how to get *td structure. Depends on context. curthread perhaps. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpuKoZzaKww3.pgp Description: PGP signature
Re: Ramdisk support
On Wed, Nov 15, 2006 at 05:25:36PM +0530, Aditya Godbole wrote: On 11/15/06, Oliver Fromme [EMAIL PROTECTED] wrote: Aditya Godbole wrote: Is there any ramdisk support in freebsd, as there is in netbsd? What are the alternatives if I want to mount a root filesytem from ram? You mean a diskless setup? I think there's a detailed description of diskless setups in the FreeBSD Handbook. You might also want to look at the diskless(8) manpage. Hi, I was looking for something like initrd support of Linux or the mdsetimage of NetBSD. I have no disc or network card support for my hardware at the moment. Well, how are you going to boot your system without a disk and network then? We support disk booting, and diskless (network) booting, also support CD-ROM and floppy booting. What of these do you need? Like others have said, we can load kernels with an embedded root filesystem image; the image can either be read-write or read-only; in the latter case, it can also be compressed with geom_uzip(4). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpjZoVUXmcH7.pgp Description: PGP signature
Re: RFC: pam_krb5: minimum_[ug]id options
On Thu, Nov 09, 2006 at 01:18:44AM +, Shaun Amott wrote:
Thanks for reviewing the patch. Here's an updated version with your
suggestions incorporated.
Please don't remove me from Cc:. I prefer to receive directed
replies, and I didn't ask for non-directed reply via setting the
Mail-Followup-To: header like you seem to prefer. Thanks.
Below are some more comments; it's still not being perfect...
Index: pam_krb5.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.8,v
retrieving revision 1.6
diff -u -r1.6 pam_krb5.8
--- pam_krb5.824 Nov 2001 23:41:32 - 1.6
+++ pam_krb5.89 Nov 2006 01:14:18 -
@@ -1,7 +1,7 @@
.\
.\ $Id: pam_krb5.5,v 1.5 2000/01/05 00:59:56 fcusack Exp $
.\ $FreeBSD: src/lib/libpam/modules/pam_krb5/pam_krb5.8,v 1.6 2001/11/24
23:41:32 dd Exp $
-.Dd January 15, 1999
+.Dd Thursday 09, 2006
It should be .Dd November 9, 2006.
Index: pam_krb5.c
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.c,v
retrieving revision 1.23
diff -u -r1.23 pam_krb5.c
--- pam_krb5.c7 Jul 2005 14:16:38 - 1.23
+++ pam_krb5.c9 Nov 2006 01:14:19 -
@@ -88,6 +88,8 @@
#define PAM_OPT_CCACHE ccache
#define PAM_OPT_DEBUGdebug
#define PAM_OPT_FORWARDABLE forwardable
+#define PAM_OPT_MINIMUM_GID minimum_gid
+#define PAM_OPT_MINIMUM_UID minimum_uid
#define PAM_OPT_NO_CCACHEno_ccache
#define PAM_OPT_REUSE_CCACHE reuse_ccache
@@ -110,6 +112,9 @@
const char *user, *pass;
const void *sourceuser, *service;
char *principal, *princ_name, *ccache_name, luser[32], *srvdup;
+ const char *retstr;
+ uid_t minuid = 0;
+ gid_t mingid = 0;
Initializations can be done later, please see below.
retval = pam_get_user(pamh, user, USER_PROMPT);
if (retval != PAM_SUCCESS)
@@ -222,6 +227,39 @@
PAM_LOG(Done getpwnam());
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_UID);
+ if (retstr != NULL) {
+ if ((minuid = (uid_t)strtoul(retstr, NULL, 10)) == 0) {
+ if (errno == ERANGE || errno == EINVAL) {
Checking for ERANGE here is pointless, as when it's set, the
return value will be ULONG_MAX and not zero.
+ PAM_LOG(Error in minimum_uid: %s,
+ strerror(errno));
+ return (PAM_SERVICE_ERR);
+ }
+ } else if (minuid UID_MAX) {
Err, you should be range checking an uncasted unsigned long
value against UID_MAX because by casting it to (uid_t) this
condition is always false. On 32-bit platforms where long
is 4 bytes it's moot anyway, but on 64-bit platforms with
8-byte longs it will make a difference. I think a correct
code would look something like this (assuming it's guaranteed
that sizeof(uid_t) = sizeof(long) ;-):
: unsigned long val;
:
: val = strtoul(retstr, NULL, 10);
: if ((val == ULONG_MAX errno == ERANGE) ||
: (val == 0 errno == EINVAL))
: /* error1 */
: else if (val UID_MAX)
: /* error2 */
: else
: uid = (uid_t)val;
+ PAM_LOG(Error in minimum_uid: invalid UID);
+ return (PAM_SERVICE_ERR);
+ }
+ }
It probably makes sense to initialize minuid = 0 only here (in
the else clause), rather than doing it in the declaration part.
+
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_GID);
+ if (retstr != NULL) {
+ if ((mingid = (gid_t)strtoul(retstr, NULL, 10)) == 0) {
+ if (errno == ERANGE || errno == EINVAL) {
+ PAM_LOG(Error in minimum_gid: %s,
+ strerror(errno));
+ return (PAM_SERVICE_ERR);
+ }
+ } else if (mingid GID_MAX) {
+ PAM_LOG(Error in minimum_gid: invalid GID);
+ return (PAM_SERVICE_ERR);
+ }
+ }
+
+ if (pwd-pw_uid minuid || pwd-pw_gid mingid)
+ return (PAM_IGNORE);
Ditto for the GID code.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpfD2rHnQDuM.pgp
Description: PGP signature
Re: m_free() in if_bridge
On Wed, Nov 08, 2006 at 04:37:34PM +0200, Jacques Fourie wrote: While browsing through if_bridge.c I noticed that if the bridge interface is in monitoring mode, m_free() gets called on the packet after passing it to BPF. Should this not be m_freem() instead or am I missing something? The code in question can be found in the bridge_input() function, line 1877 in if_bridge.c. It's been fixed already: : revision 1.85 : date: 2006/11/05 17:56:25; author: csjp; state: Exp; lines: +1 -1 : Fix possible leak when bridge is in monitor mode. Use m_freem() which will : free the entire chain, instead of using m_free() which will free just the : mbuf that was passed. : : Discussed with: thompsa : MFC after: 3 days Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpunGeIg36Kh.pgp Description: PGP signature
Re: RFC: pam_krb5: minimum_[ug]id options
On Wed, Nov 08, 2006 at 09:28:30PM +, Shaun Amott wrote:
While fiddling with PAM, it came to my attention that the pam_krb5
module in some other (Linux?) PAM implementations supports, amongst
other things, a minimum_uid option. This makes it possible to skip over
Kerberos authentication for local system accounts, like so:
authrequiredpam_krb5.sono_warn minimum_uid=1000
authrequiredpam_unix.sono_warn try_first_pass
I think it'd a nice addition to our pam_krb5 at least.
I've attached an initial patch. Comments/review welcome.
OK.
Index: pam_krb5.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.8,v
retrieving revision 1.6
diff -u -r1.6 pam_krb5.8
--- pam_krb5.824 Nov 2001 23:41:32 - 1.6
+++ pam_krb5.88 Nov 2006 20:50:35 -
@@ -108,6 +108,13 @@
.Ql %p ,
to designate the current process ID; can be used in
.Ar name .
+.It Cm minimum_uid Ns = Ns Ar id
+Do not attempt to authenticate users with a uid below
^^^ UID
+.Ar id .
+Instead, simply return; thus allowing a later module to authenticate
+the user.
+.It Cm minimum_gid Ns = Ns Ar id
+As above, but specifies a minimum group.
^ group ID or GID
Also, it could be explicit about this being a primary GID.
.El
.Ss Kerberos 5 Account Management Module
The Kerberos 5 account management component
Document date should be bumped (the .Dd macro).
Index: pam_krb5.c
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.c,v
retrieving revision 1.23
diff -u -r1.23 pam_krb5.c
--- pam_krb5.c7 Jul 2005 14:16:38 - 1.23
+++ pam_krb5.c8 Nov 2006 20:50:36 -
@@ -90,6 +90,8 @@
#define PAM_OPT_FORWARDABLE forwardable
#define PAM_OPT_NO_CCACHEno_ccache
#define PAM_OPT_REUSE_CCACHE reuse_ccache
+#define PAM_OPT_MINIMUM_UID minimum_uid
+#define PAM_OPT_MINIMUM_GID minimum_gid
Defines were sorted alphabetically by a defined name.
/*
* authentication management
@@ -110,6 +112,9 @@
const char *user, *pass;
const void *sourceuser, *service;
char *principal, *princ_name, *ccache_name, luser[32], *srvdup;
+ const char *retstr;
+ uid_t minuid = 0;
+ gid_t mingid = 0;
retval = pam_get_user(pamh, user, USER_PROMPT);
if (retval != PAM_SUCCESS)
@@ -222,6 +227,21 @@
PAM_LOG(Done getpwnam());
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_UID);
+
Extraneous empty line.
+ if (retstr)
^ missing != NULL
+ minuid = (uid_t)strtoul(retstr, NULL, 10);
Errors are silently ignored; limit (UID_MAX) isn't checked.
+
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_GID);
+
+ if (retstr)
+ mingid = (gid_t)strtoul(retstr, NULL, 10);
+
Ditto but s/UID_MAX/GID_MAX/.
+ if (pwd-pw_uid minuid || pwd-pw_gid mingid)
+ return (PAM_IGNORE);
+
+ PAM_LOG(Checked uid and gid bounds);
+
/* Get a TGT */
memset(creds, 0, sizeof(krb5_creds));
krbret = krb5_get_init_creds_password(pam_context, creds, princ,
@@ -349,6 +369,9 @@
const void *user;
void *cache_data;
char *cache_name_buf = NULL, *p;
+ const char *retstr;
+ uid_t minuid = 0;
+ gid_t mingid = 0;
uid_t euid;
gid_t egid;
@@ -391,6 +414,30 @@
PAM_LOG(Got euid, egid: %d %d, euid, egid);
+ /* Get the uid. This should exist. */
+ pwd = getpwnam(user);
+ if (pwd == NULL) {
+ retval = PAM_USER_UNKNOWN;
+ goto cleanup3;
+ }
+
+ PAM_LOG(Done getpwnam());
+
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_UID);
+
+ if (retstr)
+ minuid = (uid_t)strtoul(retstr, NULL, 10);
+
+ retstr = openpam_get_option(pamh, PAM_OPT_MINIMUM_GID);
+
+ if (retstr)
+ mingid = (gid_t)strtoul(retstr, NULL, 10);
+
+ if (pwd-pw_uid minuid || pwd-pw_gid mingid)
+ return (PAM_IGNORE);
+
+ PAM_LOG(Checked uid and gid bounds);
+
/* Retrieve the temporary cache */
retval = pam_get_data(pamh, ccache, cache_data);
if (retval != PAM_SUCCESS) {
@@ -405,15 +452,6 @@
goto cleanup3;
}
- /* Get the uid. This should exist. */
- pwd = getpwnam(user);
- if (pwd == NULL) {
- retval = PAM_USER_UNKNOWN;
- goto cleanup3;
- }
-
- PAM_LOG(Done getpwnam());
-
/* Avoid following a symlink as root */
if (setegid(pwd-pw_gid)) {
retval = PAM_SERVICE_ERR;
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpEGzGpWOdwY.pgp
Description: PGP signature
Re: Puzzling variables behaviour in make(1)
On Sun, Nov 05, 2006 at 09:04:47PM +0100, Jeremie Le Hen wrote:
Hello,
I wrote the following piece of Makefile:
% .warning VAR contains: ${VAR}
%
% VAR_BACKUP:= ${VAR}
% VAR:= value2
%
% .if ${VAR} == value2
% .warning VAR is overwritable: ${VAR}
% .else
% .warning VAR is NOT overwritable: ${VAR}
% .endif
%
% VAR:= ${VAR_BACKUP}
%
% all:
If I define VAR within the Makefile (VAR:= value1), I get:
% jarjarbinks:~/test/makevars:230# make
% Makefile, line 3: warning: VAR contains: value1
% Makefile, line 7: warning: VAR is overwritable: value2
If I remove the VAR assignment in the Makefile and define it from
the command -line, I get:
% jarjarbinks:~/test/makevars:232# make VAR=value1
% Makefile, line 3: warning: VAR contains: value1
% Makefile, line 9: warning: VAR is NOT overwritable: value2
Note that this behaviour is puzzling since it follows the path as if
{VAR} didn't contain value2 but the warning message shows it does
contains value2.
Finally, if I define VAR both from the command-line and within the
Makefile:
% jarjarbinks:~/test/makevars:242# make VAR=value1
% Makefile, line 3: warning: VAR contains: value1
% Makefile, line 11: warning: VAR is NOT overwritable: value2
Same weird behaviour.
Actually I am trying to find a way to tell whether a variable has
been defined from make.conf(5) or src.conf(5) or from the command-line.
According to the code path this method appears to work, but the
value of ${VAR} isn't correct.
If this is the expected behaviour, I'd be glad to understand the magic
behind this.
Command-line variables are of the highest precedence.
%%%
Index: parse.c
===
RCS file: /home/ncvs/src/usr.bin/make/parse.c,v
retrieving revision 1.111
diff -u -p -r1.111 parse.c
--- parse.c 22 Jul 2006 14:00:31 - 1.111
+++ parse.c 5 Nov 2006 21:09:51 -
@@ -2231,7 +2231,7 @@ parse_message(char *line, int iserror, i
while (isspace((u_char)*line))
line++;
- line = Buf_Peel(Var_Subst(line, VAR_GLOBAL, FALSE));
+ line = Buf_Peel(Var_Subst(line, VAR_CMD, FALSE));
Parse_Error(iserror ? PARSE_FATAL : PARSE_WARNING, %s, line);
free(line);
%%%
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpK0Wu8zSnl8.pgp
Description: PGP signature
Re: src.conf(5) seems to affect ports build
On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
I still don't understand why my patch created a problem for you.
This option is not in bsd.own.mk, so it's not covered by my patch.
All my patch does is don't process /etc/src.conf which is entirely
for src/.
So, you can continue to use your bsd.ssp.mk as before, and my patch
shouldn't influence it.
If you want to really mimic the standard behavior, then bsd.ssp.mk
should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
to yes/no, accordingly; setting MK_SSP by a user shouldn't be
allowed or supported. You then set WITH_SSP= in /etc/make.conf
(or in /etc/src.conf if you want it only for src/), or pass
-DWITH_SSP on the make command line, and you're done.
P.S. There has been a patch floating around that adds support for
/etc/ports.conf. That would allow for clear separation:
src.confsrc/ only settings;
ports.conf ports/ only settings;
make.conf all-time settings, including when building
src/ and ports/.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpABFizcnWOK.pgp
Description: PGP signature
Re: src.conf(5) seems to affect ports build
On Tue, Oct 24, 2006 at 04:23:40PM +0100, Florent Thoumie wrote:
On Tue, 2006-10-24 at 17:48 +0400, Ruslan Ermilov wrote:
On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the
future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
I still don't understand why my patch created a problem for you.
This option is not in bsd.own.mk, so it's not covered by my patch.
All my patch does is don't process /etc/src.conf which is entirely
for src/.
So, you can continue to use your bsd.ssp.mk as before, and my patch
shouldn't influence it.
If you want to really mimic the standard behavior, then bsd.ssp.mk
should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
to yes/no, accordingly; setting MK_SSP by a user shouldn't be
allowed or supported. You then set WITH_SSP= in /etc/make.conf
(or in /etc/src.conf if you want it only for src/), or pass
-DWITH_SSP on the make command line, and you're done.
P.S. There has been a patch floating around that adds support for
/etc/ports.conf.
[...] that you sent :-)
Could try to revive the thread with a new patch.
Better just commit something. :-)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpX7PM4nLBD5.pgp
Description: PGP signature
Re: src.conf(5) seems to affect ports build
On Sat, Oct 21, 2006 at 06:26:35PM +0200, Jeremie Le Hen wrote: Hi Ruslan, On Fri, Oct 20, 2006 at 11:13:32PM +0400, Ruslan Ermilov wrote: On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote: Hi, src.conf(5) manual page states: % The src.conf file contains settings that will apply to every build % involving the FreeBSD source tree; see build(7). % ... % The only purpose of src.conf is to control the compilation of the FreeBSD % sources, which are usually found in /usr/src. However, share/mk/bsd.port.mk includes bsd.own.mk which in turn includes /etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it which affects CFLAGS, they will be taken into account even for port builds. Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid modifying CFLAGS (though I think this might become useful in the near future). See if the attached patch helps. If it does, I'll commit. I've never heard back on this patch after I sent it to [EMAIL PROTECTED] This patch works correctly. Would you explain me why assigning /dev/null to _SRCCONF don't work in the current version of bsd.port.mk ? 1) It's spelled SRCCONF. 2) Even if spelled correctly, setting it to /dev/null doesn't prevent MK_* variables to be set to their default values: cd /usr/src make showconfig SRCCONF=/dev/null Also, your patch avoids performing the WITH(OUT)_* stuff for ports in order to prevent from polluting the namespace. If there is to be some WITH(OUT)_* knobs which leads to CFLAGS modification in the future (I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it be worth benefiting this framework for ports ? It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put WITH(OUT)_* in /etc/make.conf it will still be picked up. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDKhRANkkH4.pgp Description: PGP signature
Re: src.conf(5) seems to affect ports build
On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote:
Hi,
src.conf(5) manual page states:
% The src.conf file contains settings that will apply to every build
% involving the FreeBSD source tree; see build(7).
% ...
% The only purpose of src.conf is to control the compilation of the FreeBSD
% sources, which are usually found in /usr/src.
However, share/mk/bsd.port.mk includes bsd.own.mk which in turn includes
/etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it
which affects CFLAGS, they will be taken into account even for port builds.
Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid
modifying CFLAGS (though I think this might become useful in the near
future).
See if the attached patch helps. If it does, I'll commit. I've
never heard back on this patch after I sent it to [EMAIL PROTECTED]
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
Index: bsd.own.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.57
diff -u -p -r1.57 bsd.own.mk
--- bsd.own.mk 30 Sep 2006 11:32:46 - 1.57
+++ bsd.own.mk 30 Sep 2006 20:31:16 -
@@ -104,10 +104,12 @@
.if !target(__bsd.own.mk__)
__bsd.own.mk__:
+.if !defined(_WITHOUT_SRCCONF)
SRCCONF?= /etc/src.conf
.if exists(${SRCCONF})
.include ${SRCCONF}
.endif
+.endif
# Binaries
BINOWN?= root
@@ -170,6 +172,7 @@ STRIP?= -s
COMPRESS_CMD?= gzip -cn
COMPRESS_EXT?= .gz
+.if !defined(_WITHOUT_SRCCONF)
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
@@ -447,5 +450,6 @@ MK_${var}_SUPPORT:= no
MK_${var}_SUPPORT:= yes
.endif
.endfor
+.endif # !_WITHOUT_SRCCONF
.endif # !target(__bsd.own.mk__)
Index: bsd.port.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.port.mk,v
retrieving revision 1.308
diff -u -p -r1.308 bsd.port.mk
--- bsd.port.mk 24 Aug 2006 18:04:49 - 1.308
+++ bsd.port.mk 26 Aug 2006 13:55:59 -
@@ -3,8 +3,9 @@
PORTSDIR?= /usr/ports
BSDPORTMK?=${PORTSDIR}/Mk/bsd.port.mk
-# Needed to keep bsd.own.mk from reading in /etc/src.conf when building ports.
-SRCCONF= /dev/null
+# Needed to keep bsd.own.mk from reading in /etc/src.conf
+# and setting MK_* variables when building ports.
+_WITHOUT_SRCCONF=
.include bsd.own.mk
.include ${BSDPORTMK}
pgpHcA50rvwUG.pgp
Description: PGP signature
Re: truncate tool - must be root?
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote: Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) If you speak about truncate(1), it works here under non-root: $ uname -sr FreeBSD 7.0-CURRENT $ dd if=/dev/zero of=foo bs=64k count=10 10+0 records in 10+0 records out 655360 bytes transferred in 0.002590 secs (253040511 bytes/sec) $ id -u 1001 $ truncate -s 0 foo $ ls -l foo -rw--- 1 ru ru 0 May 30 19:21 foo $ -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpc9Cj4qTgpw.pgp Description: PGP signature
Re: FreeBSD 6.1-RELEASE - make distribution
On Mon, May 29, 2006 at 10:56:54AM -0300, Cesar wrote: I noticed that FreeBSD 6.1-RELEASE produce an error while trying to make distribution. Is this changed or just a small bug? Neither. It just tells you the truth -- you don't have the /tmp/distro/etc directory since you forgot to run make distrib-dirs. [EMAIL PROTECTED] /usr/src]# make distribution DESTDIR=/tmp/distro cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distribution cd /usr/src/etc; install -o root -g wheel -m 644 amd.map apmd.conf auth.conf crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf portsnap.conf pf.conf pf.os phones profile protocols rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells snmpd.config sysctl.conf syslog.conf usbd.conf etc.i386/ttys /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../usr.bin/locate/locate/locate.rc printcap /tmp/distro/etc; cap_mkdb -l /tmp/distro/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /tmp/distro/etc; install -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /tmp/distro/etc; pwd_mkdb -L -i -p -d /tmp/distro/etc /tmp/distro/etc/master.passwd install: wrong number or types of arguments usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... *** Error code 64 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [EMAIL PROTECTED] /usr/src]# ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpvWmJjKBQLo.pgp Description: PGP signature
Re: world's toolchain CPUTYPE
On Wed, Mar 01, 2006 at 06:02:26AM +0300, Alex Semenyaka wrote:
On Tue, Feb 28, 2006 at 10:19:11AM +0200, Ruslan Ermilov wrote:
Isn't is reasonable to add corresponding optional functionality
into the buld process?
No.
Why? :)
I think I've explained this in the non-quoted here part.
For example, if -DSTATIC_TOOLCHAIN (or
pick any other name) is set, then:
1) build toolchain statically linked
This is already the case (${XMAKE} has -DNO_SHARED).
Oh, great. Could we also add -DNO_MAKE_CONF then?
Or at least -DTOOLCHAIN_NO_MAKE_CONF :)
That's would be enough. Or do I miss something?
What problem are you trying to attack, I fail to see?
-DNO_CPU_CFLAGS is already there, if that's what you mean:
BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \
${BMAKEENV} ${MAKE} -f Makefile.inc1 \
DESTDIR= \
BOOTSTRAPPING=${OSRELDATE} \
-DNO_HTML -DNO_INFO -DNO_LINT -DNO_MAN -DNO_NLS -DNO_PIC \
-DNO_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS
^^^
XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} -DNO_FORTRAN -DNO_GDB
... and has the following effect:
$ make -V CFLAGS CPUTYPE=opteron
-O2 -fno-strict-aliasing -pipe -march=opteron
$ make -V CFLAGS CPUTYPE=opteron -DNO_CPU_CFLAGS
-O2 -fno-strict-aliasing -pipe
But it doesn't really matter since building host's libraries that
ARE used to build toolchain might have been built using optimized
CFLAGS. See other posts where people go into more details what
should be the conditions to allow NFS-mounted src/ installs.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpQOgnRb78KL.pgp
Description: PGP signature
Re: world's toolchain CPUTYPE
On Mon, Feb 27, 2006 at 01:15:02PM +0300, Yar Tikhiy wrote: What's really fun is tricking the build system so you can cross build on one system, but native install on another from the same tree... I wondered, too, if it would be possible to cross-build install tools so that they could run on the target system, but I haven't investigated this way yet. Do you have any ideas/recipes? Thanks! Well, the tools you want were already built, for the target host. But you might not be able to install and run them (they may require a new syscall, some new shared libraries, etc.). The tools that you intend to run on host I during the install should either be compiled on this host (using its libraries, preferably statically linked), or on a compatible host in a compatible build environment. So it all depends on how similar the hosts B and I and their build environments are. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpvr24TkJVjh.pgp Description: PGP signature
Re: world's toolchain CPUTYPE
On Tue, Feb 28, 2006 at 07:45:20AM +0300, Alex Semenyaka wrote:
On Sun, Feb 26, 2006 at 08:57:21PM +0200, Ruslan Ermilov wrote:
More details: during the install, part of the toolchain and
some special install tools that were built on the build
host are used. They have been built using that host's
toolchain, CFLAGS, libraries, etc., but libraries is the
most important factor. That means that the install host
should be CPU/syscall/etc. compatible with the build
Isn't is reasonable to add corresponding optional functionality
into the buld process?
No.
For example, if -DSTATIC_TOOLCHAIN (or
pick any other name) is set, then:
1) build toolchain statically linked
This is already the case (${XMAKE} has -DNO_SHARED).
2) use newly built libraries to link instead of libraries of
build host
Impossible. The tools are built to be run on the build host.
(Some of them are also run on the install host, e.g. strip(1)).
Also, you cannot link with new libraries before you built them,
and these tools are needed to build the new libraries.
It does not look dangerous, and it will break nothing since
administrator will hav to take special action to turn it on.
It's certainly dangerous.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpAf3k2u1GXv.pgp
Description: PGP signature
Re: world's toolchain CPUTYPE
On Mon, Feb 27, 2006 at 05:24:42AM +1100, Peter Jeremy wrote: [...] The supported approach is to NFS mount the target onto the buildhost and use make DESTDIR=/target installworld ... and to make it work, make sure to chflags -R noschg the target / on the target host first. (I upgrade all my animals in a zoo this way, from the Hammer.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplC58AqacEg.pgp Description: PGP signature
Re: world's toolchain CPUTYPE
On Sun, Feb 26, 2006 at 06:50:09PM +0300, Yar Tikhiy wrote: Hi all, Yesterday I hit the following problem: - was given an Athlon XP machine with a fresh CURRENT built with CPUTYPE=athlon-xp; - used it to build a fresh RELENG_6 world with no customizations at all -- __MAKE_CONF=/dev/null; - tried to install the world over NFS on an old Pentium machine with some 5.3-BETA; - make installkernel failed instantly because install(1) died on signal 4, illegal instruction. Quick investigation showed that the world was built using generic i386 code, as expected, but its toolchain was linked against the builder system libs contaminated by Athlon-specific code. It was sufficient to rebuild and reinstall all libs on the builder machine with no particular CPUTYPE set and then to rebuild the world's toolchain again to make the latter run well on the Pentium. I used to be under impression that a world's toolchain should be fairly independent from the builder system. However, this case showed that it wasn't quite true. Is it a known issue, or am I missing a key point? Thanks! Simple answer: we just don't support installing from NFS, but we do support installing to NFS. Any documentation that says it's supported is lying. More details: during the install, part of the toolchain and some special install tools that were built on the build host are used. They have been built using that host's toolchain, CFLAGS, libraries, etc., but libraries is the most important factor. That means that the install host should be CPU/syscall/etc. compatible with the build host. When build == install, all these conditions are met. When CPUs match, kernels may be different enough so there will be missing syscalls. And so far... Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpSNCOcrJOOg.pgp Description: PGP signature
Re: Loading gzipped mfsroot
On Mon, Nov 28, 2005 at 04:38:11PM +0200, Iasen Kostov wrote: On Mon, 2005-11-28 at 09:18 -0500, David S. Madole wrote: From: Iasen Kostov [EMAIL PROTECTED] I've seen a lot of examples where peeple load gzipped mfsroot images and everything looks fine for them, but not for me. It loads uncompressed image and boots ok, it loads compressed image and does not uncompress it and then tries to mount ufs directly on it which fails ofcourse. As I saw bay default loader(and pxeboot porbably - its a diskless machine which boots over ethernet) have LOADER_GZIP_SUPPORT defined so I think I should have gzip support in loader. Here is the loader.conf: rootfs_load=YES rootfs_name=dlroot.gz rootfs_type=mfs_root I've not users this in quite a while, so I may be wrong here, but I think what you need is: rootfs_name=dlroot If gzip support is compiled in, it will automatically try to fetch dlroot.gz first and if it succeeds, it will uncompress and use it. The way you have configured it, it tries dlroot.gz.gz, which fails, so then it tried to load dlroot.gz as an uncompressed file. David Thanks a lot ! That do the trick :) It will realy be good if this is documented somewhere - probably in loader(8) manual page ... And will save people some hours of blessing loader(8) :) loader(8) has no business documenting this; it's already documented (though not too verbose) in the libstand(3) manpage. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpcn5ZjfD1SF.pgp Description: PGP signature
Re: correct use of bus_dmamap_sync
On Tue, Oct 25, 2005 at 04:10:52PM -0400, John Baldwin wrote: On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: [...] thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. Yes, I know. :) Please go read the HEAD version of the manpage; it's been fixed recently to improve the description of these details. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpN3gKadHm2L.pgp Description: PGP signature
Re: FreeBSD-* files in non-HEAD branches
Hi, On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? At least is makes it easy to view diffs between branches. I'd prefer it if you don't remove them from src/contrib/groff/ and src/contrib/texinfo/ at least that I maintain. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpY5f1FxA5IO.pgp Description: PGP signature
Re: How to make use of the current source tree's include file?
Hi Xin,
On Sun, Jun 12, 2005 at 11:34:04PM +0800, Xin LI wrote:
I am recently working on a patchset that would provide mini-crashdump
which needs to include a newly added include file into /sys/sys/ from
the kgdb(1) source code. I have used the following line to make this
possible, in the latter's Makefile:
CFLAGS+= -I${.CURDIR}/../../../../sys/
However I'm under the impression that there is some better ways to
archive this, will you please give me some hints?
This line would be redundant when you make buildworld -- in this
case, the fresh headers are used.
But if you are looking for a way to compile a program with a new
(previously non-existent) header, the above makes sense.
Alternatively, you can make .. DEBUG_FLAGS=-I${.CURDIR}/.../sys
without modifying the makefile.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgp2I4MhpT5L1.pgp
Description: PGP signature
Re: How to do a routing lookup inside the kernel in FreeBSD ?
On Thu, Jun 09, 2005 at 05:42:16PM -0400, Aziz Kezzou wrote: Hi all, I am trying to figure out from the kernel source code (FreeBSD 5.3) how can I perform a routing lookup in a KLD module. Since I am short in time, if anyone knows how do to do this I would appreciate. Any pointers to the right portion of the code are also apperciated. man 9 rtalloc Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplMLIfk8hyC.pgp Description: PGP signature
Re: Bootable CDROM creation system
On Thu, Jun 09, 2005 at 08:35:59AM +0200, Dag-Erling Sm?rgrav wrote: Chad David [EMAIL PROTECTED] writes: My company built a tool a few years back for creating a bootable cdrom based on a running host FreeBSD 3/4 system, which promptly got shelved and forgotten.I recently had to update it for FreeBSD 5 and thought that perhaps the community at large could make use it before it gets forgotten again. # cd /usr/src # make buildworld buildkernel # mkdir /tmp/cdrom # make installworld installkernel DESTDIR=/tmp/cdrom # cd /usr/src/etc # make distribution DESTDIR=/tmp/cdrom # mkisofs -o /tmp/cdrom.iso -r -no-emul-boot -b /tmp/cdrom/boot/cdboot /tmp/cdrom # burncd -s max data /tmp/cdrom.iso fixate eject did I leave anything out? :-) -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp7Tyj0rPmXj.pgp Description: PGP signature
Re: Makefile .for and .if expansion
Hi Kris,
On Sat, Feb 12, 2005 at 06:32:01PM -0800, Kris Kennaway wrote:
The following small makefile doesn't behave as one would naively
expect:
MANLANG?=foo
all:
.for i in ${MANLANG}
.if empty(${i})
@echo foo ${i}
.endif
.endfor
ports-i386%make
foo foo
foo
I think this is because the .if evaluation is happening too early, and
it's not being done after the .for loop is expanded and the i variable
is set.
This makefile is broken, you're abusing empty(). empty() expects
a variable name (without `$') as an argument, and ``.if empty(foo)''
means true if ${foo} has an empty value. Note that in 4.x, foo
also needs to be a defined variable, for this to work at all. In
5.x and 6.x, undefined variables are treated like empty variable
by empty().
In order to get this to work I seem to have to do the following:
MANLANG?=foo
.for i in ${MANLANG}
j= ${i}
.if (${j} != \\)
.for l in ${j}
k+= ${l}
.endfor
.endif
.endfor
all:
@echo ${k}
ports-i386%make
foo
If I remove the inner .for it breaks, and if I remove the j assignment
it breaks. Also if I try and remove the use of k and put an echo
inside the inner .for (with the all: preceding the whole loop) it
breaks.
This is extremely nasty.
Yes. This behavior is documented in the BUGS section of the make(1)
manpage: .for loops are unrolled before tests, and .for variables
aren't real variables, so a fragment like this:
.for i in foo bar
.if ${i} == foo
echo ${i}
.endif
.endfor
doesn't work. This fragment is rewritten by make(1) before further
parsing as follows:
.if foo == foo
echo foo
.endif
.if bar == foo
echo bar
.endif
And since .if expects a ${variable} as its first argument, it fails.
About why you need an inner loop. Remember again that .for loops
are unrolled before parsing, it means that a fragment like this:
.for i in foo bar
j=${i}
k+=${j}
.endfor
is equivalent to
j=foo
k+=${j}
j=bar
k+=${j}
which means that `k' will get a value of bar bar. When you use
an inner loop,
.for i in foo bar
j=${i}
.for l in ${j}
k+=${l}
.endfor
.endfor
it first gets rewritten to:
j=foo
.for l in ${j}
k+=${l}
.endfor
j=bar
.for l in ${j}
k+=${l}
.endfor
then to:
j=foo
k+=foo
j=bar
k+=bar
which DTRT, but also has a side effect of setting j to bar.
Am I missing an easier way to do this?
May I suggest the following instead:
%%%
MANLANG?= foo bar
all:
.for i in ${MANLANG:N}
@echo foo ${i}
.endfor
%%%
Note that `' is not an empty value in make(1), it's just a
regular value consisting of two double quotes.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpjj2c9e1zVG.pgp
Description: PGP signature
Re: Patch to be commited.
On Tue, Dec 14, 2004 at 07:55:35PM -0600, Mike Meyer wrote: I just spent three days trying various source trees and kernel configs down a bug. My bad - I should have checked the bugs database first. My second query turned up kern/71130, which contains a patch that fixes the compilation problem I was having. I can confirm that it works as advertised. Now, could some nice committer please commit this so I don't have to fix it again next time I upgrade? Done, enjoy! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpNzjX1cczTx.pgp Description: PGP signature
Re: embedded assembler in .c files
On Wed, Dec 15, 2004 at 03:09:23PM +0100, Andre Oppermann wrote: I'm trying to access an assembler CPU instructions from within a normal .c file and function. Unfortunatly I have no idea how this works. If you know how to do this please contact me directly. Any help appreciated. find /usr/src/lib/libc -name '*.c' | xargs grep -l __asm__ Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDsjkIUxXLX.pgp Description: PGP signature
Re: A hack to rebuild port KLDs during kernel builds
On Mon, Nov 29, 2004 at 10:54:26PM +1030, Daniel O'Connor wrote: Hi, I have a few third party KLDs on my system (nvidia, acpi_ppc, dell, if_ndis) and it's quite annoying to have to rebuild them each kernel build, or upgrade. I have thought about putting them in /boot/modules but I have had this crash on my fairly often (esp since I am running -current). If you want to try it.. Apply the diff and make /usr/local/kld and copy port-makefile.txt there as Makefile. Note that (obviously) the ports need to be tweaked to install the driver source and build infrastructure there, but that's not too hard (to do by hand for now anyway). I have the 4 I mentioned building just fine with 5 minutes work. Any chance you can use the recently added PORTS_MODULES knob to do what you want? : # cvs -R log -N -r1.71 kern.post.mk : : RCS file: /home/ncvs/src/sys/conf/kern.post.mk,v : Working file: kern.post.mk : head: 1.73 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 74;selected revisions: 1 : description: : : revision 1.71 : date: 2004/11/11 23:58:14; author: imp; state: Exp; lines: +14 -0 : PORTS_MODULES: a list of ports to build with this kernel. : : # I directly use the targets for building this, but it was suggested : # to use portupgrade. I couldn't fit that into the target model, so I : # punted. : = Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpIz0SLAWTYY.pgp Description: PGP signature
Re: boot serial console speed
On Sun, Nov 14, 2004 at 10:39:13AM +0200, Danny Braniss wrote: what's the magic encantation to set the console to 38400? btw, i solved my problem by just commenting out that part of the code, since i rely on the bios setting it. from src/sys/boot/i386/boot0/Makefile: # Comm settings for boot0sio. 0xE3 = 9600 8-N-1 # XXX: We should create a build-tool or something to convert BOOT_CONSOLE_SPEED # and BOOT_COMCONSOLE_PORT into the correct values to define on the build # command line BOOT_BOOT0_COMCONSOLE_SPEED?= 0xE3 This is the value passed in the AL register to the Int 14/AH=00h BIOS function: http://www.ctyme.com/intr/rb-0811.htm : Bit(s) Description (Table 00300) : 7-5data rate (110,150,300,600,1200,2400,4800,9600 bps) : 4-3parity (00 or 10 = none, 01 = odd, 11 = even) : 2 stop bits (set = 2, clear = 1) : 1-0data bits (00 = 5, 01 = 6, 10 = 7, 11 = 8) 0xE3 = 111-00-0-11 = 9600 bps, no parity, 1 stop bit, 8 data bits But I think it's not possible to set it to anything above 9600 bps using this BIOS call. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0g6jH8W9BY.pgp Description: PGP signature
Re: boot serial console speed
On Sun, Nov 14, 2004 at 11:38:50AM +0200, Ruslan Ermilov wrote:
On Sun, Nov 14, 2004 at 10:39:13AM +0200, Danny Braniss wrote:
what's the magic encantation to set the console to 38400?
btw, i solved my problem by just commenting out that part of the code,
since i rely on the bios setting it.
from src/sys/boot/i386/boot0/Makefile:
# Comm settings for boot0sio. 0xE3 = 9600 8-N-1
# XXX: We should create a build-tool or something to convert
BOOT_CONSOLE_SPEED
# and BOOT_COMCONSOLE_PORT into the correct values to define on the build
# command line
BOOT_BOOT0_COMCONSOLE_SPEED?= 0xE3
This is the value passed in the AL register to the Int 14/AH=00h
BIOS function:
http://www.ctyme.com/intr/rb-0811.htm
: Bit(s) Description (Table 00300)
: 7-5data rate (110,150,300,600,1200,2400,4800,9600 bps)
: 4-3parity (00 or 10 = none, 01 = odd, 11 = even)
: 2 stop bits (set = 2, clear = 1)
: 1-0data bits (00 = 5, 01 = 6, 10 = 7, 11 = 8)
0xE3 = 111-00-0-11 = 9600 bps, no parity, 1 stop bit, 8 data bits
But I think it's not possible to set it to anything above 9600 bps
using this BIOS call.
Attached is the patch that converts supported BOOT_COMCONSOLE_SPEED
values into corresponding BOOT_BOOT0_COMCONSOLE_SPEED. Unsupported
BOOT_COMCONSOLE_VALUES cause the boot0sio console speed to be set
to 9600.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
Index: Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/boot0/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile27 Aug 2004 00:18:03 - 1.30
+++ Makefile14 Nov 2004 10:04:36 -
@@ -21,11 +21,34 @@
# unless you are glutton for punishment.
BOOT_BOOT0_ORG?= 0x600
-# Comm settings for boot0sio. 0xE3 = 9600 8-N-1
-# XXX: We should create a build-tool or something to convert BOOT_CONSOLE_SPEED
-# and BOOT_COMCONSOLE_PORT into the correct values to define on the build
-# command line
-BOOT_BOOT0_COMCONSOLE_SPEED?= 0xE3
+# Comm settings for boot0sio.
+# Bit(s) Description
+# 7-5data rate (110,150,300,600,1200,2400,4800,9600 bps)
+# 4-3parity (00 or 10 = none, 01 = odd, 11 = even)
+# 2 stop bits (set = 2, clear = 1)
+# 1-0data bits (00 = 5, 01 = 6, 10 = 7, 11 = 8)
+.if !defined(BOOT_BOOT0_COMCONSOLE_SPEED)
+BOOT_COMCONSOLE_SPEED?=9600
+.if ${BOOT_COMCONSOLE_SPEED} == 9600
+BOOT_BOOT0_COMCONSOLE_SPEED= 7 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 4800
+BOOT_BOOT0_COMCONSOLE_SPEED= 6 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 2400
+BOOT_BOOT0_COMCONSOLE_SPEED= 5 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 1200
+BOOT_BOOT0_COMCONSOLE_SPEED= 4 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 600
+BOOT_BOOT0_COMCONSOLE_SPEED= 3 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 300
+BOOT_BOOT0_COMCONSOLE_SPEED= 2 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 150
+BOOT_BOOT0_COMCONSOLE_SPEED= 1 5 + 3
+.elif ${BOOT_COMCONSOLE_SPEED} == 110
+BOOT_BOOT0_COMCONSOLE_SPEED= 0 5 + 3
+.else
+BOOT_BOOT0_COMCONSOLE_SPEED= 7 5 + 3
+.endif
+.endif
CFLAGS+=-DFLAGS=${BOOT_BOOT0_FLAGS} \
-DTICKS=${BOOT_BOOT0_TICKS} \
pgpPATDGXUoKS.pgp
Description: PGP signature
Re: [CFR] Specify the lock(1) timeout unit
On Thu, Oct 21, 2004 at 04:32:08PM +0200, Simon L. Nielsen wrote: On 2004.10.21 14:37:10 +0300, Peter Pentchev wrote: Here's a little patch that teaches lock(1) about timeouts specified in seconds, hours, or days in addition to the minutes it currently assumes. I could commit this in a week if there are no objections. Wouldn't it be more natural to just append the time-unit type to the argument given to -t, e.g. -t 10s or -t 10h. That just seem like the more intuitive way to handle it to me... Note: this is a suggestion, not an objection to the original patch. Yes, please. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp1k9I6rgODg.pgp Description: PGP signature
Re: BTX scripting help
On Thu, Oct 07, 2004 at 11:00:06AM -0700, Kelly Hall wrote: Hi Folks, I'm trying to automate a sequence of BTX commands and I'm hitting some snags. I've got some minor forth experience, but it isn't enough. My machine uses the standard bootloader and doesn't present a menu for the user. By default, the machine boots a standard kernel and fs-image file and everything is happy. Sometimes, though, I want my users to be able to boot an alternate kernel and fs-image. To do this, what they do now is: - wait for the default kernel to start loading - hit the space bar - BTX breaks out and gives them a prompt - they type four commands: - unload - load /kernel - load -t md_image /altfs-image - boot I'd like to replace those four commands with one command to make things nicer for them. So I tried to define the obvious forth word: : altboot unload load /kernel load -t md_image /altfs-image boot ; which fails to compile because /kernel isn't a word. These all compile, but reboot when invoked : altboot unload s /kernel load ; \ reboots the box : altboot unload load s /kernel ; \ reboots the box : altboot unload . /kernel load ; \ reboots the box : altboot unload load . /kernel ; \ reboots the box I'm stumped. Any suggestions? Read the loader(8) manpage, it says: BUILTIN COMMANDS Loader's builtin commands take its parameters from the command line. Presently, the only way to call them from a script is by using evaluate on a string. : OK : altboot : s unload evaluate : s load /boot/kernel/kernel evaluate : s lsmod evaluate : ; : OK altboot : /boot/kernel/kernel data=0x5ce910+0x488e0 syms=[0x8+0x69798+0x8+0x56466] : 0xfc30: /boot/kernel/kernel (elf kernel, 0x6d6e00) : modules: splash.1 nfsserver.1 nfs4.1 nfs.1 if_gif.1 if_faith.1 ether.1 sysvshm.1 sysvsem.1 sysvmsg.1 cd9660.1 isa.1 pseudofs.1 procfs.1 msdosfs.1 usb.1 random.1 ppbus.1 pci.1 null.1 mpt.1 miibus.1 mem.1 ispfw.0 isp.1 sbp.1 fwe.1 firewire.1 ahc.1 ahc_pci.1 ahc_isa.1 ahc_eisa.1 cam.1 Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpTs6CKWCUlb.pgp Description: PGP signature
Re: How to customize a release?
Hi Chris,
On Thu, Sep 02, 2004 at 04:19:18PM -0400, John Baldwin wrote:
On Thursday 02 September 2004 04:07 pm, [EMAIL PROTECTED] wrote:
John,
Thanks for the quick reply.
There is a 'KERNELS' variable that is helpful.
I see this in the Makefile, but if I were to use KERNELS=MYKERNEL will
that prevent the other standard kernels from being built?
Let me know if you believe this is unclear and should be improved (from the
release(7) manpage):
: release.3Makes and installs the GENERIC kernel as well as any
^^^^^
: other kernels listed in KERNELS.
^^^
:
: KERNELS Specifies a list of additional kernel configura-
^
: tions to compile and install into the ``base'' dis-
: tribution. Each kernel is installed into
: /boot/config so that it can be booted from the
: loader via ``boot config''.
Also, look at LOCAL_PATCHES and LOCAL_SCRIPTS as far as how to patch a
release build. Note that you can include patches to
src/release/Makefile in LOCAL_PATCHES if need be. :)
LOCAL_PATCHES is what I'm using now (waiting for build to finish to see
how it worked). I was hoping for a way to populate the src tree without
doing a full release so I could create the patches, then run make release
only once (it took 5 hours on my devel system last time). At this point
I've already done that, but for the next time I'd like to work more
efficiently.
What do you mean, I don't get it?
BTW, I see I overlooked the RELEASENOUPDATE variable in the man page, so
that answers my question about preventing CVS updates on make rerelease.
Unfortunately make rerelease didn't rebuild anything in /R/stage (I got
ftp.1 is up to date). Am I supposed to delete the stage directories to
force a rebuild, or do I need to do a full release to incorporate any
minor changes?
I just delete the files in ${CHROOTDIR}/usr/obj/usr/src/release to get it to
rebuild the targets I want.
So do I.
One more hint: suppose you want to rebuild world inside the chroot. Then
you have two options with make rerelease: one is to *not* use RELEASENOUPDATE
-- it will then use CVS to update your source tree (beware this doesn't work
if you ran make release with EXTSRCDIR). Another is to run make rerelease
with RELEASENOUPDATE and remove ${CHROOTDIR}/tmp/.world_done before doing it.
In any case, buildworld will be rebuilt with -DNOCLEAN, which should be fast.
To force rebuild of other stages, you need to remove particular files under
${CHROOTDIR}/usr/obj/usr/src/release/ (as has been already mentioned).
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpKqVKAv3V9I.pgp
Description: PGP signature
Re: How to customize a release?
On Fri, Sep 03, 2004 at 01:04:19AM -0700, [EMAIL PROTECTED] wrote: Let me know if you believe this is unclear and should be improved (from the release(7) manpage): : release.3Makes and installs the GENERIC kernel as well as any ^^^^^ : other kernels listed in KERNELS. ^^^ : : KERNELS Specifies a list of additional kernel configura- ^ : tions to compile and install into the ``base'' dis- : tribution. Each kernel is installed into : /boot/config so that it can be booted from the : loader via ``boot config''. This must exist in the 5.x man pages, I'm working with 4.x systems : release.3 Builds and installs ``crypto'', ``krb4'' and ``krb5'' distri-butions. release.4 Makes and installs the GENERIC kernel. There is no reference to the KERNELS variable in the 4.x version of the man page although it does exist in the Makefile. So this explains why you think I hadn't RTFM ;-) Thanks for your help, between you and John I think I've got this mostly figured out. I've just updated the release(7) manapge in RELENG_4, merging all documentation changes from HEAD that were relevant. You might want to update and re-read it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpKOda3WZQXj.pgp Description: PGP signature
Re: How to customize a release?
On Thu, Sep 02, 2004 at 03:38:26PM -0400, John Baldwin wrote: On Thursday 02 September 2004 03:21 pm, [EMAIL PROTECTED] wrote: I'm looking for information on how to properly customize a FreeBSD distribution when using the make release framework. Specifically I need to modify some config files to default to serial console and fast baud rate, and use a custom kernel configuration (not just hack the GENERIC conf file). The documentation on the FreeBSD site covers how to build a release, but other than a few hints I'm not finding and references on the correct way to _customize_ the release. I did find a site that discusses building a release, mirroring the usr/src tree from that release directory, modifying the source, then creating a diff patch that's used on a subsequent make release. If it works as advertised, this is somewhat helpful other than waiting an entire day for multiple release builds to finish. Is there a way to populate the build area with the source, then apply my own patches prior to running a full make release? I tried make release.1 but this totally ignored my CHROOTDIR and tried to create /R in my root partition :-(. Also I noted that make rerelease updates the source from CVS which is undesirable in my case since I already have fresh source that was used to create patches, and if any of those original files changed my patches could fail. Can CVS updates be turned off for subsequent builds? Lastly, KERNCONF seems to have no relevance in make release. How can I force a non generic kernel to be used when building the release? There is a 'KERNELS' variable that is helpful. Also, look at LOCAL_PATCHES and LOCAL_SCRIPTS as far as how to patch a release build. Note that you can include patches to src/release/Makefile in LOCAL_PATCHES if need be. :) I'd say, please read the release(7) manpage. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpoiYMD5MKux.pgp Description: PGP signature
Re: make quickworld? (like in DragonFly)
On Sun, Aug 15, 2004 at 09:53:30AM -0700, Brooks Davis wrote: On Sat, Aug 14, 2004 at 10:03:37AM +0200, Geert Hendrickx wrote: On Wed, Aug 11, 2004 at 02:47:14PM +0200, Simon L. Nielsen wrote: On 2004.08.11 00:36:06 +0200, Geert Hendrickx wrote: Hi, is there any way (or could it be implemented) to rebuild only the changes in world and kernel sources after a cvsup? DragonFly BSD features make quickworld and make quickkernel which does exactly that. You can do that already: make buildworld buildkernel -DNOCLEAN Does adding NOCLEAN=true to /etc/make.conf have the same effect? Yes, but it's likely to attract flames because NOCLEAN does fail. If you forget it's in your make.conf there's a good chance you could report a bug that isn't a bug a waste a bunch of developer time. Yes, please don't use NOCLEAN routinely. It's certainly okay to use it if you started a clean build, it failed for some reason, you corrected a cause, and want to resume. If may also work if you've updated the sources, but no guarantees -- often it has been shown that make clean is necessary to remove some old cruft that now conflicts with the new sources. For example, if compiler sources have been updated, it can generate different code, but foo.o will only depend on foo.c, and will not be rebuilt if you use -DNOCLEAN. In short, don't use it if you don't fully understand all the consequences. ;) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpGOBsMPHhOT.pgp Description: PGP signature
Re: How to clean out old files after 'make world'?
On Tue, Jul 20, 2004 at 10:23:25PM +0300, Stas D.Myasnikov wrote: Hello! While doing 'make world' I used make.conf with couple on 'NO_*=yes', e.g. NO_KERBEROS=yes (I don't need Kerberos on my home computer). But after rebuilding world and install I saw the old binaries, configs, etc. of Kerberos and other parts of base that I didn't build. I had thought that install script removes all unneeded files, but it don't. How can I clean out this old binaries, configs, etc?.. Is there any automatic way to do this? I routinely use find(1) and some secret knowledge about files that do not change their timestamps between installworlds to clean up stale files. Fortunately there are not too much files that install with -C, less in 5.x than in 4.x. Also, Warner Losh worked on a project that would allow to remove files obsoleted between releases. I don't know what the current status of this project is, or if it's still alive. ;) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpuYagGAVB4Q.pgp Description: PGP signature
Re: RFC: -exit option for find(1)
On Fri, Jul 16, 2004 at 12:23:41AM -0700, Alfred Perlstein wrote: I'm up too late, this doesn't work because find returns success whenever it successfully runs thought everything. Perhaps the primary change to just -exit which would make find exit successfully, and if the primary is never encountered (ie. our find logic never hits it) find would exit with a non-zero exit status? Ideas? Better ideas? The reason I want this is to avoid extracting a tarball over a directory that has files in it that are newer than the tarball. Neither tar nor find seem to make this easy... [ `find . -type f -newer ../src.tar.gz |head -1 |wc -l` -eq 0 ] echo hi Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgptKBBVmt0E5.pgp Description: PGP signature
Re: make installworld for non-root user
On Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote: Hi all, is there an easy way for a non-root user to test the installworld target? I came up with make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ installworld but that one breaks in libexec/pt_chown (which has a hard-coded BINOWN=root). Perhaps I can't see the obvious solution? Many bits hardcode owners/groups/modes/flags, but it's still possible to install as non-root. In fact, buildworld already does this for you -- it uses src/tools/install.sh as INSTALL to do it (see the BMAKEENV setting in Makefile.inc1). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpCsKkhv5F4s.pgp Description: PGP signature
Re: make installworld for non-root user
On Wed, Jul 07, 2004 at 11:17:00AM +0200, Harti Brandt wrote:
On Wed, 7 Jul 2004, Ruslan Ermilov wrote:
REOn Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote:
RE
RE Hi all,
RE
RE is there an easy way for a non-root user to test the installworld target?
RE I came up with
RE
RE make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \
RE NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \
RE MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \
RE installworld
RE
RE but that one breaks in libexec/pt_chown (which has a hard-coded
RE BINOWN=root).
RE
RE Perhaps I can't see the obvious solution?
RE
REMany bits hardcode owners/groups/modes/flags, but it's still
REpossible to install as non-root. In fact, buildworld already
REdoes this for you -- it uses src/tools/install.sh as INSTALL
REto do it (see the BMAKEENV setting in Makefile.inc1).
So it seems that:
make SHAREOWN=harti SHAREGRP=harti INSTALL=sh `pwd`/release/install.sh \
DESTDIR=/somewhere installworld
almost works. Almost, because bsd.lib.mk contains
SHLINSTALLFLAGS += -fschg
That case is not handled in install.sh and should probably read
SHLINSTALLFLAGS += -f schg
Rather I've fixed install.sh (committed):
%%%
Index: install.sh
===
RCS file: /home/ncvs/src/tools/install.sh,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- install.sh 6 Feb 2004 11:00:13 - 1.6
+++ install.sh 7 Jul 2004 09:38:14 - 1.7
@@ -33,6 +33,7 @@
case $1 in
-[bCcMpSs]) shift;;
-[Bfgmo]) shift; shift;;
+-[Bfgmo]*) shift;;
*) break;
esac
done
%%%
Additionally I had to add
-fschg) shift;;
to install.sh, because it seems that the installworld target uses the
currently installed mk files not those from src/share/mk.
Not until you call installworld with make -fMakefile.inc1
Normally, src/Makefile is used and it calls installworld with
-m${.CURDIR}/share/mk. You can verify with ``make -n installworld''.
The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes
these directly to zic. This could probably be fixed by calling zic
during buildworld and just install the compiled files during installworld.
Yes, I've been thinking of doing this for some years now. I will see if
I can fix it easily, now that I have a good reason for it. ;)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpvD3HWRjNKh.pgp
Description: PGP signature
Re: device pooling and high interrupts
On Sat, Apr 24, 2004 at 01:14:26PM -0500, Mike Silbersack wrote: On Sat, 24 Apr 2004, GiZmen wrote: Hello, I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard is on VIA KT 266A with AMD athlon 1.1. I read man polling and i have HZ=1000. My problem is that when i set up sysctl variable kern.polling.enable=1 my interrupts greatly increase. When my system is idle and indicate 0-1% interrupts with out polling. and when i turn on polling interrupts goes up to about 20% on idle system. Is it normal ? I never before use polling and i dont know that i have something bad in my system ? Can somebody explain me this ? thx -- Best Regards: GiZmen Ruslan can probably jump in and give you a better explanation than I can, but I'll try to provide a quick answer. In short, the rl cards + driver are not well suited to polling and will not work well with it enabled. Support for polling on rl may in fact be removed as a result of this. Well, basically, 8139's TX/RX engine is just not worth for use with polling(4). Now that we have per-interface polling(4) controls, I suggest that we leave it _disabled_ for rl(4) by default. My tests have shown that I could only get a comparable throughput with rl(4) given HZ=5000, which is *ahem* quite large to be really useful. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: netgraph ability
[ Redirected to -net ] On Thu, Apr 22, 2004 at 05:50:57PM -0700, David Yeske wrote: I'm in a situation where I need to emulate multiple ethernet devices with different mac addresses. I have gotten far enough to have this. I ran ngctl and then ran mkpeer . eiface hook ether I then ran ifconfig ngeth0 link '00:bd:03:11:21:11' ifconfig ngeth0 192.168.20.5 ifconfig sis0 192.168.23.45 So basically I want to be able to ping / connect to 192.168.20.5 from another box on the 192.168.23.0/24 network, and have it see the mac address that I have set rather than the mac address of my sis0 device. I know I can do this with vmware, but I am trying to avoid that. Anyone know if this is possible? Is there a way to do this with the tap device and or arpd? Using Netgraph, you can emulate any number of Ethernet interfaces on one physical interface. Here's my recipe for you: 1. Load the ng_ether(4) module. 2. Create the required number of ng_eiface(4) nodes. 3. Connect lower and upper of sis0: and all ngethX: ng_ether(4) nodes to one ng_bridge(4). 4. Make sure to ngctl msg if: setautosrc 0 to all ng_ether(4) nodes. 5. Optionally set net.link.ether.inet.log_arp_wrong_iface=0. Here's my test (I've omitted obvious configuration steps): # ifconfig dc0 ether dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=48VLAN_MTU,POLLING ether 00:10:a4:c0:c0:45 # ifconfig ngeth0 ngeth0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:00:00:01:02:03 # ngctl show bridge: Name: bridge Type: bridge ID: 000b Num hooks: 4 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - link4 ngeth0 ether0007lower link3 ngeth0 ether0007upper link2 dc0 ether0002lower link1 dc0 ether0002upper # ifconfig ngeth0 1.2.3.4 # tcpdump -lenx -i dc0 ether host 0:0:0:1:2:3 tcpdump: listening on dc0 20:29:05.571179 0:0:0:1:2:3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 1.2.3.4 tell 1.2.3.4 0001 0800 0604 0001 0001 0203 0102 0304 0102 0304 Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Changing ttl of incoming packets
On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Changing ttl of incoming packets
On Thu, Apr 22, 2004 at 07:02:45PM -0700, Julian Elischer wrote: start with natd and chop it until you have what you want.. ports/net/tcpmssd might be easier to adopt. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: make(1) guru question
On Tue, Apr 06, 2004 at 12:11:35PM -0700, Luigi Rizzo wrote: On Tue, Apr 06, 2004 at 08:26:00PM +0200, Jens Schweikhardt wrote: Fellow hackers, suppose you have a long list of files in a make variable V, exceeding kern.argmax. This means there is no way you can write a rule where $(V) is a command argument in any way shape or form. There is also no way to pass the value of V to xargs that I know of. For example with this depending on the use, you might use something like make -V variable_name | xargs ... within the makefile. I got the suggestion from someone long ago when I had this problem with src/sys/conf/Makefile.i386 I can only confirm that this is the only known solution so far. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: CVS question: diff between dates on a branch
On Thu, Mar 18, 2004 at 01:49:07PM +0300, Dmitry Morozovsky wrote: Dear colleagues, maybe I'm stupid and blind ;-) but I still can't fugure out how can I ask CVS to get diff between two states of a branch with known dates (such as today and yesterday). All that I found was 'cvs get -jBRANCH:date1 -jBRACH:date2' but this looks very sub-optimal. Any hints? Surprisingly (it's undocumented) but the exact same synopsis seems to work here with cvs diff: $ ident Makefile.inc1 Makefile.inc1: $FreeBSD: src/Makefile.inc1,v 1.418 2004/03/18 10:17:03 ru Exp $ $ cat CVS/Tag cat: CVS/Tag: No such file or directory $ cvs di -jRELENG_4:2002/01/01 -jRELENG_4:2003/01/01 --brief Makefile.inc1 Index: Makefile.inc1 === RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.141.2.39 retrieving revision 1.141.2.57 diff -u -p --brief -r1.141.2.39 -r1.141.2.57 Files /home/ru/tmp/cvsv60oN8 and /home/ru/tmp/cvsmonEXm differ Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: make install (kernel) without /modules dir
Roman Kurakin wrote:
I forget to say that this problem is for 4. branch
Roman Kurakin wrote:
Hi,
It seems that I've found another problem. If /modules dir would be
removed,
make install (of kernel and kernel modules) will not create modules
dir and you'll
get /modules file with one of the modules inside.
One of the variants is to add flag -d to install or other to mkdir -p
explicitly:
--- Makefile.oldFri Mar 12 00:13:45 2004
+++ MakefileFri Mar 12 00:15:03 2004
@@ -626,6 +626,7 @@
cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old; \
fi;
.endif
+ mkdir -p ${DESTDIR}/modules
cd $S/modules ; env ${MKMODULESENV} ${MAKE} install
modules-reinstall modules-reinstall.debug:
An old problem. 5.x is only partly affected by this, because
of a side effect of kern.post.mk creating the necessary directory,
but if you attempt to install from src/sys/modules/ when
/boot/kernel doesn't exist, it exhibits the same behavior.
In RELENG_4 the situation is worse, as even make installkernel
can exhibit such behavior. I once had a patch locally that adds
make hierarchy to the installkernel path, similar to how this
is done for installworld.
The problem is not unique to just kernel modules; if you attempt
to install src/bin/ when /bin doesn't exist you'll see the same
behavior, that's why I think the below change is not quite
incorrect.
I believe there's a PR open on this (probably even assigned to
myself), but I just don't have a clever idea of how to fix it
properly, sorry -- generally, standard directories are created
with mtree(8), and not with mkdir(1).
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: make install (kernel) without /modules dir
On Fri, Mar 12, 2004 at 06:08:22PM +0300, Roman Kurakin wrote: [...] If our install was like linux one which have -D flag, we could solve our problem by setting it globaly to install in sys.mk: -INSTALL ?= install -D +INSTALL ?= install -D This flag dictates to create all necessary dirs if needed. It would be nice to have such option, not -D of course. $ install file foo/bar Should it install file as foo/bar or should it create the foo/bar directory and install it as foo/bar/file? ;) Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: complete in src tree build world w/o /usr/include/** ?
On Thu, Mar 11, 2004 at 09:52:41AM +, Bjoern A. Zeeb wrote: Hi, I once again ran into the problem that a buildworld didn't succeed as unpriv. user without populating some headers to the base system before. But I do not want to populate headers that do not match my installed system on that machine if I am building for another one. This leads to inconsistency. Is there any chance that the whole source tree could be built w/o /usr/include/** ? A complete (and consistent with the rest of the running world) /usr/include is a prerequisite for a successful buildworld. or should that be the case already ? No. or why can't it be done ? We build some tools (like compiler, binutils, make, etc.) using the system headers, libraries, compiler, and binutils. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: add cvs -W option to disable -R/CVSREADONLYFS
On Tue, Mar 09, 2004 at 09:33:44PM +0900, Norikatsu Shigemura wrote: On Tue, 9 Mar 2004 20:17:34 +0900 (JST) Norikatsu Shigemrua [EMAIL PROTECTED] wrote: Synopsis: add cvs -W option to disable -R/CVSREADONLYFS Description: I added a feature which is to nagate a effect of -R/CVSREADONLYFS to cvs as -W option. Please review and commit. Although I am checkout-ing well by using cvs -R in ~/.cvsrc, when I want to commit, It is prevented by -R. So I wanted to disable this feature. Although control by the environment variable CVSREADONLYFS was also considered, honestly it is troublesome. I also have -R in most of my ~/.cvsrc's, and when I need to commit, I just use cvs -f (for local repos). For remote repos, -R is not a problem (it's not passed on the wire) unless you happen to have it set in ~/.cvsrc on the repository host. Even in this case, it is still possible to commit by setting CVS_SERVER=cvs -f in the environment of the committing host. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: DEVICE_IDENTIFY(9)
On Fri, Mar 05, 2004 at 11:52:28AM +0100, Mark Santcroos wrote: The above manpage documents the return values, but it is a void function. Fixed, thanks! Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 05:57:14AM -0600, Matthew D. Fuller wrote: On Sun, Feb 15, 2004 at 09:20:56AM + I heard the voice of Bruce M Simpson, and lo! it spake thus: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). And, last time I tried it (which admittedly was a long time ago, so grab your salt grainer), the same applied to world builds too. To stop this from being happening, Jun Kuriyama has done a cleanup lately to replace lots of symlink created during buildworld with cp(1) commands. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: ELF branding / magic numbers
On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote: [...] Does the magic number not then support multiple ABI's per system architecture, or is there some part of the puzzle I'm missing? There's an EI_ABIVERSION byte following the EI_OSABI byte, which is both documented in the elf(5) manpage, and is shown in the ``readelf -h'' output. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Build System Doc
On Thu, Jan 29, 2004 at 11:02:19PM +0100, sebastian ssmoller wrote: hi, is there any doc available describing how the fbsd build process / system for /usr/src and /usr/src/sys works ? i googled a bit but have not found any useful doc. i had a short look to /usr/share/mk but i guess reading makefiles could be a bit difficult to get the big picture. man 7 build Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote: Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. Have you tried ``sysctl net.inet.ip.fastforwarding=1''? It's documented in the inet(4) manpage. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: FreeBSD 5.2-RELEASE buildworld failure.
On Fri, Jan 23, 2004 at 06:13:24PM -0800, erek wrote: I cvsuped today using tag RELENG_5_2 (i'm already using 5.2-RELEASE), [...] During the buildworld I get this VERY odd error: [...] /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned malloc [...] mkdep: compile failed *** Error code 1 [...] any suggestions? wizard mode Go to /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus, and compare parse.c and parse+%DIKED.c there. They should be different, xmalloc vs malloc, xrealloc vs realloc. If they are identical, chances are your /usr/bin/sed is probably broken, and you should read this entry from src/UPDATING: : 20030613: [retrospective] : There was a small window in which sed(1) was broken. If you : happen to have sed(1) installed during that window, which is : evidenced by an inability to build world with the failure : given below, you need to manually build and install sed(1) : (and only sed(1)) before doing anything else. This is a one- : time snafu. Typical failure mode: : : In file included from /usr/src/contrib/binutils/bfd/targets.c:1092: : targmatch.h:7:1: null character(s) ignored : targmatch.h:12:1: null character(s) ignored : targmatch.h:16:1: null character(s) ignored : : : : The window of sed(1)-uction is from Wed Jun 4 15:31:55 2003 UTC : to Thu Jun 5 12:10:19 2003 UTC (from rev 1.30 to rev 1.31 of : usr.bin/sed/process.c). To see if you're affected, run this: ident /usr/bin/sed And see which process.c revision your sed(1) has. It if's 1.30, you're affected. /wizard mode Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: send(2) does not block, send(2) man page wrong?
On Fri, Jan 23, 2004 at 04:25:07PM +0100, Stuart Pook wrote:
The documentation for send(2) says
If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode. The select(2) call may be used to
determine when it is possible to send more data.
I cannot get send (or sendto which is what really interests me)
to block on FreeBSD 4.9. When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS. I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.
Select does not block either. It always says that I can write to the
socket and then send fails with ENOBUFS.
The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
/*
* Calculate data length and get a mbuf
* for UDP and IP headers.
*/
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}
There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.
Is the documentation for send(2) wrong or is there some way to make
send and sendto block?
I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.
UDP sockets don't use send buffer (like TCP does) for storing data,
only receive buffer, so SO_SNDBUF only affects the maximum size of
one write operation.
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: [CHECKER] bugs in FreeBSD
On Sun, Jan 18, 2004 at 05:44:52PM -0500, Matthew N. Dodd wrote: On Sun, 18 Jan 2004, Ruslan Ermilov wrote: But we're missing the proper NULL checking, here's the fix: ... I've already dealt with this. Neat, this works much better! Can you please propagate your fix to dev/iir/iir.c:iir_attach()? Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 08:17:19AM -0800, David O'Brien wrote: On Mon, Jan 19, 2004 at 02:41:26PM +0100, Harti Brandt wrote: [...] What about third party code that reads cdefs.h and is pre-c99? It's perfectly ok to use restrict as a name there. Its also perfectly OK to use 'exp' as a varible, but we've been getting rid of those because they are difficult to deal with. The same is true of older C++ code when new reserved words were added. Sometimes one has to move forward to the modern world. This is all congecture -- can you find one thing in /usr/ports that uses restrict as a symbol? This is not the point. The point was if we want to stay C89 compatible or not. If we decide at some point that FreeBSD should no longer accept valid C89 code, this change is probably ok. If we decide now that our kernel should be C99 clean, we should compile it with -std=c99, and replace all `__restrict''s in not headers with C99 `restrict's. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [CHECKER] bugs in FreeBSD
Scott,
Attached is the patch that fixes memory leak according to the below report.
On Fri, Jan 16, 2004 at 04:09:34PM -0800, Paul Twohey wrote:
-
[BUG] though we should demote things that are not locals.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154:
pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked!
[z=1.0] [success=5]
ips_command_t *command;
ips_wait_list_t *waiter;
unsigned long memflags = 0;
if(IPS_NOWAIT_FLAG flags)
memflags = M_NOWAIT;
Start ---
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc-state IPS_OFFLINE){
splx(mask);
Error ---
return EIO;
}
command = SLIST_FIRST(sc-free_cmd_list);
if(command !(sc-state IPS_TIMEOUT)){
-
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
Index: ips.c
===
RCS file: /home/ncvs/src/sys/dev/ips/ips.c,v
retrieving revision 1.6
diff -u -p -r1.6 ips.c
--- ips.c 27 Nov 2003 08:37:36 - 1.6
+++ ips.c 18 Jan 2004 12:41:22 -
@@ -163,14 +163,14 @@ static int ips_add_waiting_command(ips_s
unsigned long memflags = 0;
if(IPS_NOWAIT_FLAG flags)
memflags = M_NOWAIT;
- waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
- if(!waiter)
- return ENOMEM;
mask = splbio();
if(sc-state IPS_OFFLINE){
splx(mask);
return EIO;
}
+ waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
+ if(!waiter)
+ return ENOMEM;
command = SLIST_FIRST(sc-free_cmd_list);
if(command !(sc-state IPS_TIMEOUT)){
SLIST_REMOVE_HEAD(sc-free_cmd_list, next);
pgp0.pgp
Description: PGP signature
Re: [CHECKER] bugs in FreeBSD
On Sun, Jan 18, 2004 at 02:45:02PM +0200, Ruslan Ermilov wrote:
Scott,
Attached is the patch that fixes memory leak according to the below report.
Attached is the corrected patch that doesn't do a waiting malloc()
while interrupts are blocked. Yes I know that splbio() is a no-op
these days. ;)
On Fri, Jan 16, 2004 at 04:09:34PM -0800, Paul Twohey wrote:
-
[BUG] though we should demote things that are not locals.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154:
pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked!
[z=1.0] [success=5]
ips_command_t *command;
ips_wait_list_t *waiter;
unsigned long memflags = 0;
if(IPS_NOWAIT_FLAG flags)
memflags = M_NOWAIT;
Start ---
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc-state IPS_OFFLINE){
splx(mask);
Error ---
return EIO;
}
command = SLIST_FIRST(sc-free_cmd_list);
if(command !(sc-state IPS_TIMEOUT)){
-
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
Index: ips.c
===
RCS file: /home/ncvs/src/sys/dev/ips/ips.c,v
retrieving revision 1.6
diff -u -p -r1.6 ips.c
--- ips.c 27 Nov 2003 08:37:36 - 1.6
+++ ips.c 18 Jan 2004 13:16:00 -
@@ -169,6 +169,7 @@ static int ips_add_waiting_command(ips_s
mask = splbio();
if(sc-state IPS_OFFLINE){
splx(mask);
+ free(waiter, M_DEVBUF);
return EIO;
}
command = SLIST_FIRST(sc-free_cmd_list);
pgp0.pgp
Description: PGP signature
Re: [CHECKER] bugs in FreeBSD
On Fri, Jan 16, 2004 at 04:09:34PM -0800, Paul Twohey wrote:
[...]
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/dpt/dpt_scsi.c:1542:dpt_attach:ERROR:LEAK:1542:1571:
pointer=devq from RO=cam_simq_alloc(-1) [s=21,pop=21,pr=0.99] [rank=med] leaked!
[z=1.0] [success=3]
int i;
/*
* Create the device queue for our SIM.
*/
Start ---
devq = cam_simq_alloc(dpt-max_dccbs);
... DELETED 23 lines ...
}
if (i 0)
EVENTHANDLER_REGISTER(shutdown_final, dptshutdown,
dpt, SHUTDOWN_PRI_DEFAULT);
Error ---
return (i);
}
int
-
We aren't leaking devq here, it's freed (if necessary) by setting
the second cam_sim_free() argument to true:
if (xpt_bus_register(dpt-sims[i], i) != CAM_SUCCESS) {
cam_sim_free(dpt-sims[i], /*free_devq*/i == 0);
break;
}
But we're missing the proper NULL checking, here's the fix:
%%%
Index: dpt_scsi.c
===
RCS file: /home/ncvs/src/sys/dev/dpt/dpt_scsi.c,v
retrieving revision 1.45
diff -u -p -r1.45 dpt_scsi.c
--- dpt_scsi.c 24 Aug 2003 17:46:04 - 1.45
+++ dpt_scsi.c 18 Jan 2004 15:39:13 -
@@ -1553,6 +1553,8 @@ dpt_attach(dpt_softc_t *dpt)
dpt-sims[i] = cam_sim_alloc(dpt_action, dpt_poll, dpt,
dpt, dpt-unit, /*untagged*/2,
/*tagged*/dpt-max_dccbs, devq);
+ if (dpt-sims[i] == NULL)
+ break;
if (xpt_bus_register(dpt-sims[i], i) != CAM_SUCCESS) {
cam_sim_free(dpt-sims[i], /*free_devq*/i == 0);
break;
%%%
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: __restrict__ vs __restrict ?
On Sat, Jan 17, 2004 at 09:19:28AM -0800, David O'Brien wrote:
On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote:
No, we should be using the __restrict as coded. But I wonder why
we can't just use restrict...
Because that would really mess up any user program that used
'restrict' as a variable or function name. I think the
current approach is the best.
Such code isn't portable to C99, which is still a goal of ours. I like
RU's suggestion, because it is straight C[99] code and not an
abstraction. I'll do a 'make world' test and see if we'd have trouble
with RU's form.
The code I've posted has obvious troubles. It would take care
of the following fragment for -std=c89 and be pure C99 for
-std=c99,
void
foo(char * restrict fa)
{
}
but will break this for -std=c89:
void
restrict(void)
{
}
We have a problem if we want to mix old C89 and new C99 code.
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: __restrict__ vs __restrict ?
On Fri, Jan 16, 2004 at 05:23:01PM -0800, Tim Kientzle wrote: I've been enabling a LOT of gcc warnings recently in the process of linting some code I'm writing. In the process, I stumbled across the following curiosity: cat test.c #include stdio.h gcc -std=c99 -ansi test.c In file included from test.c:1: /usr/include/stdio.h:220: conflicting types for `restrict' /usr/include/stdio.h:220: previous declaration of `restrict' /usr/include/stdio.h:221: conflicting types for `restrict' /usr/include/stdio.h:221: previous declaration of `restrict' /usr/include/stdio.h:222: redefinition of `restrict' /usr/include/stdio.h:222: `restrict' previously declared here /usr/include/stdio.h:223: conflicting types for `restrict' [ many similar lines omitted ] If I change all __restrict in stdio.h to __restrict__, these warnings disappear. Question: Does anyone know the difference between __restrict and __restrict__? __restrict__ is the gcc(1)-only feature. From gcc.info: : `-std=' : Determine the language standard. This option is currently only : supported when compiling C or C++. A value for this option must be : provided; possible values are : [...] : Even when this option is not specified, you can still use some of : the features of newer standards in so far as they do not conflict : with previous C standards. For example, you may use : `__restrict__' even when `-std=c99' is not specified. : [...] : As with gcc, g++ understands the C99 feature of restricted pointers, : specified with the `__restrict__', or `__restrict' type qualifier. : Because you cannot compile C++ by specifying the `-std=c99' language : flag, `restrict' is not a keyword in C++. __restrict is defined in sys/cdefs.h, it's the FreeBSD feature. Should we be using the latter in our system headers? No, we should be using the __restrict as coded. But I wonder why we can't just use restrict, please see below. Note that __restrict is a no-op these days because we don't compile our C code by default with -std=c99. I'm not sure why we can't replace #if !(__GNUC__ == 2 __GNUC_MINOR__ == 95) #if !defined(__STDC_VERSION__) || __STDC_VERSION__ 199901 #define __restrict #else #define __restrict restrict #endif #endif with #if !defined(__STDC_VERSION__) || __STDC_VERSION__ 199901 #define restrict #endif and just use restrict everywhere. Also similarly I'm not aware of the status of the CSTD feature for share/mk that was backed out. (8 makefiles in src/ still have CSTD.) Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Upgrade from 4.9 to 5.1
On Thu, Jan 15, 2004 at 04:55:41PM +0300, Dmitry A. Bondareff wrote: Hello hackers! Help to understand problem. I have FreeBSD 4.9 on my box. # uname -a FreeBSD wall.ru 4.9-RELEASE-p1 FreeBSD 4.9-RELEASE-p1 #24 I've tried to Upgrade it up to 5.1 # cvsup /etc/cvsupfile # cd /usr/src # make buildworld === lib/libpam/modules/pam_krb5 rm -f .depend mkdep -f .depend -a -I/usr/src/lib/libpam/modules/pam_krb5/../../../../contrib/openpam/i nclude -I/usr/src/lib/libpam/modules/pam_krb5/../../libpam /usr/src/lib/libpam/modules/pam _krb5/pam_krb5.c *** Error code 1 This doesn't inlude the actual error that caused the breakage. Please put the full log (compressed) available somewhere for download, and I will look into it. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: 5.1 - 5.2 upgrade, Promise FastTrak device /dev/ar0 missing?
On Sun, Dec 28, 2003 at 05:22:57PM +0100, Dimitry Andric wrote: On 2003-12-28 at 14:51:42 Kevin A. Pieckiel wrote: Included is my dmesg output from the 5.1 kernel and my kernel config file SAMSON for the 5.1 kernel. Any help would be appreciated. You need device ataraid in your config file.. Thanks. That worked great. For some reason I missed this bit... This is a good example: making a copy of GENERIC some time in the past, and forgetting to update it when you upgrade the whole OS. :) In the latest version of GENERIC, ataraid is included by default. Maybe it would be nice to have a system for this, like what is used for /etc/rc.conf, i.e. making your kernel config file simply include GENERIC, and then only adding/removing those items you want to be changed from the defaults. There is: look how the PAE and OLDCARD configs are constructed. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: BSD make question
On Thu, Aug 07, 2003 at 02:50:51PM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: Using BSD make, how can I apply different rules based on different directories while using only a single makefile? There's a .CURDIR variable that can be used to conditionalize parts of a makefile. Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? It just works as is with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c ;) But its missing the -DLIB or -DMCP. Thanks for the .CURDIR hint. Ah, didn't notice it. Try this: .for f in $(LIB) $(f:.c=.o): $(f) gcc -DLIB -c $ -o $@ .endfor .for f in $(MCP) $(f:.c=.o): $(f) gcc -DMCP -c $ -o $@ .endfor Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: BSD make question
On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: Using BSD make, how can I apply different rules based on different directories while using only a single makefile? There's a .CURDIR variable that can be used to conditionalize parts of a makefile. Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? It just works as is with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c cc -O -pipe -march=pentiumpro -c lib/bar.c cc -O -pipe -march=pentiumpro -c mcp/baz.c ### .SUFFIXES: .SUFFIXES: .o .c LIB=\ lib/foo.c \ lib/bar.c MCP=\ mcp/baz.c all: $(LIB:.c=.o) $(MCP:.c=.o) lib/%.o: lib/%.c gcc -DLIB -c $ -o $@ mcp/%.o: mcp/%.c gcc -DMCP -c $ -o $@ .PHONY: clean clean: rm -f $(LIB:.c=.o) $(MCP:.c=.o) ### -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: sysctl kern.ipc.shm* description ?
On Thu, Aug 07, 2003 at 09:11:44PM -0700, bruno schwander wrote: Is there a good explanation of what those variables are and the dangers/advantages of changing them ? Look for the SHM* options descriptions in the /sys/conf/NOTES file (assuming you're running 5.x), or /sys/i386/conf/LINT on 4.x. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Assembly Syscall Question
On Thu, Jul 31, 2003 at 04:12:27PM -0400, Ryan Sommers wrote: When making a system call to the kernel why is it necessary to push the syscall value onto the stack when you don't call another function? Example: access.the.bsd.kernel: int 80h ret func: mov eax, 4; Write call access.the.bsd.kernel ; End Works. However: func: mov eax, 4; Write int 80h ; End Doesn't. This is because in a C library, all system calls are wrapped into C functions, so the stack looks like this when in the syscall code in libc: return address to a program syscall args So the kernel knows how to account for a return address to access actual arguments. So when calling the kernel directly (not through a C library wrapper function), we need to align the stack to fake the kernel we're calling it from the syscall code in libc. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
make -U
Sorry, I've accidentally dropped an email about `make -U'.
I think that it's not needed, since the functionality can
easily be achieved by running make FOO=, i.e., assigning
an empty value. Remember that command line variables take
precedence over globals, so the following makefile,
FOO+= bar
all:
@echo ${FOO}
when run as ``make FOO=foo'', will print just ``foo''.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: make -U
On Wed, Jul 30, 2003 at 04:23:20PM -0500, Juli Mallett wrote:
* Ruslan Ermilov [EMAIL PROTECTED] [ Date: 2003-07-30 ]
[ w.r.t. make -U ]
Sorry, I've accidentally dropped an email about `make -U'.
I think that it's not needed, since the functionality can
easily be achieved by running make FOO=, i.e., assigning
an empty value. Remember that command line variables take
precedence over globals, so the following makefile,
FOO+= bar
all:
@echo ${FOO}
when run as ``make FOO=foo'', will print just ``foo''.
Does that work for the .if defined() case, too? Makefiles can grow
to be more complex than just that sort of stuff, after all :)
Not sure what do you mean. The make -U FOO was support to
undefine the FOO variable, as it the ``.undef FOO'' was called
at the end of makefile. Of course, setting FOO= on a command
line still gets you a defined variable, but
.if defined(FOO) !empty(FOO)
should do the trick. Try this out with make FOO=:
FOO=bar
all:
.if defined(FOO) !empty(FOO)
@echo FOO is set
.endif
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: How to use functions from libs in /usr/local/lib in pam?
On Mon, Jul 21, 2003 at 04:42:12AM -0400, Ilmar S. Habibulin wrote:
I'm trying to write pam module, which uses libs from /usr/local/lib (lber
and lsap). What should i put in Makefile in order to link module with this
libs?
LIBLDAP= /usr/local/lib/ldap.a
LDADD+= -L/usr/local/lib -lldap
LDFLAGS += -L/usr/local/lib -lldap
DPADD= ${LIBCRYPT} ${LIBLDAP}
doesn't help.
The library should be named /usr/local/lib/libldap.a at the minimum,
to make -lldap work. Also, -L should be taken out of LDADD, and be
put only in LDFLAGS, so it should look like this:
LIBLDAP=/usr/local/lib/libldap.a
DPADD= ${LIBCRYPT} ${LIBLDAP}
LDADD= -lcrypt -lldap
LDFLAGS=-L/usr/local/lib
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: Is GNATS broken ??
On Sun, Jun 29, 2003 at 02:18:01AM +0200, Vahe Khachikyan wrote: [...] Who knows whether the mentioned server is in blacklist ? http://dsbl.org/listing Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
FreeBSD CVSROOT scripts and spaces in directory and file names
Hi there!
Our local CVSROOT scripts are based on a 1997 year version of FreeBSD
CVSROOT scripts, slightly modified to fit local needs, and we recently
noticed a problem with not getting email notifications if the affected
repository path has spaces in its name. I have verified that the
modern CVSROOT scripts (which I am planning to migrate to soon) are
subject to this problem as well.
There is a couple of problems actually.
The first problem turns out to be a known limitation in cvs(1), in
a way how it constructs the argument to the log_accum.pl script
(using the %s in CVSROOT/loginfo). With %s, both repository path
and the list of files (added, removed, or changed) in that directory
are passed as a single argument to the log_accum.pl script, separated
by a single whitespace character, which obviously creates a problem
for a parser in log_accum.pl that does a simple split().
The solution that works here and was inspired by reading the following
comment in src/contrib/cvs/src/logmsg.c, describing the % format
specifiers,
/* All other characters, we insert an empty field (but
we do put in the comma separating it from other
fields). This way if future CVS versions add formatting
characters, one can write a loginfo file which at least
won't blow up on an old CVS. */
/* Note that people who have to deal with spaces in file
and directory names are using space to get a known
delimiter for the directory name, so it's probably
not a good idea to ever define that as a formatting
character. */
was to use %{ s} to get a known , delimiter. (Chances still
are that the file/directory name will contain the , sequence,
but this is less likely.)
With this fix, no emails were lost anymore, but the contents were
still damaged. If a directory name had a space in its name, the
log_accum.pl::get_revision_number() that does a simple split()
when parsing the Repository revision string from cvs -Qn status,
hits the whitespace problem. That was easy to fix, by limiting
splitting to four elements only. Then I hit a real PROBLEM.
The log_accum.pl script parses the standard log message generated
by logmsg.c, to build three lists of added, removed, and modified
files, each hashed by the tag (yes, it's possible to commit to
different branches in one commit, and even to commit to a single
file twice in a single commit). I first thought that I could just
take the list of files from the argument to the script (generated
by %{ s}), but there is no indication of added/removed/changed,
and, more importantly, there is no tag information. And the
problem with building these lists by parsing the log message is
that the lists of added, removed, and modified files are formatted
by logmsg.c as separated by a single whitespace character (and to
make it fit the 70-column width), which creates the same problem
if a file has a space in a name.
My first hack was to patch logmsg.c to have it list files one per
line, so, for example, instead of
Modified files:
a b c
I have now been getting
Modified files:
a
b
c
This worked well, but I wanted a real SOLUTION. The solution
I have found is to implement the %T modifier for loginfo
scripts, which prints the tag (or HEAD for trunk). Combined
with the %V and %v modifiers which print NONE for added
and removed files, respectively, I have been able to fix the
log_accum.pl's logic to not depend on the contents of the log
message to build lists of added, removed, and modified files.
Attached in this email are:
- a patch for src/contrib/cvs that implements the %T (tag)
modifier for CVSROOT/loginfo scripts,
- a patch for log_accum.pl and loginfo that uses %T to deal
with whitespaces in directory and file names.
I'd like some input here before I submit this patch to CVS
developers.
P.S. The patch also removes two /usr/local/bin/awake uses
from log_accum.pl, as these made it unuseable for third
party application. Josef, Peter suggested me to ask you
to please address this particular problem with awake,
and to make this script useful for third-parties again.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
Index: doc/cvs.texinfo
===
RCS file: /home/ncvs/src/contrib/cvs/doc/cvs.texinfo,v
retrieving revision 1.1.1.13
diff -u -p -r1.1.1.13 cvs.texinfo
--- doc/cvs.texinfo 2 Dec 2002 03:13:37 - 1.1.1.13
+++ doc/cvs.texinfo 21 Jun 2003 20:21:34 -
@@ -12888,6 +12888,8 @@ separators. The format characters are:
@table @t
@item s
file name
[EMAIL PROTECTED] T
+tag
@item V
old version number (pre-checkin)
@item v
Index: src/logmsg.c
===
RCS file
Re: How do I see open sockets count (kern.ipc.maxsockets, butstatus)
On Fri, Jun 13, 2003 at 01:22:52PM -0700, Josh Brooks wrote: Hello, When I run out of files, I can see how many files are actually open by looking at the kern.openfiles sysctl. This makes it easy to see if I am hitting my limit or not. However, I am experiencing No buffer space available errors, and since I am not running out of mbufs: netstat -m 1728/2496/34816 mbufs in use (current/peak/max): 1714 mbufs allocated to data 14 mbufs allocated to packet headers 677/1430/8704 mbuf clusters in use (current/peak/max) 3484 Kbytes allocated to network (13% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines My natural choice is to increase: kern.ipc.maxsockets: 16424 But before I do that, I want to see how many I am currently using. So, whereas with open files I would simply check the kern.openfiles sysctl, how do I check how many sockets I currently have open ? In 5.x, there's the kern.ipc.numopensockets sysctl(8). However, this is unlikely to fix your ENOBUFS problem. : 55 ENOBUFS No buffer space available. An operation on a socket or pipe : was not performed because the system lacked sufficient buffer : space or because a queue was full. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Policy Routing / NAT Question
On Wed, Jun 11, 2003 at 08:55:53AM -0400, Ryan Wilkins wrote: Hello.. I'm setting up a TCP protocol testbed for testing various enhanced TCP stacks for use over high bandwidth, high latency links such as Satellite. Due to hardware limitations of the FreeBSD boxes we're using (1U rackmount), there are no expansion slots left for additional network cards. This forces me to have to run some traffic over one gateway and the rest of the traffic over another gateway, all through one ethernet. The problem I have is I need to change the source address of some packets based on destination address. I was able to accomplish this in Linux using Source NAT. I'm not real well versed in FreeBSD hence the reason I'm asking for any assistance here. Does anyone have an idea how to change the source address based on destination address? If all of these possible source addresses belong to the same interface of the box in question (it's unclear from your message), this can be done with route(8). For example: # ifconfig rl0 inet rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.4.115 netmask 0xff00 broadcast 192.168.4.255 inet 10.0.0.1 netmask 0xff00 broadcast 10.255.255.255 inet 10.0.0.2 netmask 0x broadcast 10.0.0.2 # route add -net 11 10.0.0.3 add net 11: gateway 10.0.0.3 # route add -net 12 -ifa 10.0.0.2 10.0.0.4 add net 12: gateway 10.0.0.4 The route to the network 12 says to use 10.0.0.2 as the source address when sending anonymous (with unfilled source address) datagrams. But if you need to change the traffic originated from other hosts on your box, there are several NAT solutions for you. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Are write() calls guaranteed atomic?
On Mon, Jun 02, 2003 at 12:57:05PM -0400, Matthew Hagerty wrote:
In the last episode (Jun 02), Matthew Hagerty said:
I'm writing a server that receives data via a named pipe (FIFO) and
will always have more than one other process sending data to it, and
I'm concerned with preventing data multiplexing. The data coming in
will be lines of text delimited with a newline, but the processes
writing the data have no knowledge of the FIFO, they simply think
they are writing to a file. This being the case, the processes
writing the data give no regard to PIPE_BUF and may send data in
longer lengths (but probably never longer than 2K to 4K.)
Will the kernel ensure that the data write() will be delivered to the
FIFO atomically even if the data is larger than PIPE_BUF, such that
two or more successive read() calls will retrieve the data in order?
Pipes are always FIFO; it's part of their definition. From SUSv3:
A read on the file descriptor fildes[0] shall access data written to
the file descriptor fildes[1] on a first-in-first-out basis.
To ensure that your writes don't get interleaved with writes from other
processes, you do need to limit your write sizes to PIPE_BUF or less
bytes:
Write requests of {PIPE_BUF} bytes or less shall not be interleaved
with data from other processes doing writes on the same pipe. Writes
of greater than {PIPE_BUF} bytes may have data interleaved, on
arbitrary boundaries, with writes by other processes, whether or not
the O_NONBLOCK flag of the file status flags is set.
If you cannot modify the clients, try changing your server to create a
Unix domain socket instead of a named pipe (the clients shouldn't see
any difference).
--
Dan Nelson
[EMAIL PROTECTED]
Dan,
Thanks for the info, very helpful! What reference did you get that from?
I searched high and low to find a definitive answer (like the one above)
before posting.
http://www.unix-systems.org/version3/online.html
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
libc_r: threaded application could stuck in accept(2)
Hi!
We had a bug in our threaded application that would mistakenly close
the descriptor 0, and this triggers a bug in libc_r which I will try
to describe below.
The bug (in libc_r only, libpthread^Wlibkse is unaffected) causes a
threaded application to stuck in accept(2). libc_r makes every new
descriptor non-blocking, and uses poll(2) and thread context switching
to emulate a blocking behavior. The bug somehow causes the descriptor
to be left in a blocking mode.
Attached is the test case that demonstrates this bug (this is the
same on 4.8-STABLE and 5.1-BETA). The utility runs two threads:
the first thread prints the alive message every 3 seconds, and
the second thread emulates what our unfortunate application did,
i.e., open() a TCP socket, listen(), accept(), then close() it,
then mistakenly close() descriptor 0. (Closing the descriptor
0 causes the next socket() call to return 0.)
Some important notes: this bug is only applicable to descriptors
0 - 2 (stdio set), and might have something to do with the code
in uthread_fd.c. If you remove two lines that free the descriptor
0 in the attached test case, the bug won't manifest itself.
Attached also is the patch for the threaded close() function
that avoids the bug by disallowing the close() call on a
non-active descriptor.
The patch should be committed, but I'm now more interested in
what's going on inside libc_r that causes the descriptor 0 to
be left in the blocking mode. IOW, I wonder if the attached
patch is the real fix. ;)
Ah yes, when you'll run the application, it will report
which TCP port it listens to, you then connect to this port,
the application closes the connection, and on the next loop
the application gets stuck in accept().
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer.
#include sys/param.h
#include sys/socket.h
#include netinet/in.h
#include err.h
#include pthread.h
#include stdio.h
#include stdlib.h
#include unistd.h
static void *thread1(void *);
static void *thread2(void *);
int
main(void)
{
pthread_t thr1, thr2;
int r;
if ((r = pthread_create(thr1, NULL, thread1, NULL)) != 0)
errc(1, r, pthread_create);
if ((r = pthread_create(thr2, NULL, thread2, NULL)) != 0)
errc(1, r, pthread_create);
if ((r = pthread_join(thr1, NULL)) != 0)
errc(1, r, pthread_join);
if ((r = pthread_join(thr2, NULL)) != 0)
errc(1, r, pthread_join);
exit(0);
}
static void *
thread1(void *arg __unused)
{
for (;;) {
printf(thread 1: alive\n);
sleep(3);
}
}
static void *
thread2(void *arg __unused)
{
int s, s2;
struct sockaddr_in addr;
socklen_t addrlen;
printf(thread 2: freeing descriptor 0 (closing)\n);
close(0);
for (;;) {
if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1)
warn(thread 2: socket);
else {
printf(thread 2: socket() returned %d\n, s);
if (listen(s, 1) == -1)
warn(thread 2: listen);
else {
addrlen = sizeof(addr);
if (getsockname(s, (struct sockaddr *)addr, addrlen)
== -1)
warn(thread 2: getsockname);
else
printf(thread 2: listening on port %d\n,
ntohs(addr.sin_port));
printf(thread 2: calling accept() on %d\n, s);
s2 = accept(s, (struct sockaddr *)addr, addrlen);
if (s2 == -1)
warn(thread 2: accept);
else {
printf(thread 2: accept() returned %d,
closing\n, s2);
close(s2);
}
}
printf(thread 2: closing descriptor %d (1st)\n, s);
close(s);
printf(thread 2: closing descriptor %d (2nd)\n, s);
close(s);
}
sleep(1);
}
}
Index: uthread_close.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.10.2.3
diff -u -p -r1.10.2.3 uthread_close.c
--- uthread_close.c 22 Oct 2002 14:44:02 - 1.10.2.3
+++ uthread_close.c 30 May 2003 14:13:54 -
@@ -47,7 +47,8 @@ _close(int fd)
struct stat sb;
struct fd_table_entry *entry;
- if ((fd == _thread_kern_pipe[0]) || (fd
Re: libc_r: threaded application could stuck in accept(2)
On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote: On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote: We had a bug in our threaded application that would mistakenly close the descriptor 0, and this triggers a bug in libc_r which I will try to describe below. ... Some important notes: this bug is only applicable to descriptors 0 - 2 (stdio set), and might have something to do with the code in uthread_fd.c. If you remove two lines that free the descriptor 0 in the attached test case, the bug won't manifest itself. please have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=51535 Thanks, I had this same patch in my first version of the fix. Yes it works too, but do you have an insight what's going on without these fixes so that the 0..2 descriptors are left in a blocking mode? I just can't get it where this happens. P.S. I will commit both patches after the freeze is over. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer. pgp0.pgp Description: PGP signature
Re: libc_r: threaded application could stuck in accept(2)
On Fri, May 30, 2003 at 08:16:41PM +0300, Ruslan Ermilov wrote:
On Fri, May 30, 2003 at 07:07:23PM +0300, Enache Adrian wrote:
On Fri, May 30, 2003 at 05:35:41PM +0300, Ruslan Ermilov wrote:
We had a bug in our threaded application that would mistakenly close
the descriptor 0, and this triggers a bug in libc_r which I will try
to describe below.
...
Some important notes: this bug is only applicable to descriptors
0 - 2 (stdio set), and might have something to do with the code
in uthread_fd.c. If you remove two lines that free the descriptor
0 in the attached test case, the bug won't manifest itself.
please have a look at
http://www.freebsd.org/cgi/query-pr.cgi?pr=51535
Thanks, I had this same patch in my first version of the fix.
Yes it works too, but do you have an insight what's going on
without these fixes so that the 0..2 descriptors are left in
a blocking mode? I just can't get it where this happens.
OK, I now know what's going on here. Without patches, a
second close(0) calls _FDLOCK(0, ...) which calls
_thread_fd_table_init(0). In this functions, the
following condition becomes false
/* Get the flags for the file: */
if (((fd = 3) || (_pthread_stdio_flags[fd] == -1))
(entry-flags = __sys_fcntl(fd, F_GETFL, 0)) == -1) {
ret = -1;
}
due to _pthread_stdio_flags[0] != -1, and we succeed
to the else block which eventually installs the entry
as _thread_fd_table[0].
Then, the call to socket() calls _thread_fd_table_init(0)
again, but since it detects that the memory is already
allocated (for non-existing descriptor 0), it doesn't
try to set it to non-blocking mode.
With my patch, we just don't allow the second call to
_thread_fd_table_init(0) when descriptor 0 doesn't exist.
With your patch that resets _pthread_stdio_flags[0] to -1
on close, attempting to close(0) for the second time
evaluates the condition above to true, and then
__sys_fcntl(0, F_GETFL, 0) returns -1 (EBADF), and
then the entry is free()'ed. Then, on the next socket()
call, _thread_fd_table_init(0) allocates the memory
for fd 0, and sets it to non-blocking mode.
P.S. I will commit both patches after the freeze is over.
Your patch also fixes the bug you mentioned, so I will
commit both patches.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer.
pgp0.pgp
Description: PGP signature
Re: disklabal messed, need help!
On Wed, Mar 26, 2003 at 01:03:03AM +0800, af asdf wrote: Anyone knows how to repair disk when the freebsddisk lable is destroyed? I have a 12G HD, the 1st partition is Windows NT, the second the for FreeBSD. For some reason i installed a new disk label to it and newfs it a bit. Once I found the newfs started, I have turned power off right away, but the disk is bad now. anyone knows how to repair this? Yes. Read the attached. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age ---BeginMessage--- Hi! I have my disk set in a so-called dangerously-dedicated mode, and its disklabel looks like this: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 8388608 2621444.2BSD 1024 819216 # (Cyl. 260*- 8582*) b: 2621440 swap# (Cyl.0 - 260*) c: 199321920unused0 0 # (Cyl.0 - 19773) d: 11281440 86507524.2BSD 1024 819216 # (Cyl. 8582*- 19773*) I recently upgraded the amount of RAM available on this machine from 128M to 256M, and it took me a while to figure out why swapon(8) no longer wants to enable swapping on `b' (which is only 128M large). I was pretty tired at the moment, and I thought that maybe the problem is with the contents of my `b' partition, so I did: dd if=/dev/zero of=/dev/ad0b bs=512 count=1000. This did not help, and eventually I recalled the fact of upgrading RAM, and I've looked into some /sys/kern code to verify my guesses. Nevertheless, I continued with my work on this machine, and compiled and installed the new kernel (without any problems) on it. Next reboot refused to boot FreeBSD by mentioning that No operating system was found. I wondered how I managed to screw my disk up. It was too late in the night, so I delayed it until the next morning. The night and next morning gave me the knowledge about what I did wrong, and it surprised me a lot, as I never thought about it before. The disklabel occupies the first sectors of the disk (or slice, if you are under i386 and have your disk sliced). My `b' partition starts from the very first sector of my disk, so when I did the dd(1) it overwrote the disklabel of my disk with zeroes. Once I understood and verified it, I recovered from this very fast. I remembered that my swap partition was first and exactly 128M large, so I skipped over this space, and saved some amount of my `a' partition into a plain file. Fortunately, file(1) is smart enough to read the superblock and tell you about the size of the filesystems. This way I found the size of my `a' partition and an offset for my `d' partition. Hope this technique could help someone in a similar situation. Now the question. Where is the code in the kernel that prevents swapping and/or writing to a disklabel portion of a physically first partition on the disk? Thanks, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature ---End Message--- pgp1.pgp Description: PGP signature
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 11:43:39PM -0800, Terry Lambert wrote: [...] IMO, it's better to use .PATH:, which makes the problem go away, by making the linker look for the objects where the compiler put them (instead of making the compiler put them where the linker is looking). See previous message. Sure thing! -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: KVM mice issues
I think Alexey was having similar issues, and may have some non-production quality patches for you to try. On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: Greetings hackers, I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, and I've found that while FreeBSD properly detects the mouse and all its functionality (buttons, scrollwheel, etc) upon boot if I switch to another port on the KVM and then switch back my mouse loses its functionality. After spending a while trying to figure out this problem (and reading PRs on the issue (esp. i386/25463)) I found that a solution was not immediately available, but might be somewhat easy to achieve. In particular, for my mouse, the mouse driver can and does detect invalid packets, and invalid packets are always received after a return to my FreeBSD system via the KVM. I found that doing a reinitialization of the device would fix the mouse, but that doing it from the interrupt handler (in sys/isa/psm.c around line 2170) caused some intermediate problems. Normally the mouse would just bounce around and generate click events for a while and then settle down, but occasionally the driver (or maybe mouse?) would lock solid and I'd have to reboot the system. Anyways, I'd like to work further on this problem and hopefully find a solution, but I'm having some trouble understanding where and what I should do. I'm not a novice C hacker, but I *am* a very novice kernel hacker and would appreciate help from anyone with knowledge of the psm (and atkbdc) code. I've considered maybe adding an ioctl to reset the mouse and adding a signal handler to moused to force a reset, but that seems kind of silly when the kernel driver can detect the problem itself and resolve it. On the other hand, maybe that's the right way to go? Advice would be greatly appreciated. -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Framebuffer howto?
On Tue, Dec 24, 2002 at 04:51:25PM +, Mayuresh Kathe wrote: Hi, I am not on the list, and am new to BSD, just graduated from Linux :) I wanted to port my OS (http://tisya.co.in/) to get away from Linux completely... For the same, the only hinderance lies in using framebuffer. Our GUI is based on Linux framebuffer, we don't use X Win at all... Is there something similar to Linux FB with FreeBSD? If yes, how do I activate it? (on linux there's ad evice at /dev/fb0) Eagerly awaiting your reply and waiting to take the plunge at full steam... /sys/dev/fb/ might be relevant, not sure. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38833/pgp0.pgp Description: PGP signature
Re: Need to override KRNLCONFDIR variable in command line of make (file /usr/src/Makefile.inc1).
On Tue, Dec 03, 2002 at 10:54:28PM +0300, Oleg Sharoiko wrote: On Tue, 3 Dec 2002, Ruslan Ermilov wrote: RE KRNLCONFDIR shouldn't be overridden -- we already provide (undocumented) RE user-redefineable KERNCONFDIR which should be used in cases like this. RE KRNLCONFDIR, on the other hand, is dependent on src/ used, and should RE NOT be overridden. That's in -CURRENT, are there any plans on merging it into -STABLE ? Done (merged). Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38469/pgp0.pgp Description: PGP signature
Re: Need to override KRNLCONFDIR variable in command line of make (file /usr/src/Makefile.inc1).
On Tue, Dec 03, 2002 at 06:22:42PM +0300, Andrey Beresovsky wrote: On Tue, 3 Dec 2002, Peter Pentchev wrote: PP I was wondering about that when I saw your PR; actually, I think that PP the current FreeBSD kernel building infrastructure is quite sufficient PP for what you want to do, without any more modifications. PP PP Why do you need different source trees and kernel config dirs? I see no PP problem with keeping all kernel configs for the same version of FreeBSD PP in the same src/sys/arch/conf/ directory, or at least keeping symlinks PP to different files in the same src/sys/arch/conf/ directory. PP PP Different source trees - if you have a source tree checked out to use PP for building the kernel, what is stopping you from invoking the PP 'buildkernel' target from the corresponding src/ directory, the one PP directly above the sys/ directory? My project involves automatic or semiautomatic checkouts, updates and removals of source trees. It would be unwise to keep kernel configs in this source trees. Thats why I need to change KRNLCONFDIR variable. Of course, I can do it with the help of links, but I think it's not a good solution. I guess the changes I suggest will definitely not break anything but only add flexibility which is typical for BSD make files. The solution with links is not a right thing, because it involves more dirty work which can be avoided with a help of simple makefile modification. KRNLCONFDIR shouldn't be overridden -- we already provide (undocumented) user-redefineable KERNCONFDIR which should be used in cases like this. KRNLCONFDIR, on the other hand, is dependent on src/ used, and should NOT be overridden. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38451/pgp0.pgp Description: PGP signature
fsck -p
Hi! Today I've got a hard lockup with 4.7 box. Upon reboot, ``fsck -p'' was run, and it resulted in the following, in particular: /dev/da0s1h: UNREF FILE I=591 OWNER=nobody MODE=100644 /dev/da0s1h: SIZE=81269024 MTIME=Nov 20 09:50 2002 (CLEARED) /dev/da0s1h: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/da0s1h: SUMMARY INFORMATION BAD (SALVAGED) /dev/da0s1h: BLK(S) MISSING IN BIT MAPS (SALVAGED) I thought that the correct action here would be to reconnect this file under fs's lost+found, but it did not happen. Why? (I've lost a week of useful squid's access.log.) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38206/pgp0.pgp Description: PGP signature
