From imp at bsdimp.com  Thu Jan  1 06:38:11 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu Jan  1 06:47:15 2009
Subject: svn commit: r186519 - head
In-Reply-To: <86r63p5334.fsf@ds4.des.no>
References: <26259E4E-6E26-4DAE-8046-80C7C46B7CD5@gmail.com>
	<20081227.193308.255407637.imp@bsdimp.com>
	<86r63p5334.fsf@ds4.des.no>
Message-ID: <20081231.233644.1974810120.imp@bsdimp.com>

In message: <86r63p5334.fsf@ds4.des.no>
            Dag-Erling_Sm?rgrav <des@des.no> writes:
: "M. Warner Losh" <imp@bsdimp.com> writes:
: > Still working on a solution that's correct and mutually acceptable to
: > DES.  i think the ball is in my court.
: 
: No, it's a build system issue.  If it's in anyone's court, it would be
: ru@'s.
: 
: The problem is that we need to use different CFLAGS for .o and .So.  The
: quick and dirty fix is to override the .c.o rule for PAM modules:
: 
: Index: /home/des/freebsd/base/head/lib/libpam/modules/Makefile.inc
: ===================================================================
: --- /home/des/freebsd/base/head/lib/libpam/modules/Makefile.inc	(revision 186063)
: +++ /home/des/freebsd/base/head/lib/libpam/modules/Makefile.inc	(working copy)
: @@ -19,4 +19,7 @@
:  LDADD+=		-lpam
:  .endif
:  
: +.c.o:
: +	${CC} ${CFLAGS} -DOPENPAM_STATIC_MODULES -c ${.IMPSRC}
: +
:  .include "../Makefile.inc"

I just tried this, and it doesn't work for me.  I still get the
errors.  The problem, I think, is that this doesn't get to the
root-cause of the issues I'm seeing.  This define doesn't affect
enough things.  If we look at
contrib/openpam/include/security/openpam.h, we see:

/*
 * Infrastructure for static modules using GCC linker sets.
 * You are not expected to understand this.
 */
#if defined(__FreeBSD__)
# define PAM_SOEXT ".so"
#else
# undef NO_STATIC_MODULES
# define NO_STATIC_MODULES
#endif

#if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES)
/* gcc, static linking */
# include <sys/cdefs.h>
# include <linker_set.h>
# define OPENPAM_STATIC_MODULES
# define PAM_EXTERN static
# define PAM_MODULE_ENTRY(name)						\
	static char _pam_name[] = name PAM_SOEXT;			\
	static struct pam_module _pam_module = {			\
		.path = _pam_name,					\
		.func = {						\
			[PAM_SM_AUTHENTICATE] = _PAM_SM_AUTHENTICATE,	\
			[PAM_SM_SETCRED] = _PAM_SM_SETCRED,		\
			[PAM_SM_ACCT_MGMT] = _PAM_SM_ACCT_MGMT,		\
			[PAM_SM_OPEN_SESSION] = _PAM_SM_OPEN_SESSION,	\
			[PAM_SM_CLOSE_SESSION] = _PAM_SM_CLOSE_SESSION, \
			[PAM_SM_CHAUTHTOK] = _PAM_SM_CHAUTHTOK		\
		},							\
	};								\
	DATA_SET(_openpam_static_modules, _pam_module)
#else
/* normal case */
# define PAM_EXTERN
# define PAM_MODULE_ENTRY(name)
#endif

so defining OPENPAM_STATIC_MODULES doesn't affect the PAM_EXTERN
define, so I get multiple defined things because __PIC__ is always
defined for mips, both for .o and .so compilation (because MIPS always
does PIC code for ABI compliance):

../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In function `pam_sm_open_session':
: multiple definition of `pam_sm_open_session'
../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14): first defined here
../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x50): In function `pam_sm_close_session':
: multiple definition of `pam_sm_close_session'
../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here
../modules/pam_echo/libpam_echo.a(pam_echo.o)(.text+0x0): In function `pam_sm_setcred':
: multiple definition of `pam_sm_setcred'
../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here

<etc>

The only thing that I've seen that really works is the following
unsatisfying kludge:

Index: include/security/openpam.h
===================================================================
--- include/security/openpam.h  (revision 186587)
+++ include/security/openpam.h  (working copy)
@@ -308,8 +308,9 @@
 /*
  * Infrastructure for static modules using GCC linker sets.
  * You are not expected to understand this.
+ * And it doesn't work on mips, so is disabled there.
  */
-#if defined(__FreeBSD__)
+#if defined(__FreeBSD__) && !defined(__mips__)
 # define PAM_SOEXT ".so"
 #else
 # undef NO_STATIC_MODULES

Or the following also works, which seems less kludgy.  Note, this
hasn't been run-time tested yet, just compile time.  It resolves the
overloading of __PIC__ to mean 'compiling dynamic libraries' by
relying on the OPENPAM_STATIC_MODULES being defined.  It also has the
advantage of not disabling this functionality on mips.  It has the
very mild disadvantage of not wrapping at 80 columns too :)

Index: contrib/openpam/include/security/openpam.h
===================================================================
--- contrib/openpam/include/security/openpam.h	(revision 186639)
+++ contrib/openpam/include/security/openpam.h	(working copy)
@@ -316,11 +316,10 @@
 # define NO_STATIC_MODULES
 #endif
 
-#if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES)
+#if defined(__GNUC__) && defined(OPENPAM_STATIC_MODULES) && !defined(NO_STATIC_MODULES)
 /* gcc, static linking */
 # include <sys/cdefs.h>
 # include <linker_set.h>
-# define OPENPAM_STATIC_MODULES
 # define PAM_EXTERN static
 # define PAM_MODULE_ENTRY(name)						\
 	static char _pam_name[] = name PAM_SOEXT;			\
Index: lib/libpam/modules/Makefile.inc
===================================================================
--- lib/libpam/modules/Makefile.inc	(revision 186639)
+++ lib/libpam/modules/Makefile.inc	(working copy)
@@ -19,4 +19,7 @@
 LDADD+=		-lpam
 .endif
 
+.c.o:
+	${CC} ${CFLAGS} -DOPENPAM_STATIC_MODULES -c ${.IMPSRC}
+
 .include "../Makefile.inc"

btw, I suspect that if we have a #define that's really true only for
.so's, then we should use that.  My quick look at the spec file didn't
show one.  I think one will have to come from the build system, and
I'm a little hesitant to innovate there too much without first having
a discussion about the right way to go.  Looking at your patch here,
it seems to be along the same lines that I'm thinking, but I'm not
sure I like the new variable names.

Comments?

Warner

P.S.  I've moved this discussion to arch@, which appears to be our
best, high S/N mailing list these days...
From des at des.no  Mon Jan  5 10:33:36 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Jan  5 10:33:43 2009
Subject: svn commit: r186519 - head
In-Reply-To: <20081231.233644.1974810120.imp@bsdimp.com> (M. Warner Losh's
	message of "Wed, 31 Dec 2008 23:36:44 -0700 (MST)")
References: <26259E4E-6E26-4DAE-8046-80C7C46B7CD5@gmail.com>
	<20081227.193308.255407637.imp@bsdimp.com> <86r63p5334.fsf@ds4.des.no>
	<20081231.233644.1974810120.imp@bsdimp.com>
Message-ID: <86eizim48w.fsf@ds4.des.no>

"M. Warner Losh" <imp@bsdimp.com> writes:
> I just tried this, and it doesn't work for me.

I didn't say it was sufficient, just that it was necessary.  You need an
OpenPAM patch as well (r418), but I can't commit it independently of the
build system changes.  I believe I posted the patch in an earlier
discussion.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From bugmaster at FreeBSD.org  Mon Jan  5 11:06:49 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jan  5 11:07:30 2009
Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org
Message-ID: <200901051106.n05B6mMO002717@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/120749  arch       [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

From rizzo at iet.unipi.it  Tue Jan  6 12:25:04 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Tue Jan  6 12:25:10 2009
Subject: RFC: adding > and >= to /usr/bin/make conditionals ?
In-Reply-To: <E2F5A6372272F744859F67CB11ABC1110507C7@exbe05.intra.dlr.de>
References: <200812262231.mBQMVjHC052150@svn.freebsd.org>
	<867i59lvbj.fsf@ds4.des.no>
	<20090105142929.GA70683@onelab2.iet.unipi.it>
	<E2F5A6372272F744859F67CB11ABC1110507C7@exbe05.intra.dlr.de>
Message-ID: <20090106121029.GA83861@onelab2.iet.unipi.it>

[not sure what is the proper forum for discussing this...]

I recently realised (and documented in the manpage) that /usr/bin/make
only implements == and != when comparing strings in coditionals,
yet it would be totally trivial to add support for > >= < <= as
well, because the underlying code already uses strcmp(), and
according to Harti (message attached below) there are no restrictions
from the standards point of view.

There is some value in having this feature, e.g. when comparing
package names to find out which one is more recent, etc.;
on the other hand, if we add (and start using) this feature,
our Makefiles might become harder to reuse on other platforms
(e.g. other BSDs, OSX ports) which use the same 'make' program.

So, I am polling to see if there is any consensus for or against
adding this feature to /usr/bin/make

	cheers
	luigi

[excerpt from Harti's message explaining the relation with standards]

On Mon, Jan 05, 2009 at 05:40:33PM +0100, Hartmut.Brandt@dlr.de wrote:
...
> >From the Posix standpoint of view, we can do what we want as long as we
> are not syntax compatible with posix-make :-) This is the reason, why
> most of our make extensions are compatible with posix. As soon as you
> have a construct that is a syntax error according to the Posix
> specification you invoke implementation-defined behaviour and as such
> you just have to document it. There are several of these escape
> mechanisms in the standard: the .POSIX pseudo-target and all targets
> that start with a dot and consist of uppercase letters.
> 
> With regard to conditionals: there is no standard. Posix decided to
> standard only minimal make, which is roughly compatible to V7 make. If
> you change things like conditional semantics you should: (1) document
> it, and (2) arrange a full ports build with the portcluster people. This
> takes some days, but is a good thing to do.
> 
> harti
From nwhitehorn at freebsd.org  Tue Jan  6 19:54:43 2009
From: nwhitehorn at freebsd.org (Nathan Whitehorn)
Date: Tue Jan  6 19:55:15 2009
Subject: Enumerable I2C busses
In-Reply-To: <20081124.105800.-267230932.imp@bsdimp.com>
References: <4929C6D8.7090305@freebsd.org>	<20081123.170854.-626772149.imp@bsdimp.com>	<492AC8DE.6050902@freebsd.org>
	<20081124.105800.-267230932.imp@bsdimp.com>
Message-ID: <4963AFE3.5080607@freebsd.org>

M. Warner Losh wrote:
> In message: <492AC8DE.6050902@freebsd.org>
>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : M. Warner Losh wrote:
> : > In message: <4929C6D8.7090305@freebsd.org>
> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : > : Rafa? Jaworowski wrote:
> : > : > 
> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
> : > : > 
> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : > : >>> The current I2C bus mechanism does not support the bus adding its own
> : > : >>> children [...]
> : > : >>
> : > : >> That's because the I2C protocol does not support device enumeration or
> : > : >> identification.  You have to know in advance what kind of devices are
> : > : >> attached and at what address.  Even worse, it is not uncommon for
> : > : >> similar but not entirely compatible devices to use the same I2C address
> : > : >> (for instance, every I2C-capable RTC chip uses the same address, even
> : > : >> though they have different feature sets)
> : > : > 
> : > : > Well, hard-coded addresses and conflicting assignments between vendors 
> : > : > do not technically prevent from scanning the bus; actually, our current 
> : > : > iicbus code can do bus scaning when compiled with a diag define. The 
> : > : > problem however is some slave devices are not well-behaved, and they 
> : > : > don't like to be read/written to other than in very specific scenario: 
> : > : > if polled during bus scan strange effects occur e.g. they disappear from 
> : > : > the bus, or do not react to consecutive requests etc.
> : > : 
> : > : All of this is true, but perhaps my question was badly worded. What I am 
> : > : trying to figure out is how to shove information from an out-of-band 
> : > : source (Open Firmware, in this case) into newbus without disrupting 
> : > : existing code. In that way, my question is not I2C specific -- we run 
> : > : into the same issue with the Open Firmware nexus node and pseudo-devices 
> : > : like cryptosoft that attach themselves.
> : > 
> : > You are looking at the problem incorrectly.  In newbus, a case like
> : > this the i2c bus should be a subclass (say i2c_of) that is derived
> : > from the normal i2c bus stuff, but replaces the hints insertion of
> : > devices with OF enumeration of devices.  The OF higher levels will
> : > already know to attach this kind of i2c bus to certain i2c
> : > controllers, or always on certain platforms.
> : 
> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
> : 
> : > : What I want to do is to have the I2C bus add the children that the 
> : > : firmware says it has. What the firmware cannot tell in advance, however, 
> : > : is which FreeBSD driver is responsible for those devices, and so the I2C 
> : > : bus driver can't know that without a translation table that I would 
> : > : prefer not to hack in to the bus driver.
> : > 
> : > This is the bigger problem.  Today, we are stuck with a lame table
> : > that will translate the OF provided properties into FreeBSD driver
> : > names.
> : 
> : At the moment, I don't believe Apple uses any of the current very small 
> : number of I2C device drivers in tree. So I may skip the table for the 
> : time being, assuming the hack below is OK. In future, this may change, 
> : since G5 systems require software thermal control. But that will be the 
> : subject of another mail to this list...
> : 
> : > : It seems reasonable to allow devices to use a real probe routine to look 
> : > : at the firmware's name and compatible properties, like we allow on other 
> : > : Open Firmware busses. The trouble is that existing drivers don't do 
> : > : this, because they expect to be attached with hints, so they will attach 
> : > : to all devices. I'm trying to figure out how to avoid this.
> : > : 
> : > : My basic question comes down to whether there is a good way in newbus to 
> : > : handle busses that may be wholly or partially enumerated by firmware or 
> : > : some other method, and may also have devices that can only attach 
> : > : themselves if told to by hints.
> : > 
> : > Yes.  This is a bit of a problem.  The problem is that the existing
> : > hints mechanism combines device tree and driver tree into one, and in
> : > such a scenario, we wind up with the problem that you have.
> : > 
> : > One could make the probe routines return BUS_PROBE_GENERIC, and that
> : > would help somewhat.  One could also have the probe routine check to
> : > see if a specific driver is assigned to the device or not.  That would
> : > also help, but does mean changing all the i2c bus attached drivers in
> : > the tree.
> : 
> : I think changing existing I2C drivers may be unavoidable. Would there be 
> : any objection to changing the MI iicbus drivers to return 
> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been 
> : introduced (by you) to solve more or less exactly this problem. By my 
> : count, the relevant files are:
> : dev/iicbus/ds133x.c
> : dev/iicbus/icee.c
> : dev/iicbus/ad7418.c
> : dev/iicbus/iicsmb.c
> : dev/iicbus/ds1672.c
> : dev/iicbus/if_ic.c
> : dev/iicbus/iic.c
> : 
> : I would also like to change iicbus_probe to return -1000 like 
> : dev/pci/pci.c to allow it to be overridden by a subclass. Please let me 
> : know if this is a terrible idea or if I have forgotten any I2C device 
> : drivers.
>
> Short term, this is the right fix.  There was an objection, I think by
> Marcel, to this approach.  However, his objections were part of a
> larger set of objections and I think that we're working to solve
> those.
>
> Warner
>   
This is now in the tree. Now for part 2, which I had not considered 
previously: connecting the I2C bus layer to the I2C host adapters.

Right now, we have the following:
kiic/other i2c adapters
---iicbus
---ofw_iicbus

Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
attaches, and everything after that is wonderful. The issue is how best 
to attach the iicbus modules to kiic. Current I2C controllers contain a 
line like this:
DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);

This explicitly specifies that you want the standard driver, so we need 
additional glue to allow the ofw_iicbus driver to attach. One solution 
is that each relevant host adapter can add an additional DRIVER_MODULE 
line with the ofw_iicbus driver and class, which would have to exported 
in a header somewhere. This is pretty ugly. Another solution is for the 
ofw_iicbus module to grow a list of the names of interesting adapters. 
This is worse.

The third option is to do what we do for pci, where all PCI adapters are 
named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
something, and then move the DRIVER_MODULE logic for new code into the 
bus modules, as is done for PCI. This decreases the amount of 
information in the device names, but seems a bit cleaner. Thoughts?
-Nathan
From delphij at delphij.net  Fri Jan  9 02:26:46 2009
From: delphij at delphij.net (Xin LI)
Date: Fri Jan  9 02:26:53 2009
Subject: RFC: MI strlen()
Message-ID: <4966B5D4.7040709@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Here is a new implementation of strlen() which employed the bitmask
skill in order to achieve better performance on modern hardware.  For
common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is
intended for MI use when there is no hand-optimized assembly.

	http://people.freebsd.org/~delphij/for_review/strlen.diff

Note that this version of strlen() has suboptimal performance if there
are a lot of characters that has their highest bit set (we can change it
to have uniform performance at the expense of about ~30% performance
penalty).

Comments?

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklmtdQACgkQi+vbBBjt66CltACfY1j+JJnn3PDLOmO1uOpMkMlg
94gAn3v9eSExj84hcNYEI0AhLGWBCxMj
=xzFJ
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: strlen.c
===================================================================
--- strlen.c	(revision 186910)
+++ strlen.c	(working copy)
@@ -1,6 +1,6 @@
 /*-
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
+ * Copyright (c) 2009 Xin LI <delphij@FreeBSD.org>
+ * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -10,14 +10,11 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
  *    documentation and/or other materials provided with the distribution.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
  *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
@@ -27,21 +24,93 @@
  * SUCH DAMAGE.
  */
 
-#if defined(LIBC_SCCS) && !defined(lint)
-static char sccsid[] = "@(#)strlen.c	8.1 (Berkeley) 6/4/93";
-#endif /* LIBC_SCCS and not lint */
 #include <sys/cdefs.h>
 __FBSDID("$FreeBSD$");
 
+#include <sys/limits.h>
+#include <sys/types.h>
 #include <string.h>
 
+#ifndef CTASSERT
+#define CTASSERT(x)		_CTASSERT(x, __LINE__)
+#define _CTASSERT(x, y)		__CTASSERT(x, y)
+#define __CTASSERT(x, y)	typedef char __assert_ ## y [(x) ? 1 : -1]
+#endif
+
+CTASSERT(LONG_BIT == 32 || LONG_BIT == 64);
+
+/*
+ * Portable strlen() for 32-bit and 64-bit systems.
+ *
+ * Rationale: it is generally much more efficient to do word length
+ * operations and avoid branches on modern computer systems, as
+ * compared to byte-length operations with a lot of branches.
+ *
+ * The expression:
+ *
+ *	((x - 0x01....01) & ~x & 0x80....80)
+ *
+ * would evaluate to a non-zero value iff any of the bytes in the
+ * original word is zero.  However, we can further reduce ~1/3 of
+ * time if we consider that strlen() usually operate on 7-bit ASCII
+ * by employing the following expression, which allows false positive
+ * when high bit of 1 and use the tail case to catch these case:
+ *
+ *	((x - 0x01....01) & 0x80....80)
+ *
+ * This is more than 5.2 times as compared to the raw implementation
+ * on Intel T7300 under EM64T mode.
+ */
+
+/* Magic numbers for the algorithm */
+#if LONG_BIT == 32
+static const unsigned long mask01 = 0x01010101;
+static const unsigned long mask80 = 0x80808080;
+#elif LONG_BIT == 64
+static const unsigned long mask01 = 0x0101010101010101;
+static const unsigned long mask80 = 0x8080808080808080;
+#endif
+
+#define	LONGPTR_MASK (sizeof(long) - 1)
+
+/*
+ * Helper macro to return string length if we caught the zero
+ * byte.
+ */
+#define testbyte(x)				\
+	do {					\
+		if (p[x] == '\0')		\
+		    return (p - str + x);	\
+	} while (0);
+
 size_t
-strlen(str)
-	const char *str;
+strlen(const char *str)
 {
-	const char *s;
+	const char *p;
+	const unsigned long *lp;
 
-	for (s = str; *s; ++s);
-	return(s - str);
+	/* Skip the first few bytes until we have an aligned p */
+	for (p = str; (uintptr_t)p & LONGPTR_MASK; ++p)
+	    if (*p == 0)
+		return (p - str);
+
+	/* Scan the rest of the string using word sized operation */
+	for (lp = (const unsigned long *)p; ; lp++)
+	    if ((*lp - mask01) & mask80) {
+		p = (const char *)(lp);
+		testbyte(0);
+		testbyte(1);
+		testbyte(2);
+		testbyte(3);
+#if (LONG_BIT >= 64)
+		testbyte(4);
+		testbyte(5);
+		testbyte(6);
+		testbyte(7);
+#endif
+	    }
+
+	/* NOTREACHED */
+	return 0;
 }
 
From delphij at delphij.net  Fri Jan  9 04:26:43 2009
From: delphij at delphij.net (Xin LI)
Date: Fri Jan  9 04:28:57 2009
Subject: RFC: MI strlen()
In-Reply-To: <alpine.BSF.2.00.0901082137210.1315@baba.farley.org>
References: <4966B5D4.7040709@delphij.net>
	<alpine.BSF.2.00.0901082137210.1315@baba.farley.org>
Message-ID: <4966D1F7.1040105@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Sean,

Sean C. Farley wrote:
> On Thu, 8 Jan 2009, Xin LI wrote:
> 
>> Hi,
>>
>> Here is a new implementation of strlen() which employed the bitmask
>> skill in order to achieve better performance on modern hardware.  For
>> common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is
>> intended for MI use when there is no hand-optimized assembly.
>>
>>     http://people.freebsd.org/~delphij/for_review/strlen.diff
>>
>> Note that this version of strlen() has suboptimal performance if there
>> are a lot of characters that has their highest bit set (we can change
>> it to have uniform performance at the expense of about ~30%
>> performance penalty).
>>
>> Comments?
> 
> I only glanced over it, but I like the idea about having it.
> 
> I see that you investigated this before[1]?  Amusingly, I did something

Yes, but nothing gets committed :-/  I think I had lost that work due to
a hard disk failure.

> similar two years later[2] with a C version of strlen()[3].  :)
> 
> Out of curiosity, is an assert (i.e., CTASSERT) better than an #error?

Hmm...  I did not thought about it, but looking at your code, it seems
that using #error makes it more obvious.

I have put the revised version at:

	http://people.freebsd.org/~delphij/for_review/strlen-r1.diff

For those who wants to see the file instead of the diff:

	http://people.freebsd.org/~delphij/for_review/strlen.c

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklm0fcACgkQi+vbBBjt66DWMgCePfKWpIzThVYBRd41lJ3t85KU
UrUAoLyiCnnLBBgWk2YbevkZcxHI6XQy
=Qhk+
-----END PGP SIGNATURE-----
From alfred at freebsd.org  Fri Jan  9 04:42:27 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Fri Jan  9 04:42:34 2009
Subject: RFC: MI strlen()
In-Reply-To: <4966B5D4.7040709@delphij.net>
References: <4966B5D4.7040709@delphij.net>
Message-ID: <20090109042557.GH60686@elvis.mu.org>

* Xin LI <delphij@delphij.net> [090108 18:27] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Here is a new implementation of strlen() which employed the bitmask
> skill in order to achieve better performance on modern hardware.  For
> common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is
> intended for MI use when there is no hand-optimized assembly.
> 
> 	http://people.freebsd.org/~delphij/for_review/strlen.diff
> 
> Note that this version of strlen() has suboptimal performance if there
> are a lot of characters that has their highest bit set (we can change it
> to have uniform performance at the expense of about ~30% performance
> penalty).
> 
> Comments?

It's pretty cool, what does valgrind say when you walk past
the end of a string, can it figure that out?

> 
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
> FreeBSD - The Power to Serve!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
> 
> iEYEARECAAYFAklmtdQACgkQi+vbBBjt66CltACfY1j+JJnn3PDLOmO1uOpMkMlg
> 94gAn3v9eSExj84hcNYEI0AhLGWBCxMj
> =xzFJ
> -----END PGP SIGNATURE-----

> Index: strlen.c
> ===================================================================
> --- strlen.c	(revision 186910)
> +++ strlen.c	(working copy)
> @@ -1,6 +1,6 @@
>  /*-
> - * Copyright (c) 1990, 1993
> - *	The Regents of the University of California.  All rights reserved.
> + * Copyright (c) 2009 Xin LI <delphij@FreeBSD.org>
> + * All rights reserved.
>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> @@ -10,14 +10,11 @@
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *    notice, this list of conditions and the following disclaimer in the
>   *    documentation and/or other materials provided with the distribution.
> - * 4. Neither the name of the University nor the names of its contributors
> - *    may be used to endorse or promote products derived from this software
> - *    without specific prior written permission.
>   *
> - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
>   * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>   * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> - * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
>   * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
>   * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
>   * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> @@ -27,21 +24,93 @@
>   * SUCH DAMAGE.
>   */
>  
> -#if defined(LIBC_SCCS) && !defined(lint)
> -static char sccsid[] = "@(#)strlen.c	8.1 (Berkeley) 6/4/93";
> -#endif /* LIBC_SCCS and not lint */
>  #include <sys/cdefs.h>
>  __FBSDID("$FreeBSD$");
>  
> +#include <sys/limits.h>
> +#include <sys/types.h>
>  #include <string.h>
>  
> +#ifndef CTASSERT
> +#define CTASSERT(x)		_CTASSERT(x, __LINE__)
> +#define _CTASSERT(x, y)		__CTASSERT(x, y)
> +#define __CTASSERT(x, y)	typedef char __assert_ ## y [(x) ? 1 : -1]
> +#endif
> +
> +CTASSERT(LONG_BIT == 32 || LONG_BIT == 64);
> +
> +/*
> + * Portable strlen() for 32-bit and 64-bit systems.
> + *
> + * Rationale: it is generally much more efficient to do word length
> + * operations and avoid branches on modern computer systems, as
> + * compared to byte-length operations with a lot of branches.
> + *
> + * The expression:
> + *
> + *	((x - 0x01....01) & ~x & 0x80....80)
> + *
> + * would evaluate to a non-zero value iff any of the bytes in the
> + * original word is zero.  However, we can further reduce ~1/3 of
> + * time if we consider that strlen() usually operate on 7-bit ASCII
> + * by employing the following expression, which allows false positive
> + * when high bit of 1 and use the tail case to catch these case:
> + *
> + *	((x - 0x01....01) & 0x80....80)
> + *
> + * This is more than 5.2 times as compared to the raw implementation
> + * on Intel T7300 under EM64T mode.
> + */
> +
> +/* Magic numbers for the algorithm */
> +#if LONG_BIT == 32
> +static const unsigned long mask01 = 0x01010101;
> +static const unsigned long mask80 = 0x80808080;
> +#elif LONG_BIT == 64
> +static const unsigned long mask01 = 0x0101010101010101;
> +static const unsigned long mask80 = 0x8080808080808080;
> +#endif
> +
> +#define	LONGPTR_MASK (sizeof(long) - 1)
> +
> +/*
> + * Helper macro to return string length if we caught the zero
> + * byte.
> + */
> +#define testbyte(x)				\
> +	do {					\
> +		if (p[x] == '\0')		\
> +		    return (p - str + x);	\
> +	} while (0);
> +
>  size_t
> -strlen(str)
> -	const char *str;
> +strlen(const char *str)
>  {
> -	const char *s;
> +	const char *p;
> +	const unsigned long *lp;
>  
> -	for (s = str; *s; ++s);
> -	return(s - str);
> +	/* Skip the first few bytes until we have an aligned p */
> +	for (p = str; (uintptr_t)p & LONGPTR_MASK; ++p)
> +	    if (*p == 0)
> +		return (p - str);
> +
> +	/* Scan the rest of the string using word sized operation */
> +	for (lp = (const unsigned long *)p; ; lp++)
> +	    if ((*lp - mask01) & mask80) {
> +		p = (const char *)(lp);
> +		testbyte(0);
> +		testbyte(1);
> +		testbyte(2);
> +		testbyte(3);
> +#if (LONG_BIT >= 64)
> +		testbyte(4);
> +		testbyte(5);
> +		testbyte(6);
> +		testbyte(7);
> +#endif
> +	    }
> +
> +	/* NOTREACHED */
> +	return 0;
>  }
>  

> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-- 
- Alfred Perlstein
From scf at FreeBSD.org  Fri Jan  9 04:43:57 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Jan  9 04:44:09 2009
Subject: RFC: MI strlen()
In-Reply-To: <4966B5D4.7040709@delphij.net>
References: <4966B5D4.7040709@delphij.net>
Message-ID: <alpine.BSF.2.00.0901082137210.1315@baba.farley.org>

On Thu, 8 Jan 2009, Xin LI wrote:

> Hi,
>
> Here is a new implementation of strlen() which employed the bitmask 
> skill in order to achieve better performance on modern hardware.  For 
> common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is 
> intended for MI use when there is no hand-optimized assembly.
>
> 	http://people.freebsd.org/~delphij/for_review/strlen.diff
>
> Note that this version of strlen() has suboptimal performance if there
> are a lot of characters that has their highest bit set (we can change 
> it to have uniform performance at the expense of about ~30% 
> performance penalty).
>
> Comments?

I only glanced over it, but I like the idea about having it.

I see that you investigated this before[1]?  Amusingly, I did something 
similar two years later[2] with a C version of strlen()[3].  :)

Out of curiosity, is an assert (i.e., CTASSERT) better than an #error?

Sean
   1. http://lists.freebsd.org/mailman/htdig/freebsd-arch/2005-August/004076.html
   2. http://lists.freebsd.org/pipermail/freebsd-arch/2007-July/006636.html
   3. http://www.farley.org/freebsd/tmp/strlen/strlen.c
-- 
scf@FreeBSD.org
From delphij at delphij.net  Fri Jan  9 05:01:03 2009
From: delphij at delphij.net (Xin LI)
Date: Fri Jan  9 05:01:10 2009
Subject: RFC: MI strlen()
In-Reply-To: <20090109042557.GH60686@elvis.mu.org>
References: <4966B5D4.7040709@delphij.net>
	<20090109042557.GH60686@elvis.mu.org>
Message-ID: <4966DA02.6060508@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alfred Perlstein wrote:
> * Xin LI <delphij@delphij.net> [090108 18:27] wrote:
> Hi,
> 
> Here is a new implementation of strlen() which employed the bitmask
> skill in order to achieve better performance on modern hardware.  For
> common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is
> intended for MI use when there is no hand-optimized assembly.
> 
> 	http://people.freebsd.org/~delphij/for_review/strlen.diff
> 
> Note that this version of strlen() has suboptimal performance if there
> are a lot of characters that has their highest bit set (we can change it
> to have uniform performance at the expense of about ~30% performance
> penalty).
> 
> Comments?
> 
>> It's pretty cool, what does valgrind say when you walk past
>> the end of a string, can it figure that out?

I don't have a runnable valgrind at hand so can't say about it :(  This
type of walk past should not cause problem though, as page is always
word aligned and it does not do more speculative read than the old
strlen() implementation (read past a word vs read past a byte against
the page when overrun happen).

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklm2gAACgkQi+vbBBjt66C0KACfctSU8/o2ciuu79XYZ21G0VRY
qC0AoIeC/cKp1bHJqxNsVr391BBvzyK9
=kxFV
-----END PGP SIGNATURE-----
From rizzo at iet.unipi.it  Fri Jan  9 13:04:10 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Fri Jan  9 13:04:17 2009
Subject: tagging disk requests (geom-related)
Message-ID: <20090109130911.GA17017@onelab2.iet.unipi.it>

Hi,
together with Fabio Checconi we are working on some disk schedulers
using a geom class.
One of the things we have is to do is tag requests (struct bio)
with the identity of the thread issuing the request (or some other
classification information, but which one is irrelevant here).
We cannot do the tagging when we reach our geom class because at this
point we have lost the thread information (curthread is "g_down"
at this point).

So there are two issues here: 1) where to store the tag, 2) who
does the tagging.

    (Background for non geom-aware people: each request is identified
    by a 'struct bio' (BIO); when moving from a GEOM class to the
    next one downstream, a BIO is cloned and possibly split (e.g.,
    to do slicing, RAID, or simply breaking up large requests) and
    each child BIO has a pointer to the parent BIO, so overall they
    are connected in a tree even though more frequently there is
    just a linear chain.)

For #1, to avoid adding a field to 'struct bio', we store the tag
in the bio_caller1 field (if available) of the root element of the
BIO tree, bio_caller1 is normally unused (except by ZFS), and we
say it is available if it contains NULL. For the reasons stated
above, we cannot store the mark in the BIO associated to our geom
class because it does not exist yet when we need to store the mark.

Re #2, we can put the code that does the marking either in the place
where the root BIO is created (but there may be many such places,
and especially they can be in external modules that we are not even
aware of), or hook into a central place, g_io_request(), and walk
up the BIO tree until we find the root:

        {
                struct bio *top = bp;

                while (top->bio_parent)
                        top = top->bio_parent;
                if (top->bio_caller1 == NULL)
                        top->bio_caller1 = (void *)curthread->td_tid;
        }

We opted for the latter.
The drawbacks of this approach are that we are writing in a BIO
that is not ours, also that bio_caller1 might be unavailable (e.g.
in the ZFS case).

The alternative approach is adding one field to the struct bio -- in this
case the marking could just be done on the current BIO in g_io_request,
and propagated down in g_clone_bio() (or just in the lookup, walk
up the tree to the topmost marked bio).

So, do you have any better ideas, e.g. other fields in the topmost
bio that we can use ?

	cheers
	luigi

From rizzo at iet.unipi.it  Fri Jan  9 14:31:39 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Fri Jan  9 14:31:46 2009
Subject: tagging disk requests (geom-related)
In-Reply-To: <22308.1231510855@critter.freebsd.dk>
References: <20090109130911.GA17017@onelab2.iet.unipi.it>
	<22308.1231510855@critter.freebsd.dk>
Message-ID: <20090109143641.GA19478@onelab2.iet.unipi.it>

On Fri, Jan 09, 2009 at 02:20:55PM +0000, Poul-Henning Kamp wrote:
> In message <20090109130911.GA17017@onelab2.iet.unipi.it>, Luigi Rizzo writes:
> 
> >    (Background for non geom-aware people: each request is identified
> >    by a 'struct bio' (BIO);
> 
> Strictly speaking, the bio *is* the request :-)
> 
> >For #1, to avoid adding a field to 'struct bio', we store the tag
> >in the bio_caller1 field (if available) of the root element of the
> >BIO tree, bio_caller1 is normally unused (except by ZFS), and we
> >say it is available if it contains NULL.
> 
> This is wrong, bio_caller1 is for the caller to store private
> information, you should not hi-jack it.
> 
> >Re #2, we can put the code that does the marking either in the place
> >where the root BIO is created (but there may be many such places,
> >and especially they can be in external modules that we are not even
> >aware of), or hook into a central place, g_io_request(), and walk
> >up the BIO tree until we find the root:
> 
> This will not work, some GEOM classes initiate bios, (RAID5 parity
> stripes for instance.
> 
> It is also really stupid to walk the chain repeatedly like this.
> 
> >The alternative approach is adding one field to the struct bio -- in this
> >case the marking could just be done on the current BIO in g_io_request,
> >and propagated down in g_clone_bio() (or just in the lookup, walk
> >up the tree to the topmost marked bio).
> 
> That's the way to go.

I agree. Probably there is no other reliable way.
The unfortunate drawback of this approach is that it changes
the size of the bio (so you need a full rebuild of kernel and modules),
that's why I was hoping for a possibly unused field in the topmost bio
to store the tag.

> Also, and please make sure you understand the depth of this suggestion
> before you dismiss it:
> 
> Instead of recording the identity of the originator, you should
> record a struct containing capabilities of the originator, one
> of which could be the identity.

yes, as i said in the original post the details are irrelevant now,
i just needed a place to hook the additional info to the bio.
Once i have that, i can do all details i need.

	thanks
	luigi
From phk at phk.freebsd.dk  Fri Jan  9 14:36:30 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri Jan  9 14:36:37 2009
Subject: tagging disk requests (geom-related) 
In-Reply-To: Your message of "Fri, 09 Jan 2009 14:09:11 +0100."
	<20090109130911.GA17017@onelab2.iet.unipi.it> 
Message-ID: <22308.1231510855@critter.freebsd.dk>

In message <20090109130911.GA17017@onelab2.iet.unipi.it>, Luigi Rizzo writes:

>    (Background for non geom-aware people: each request is identified
>    by a 'struct bio' (BIO);

Strictly speaking, the bio *is* the request :-)

>For #1, to avoid adding a field to 'struct bio', we store the tag
>in the bio_caller1 field (if available) of the root element of the
>BIO tree, bio_caller1 is normally unused (except by ZFS), and we
>say it is available if it contains NULL.

This is wrong, bio_caller1 is for the caller to store private
information, you should not hi-jack it.

>Re #2, we can put the code that does the marking either in the place
>where the root BIO is created (but there may be many such places,
>and especially they can be in external modules that we are not even
>aware of), or hook into a central place, g_io_request(), and walk
>up the BIO tree until we find the root:

This will not work, some GEOM classes initiate bios, (RAID5 parity
stripes for instance.

It is also really stupid to walk the chain repeatedly like this.

>The alternative approach is adding one field to the struct bio -- in this
>case the marking could just be done on the current BIO in g_io_request,
>and propagated down in g_clone_bio() (or just in the lookup, walk
>up the tree to the topmost marked bio).

That's the way to go.

Also, and please make sure you understand the depth of this suggestion
before you dismiss it:

Instead of recording the identity of the originator, you should
record a struct containing capabilities of the originator, one
of which could be the identity.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
From imp at bsdimp.com  Sun Jan 11 08:53:56 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Jan 11 08:54:02 2009
Subject: Quick hack to make fast kernel builds easier
Message-ID: <20090111.095109.-1112748421.imp@bsdimp.com>

This patch makes

make buildkernel -DKERNFAST

a short cut for

make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND

which is a lot shorter to type.

comments?

Warner


Index: Makefile.inc1
===================================================================
--- Makefile.inc1	(revision 186807)
+++ Makefile.inc1	(working copy)
@@ -5,6 +5,7 @@
 #	-DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir
 #	-DNO_CLEAN do not clean at all
 #	-DNO_SHARE do not go into share subdir
+#	-DKERNFAST define NO_KERNELCONFIG, NO_KERNELCLEAN and NO_KERNELCONFIG
 #	-DNO_KERNELCONFIG do not run config in ${MAKE} buildkernel
 #	-DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel
 #	-DNO_KERNELDEPEND do not run ${MAKE} depend in ${MAKE} buildkernel
@@ -697,6 +699,11 @@
 # be set to cross-build, we have to make sure TARGET is set
 # properly.
 
+.if defined(KERNFAST)
+NO_KERNELCLEAN=	t
+NO_KERNELCONFIG=	t
+NO_KERNELDEPEND=	t
+.endif
 .if !defined(KERNCONF) && defined(KERNEL)
 KERNCONF=	${KERNEL}
 KERNWARN=
From kostikbel at gmail.com  Sun Jan 11 09:04:26 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Jan 11 09:05:59 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
Message-ID: <20090111170420.GV93900@deviant.kiev.zoral.com.ua>

On Sun, Jan 11, 2009 at 09:51:09AM -0700, M. Warner Losh wrote:
> This patch makes
> 
> make buildkernel -DKERNFAST
> 
> a short cut for
> 
> make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND
> 
> which is a lot shorter to type.
> 
> comments?

Nice and useful. I have 3x-DNO_... scripted in several places,
this options would reduce my typing when I do make by hands.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090111/b08d90e2/attachment.pgp
From ed at 80386.nl  Sun Jan 11 09:24:29 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sun Jan 11 09:24:36 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
Message-ID: <20090111172427.GD89178@hoeg.nl>

* M. Warner Losh <imp@bsdimp.com> wrote:
> This patch makes
> 
> make buildkernel -DKERNFAST
> 
> a short cut for
> 
> make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND
> 
> which is a lot shorter to type.

Why not call it:

	make buildkernel -DOIT

</bikeshed>

Seriously: Please commit this. I often just run `make' in /usr/obj/...,
which also saves some typing, but unfortunately that doesn't work when
cross compiling.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090111/74ad1ab4/attachment.pgp
From gnn at neville-neil.com  Sun Jan 11 10:31:51 2009
From: gnn at neville-neil.com (George Neville-Neil)
Date: Sun Jan 11 10:31:58 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
Message-ID: <80B0FC55-BCC9-4971-84F7-5838D6892EC1@neville-neil.com>


On Jan 11, 2009, at 11:51 , M. Warner Losh wrote:

> This patch makes
>
> make buildkernel -DKERNFAST
>
> a short cut for
>
> make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND
>
> which is a lot shorter to type.
>
> comments?
>

Looks great to me.

Later,
George

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090111/8d973a41/PGP.pgp
From das at FreeBSD.ORG  Sun Jan 11 11:22:32 2009
From: das at FreeBSD.ORG (David Schultz)
Date: Sun Jan 11 11:22:39 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111172427.GD89178@hoeg.nl>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
	<20090111172427.GD89178@hoeg.nl>
Message-ID: <20090111191251.GA74450@zim.MIT.EDU>

On Sun, Jan 11, 2009, Ed Schouten wrote:
> I often just run `make' in /usr/obj/...,
> which also saves some typing, but unfortunately that doesn't work when
> cross compiling.

Also, as far as I know, there's no convenient way to rebuild a
single module for another architecture. I use the following script
called 'arch' to set the appropriate environment variables, so if
I've already run 'make universe' and I want to rebuild libc for
sparc64, I say:

   cd /usr/src/lib/libc && arch sparc64 make

It would be nice if there were a better mechanism for this that's
integrated into the build system.

#!/bin/sh

arch=$1
basepath=/usr/src

export __MAKE_CONF=/dev/null
export MAKEOBJDIRPREFIX=/usr/obj/${arch}
export MACHINE_ARCH=${arch}
export MACHINE=${arch}
export CPUTYPE=
export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin
export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font
export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac
export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp
export INSTALL="sh /usr/src/tools/install.sh"
export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
DESTDIR=/usr/obj/${arch}${basepath}/tmp

shift
$*
From imp at bsdimp.com  Sun Jan 11 13:27:54 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Jan 11 13:28:01 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
	<20090111172427.GD89178@hoeg.nl>
	<20090111191251.GA74450@zim.MIT.EDU>
Message-ID: <20090111.142350.1560738814.imp@bsdimp.com>

In message: <20090111191251.GA74450@zim.MIT.EDU>
            David Schultz <das@FreeBSD.ORG> writes:
: On Sun, Jan 11, 2009, Ed Schouten wrote:
: > I often just run `make' in /usr/obj/...,
: > which also saves some typing, but unfortunately that doesn't work when
: > cross compiling.
: 
: Also, as far as I know, there's no convenient way to rebuild a
: single module for another architecture. I use the following script
: called 'arch' to set the appropriate environment variables, so if
: I've already run 'make universe' and I want to rebuild libc for
: sparc64, I say:
: 
:    cd /usr/src/lib/libc && arch sparc64 make
: 
: It would be nice if there were a better mechanism for this that's
: integrated into the build system.

I do one of the following:

(1) env TARGET=arm make buildworld -DNO_CLEAN

or

(2) env TARGET=arm make buildenv
$ cd lib/libc && make

These both work out well enough in practice for me.  I've wanted a
target that was 'reworld' that just did an 'all' and maybe a few other
things, but I've never had the time to polish this up (had it in a
couple of trees that I lost due to disk failure).

I do agree it would be nice if there was some way to do 'all' for a
subdirectory with a 'trust me, I know what I'm doing, so don't do all
that other stuff' flag.

Warner

: #!/bin/sh
: 
: arch=$1
: basepath=/usr/src
: 
: export __MAKE_CONF=/dev/null
: export MAKEOBJDIRPREFIX=/usr/obj/${arch}
: export MACHINE_ARCH=${arch}
: export MACHINE=${arch}
: export CPUTYPE=
: export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin
: export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font
: export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac
: export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp
: export INSTALL="sh /usr/src/tools/install.sh"
: export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
: DESTDIR=/usr/obj/${arch}${basepath}/tmp
: 
: shift
: $*
: 
: 
From sam at freebsd.org  Sun Jan 11 13:45:02 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Jan 11 13:45:08 2009
Subject: Quick hack to make fast kernel builds easier [really cross-build
 support]
In-Reply-To: <20090111.142350.1560738814.imp@bsdimp.com>
References: <20090111.095109.-1112748421.imp@bsdimp.com>	<20090111172427.GD89178@hoeg.nl>	<20090111191251.GA74450@zim.MIT.EDU>
	<20090111.142350.1560738814.imp@bsdimp.com>
Message-ID: <496A65E1.5030309@freebsd.org>

M. Warner Losh wrote:
> In message: <20090111191251.GA74450@zim.MIT.EDU>
>             David Schultz <das@FreeBSD.ORG> writes:
> : On Sun, Jan 11, 2009, Ed Schouten wrote:
> : > I often just run `make' in /usr/obj/...,
> : > which also saves some typing, but unfortunately that doesn't work when
> : > cross compiling.
> : 
> : Also, as far as I know, there's no convenient way to rebuild a
> : single module for another architecture. I use the following script
> : called 'arch' to set the appropriate environment variables, so if
> : I've already run 'make universe' and I want to rebuild libc for
> : sparc64, I say:
> : 
> :    cd /usr/src/lib/libc && arch sparc64 make
> : 
> : It would be nice if there were a better mechanism for this that's
> : integrated into the build system.
>
> I do one of the following:
>
> (1) env TARGET=arm make buildworld -DNO_CLEAN
>
> or
>
> (2) env TARGET=arm make buildenv
> $ cd lib/libc && make
>
> These both work out well enough in practice for me.  I've wanted a
> target that was 'reworld' that just did an 'all' and maybe a few other
> things, but I've never had the time to polish this up (had it in a
> couple of trees that I lost due to disk failure).
>
> I do agree it would be nice if there was some way to do 'all' for a
> subdirectory with a 'trust me, I know what I'm doing, so don't do all
> that other stuff' flag.
>
>   
I told das privately but will note publicly that:

tools/tools/nanobsd/gateworks

uses make buildenv to cross-build various bits.  At some point I want to 
promote some of the shell code to be part of nanobsd but until we've got 
something to deal with ports I'm in no hurry.

    Sam

From imp at bsdimp.com  Sun Jan 11 13:47:52 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Jan 11 13:47:58 2009
Subject: Quick hack to make fast kernel builds easier [really
 cross-build support]
In-Reply-To: <496A65E1.5030309@freebsd.org>
References: <20090111191251.GA74450@zim.MIT.EDU>
	<20090111.142350.1560738814.imp@bsdimp.com>
	<496A65E1.5030309@freebsd.org>
Message-ID: <20090111.144524.235773790.imp@bsdimp.com>

In message: <496A65E1.5030309@freebsd.org>
            Sam Leffler <sam@FreeBSD.org> writes:
: M. Warner Losh wrote:
: > In message: <20090111191251.GA74450@zim.MIT.EDU>
: >             David Schultz <das@FreeBSD.ORG> writes:
: > : On Sun, Jan 11, 2009, Ed Schouten wrote:
: > : > I often just run `make' in /usr/obj/...,
: > : > which also saves some typing, but unfortunately that doesn't work when
: > : > cross compiling.
: > : 
: > : Also, as far as I know, there's no convenient way to rebuild a
: > : single module for another architecture. I use the following script
: > : called 'arch' to set the appropriate environment variables, so if
: > : I've already run 'make universe' and I want to rebuild libc for
: > : sparc64, I say:
: > : 
: > :    cd /usr/src/lib/libc && arch sparc64 make
: > : 
: > : It would be nice if there were a better mechanism for this that's
: > : integrated into the build system.
: >
: > I do one of the following:
: >
: > (1) env TARGET=arm make buildworld -DNO_CLEAN
: >
: > or
: >
: > (2) env TARGET=arm make buildenv
: > $ cd lib/libc && make
: >
: > These both work out well enough in practice for me.  I've wanted a
: > target that was 'reworld' that just did an 'all' and maybe a few other
: > things, but I've never had the time to polish this up (had it in a
: > couple of trees that I lost due to disk failure).
: >
: > I do agree it would be nice if there was some way to do 'all' for a
: > subdirectory with a 'trust me, I know what I'm doing, so don't do all
: > that other stuff' flag.
: >
: >   
: I told das privately but will note publicly that:
: 
: tools/tools/nanobsd/gateworks
: 
: uses make buildenv to cross-build various bits.  At some point I want to 
: promote some of the shell code to be part of nanobsd but until we've got 
: something to deal with ports I'm in no hurry.

I've done similar things...

Cross building ports is a very interesting problem...

Warner
From imp at bsdimp.com  Sun Jan 11 16:44:43 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Jan 11 16:44:51 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
	<20090111172427.GD89178@hoeg.nl>
	<20090111191251.GA74450@zim.MIT.EDU>
Message-ID: <20090111.174327.-942991712.imp@bsdimp.com>

In message: <20090111191251.GA74450@zim.MIT.EDU>
            David Schultz <das@FreeBSD.ORG> writes:
: On Sun, Jan 11, 2009, Ed Schouten wrote:
: > I often just run `make' in /usr/obj/...,
: > which also saves some typing, but unfortunately that doesn't work when
: > cross compiling.
: 
: Also, as far as I know, there's no convenient way to rebuild a
: single module for another architecture. I use the following script
: called 'arch' to set the appropriate environment variables, so if
: I've already run 'make universe' and I want to rebuild libc for
: sparc64, I say:
: 
:    cd /usr/src/lib/libc && arch sparc64 make
: 
: It would be nice if there were a better mechanism for this that's
: integrated into the build system.
: 
: #!/bin/sh
: 
: arch=$1
: basepath=/usr/src
: 
: export __MAKE_CONF=/dev/null
: export MAKEOBJDIRPREFIX=/usr/obj/${arch}
: export MACHINE_ARCH=${arch}
: export MACHINE=${arch}
: export CPUTYPE=
: export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin
: export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font
: export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac
: export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp
: export INSTALL="sh /usr/src/tools/install.sh"
: export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
: DESTDIR=/usr/obj/${arch}${basepath}/tmp
: 
: shift
: $*

Also, the following is similar to what I've used in the past.  I think
it is a lot simpler and should be functionally equivalent.  The key
part is to have make tell you what env vars you need to export...

#!/bin/sh
# fxmake arch subdir make-target
arch=$1
dir=$2
shift
shift
target=${*:-all}
makevars=`env TARGET=$arch MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX:-/usr/obj} make buildenvvars`
cd $2 && sh -c "${makevars}" make $target

Warner
From ru at freebsd.org  Sun Jan 11 21:44:35 2009
From: ru at freebsd.org (Ruslan Ermilov)
Date: Sun Jan 11 21:45:05 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
Message-ID: <20090112050205.GA59401@edoofus.dev.vega.ru>

On Sun, Jan 11, 2009 at 09:51:09AM -0700, M. Warner Losh wrote:
> This patch makes
> 
> make buildkernel -DKERNFAST
> 
> a short cut for
> 
> make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND
> 
> which is a lot shorter to type.
> 
> comments?
> 
Except the "please don't use any values in assignments", I can't
see a reason not to commit it if it's useful.

> Index: Makefile.inc1
> ===================================================================
> --- Makefile.inc1	(revision 186807)
> +++ Makefile.inc1	(working copy)
> @@ -5,6 +5,7 @@
>  #	-DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir
>  #	-DNO_CLEAN do not clean at all
>  #	-DNO_SHARE do not go into share subdir
> +#	-DKERNFAST define NO_KERNELCONFIG, NO_KERNELCLEAN and NO_KERNELCONFIG
>  #	-DNO_KERNELCONFIG do not run config in ${MAKE} buildkernel
>  #	-DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel
>  #	-DNO_KERNELDEPEND do not run ${MAKE} depend in ${MAKE} buildkernel
> @@ -697,6 +699,11 @@
>  # be set to cross-build, we have to make sure TARGET is set
>  # properly.
>  
> +.if defined(KERNFAST)
> +NO_KERNELCLEAN=	t
> +NO_KERNELCONFIG=	t
> +NO_KERNELDEPEND=	t
> +.endif
>  .if !defined(KERNCONF) && defined(KERNEL)
>  KERNCONF=	${KERNEL}
>  KERNWARN=
> 

-- 
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
From julian at elischer.org  Mon Jan 12 00:22:39 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jan 12 00:22:55 2009
Subject: Quick hack to make fast kernel builds easier [really cross-build
 support]
In-Reply-To: <496A65E1.5030309@freebsd.org>
References: <20090111.095109.-1112748421.imp@bsdimp.com>	<20090111172427.GD89178@hoeg.nl>	<20090111191251.GA74450@zim.MIT.EDU>	<20090111.142350.1560738814.imp@bsdimp.com>
	<496A65E1.5030309@freebsd.org>
Message-ID: <496AF718.70005@elischer.org>

Sam Leffler wrote:
> M. Warner Losh wrote:
>> In message: <20090111191251.GA74450@zim.MIT.EDU>
>>             David Schultz <das@FreeBSD.ORG> writes:
>> : On Sun, Jan 11, 2009, Ed Schouten wrote:
>> : > I often just run `make' in /usr/obj/...,
>> : > which also saves some typing, but unfortunately that doesn't work 
>> when
>> : > cross compiling.
>> : : Also, as far as I know, there's no convenient way to rebuild a
>> : single module for another architecture. I use the following script
>> : called 'arch' to set the appropriate environment variables, so if
>> : I've already run 'make universe' and I want to rebuild libc for
>> : sparc64, I say:
>> : :    cd /usr/src/lib/libc && arch sparc64 make
>> : : It would be nice if there were a better mechanism for this that's
>> : integrated into the build system.
>>
>> I do one of the following:
>>
>> (1) env TARGET=arm make buildworld -DNO_CLEAN
>>
>> or
>>
>> (2) env TARGET=arm make buildenv
>> $ cd lib/libc && make
>>
>> These both work out well enough in practice for me.  I've wanted a
>> target that was 'reworld' that just did an 'all' and maybe a few other
>> things, but I've never had the time to polish this up (had it in a
>> couple of trees that I lost due to disk failure).
>>
>> I do agree it would be nice if there was some way to do 'all' for a
>> subdirectory with a 'trust me, I know what I'm doing, so don't do all
>> that other stuff' flag.
>>
>>   
> I told das privately but will note publicly that:

When Cisco was thinking of using BSD for the Nova project I had
a cross build env set up for PPC. I had a  chroot where all teh 
standard tools were cross tools...  so 'cc' ran on a PC but gave PPC
binaries. in addition all the libraries to link with etc. were
all PPC libs. Seemed to work ok..
to rebuild tools WITHIN the chroo you did the build on the enclosing
environment with a DESTDIR=/ppc-chroot TARTGET=PPC (or whatever it 
was) and to generate arbitrary PPC binaries you just compiled them
normally within the chroot.



> 
> tools/tools/nanobsd/gateworks
> 
> uses make buildenv to cross-build various bits.  At some point I want to 
> promote some of the shell code to be part of nanobsd but until we've got 
> something to deal with ports I'm in no hurry.
> 
>    Sam
> 
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

From des at des.no  Mon Jan 12 02:19:36 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Jan 12 02:19:42 2009
Subject: RFC: adding > and >= to /usr/bin/make conditionals ?
In-Reply-To: <20090106121029.GA83861@onelab2.iet.unipi.it> (Luigi Rizzo's
	message of "Tue, 6 Jan 2009 13:10:29 +0100")
References: <200812262231.mBQMVjHC052150@svn.freebsd.org>
	<867i59lvbj.fsf@ds4.des.no>
	<20090105142929.GA70683@onelab2.iet.unipi.it>
	<E2F5A6372272F744859F67CB11ABC1110507C7@exbe05.intra.dlr.de>
	<20090106121029.GA83861@onelab2.iet.unipi.it>
Message-ID: <86iqoksu6i.fsf@ds4.des.no>

Luigi Rizzo <rizzo@iet.unipi.it> writes:
> So, I am polling to see if there is any consensus for or against
> adding this feature to /usr/bin/make

for

also in favor of making comparisons in general more forgiving (removing
constraints on the lhs etc.)

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From bugmaster at FreeBSD.org  Mon Jan 12 03:06:50 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jan 12 03:07:11 2009
Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org
Message-ID: <200901121106.n0CB6mNn091929@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/120749  arch       [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

From des at des.no  Mon Jan 12 07:25:12 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Jan 12 07:25:19 2009
Subject: RFC: MI strlen()
In-Reply-To: <4966B5D4.7040709@delphij.net> (Xin LI's message of "Thu, 08 Jan
	2009 18:26:28 -0800")
References: <4966B5D4.7040709@delphij.net>
Message-ID: <86zlhw5zsr.fsf@ds4.des.no>

Xin LI <delphij@delphij.net> writes:
> Here is a new implementation of strlen() which employed the bitmask
> skill in order to achieve better performance on modern hardware.

Why bother?  Do we have code that uses strlen() heavily in performance-
critical regions?  Does anybody?

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From scf at FreeBSD.org  Mon Jan 12 10:13:57 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Mon Jan 12 10:14:05 2009
Subject: Quick hack to make fast kernel builds easier
In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU>
References: <20090111.095109.-1112748421.imp@bsdimp.com>
	<20090111172427.GD89178@hoeg.nl>
	<20090111191251.GA74450@zim.MIT.EDU>
Message-ID: <alpine.BSF.2.00.0901121142430.95180@thor.farley.org>

On Sun, 11 Jan 2009, David Schultz wrote:

> On Sun, Jan 11, 2009, Ed Schouten wrote:
>> I often just run `make' in /usr/obj/...,
>> which also saves some typing, but unfortunately that doesn't work 
>> when cross compiling.
>
> Also, as far as I know, there's no convenient way to rebuild a single 
> module for another architecture. I use the following script called 
> 'arch' to set the appropriate environment variables, so if I've 
> already run 'make universe' and I want to rebuild libc for sparc64, I 
> say:
>
>   cd /usr/src/lib/libc && arch sparc64 make
>
> It would be nice if there were a better mechanism for this that's 
> integrated into the build system.

*snip shell script*

When I am building or installing a kernel and/or world, I use a shell 
script[1] I wrote awhile back.  It could be better ("automatic" option 
probably does not work and should be removed), but it makes building and 
installing easier for me.

I wonder how many build scripts have been written over the years.

Sean
   1. http://www.farley.org/freebsd/fbinst.sh
-- 
scf@FreeBSD.org
From delphij at delphij.net  Mon Jan 12 22:54:05 2009
From: delphij at delphij.net (Xin LI)
Date: Mon Jan 12 22:54:18 2009
Subject: RFC: MI strlen()
In-Reply-To: <86zlhw5zsr.fsf@ds4.des.no>
References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no>
Message-ID: <496C3A80.5040007@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dag-Erling Sm?rgrav wrote:
> Xin LI <delphij@delphij.net> writes:
>> Here is a new implementation of strlen() which employed the bitmask
>> skill in order to achieve better performance on modern hardware.
> 
> Why bother?  Do we have code that uses strlen() heavily in performance-
> critical regions?  Does anybody?

I agree that strlen() should never be used in performance-sensitive
regions, but given we do not have assembly optimized versions of these
functions for amd64 and almost everybody else has it, having a C version
that gives similar performance is valuable.  Also, worldstone with -j9
on 2x4core machine with both src/ and obj/ in tmpfs, seems to have
small, but positive effect:

Unpatched libc:
     1400.97 real      4159.34 user      2901.08 sys
     1396.73 real      4159.06 user      2906.16 sys
     1380.27 real      4158.20 user      2803.22 sys

Patched libc:
     1363.29 real      4154.89 user      2749.94 sys
     1373.96 real      4150.45 user      2830.46 sys
     1368.62 real      4152.48 user      2838.52 sys

(with 'make cleanworld' between builds)

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklsOoAACgkQi+vbBBjt66COQgCfTmpQK9YliCxpdJkckJ2/cZim
NzEAoKRqC2HN1FtKRWaZhstYyVjYeewr
=eeea
-----END PGP SIGNATURE-----
From avg at icyb.net.ua  Tue Jan 13 04:56:57 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Jan 13 04:57:04 2009
Subject: smb(4): address format
Message-ID: <496C8C6A.2030708@icyb.net.ua>


Maybe this is not sufficiently suitable for arch@, but I couldn't think
of a more relevant list.

smb(4) conveniently omits specifying what SMBus slave address is. Ditto
for iic(4).

As you know the address itself is 7 bit but how to align those bits
within a byte is somewhat ambiguous. Even the SMBus Specification
sometimes refers to a 7-bit value as to a slave address, but sometimes
uses phrases like "Slave Address Bits 7-1". The confusion seems to come
from how the address is actually transmitted on the wire where the least
significant bit of an address byte is used to indicate direction of an
operation (read or write).

So, in practice, there two conventions of specifying a slave address:
either as 0XXXXXXXb or XXXXXXX0b.

On FreeBSD we have a situation where smb/smbus doesn't insist on any
convention nor try to enforce it, and specific hardware drivers have
differing ideas.

E.g. please see PR 100513:
http://www.freebsd.org/cgi/query-pr.cgi?pr=100513

This inconsistency can not be a good thing.
Maybe we should pick one format, document it and enforce it?

>From FreeBSD-centric point of view XXXXXXX0b format seems to be
preferable - IMHO, of course. Majority hardware drivers already expect
this format, userland programs like mbmon and smbmsg(8) also seem to use it.

In wider world 0XXXXXXXb format seems to be preferred, Linux also sticks
to it.

Of course, choosing one format means changes for those using the other
one, but I think that having current inconsistency is worse.

P.S. I hope this won't trigger a bikeshed discussion.

-- 
Andriy Gapon
From rb at gid.co.uk  Tue Jan 13 06:08:52 2009
From: rb at gid.co.uk (Bob Bishop)
Date: Tue Jan 13 06:08:59 2009
Subject: smb(4): address format
In-Reply-To: <496C8C6A.2030708@icyb.net.ua>
References: <496C8C6A.2030708@icyb.net.ua>
Message-ID: <284781C0-CC39-42C8-8772-83911A26FA85@gid.co.uk>

Hi,

On 13 Jan 2009, at 12:43, Andriy Gapon wrote:

> Maybe this is not sufficiently suitable for arch@, but I couldn't  
> think
> of a more relevant list.
>
> smb(4) conveniently omits specifying what SMBus slave address is.  
> Ditto
> for iic(4).
>
> As you know the address itself is 7 bit but how to align those bits
> within a byte is somewhat ambiguous. Even the SMBus Specification
> sometimes refers to a 7-bit value as to a slave address, but sometimes
> uses phrases like "Slave Address Bits 7-1". The confusion seems to  
> come
> from how the address is actually transmitted on the wire where the  
> least
> significant bit of an address byte is used to indicate direction of an
> operation (read or write).

Version 2 of the standard is pretty clear that the MSb of the slave  
address is transmitted first and the LSb is the r/w indicator, but  
confusingly labels timing diagrams in bit transmission order so that  
slave address bit 7 is labelled 1 and the r/w bit is labelled 8.  
However it is clear from Fig 4-9 that the address bits precede the r/w  
bit on the wire.

> So, in practice, there two conventions of specifying a slave address:
> either as 0XXXXXXXb or XXXXXXX0b.

While a convention is just that, it would seem to be perverse to put  
what is clearly the LSb at the left of the byte and I'd vote for  
XXXXXXX0b.

> On FreeBSD we have a situation where smb/smbus doesn't insist on any
> convention nor try to enforce it, and specific hardware drivers have
> differing ideas.
>
> E.g. please see PR 100513:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=100513
>
> This inconsistency can not be a good thing.
> Maybe we should pick one format, document it and enforce it?
>
>> From FreeBSD-centric point of view XXXXXXX0b format seems to be
> preferable - IMHO, of course. Majority hardware drivers already expect
> this format, userland programs like mbmon and smbmsg(8) also seem to  
> use it.
>
> In wider world 0XXXXXXXb format seems to be preferred, Linux also  
> sticks
> to it.
>
> Of course, choosing one format means changes for those using the other
> one, but I think that having current inconsistency is worse.
>
> P.S. I hope this won't trigger a bikeshed discussion.

Can you get a bikeshed with an SMBus interface? :-)

> -- 
> Andriy Gapon

--
Bob Bishop
rb@gid.co.uk




From brde at optusnet.com.au  Tue Jan 13 06:12:13 2009
From: brde at optusnet.com.au (Bruce Evans)
Date: Tue Jan 13 06:12:20 2009
Subject: RFC: MI strlen()
In-Reply-To: <20090113232658.E31712@delplex.bde.org>
References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no>
	<496C3A80.5040007@delphij.net> <20090113232658.E31712@delplex.bde.org>
Message-ID: <20090114005432.Y31765@delplex.bde.org>

On Wed, 14 Jan 2009, I wrote:

> Also, it takes something like -fno-builtin-strlen in CFLAGS for the
> libc strlen() to ever be used.  On both amd64 and i386, gcc's builtin
> strlen() uses an inline "rep scasb", which can be inferior to even the

Actually, this is no longer true.  gcc-4.2 on at least amd64 has the
weird behaviour of disabling its "optimized" builtin strlen() with -O2
but not with -O1.  Even spelling strlen as __builtin_strlen doesn't
give the builtin.

>> Unpatched libc:
>>     1400.97 real      4159.34 user      2901.08 sys
>>     1396.73 real      4159.06 user      2906.16 sys
>>     1380.27 real      4158.20 user      2803.22 sys
>> 
>> Patched libc:
>>     1363.29 real      4154.89 user      2749.94 sys
>>     1373.96 real      4150.45 user      2830.46 sys
>>     1368.62 real      4152.48 user      2838.52 sys
>> 
>> (with 'make cleanworld' between builds)
>
> I don't believe this improvement.  First, it is far too large to have been
> caused by changing libc strlen().  Second, libc strlen() is not normally
> used.

Since -O2 is a standard "optimization" for makeworld, libc strlen() is now
normally used, at least on amd64 (i386 with certain -mcpu should be the
same, but I guess it isn't).

> My buildworld times on a 1x2core machine with nfs-mounted src/ and ffs
> obj/ src are much smaller:
>
>      824.96 real      1294.35 user       187.09 sys
>
> but this is for FreeBSD-~5.2.  FreeBSD and gcc have a combined bloat factor

Of course I don't use -O2.

> Here are some old files for too-simple strlen() benchmarks:
> ...
> I forget the results (don't have an amd64 machine handy for re-testing).

I reran the test.  I had to change -O2 to -O to test builtin strlen,
and made some other changes in a failed attempt to force __builtin_strlen
with -O2).  builtin strlen is much slower than I remembered.  The
NetBSD asm strlen (it uses the 0x8080 trick with 64-bit words) is
about 4.5 faster for long strings but slower for short strings (ones
shorter than the word size).  I expect your C version is similar.

%%%
string length 0:
algorithm -DSTRLEN=__builtin_strlen:
         0.35 real         0.35 user         0.00 sys
algorithm -fno-builtin:
         0.06 real         0.05 user         0.00 sys
algorithm -fno-builtin zq.S:
         0.09 real         0.09 user         0.00 sys
string length 1:
algorithm -DSTRLEN=__builtin_strlen:
         0.39 real         0.38 user         0.00 sys
algorithm -fno-builtin:
         0.07 real         0.06 user         0.00 sys
algorithm -fno-builtin zq.S:
         0.13 real         0.12 user         0.00 sys
string length 10:
algorithm -DSTRLEN=__builtin_strlen:
         0.68 real         0.66 user         0.01 sys
algorithm -fno-builtin:
         0.21 real         0.21 user         0.00 sys
algorithm -fno-builtin zq.S:
         0.12 real         0.10 user         0.00 sys
string length 100:
algorithm -DSTRLEN=__builtin_strlen:
         3.60 real         3.60 user         0.00 sys
algorithm -fno-builtin:
         1.02 real         1.01 user         0.00 sys
algorithm -fno-builtin zq.S:
         0.26 real         0.26 user         0.00 sys
string length 1000:
algorithm -DSTRLEN=__builtin_strlen:
        32.79 real        32.78 user         0.00 sys
algorithm -fno-builtin:
         7.25 real         7.25 user         0.00 sys
algorithm -fno-builtin zq.S:
         1.55 real         1.54 user         0.00 sys
%%%

%%%
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  z.c zi zq.S
# Wrapped by root@besplex.bde.org on Wed Jan 14 01:05:11 2009
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'z.c' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'z.c'\"
else
echo shar: Extracting \"'z.c'\" \(463 characters\)
sed "s/^X//" >'z.c' <<'END_OF_FILE'
X#include <stdio.h>
X#include <stdlib.h>
X#include <string.h>
X
X#ifndef LEN
X#define	LEN	5
X#endif
X
X#ifndef STRLEN
X#define	STRLEN	strlen
X#endif
X
Xstatic char *foo[1000];
Xstatic volatile size_t s;
X
X#ifdef MISTRLEN
X#include "/usr/src/lib/libc/string/strlen.c"
X#endif
X
Xint
Xmain(void)
X{
X	int i;
X
X	for (i = 0; i < 10; i++) {
X		foo[i] = malloc(LEN + 1);
X		sprintf(foo[i], "%*.*s", LEN, LEN, "foo");
X	}
X	for (i = 0; i < 10000000; i++)
X		s = STRLEN(foo[i % 10]);
X	return (0);
X}
END_OF_FILE
if test 463 -ne `wc -c <'z.c'`; then
     echo shar: \"'z.c'\" unpacked with wrong size!
fi
# end of 'z.c'
fi
if test -f 'zi' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'zi'\"
else
echo shar: Extracting \"'zi'\" \(224 characters\)
sed "s/^X//" >'zi' <<'END_OF_FILE'
Xfor len in 0 1 10 100 1000
Xdo
X	echo "string length $len:"
X	for alg in -DSTRLEN=__builtin_strlen -fno-builtin "-fno-builtin zq.S"
X	do
X		echo "algorithm $alg:"
X		cc -o z z.c -O $alg -g -static -DLEN=$len
X		time ./z
X	done
Xdone
END_OF_FILE
if test 224 -ne `wc -c <'zi'`; then
     echo shar: \"'zi'\" unpacked with wrong size!
fi
# end of 'zi'
fi
if test -f 'zq.S' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'zq.S'\"
else
echo shar: Extracting \"'zq.S'\" \(4304 characters\)
sed "s/^X//" >'zq.S' <<'END_OF_FILE'
X/*
X * Written by J.T. Conklin <jtc@acorntoolworks.com>
X * Public domain.
X */
X
X#include <machine/asm.h>
X__FBSDID("$FreeBSD$");
X
X#if 0
X	RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $")
X#endif
X
XENTRY(strlen)
X	movq	%rdi,%rax
X	negq	%rdi
X
X.Lalign:
X	/* Consider unrolling loop? */
X	testb	$7,%al
X	je	.Lword_aligned
X	cmpb	$0,(%rax)
X	jne	1f
X	leaq	(%rdi,%rax),%rax
X	ret
X1:	incq	%rax
X	jmp	.Lalign
X
X	/*
X	 * There are many well known branch-free sequences which are used
X	 * for determining whether a zero-byte is contained within a word.
X	 * These sequences are generally much more efficent than loading
X	 * and comparing each byte individually.
X	 *
X	 * The expression [1,2]:
X	 *
X	 * (1)  ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f))
X	 *
X	 * evaluates to a non-zero value if any of the bytes in the
X	 * original word is zero.
X	 *
X	 * It also has the useful property that bytes in the result word
X	 * that coorespond to non-zero bytes in the original word have
X	 * the value 0x00, while bytes cooresponding to zero bytes have
X	 * the value 0x80. This allows calculation of the first (and
X	 * last) occurance of a zero byte within the word (useful for C's
X	 * str* primitives) by counting the number of leading (or
X	 * trailing) zeros and dividing the result by 8.  On machines
X	 * without (or with slow) clz() / ctz() instructions, testing
X	 * each byte in the result word for zero is necessary.
X	 *
X	 * This typically takes 4 instructions (5 on machines without
X	 * "not-or") not including those needed to load the constant.
X	 *
X	 *
X	 * The expression:
X	 *
X	 * (2)  ((x - 0x01....01) & ~x & 0x80....80)
X	 *
X	 * evaluates to a non-zero value if any of the bytes in the
X	 * original word is zero.
X	 *
X	 * On little endian machines, the first byte in the result word
X	 * that cooresponds to a zero byte in the original byte is 0x80,
X	 * so clz() can be used as above.  On big endian machines, and
X	 * little endian machines without (or with a slow) clz() insn,
X	 * testing each byte in the original for zero is necessary
X	 *
X	 * This typically takes 3 instructions (4 on machines without
X	 * "and with complement") not including those needed to load
X	 * constants.
X	 *
X	 *
X	 * The expression:
X	 *
X	 * (3)  ((x - 0x01....01) & 0x80....80)
X	 *
X	 * always evaluates to a non-zero value if any of the bytes in
X	 * the original word is zero.  However, in rare cases, it also
X	 * evaluates to a non-zero value when none of the bytes in the
X	 * original word is zero.
X	 *
X	 * To account for possible false positives, each byte of the
X	 * original word must be checked when the expression evaluates to
X	 * a non-zero value.  However, because it is simpler than those
X	 * presented above, code that uses it will be faster as long as
X	 * the rate of false positives is low.
X	 *
X	 * This is likely, because the the false positive can only occur
X	 * if the most siginificant bit of a byte within the word is set.
X	 * The expression will never fail for typical 7-bit ASCII strings.
X	 *
X	 * This typically takes 2 instructions not including those needed
X	 * to load constants.
X	 *
X	 *
X	 * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003
X	 *
X	 * [2] International Business Machines, "The PowerPC Compiler Writer's
X	 *     Guide", Warthman Associates, 1996
X	 */
X
X	.align 4
X.Lword_aligned:
X	movabsq	$0x0101010101010101,%r8
X	movabsq	$0x8080808080808080,%r9
X.Lloop:
X	movq	(%rax),%rdx
X	addq	$8,%rax
X	subq	%r8,%rdx
X	testq	%r9,%rdx
X	je	.Lloop
X
X	/*
X	 * In rare cases, the above loop may exit prematurely. We must
X	 * return to the loop if none of the bytes in the word equal 0.
X	 */
X	cmpb	$0,-8(%rax)		/* 1st byte == 0? */
X	je	.Lsub8
X	cmpb	$0,-7(%rax)		/* 2nd byte == 0? */
X	je	.Lsub7
X	cmpb	$0,-6(%rax)		/* 3rd byte == 0? */
X	je	.Lsub6
X	cmpb	$0,-5(%rax)		/* 4th byte == 0? */
X	je	.Lsub5
X	cmpb	$0,-4(%rax)		/* 5th byte == 0? */
X	je	.Lsub4
X	cmpb	$0,-3(%rax)		/* 6th byte == 0? */
X	je	.Lsub3
X	cmpb	$0,-2(%rax)		/* 7th byte == 0? */
X	je	.Lsub2
X	cmpb	$0,-1(%rax)		/* 8th byte == 0? */
X	jne	.Lloop
X
X.Lsub1:
X	leaq	-1(%rdi,%rax),%rax
X	ret
X.Lsub2:
X	leaq	-2(%rdi,%rax),%rax
X	ret
X.Lsub3:
X	leaq	-3(%rdi,%rax),%rax
X	ret
X.Lsub4:
X	leaq	-4(%rdi,%rax),%rax
X	ret
X.Lsub5:
X	leaq	-5(%rdi,%rax),%rax
X	ret
X.Lsub6:
X	leaq	-6(%rdi,%rax),%rax
X	ret
X.Lsub7:
X	leaq	-7(%rdi,%rax),%rax
X	ret
X.Lsub8:
X	leaq	-8(%rdi,%rax),%rax
X	ret
END_OF_FILE
if test 4304 -ne `wc -c <'zq.S'`; then
     echo shar: \"'zq.S'\" unpacked with wrong size!
fi
# end of 'zq.S'
fi
echo shar: End of shell archive.
exit 0
%%%

Bruce
From brde at optusnet.com.au  Tue Jan 13 08:18:49 2009
From: brde at optusnet.com.au (Bruce Evans)
Date: Tue Jan 13 08:18:56 2009
Subject: RFC: MI strlen()
In-Reply-To: <496C3A80.5040007@delphij.net>
References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no>
	<496C3A80.5040007@delphij.net>
Message-ID: <20090113232658.E31712@delplex.bde.org>

On Mon, 12 Jan 2009, Xin LI wrote:

> Dag-Erling Smørgrav wrote:
>> Xin LI <delphij@delphij.net> writes:
>>> Here is a new implementation of strlen() which employed the bitmask
>>> skill in order to achieve better performance on modern hardware.
>>
>> Why bother?  Do we have code that uses strlen() heavily in performance-
>> critical regions?  Does anybody?

Of course not.

Also, it takes something like -fno-builtin-strlen in CFLAGS for the
libc strlen() to ever be used.  On both amd64 and i386, gcc's builtin
strlen() uses an inline "rep scasb", which can be inferior to even the
simple C loop in the simple libc version since i386ish string instructions
tend to be inferior (e.g., on AthlonXP, "rep scas*" takes 2.5 cycles
per iteration, plus 15 cycles to start, possibly plus extra startup/finishup
costs to use specific registers for it, while the simple C loop takes
1 cycle per iteration and can have startup costs much smaller than 15+
cycles (but the function call for the libc version costs about 15
cycles).  I think most strings are short, so sophisticated methods will
usually lose since they take longer to start up and have more branches.
However, the loss is usually unnoticable since it doesn't take long to
process a non-huge number of short strings.

The "optimized" asm i386 strlen() also uses "rep scasb", so it tends to be
inferior to the simple C version.  The "optimized" asm amd64 strlen()
intentionally doesn't exist, since the "rep scasb" version of it is
believed to be slower than the simple C version on all amd64 CPUs, and
more sophisticated versions would take more work to implement and might
end up being no better, and anyway the gcc builtin normally provides
the "rep scasb" "optimization, so even more work would be required to
actually usually use the sophisticated versions.

amd64 still has "optimized" asm versions of strcat(), strcmp() and
strcpy(), and actually-optimized asm version of the memcpy() family.
For memcpy(), the string instruction actually tends to be faster (1.33
cycles/iteration on AthlonXP, same on A64 IIRC, and faster on Phenom
IIRC), though it still wins mainly because it does 64 bits at a time
while the simple libc version only does 32 bits at a time (due to its
rotted code:

typedef int word;		/* "word" used for optimal copy speed */

-- 32-bit words are of course far from optimal on 64-bit machines).

Another issue for the memcpy() family is gcc doesn't have a builtin for
everything.  IIRC, it doesn't have one for memcpy() since handling
overlapping copies makes the inline version too large.

> I agree that strlen() should never be used in performance-sensitive
> regions, but given we do not have assembly optimized versions of these
> functions for amd64 and almost everybody else has it, having a C version
> that gives similar performance is valuable.  Also, worldstone with -j9
> on 2x4core machine with both src/ and obj/ in tmpfs, seems to have
> small, but positive effect:
>
> Unpatched libc:
>     1400.97 real      4159.34 user      2901.08 sys
>     1396.73 real      4159.06 user      2906.16 sys
>     1380.27 real      4158.20 user      2803.22 sys
>
> Patched libc:
>     1363.29 real      4154.89 user      2749.94 sys
>     1373.96 real      4150.45 user      2830.46 sys
>     1368.62 real      4152.48 user      2838.52 sys
>
> (with 'make cleanworld' between builds)

I don't believe this improvement.  First, it is far too large to have been
caused by changing libc strlen().  Second, libc strlen() is not normally
used.

My buildworld times on a 1x2core machine with nfs-mounted src/ and ffs
obj/ src are much smaller:

       824.96 real      1294.35 user       187.09 sys

but this is for FreeBSD-~5.2.  FreeBSD and gcc have a combined bloat factor
of almost 4 since then :-(, and more cores don't help much, apparently
due to them always running into locks (the bloat factor for system time is
almost 15, and that is with nfs bloating my sys time by about a factor of
2).

Here are some old files for too-simple strlen() benchmarks:

%%%
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  z z.c zi zq.S
# Wrapped by root@besplex.bde.org on Wed Jan 14 00:11:47 2009
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'z' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'z'\"
else
echo shar: Extracting \"'z'\" \(0 characters\)
sed "s/^X//" >'z' <<'END_OF_FILE'
END_OF_FILE
if test 0 -ne `wc -c <'z'`; then
     echo shar: \"'z'\" unpacked with wrong size!
fi
# end of 'z'
fi
if test -f 'z.c' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'z.c'\"
else
echo shar: Extracting \"'z.c'\" \(418 characters\)
sed "s/^X//" >'z.c' <<'END_OF_FILE'
X#include <stdio.h>
X#include <stdlib.h>
X#include <string.h>
X
X#ifndef LEN
X#define	LEN	5
X#endif
X
Xstatic char *foo[1000];
Xstatic volatile size_t s;
X
X#ifdef MISTRLEN
X#include "/usr/src/lib/libc/string/strlen.c"
X#endif
X
Xint
Xmain(void)
X{
X	int i;
X
X	for (i = 0; i < 10; i++) {
X		foo[i] = malloc(LEN + 1);
X		sprintf(foo[i], "%*.*s", LEN, LEN, "foo");
X	}
X	for (i = 0; i < 10000000; i++)
X		s = strlen(foo[i % 10]);
X	return (0);
X}
END_OF_FILE
if test 418 -ne `wc -c <'z.c'`; then
     echo shar: \"'z.c'\" unpacked with wrong size!
fi
# end of 'z.c'
fi
if test -f 'zi' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'zi'\"
else
echo shar: Extracting \"'zi'\" \(209 characters\)
sed "s/^X//" >'zi' <<'END_OF_FILE'
Xfor len in 0 1 10 100 1000
Xdo
X	echo "string length $len:"
X	for alg in -fbuiltin -fno-builtin "-fno-builtin zq.S"
X	do
X		echo "algorithm $alg:"
X		cc -o z z.c -O2 $alg -g -static -DLEN=$len
X		time ./z
X	done
Xdone
END_OF_FILE
if test 209 -ne `wc -c <'zi'`; then
     echo shar: \"'zi'\" unpacked with wrong size!
fi
# end of 'zi'
fi
if test -f 'zq.S' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'zq.S'\"
else
echo shar: Extracting \"'zq.S'\" \(4304 characters\)
sed "s/^X//" >'zq.S' <<'END_OF_FILE'
X/*
X * Written by J.T. Conklin <jtc@acorntoolworks.com>
X * Public domain.
X */
X
X#include <machine/asm.h>
X__FBSDID("$FreeBSD$");
X
X#if 0
X	RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $")
X#endif
X
XENTRY(strlen)
X	movq	%rdi,%rax
X	negq	%rdi
X
X.Lalign:
X	/* Consider unrolling loop? */
X	testb	$7,%al
X	je	.Lword_aligned
X	cmpb	$0,(%rax)
X	jne	1f
X	leaq	(%rdi,%rax),%rax
X	ret
X1:	incq	%rax
X	jmp	.Lalign
X
X	/*
X	 * There are many well known branch-free sequences which are used
X	 * for determining whether a zero-byte is contained within a word.
X	 * These sequences are generally much more efficent than loading
X	 * and comparing each byte individually.
X	 *
X	 * The expression [1,2]:
X	 *
X	 * (1)  ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f))
X	 *
X	 * evaluates to a non-zero value if any of the bytes in the
X	 * original word is zero.
X	 *
X	 * It also has the useful property that bytes in the result word
X	 * that coorespond to non-zero bytes in the original word have
X	 * the value 0x00, while bytes cooresponding to zero bytes have
X	 * the value 0x80. This allows calculation of the first (and
X	 * last) occurance of a zero byte within the word (useful for C's
X	 * str* primitives) by counting the number of leading (or
X	 * trailing) zeros and dividing the result by 8.  On machines
X	 * without (or with slow) clz() / ctz() instructions, testing
X	 * each byte in the result word for zero is necessary.
X	 *
X	 * This typically takes 4 instructions (5 on machines without
X	 * "not-or") not including those needed to load the constant.
X	 *
X	 *
X	 * The expression:
X	 *
X	 * (2)  ((x - 0x01....01) & ~x & 0x80....80)
X	 *
X	 * evaluates to a non-zero value if any of the bytes in the
X	 * original word is zero.
X	 *
X	 * On little endian machines, the first byte in the result word
X	 * that cooresponds to a zero byte in the original byte is 0x80,
X	 * so clz() can be used as above.  On big endian machines, and
X	 * little endian machines without (or with a slow) clz() insn,
X	 * testing each byte in the original for zero is necessary
X	 *
X	 * This typically takes 3 instructions (4 on machines without
X	 * "and with complement") not including those needed to load
X	 * constants.
X	 *
X	 *
X	 * The expression:
X	 *
X	 * (3)  ((x - 0x01....01) & 0x80....80)
X	 *
X	 * always evaluates to a non-zero value if any of the bytes in
X	 * the original word is zero.  However, in rare cases, it also
X	 * evaluates to a non-zero value when none of the bytes in the
X	 * original word is zero.
X	 *
X	 * To account for possible false positives, each byte of the
X	 * original word must be checked when the expression evaluates to
X	 * a non-zero value.  However, because it is simpler than those
X	 * presented above, code that uses it will be faster as long as
X	 * the rate of false positives is low.
X	 *
X	 * This is likely, because the the false positive can only occur
X	 * if the most siginificant bit of a byte within the word is set.
X	 * The expression will never fail for typical 7-bit ASCII strings.
X	 *
X	 * This typically takes 2 instructions not including those needed
X	 * to load constants.
X	 *
X	 *
X	 * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003
X	 *
X	 * [2] International Business Machines, "The PowerPC Compiler Writer's
X	 *     Guide", Warthman Associates, 1996
X	 */
X
X	.align 4
X.Lword_aligned:
X	movabsq	$0x0101010101010101,%r8
X	movabsq	$0x8080808080808080,%r9
X.Lloop:
X	movq	(%rax),%rdx
X	addq	$8,%rax
X	subq	%r8,%rdx
X	testq	%r9,%rdx
X	je	.Lloop
X
X	/*
X	 * In rare cases, the above loop may exit prematurely. We must
X	 * return to the loop if none of the bytes in the word equal 0.
X	 */
X	cmpb	$0,-8(%rax)		/* 1st byte == 0? */
X	je	.Lsub8
X	cmpb	$0,-7(%rax)		/* 2nd byte == 0? */
X	je	.Lsub7
X	cmpb	$0,-6(%rax)		/* 3rd byte == 0? */
X	je	.Lsub6
X	cmpb	$0,-5(%rax)		/* 4th byte == 0? */
X	je	.Lsub5
X	cmpb	$0,-4(%rax)		/* 5th byte == 0? */
X	je	.Lsub4
X	cmpb	$0,-3(%rax)		/* 6th byte == 0? */
X	je	.Lsub3
X	cmpb	$0,-2(%rax)		/* 7th byte == 0? */
X	je	.Lsub2
X	cmpb	$0,-1(%rax)		/* 8th byte == 0? */
X	jne	.Lloop
X
X.Lsub1:
X	leaq	-1(%rdi,%rax),%rax
X	ret
X.Lsub2:
X	leaq	-2(%rdi,%rax),%rax
X	ret
X.Lsub3:
X	leaq	-3(%rdi,%rax),%rax
X	ret
X.Lsub4:
X	leaq	-4(%rdi,%rax),%rax
X	ret
X.Lsub5:
X	leaq	-5(%rdi,%rax),%rax
X	ret
X.Lsub6:
X	leaq	-6(%rdi,%rax),%rax
X	ret
X.Lsub7:
X	leaq	-7(%rdi,%rax),%rax
X	ret
X.Lsub8:
X	leaq	-8(%rdi,%rax),%rax
X	ret
END_OF_FILE
if test 4304 -ne `wc -c <'zq.S'`; then
     echo shar: \"'zq.S'\" unpacked with wrong size!
fi
# end of 'zq.S'
fi
echo shar: End of shell archive.
exit 0
%%%

Here
- z.c is a simple C program that calls strlen()
- zi is a shell script that tries various algrithms (sorry, no makefile)
- zq.S is the NetBSD amd64 asm version which uses the 0x8080 trick
   and not "rep scasb"
The algorithms are:
- -fbuiltin: try to use builtin strlen()
- -fno-builtin: use default libc strlen(), except if MISTRLEN is defined,
   use MI libc strlen().  Variation to use MISTRLEN is not supported by zi.
- -fno-builtin zq.S: use NetBSD amd64 strlen()

I forget the results (don't have an amd64 machine handy for re-testing).

Bruce
From julian at elischer.org  Tue Jan 13 10:31:50 2009
From: julian at elischer.org (Julian Elischer)
Date: Tue Jan 13 10:31:56 2009
Subject: RFC: MI strlen()
In-Reply-To: <20090114005432.Y31765@delplex.bde.org>
References: <4966B5D4.7040709@delphij.net>
	<86zlhw5zsr.fsf@ds4.des.no>	<496C3A80.5040007@delphij.net>
	<20090113232658.E31712@delplex.bde.org>
	<20090114005432.Y31765@delplex.bde.org>
Message-ID: <496CD763.80107@elischer.org>


> 
> I reran the test.  I had to change -O2 to -O to test builtin strlen,
> and made some other changes in a failed attempt to force __builtin_strlen
> with -O2).  builtin strlen is much slower than I remembered.  The
> NetBSD asm strlen (it uses the 0x8080 trick with 64-bit words) is
> about 4.5 faster for long strings but slower for short strings (ones
> shorter than the word size).  I expect your C version is similar.

any chance you could try this and make a suggestion as to whether we 
might adopt the new code?

> 
From stb at lassitu.de  Tue Jan 13 23:43:09 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Tue Jan 13 23:43:18 2009
Subject: smb(4): address format
In-Reply-To: <496C8C6A.2030708@icyb.net.ua>
References: <496C8C6A.2030708@icyb.net.ua>
Message-ID: <FC7CC7A3-18D5-4408-8F52-62B9DF189A74@lassitu.de>

Am 13.01.2009 um 13:43 schrieb Andriy Gapon:

> So, in practice, there two conventions of specifying a slave address:
> either as 0XXXXXXXb or XXXXXXX0b.

Device datasheets generally specify the hard-wired or configurable  
address as a bit string, with a slight preference to format that as  
bbbb bbb.

> In wider world 0XXXXXXXb format seems to be preferred, Linux also  
> sticks
> to it.

I personally find having the address right-aligned a sensible choice.   
I think of the address as logical unit, and normally would rather have  
the SMBus bit banging abstracted away by the driver/hardware.


? 0.02,
Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From andrew.hotlab at hotmail.com  Wed Jan 14 07:18:07 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Wed Jan 14 07:18:19 2009
Subject: Cross compiling FreeBSD
Message-ID: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>


> From: andrew.hotlab@hotmail.com
> To: freebsd-questions@freebsd.org
> Subject: Builder for many architectures and releases
> Date: Sat, 10 Jan 2009 02:37:37 +0000
>
> [...] I looked for any documentation about setup a FreeBSD builder machine which will track sources and build binaries for all the hardware platform and OS releases I need to support in my network. I have found some interesting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-system.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html), but nothing which actually addresses my needs. [...]
>

At this time, I've tried to build RELENG_7_1 for the i386 architecture using an amd64 machine (running RELENG_7_0 for amd64) then, exporting /usr/src and /usr/obj via NFS in read-only mode to target machines, I've experienced a lot of troubles trying to install both kernel and world, which made impossible for me to install FreeBSD on target i386 machines.
Can anyone kindly confirm that it's a supported procedure to compile FreeBSD for a Tier1 architecture by using another Tier1-architecture machine? Maybe I didn't understood documentation or I'm missing some essential steps in the build process?

Andrew

P.S.: sorry for this cross-posting, but I don't have a clear understand about what list best suits my question!

_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/events.aspx
From peterjeremy at optushome.com.au  Wed Jan 14 16:36:58 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Wed Jan 14 16:37:05 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
Message-ID: <20090114211616.GC16116@server.vk2pj.dyndns.org>

[Please wrap your lines before 80 columns]

On 2009-Jan-14 15:06:06 +0000, Andrew Hotlab <andrew.hotlab@hotmail.com> wrote:
>At this time, I've tried to build RELENG_7_1 for the i386
>architecture using an amd64 machine (running RELENG_7_0 for amd64)
>then, exporting /usr/src and /usr/obj via NFS in read-only mode to
>target machines,

This won't work because install{world,kernel} uses programs (under
/usr/obj) that were built to run on the build system (amd64 in
your case) and so won't run on the target (i386) system.

The supported approach is to NFS mount the target machines onto the
build machine and run "make DESTDIR=/mount/point install{world,kernel}"
on the build machine.  Note that this will report errors since NFS
cannot handle UFS flags - you will need to manually remove/add schg flags.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090115/30d8b4d8/attachment.pgp
From andrew.hotlab at hotmail.com  Wed Jan 14 17:14:19 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Wed Jan 14 17:14:31 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<20090114211616.GC16116@server.vk2pj.dyndns.org> 
Message-ID: <COL112-W214770758973401CA2ADD8F6D70@phx.gbl>


>
> [Please wrap your lines before 80 columns]
>

I'm so sorry for that: I'm using the Windows Live webmail, and it seems
impossible to have a decent message format! :(

> On 2009-Jan-14 15:06:06 +0000, Andrew Hotlab wrote:
>>At this time, I've tried to build RELENG_7_1 for the i386
>>architecture using an amd64 machine (running RELENG_7_0 for amd64)
>>then, exporting /usr/src and /usr/obj via NFS in read-only mode to
>>target machines,
>
> This won't work because install{world,kernel} uses programs (under
> /usr/obj) that were built to run on the build system (amd64 in
> your case) and so won't run on the target (i386) system.
>

So I actually misunderstood the Handbook: only now I realize that it
gives the suggestion to export /usr/obj and /usr/src from the build machine,
but only if the target architecture is the same as the builder! :S

> The supported approach is to NFS mount the target machines onto the
> build machine and run "make DESTDIR=/mount/point install{world,kernel}"
> on the build machine. Note that this will report errors since NFS
> cannot handle UFS flags - you will need to manually remove/add schg flags.
>

Ok, so I think that in a production environment I should deploy one builder machine
for each target architecture I have to support on my network... I'm right?

One last question: I would expect the same issues if I wish to to support many
FreeBSD releases running of one single type of architecture? (i.e.: both builder
and targets are amd64 machines, but I run RELENG_7 on the builder and
RELENG_6_4 and RELENG_7_1 on the targets)

Thanks for your explanation.


_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
From brooks at freebsd.org  Wed Jan 14 21:07:37 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Wed Jan 14 21:08:00 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <20090115031847.GA52343@duncan.reilly.home>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<20090114211616.GC16116@server.vk2pj.dyndns.org>
	<20090115031847.GA52343@duncan.reilly.home>
Message-ID: <20090115044309.GA72611@lor.one-eyed-alien.net>

On Thu, Jan 15, 2009 at 02:18:47PM +1100, Andrew Reilly wrote:
> On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote:
> > This won't work because install{world,kernel} uses programs (under
> > /usr/obj) that were built to run on the build system (amd64 in
> > your case) and so won't run on the target (i386) system.
> > 
> > The supported approach is to NFS mount the target machines onto the
> > build machine and run "make DESTDIR=/mount/point install{world,kernel}"
> > on the build machine.  Note that this will report errors since NFS
> > cannot handle UFS flags - you will need to manually remove/add schg flags.
> 
> Is there any reason (apart from using more space on the build
> machine) not to install to a DESTDIR (not /) on the build
> machine, and then tar/pax/cpio that tree across to the client
> system?  Presumably something like that must be done for the
> distribution builds that go into making the CD and DVD images.

This should work just fine.  I use installs to DESTDIR to build images to be
run at NFS root file systems.

> NetBSD has (had? it's been a while since I looked) a cool
> mechanism that allowed the whole tree to be built (and
> "installed" to a DESTDIR) without root permissions, using a
> variation on install that copied the file as the running user
> and recorded the intended user/group/mod/flags in an mtree file.
> Then a subsequent task created a tarball that contained the file
> contents and the mtree permissions, all as a non-root user.  So
> you don't even need to muck about with root-over-nfs issues for
> deployment: just log into the client and untar the distribution
> over the network (as root).  Very, very neat, IMO.  I used to
> build embedded i386 NetBSD installations on my amd64 FreeBSD
> system that way without much in the way of trouble.  Haven't had
> to do it for a while, though, so perhaps it's all changed.  I
> wouldn't hate to discover that FreeBSD can do that too,
> though...

We don't have this yet, but lots of people would like to see this (just
not quite enough to do it yet :).

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090115/545ce7e6/attachment.pgp
From sam at freebsd.org  Wed Jan 14 21:45:05 2009
From: sam at freebsd.org (Sam Leffler)
Date: Wed Jan 14 21:45:12 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <20090115044309.GA72611@lor.one-eyed-alien.net>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>	<20090114211616.GC16116@server.vk2pj.dyndns.org>	<20090115031847.GA52343@duncan.reilly.home>
	<20090115044309.GA72611@lor.one-eyed-alien.net>
Message-ID: <496EC6D7.4090003@freebsd.org>

Brooks Davis wrote:
> On Thu, Jan 15, 2009 at 02:18:47PM +1100, Andrew Reilly wrote:
>> On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote:
>>> This won't work because install{world,kernel} uses programs (under
>>> /usr/obj) that were built to run on the build system (amd64 in
>>> your case) and so won't run on the target (i386) system.
>>>
>>> The supported approach is to NFS mount the target machines onto the
>>> build machine and run "make DESTDIR=/mount/point install{world,kernel}"
>>> on the build machine.  Note that this will report errors since NFS
>>> cannot handle UFS flags - you will need to manually remove/add schg flags.
>> Is there any reason (apart from using more space on the build
>> machine) not to install to a DESTDIR (not /) on the build
>> machine, and then tar/pax/cpio that tree across to the client
>> system?  Presumably something like that must be done for the
>> distribution builds that go into making the CD and DVD images.
> 
> This should work just fine.  I use installs to DESTDIR to build images to be
> run at NFS root file systems.

+1

> 
>> NetBSD has (had? it's been a while since I looked) a cool
>> mechanism that allowed the whole tree to be built (and
>> "installed" to a DESTDIR) without root permissions, using a
>> variation on install that copied the file as the running user
>> and recorded the intended user/group/mod/flags in an mtree file.
>> Then a subsequent task created a tarball that contained the file
>> contents and the mtree permissions, all as a non-root user.  So
>> you don't even need to muck about with root-over-nfs issues for
>> deployment: just log into the client and untar the distribution
>> over the network (as root).  Very, very neat, IMO.  I used to
>> build embedded i386 NetBSD installations on my amd64 FreeBSD
>> system that way without much in the way of trouble.  Haven't had
>> to do it for a while, though, so perhaps it's all changed.  I
>> wouldn't hate to discover that FreeBSD can do that too,
>> though...
> 
> We don't have this yet, but lots of people would like to see this (just
> not quite enough to do it yet :).

I've used netbsd and didn't find the unprivileged build process as
useful as I expected but I'm certainly a fan of eliminating root use.  I
recently added makefs to the base system which simplifies setting up a
cross-devel environment but we still lack bi-endian native filesystem
support.  Otherwise the key issues in improving cross-build support are:
ports and requiring freebsd as the build host.  With the advent of
virtual machines however the build host issue is less critical.

	Sam
From andrew-freebsd at areilly.bpc-users.org  Wed Jan 14 21:46:09 2009
From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly)
Date: Wed Jan 14 21:46:16 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<20090114211616.GC16116@server.vk2pj.dyndns.org>
Message-ID: <20090115031847.GA52343@duncan.reilly.home>

On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote:
> This won't work because install{world,kernel} uses programs (under
> /usr/obj) that were built to run on the build system (amd64 in
> your case) and so won't run on the target (i386) system.
> 
> The supported approach is to NFS mount the target machines onto the
> build machine and run "make DESTDIR=/mount/point install{world,kernel}"
> on the build machine.  Note that this will report errors since NFS
> cannot handle UFS flags - you will need to manually remove/add schg flags.

Is there any reason (apart from using more space on the build
machine) not to install to a DESTDIR (not /) on the build
machine, and then tar/pax/cpio that tree across to the client
system?  Presumably something like that must be done for the
distribution builds that go into making the CD and DVD images.

NetBSD has (had? it's been a while since I looked) a cool
mechanism that allowed the whole tree to be built (and
"installed" to a DESTDIR) without root permissions, using a
variation on install that copied the file as the running user
and recorded the intended user/group/mod/flags in an mtree file.
Then a subsequent task created a tarball that contained the file
contents and the mtree permissions, all as a non-root user.  So
you don't even need to muck about with root-over-nfs issues for
deployment: just log into the client and untar the distribution
over the network (as root).  Very, very neat, IMO.  I used to
build embedded i386 NetBSD installations on my amd64 FreeBSD
system that way without much in the way of trouble.  Haven't had
to do it for a while, though, so perhaps it's all changed.  I
wouldn't hate to discover that FreeBSD can do that too,
though...

Cheers,

Andrew
From mehulc87 at gmail.com  Thu Jan 15 06:48:25 2009
From: mehulc87 at gmail.com (Mehul Chadha)
Date: Thu Jan 15 06:48:31 2009
Subject: doubts regarding System Initialization working (SYSINIT)
Message-ID: <251d650c0901150618o7a460083i2caab3982dce133a@mail.gmail.com>

Hello all,
                I have been browsing through the FreeBSD kernel's source
code trying to understand its working .

In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects are
sorted using bubble sort and then they are executed in order.

My doubt is that we have declared the pointer to the struct sysinit as const
pointer to a const in the macro definition of SYSINIT ie  when the macro

SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL)  is expanded
completely we get the following

static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST,
(sysinit_cfunc_t)(sysinit_nfunc_t)kmeminit, ((void *)(((void *)0))) };
static void const * const __set_sysinit_set_sym_kmem_sys_init
__attribute__((__section__("set_" "sysinit_set"))) __attribute__((__used__))
= &kmem_sys_init;

Here we see that the pointer is of type const and to a const but when we
sort
and swap using
                              *sipp=*xipp;

We are trying to change the address of const pointer to a new address in
which case it should segfault but it works fine.

Why does it not segfault it seems I have not understood the concept behind
using const *const... I will be very thankful if you can help me with it.


Regards,
Mehul
From imp at bsdimp.com  Thu Jan 15 10:09:00 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu Jan 15 10:09:07 2009
Subject: smb(4): address format
In-Reply-To: <FC7CC7A3-18D5-4408-8F52-62B9DF189A74@lassitu.de>
References: <496C8C6A.2030708@icyb.net.ua>
	<FC7CC7A3-18D5-4408-8F52-62B9DF189A74@lassitu.de>
Message-ID: <20090115.110824.298933043.imp@bsdimp.com>

In message: <FC7CC7A3-18D5-4408-8F52-62B9DF189A74@lassitu.de>
            Stefan Bethke <stb@lassitu.de> writes:
: Am 13.01.2009 um 13:43 schrieb Andriy Gapon:
: 
: > So, in practice, there two conventions of specifying a slave address:
: > either as 0XXXXXXXb or XXXXXXX0b.
: 
: Device datasheets generally specify the hard-wired or configurable  
: address as a bit string, with a slight preference to format that as  
: bbbb bbb.
:
: > In wider world 0XXXXXXXb format seems to be preferred, Linux also  
: > sticks
: > to it.
: 
: I personally find having the address right-aligned a sensible choice.   
: I think of the address as logical unit, and normally would rather have  
: the SMBus bit banging abstracted away by the driver/hardware.

The format that is preferred on FreeBSD is xxxxxxxx0b.  That's the
format that the existing IIC bridge drivers use and deal with.  I've
not looked at the SMB drivers, but I went through all the iic bridge
drivers in the 6.x time frame and made sure they were all consistent.
If I missed the smb drivers, that's my bad.

I could find no evidence that there was a format that was more
preferred apart from the dozen data sheets that I'd read at the time
which used the xxxxxxx0b.

Warner
From securitasdirect at jarfoval.fr  Thu Jan 15 13:01:31 2009
From: securitasdirect at jarfoval.fr (Securitas Direct)
Date: Thu Jan 15 13:04:58 2009
Subject: =?iso-8859-1?q?La_s=E9curit=E9_avant_tout?=
Message-ID: <MTk3OC43MDIzMjA4LjEyODY4MDk=@Se5ee6>


     Si vous ne pouvez pas voir correctement ce message, [1]cliquez ici
                        [2][emailwebreflexe_01.gif] 
                        [3][emailwebreflexe_02.gif] 
                        [4][emailwebreflexe_03.gif] 
                        [5][emailwebreflexe_04.gif] 
                        [6][emailwebreflexe_05.gif] 
                        [7][emailwebreflexe_06.gif] 
                        [8][emailwebreflexe_07.gif] 

   Soci?t? titulaire de l'autorisation administrative pr?fectorale de la
    Pr?fecture d'ANTONY n?2004/057du 01/09/04 Securitas Direct : SAS au
    capital de 1 537 424 euros - RCS B 345 006 027 - n'0 TVA : FR 60 345
    006 027 - 1 Centrale Parc - Avenue Sully Prud'homme - 92290 Ch?tenay
   Malabry Autorisation Administrative du 16 novembre 1992 - Loi 83629 du
    12 Juillet 1983, Art. 8: ?L'autorisation administrative pr?alable ne
    conf?re aucun caract?re officiel ? l'entreprise ou aux personnes qui
   en b?n?ficient. Elle n'engage en aucune mani?re la responsabilit? des
   pouvoirs publics.? Photos et documents non contractuels SD DEP 11/07.
                           www.securitasdirect.fr

   Pour ne plus recevoir nos messages : [9]d?sinscription

References

   1. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   2. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   3. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   4. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   5. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   6. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   7. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   8. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0
   9. http://url.jarfoval.fr/id.asp?l=51482-7023208-1286809-1978-0&id=1286809-1978-7023208-1b7fd7e8&res=fr
From peterjeremy at optushome.com.au  Thu Jan 15 15:09:55 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Thu Jan 15 15:10:01 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <COL112-W214770758973401CA2ADD8F6D70@phx.gbl>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<20090114211616.GC16116@server.vk2pj.dyndns.org>
	<COL112-W214770758973401CA2ADD8F6D70@phx.gbl>
Message-ID: <20090115230949.GD16116@server.vk2pj.dyndns.org>

On 2009-Jan-15 01:12:03 +0000, Andrew Hotlab <andrew.hotlab@hotmail.com> wrote:
>Ok, so I think that in a production environment I should deploy one builder machine
>for each target architecture I have to support on my network... I'm right?

A single build machine can cross-build for multiple environments so you
really only need one machine.

>One last question: I would expect the same issues if I wish to to support many
>FreeBSD releases running of one single type of architecture? (i.e.: both builder
>and targets are amd64 machines, but I run RELENG_7 on the builder and
>RELENG_6_4 and RELENG_7_1 on the targets)

In general, backward compatibility is supported, so a world built on a
RELENG_7 box should be able to be installed by a RELENG_7_1 target
(though not by a RELENG_6_4 target).  And you can run into he same
problem with different i386 variants - if your build machine is built
with (eg) P4 options than a generic world built by that box cannot be
installed by (eg) a P2 due to instruction differences.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090115/24337888/attachment.pgp
From andrew.hotlab at hotmail.com  Thu Jan 15 17:15:04 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Thu Jan 15 17:15:22 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <20090115230949.GD16116@server.vk2pj.dyndns.org>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<20090114211616.GC16116@server.vk2pj.dyndns.org>
	<COL112-W214770758973401CA2ADD8F6D70@phx.gbl>
	<20090115230949.GD16116@server.vk2pj.dyndns.org> 
Message-ID: <COL112-W374DF46E866C4A02222938F6D40@phx.gbl>


> Date: Fri, 16 Jan 2009 10:09:49 +1100
> From: peterjeremy@optushome.com.au
>
> On 2009-Jan-15 01:12:03 +0000, Andrew Hotlab wrote:
>>Ok, so I think that in a production environment I should deploy one builder machine
>>for each target architecture I have to support on my network... I'm right?
>
> A single build machine can cross-build for multiple environments so you
> really only need one machine.
>
Yes it's true, but the limitation about UFS flags over NFS will force me to make some
manual operations and, even if I'll successfully script them, it will turn to increase the
"total cost" of that solution... so I'd prefer to have a build machine for each supported
Tier1 architecture, if this can let me "sleep better at night". I don't consider this a big
issue: after all, I feel the need of a builder machine because I have a lot of physical
machines to update... I can surely dedicate a couple of them (maybe a single amd64
in a dual-boot scenario with both i386 and amd64 FreeBSD versions)! :)

>>One last question: I would expect the same issues if I wish to to support many
>>FreeBSD releases running of one single type of architecture? (i.e.: both builder
>>and targets are amd64 machines, but I run RELENG_7 on the builder and
>>RELENG_6_4 and RELENG_7_1 on the targets)
>
> In general, backward compatibility is supported, so a world built on a
> RELENG_7 box should be able to be installed by a RELENG_7_1 target
> (though not by a RELENG_6_4 target). And you can run into he same
> problem with different i386 variants - if your build machine is built
> with (eg) P4 options than a generic world built by that box cannot be
> installed by (eg) a P2 due to instruction differences.
>
So I have to experiment a little to better understand what can be safely done
and what it would be "at risk". Maybe if worst comes to worst I'll have to maintain
a builder for each single architecture and major FreeBSD branch. It could be
not impossible if I'll decide to support legacy releases only on older i386 hardware.

Thank you so much for your help!

Andrew


_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
From ck-lists at cksoft.de  Fri Jan 16 01:50:17 2009
From: ck-lists at cksoft.de (Christian Kratzer)
Date: Fri Jan 16 01:50:30 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
Message-ID: <alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>

Hi,

On Wed, 14 Jan 2009, Andrew Hotlab wrote:

>
>> From: andrew.hotlab@hotmail.com
>> To: freebsd-questions@freebsd.org
>> Subject: Builder for many architectures and releases
>> Date: Sat, 10 Jan 2009 02:37:37 +0000
>>
>> [...] I looked for any documentation about setup a FreeBSD builder machine which will track sources and build binaries for all the hardware platform and OS releases I need to support in my network. I have found some interesting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-system.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html), but nothing which actually addresses my needs. [...]
>>
>
> At this time, I've tried to build RELENG_7_1 for the i386 architecture using an amd64 machine (running RELENG_7_0 for amd64) then, exporting /usr/src and /usr/obj via NFS in read-only mode to target machines, I've experienced a lot of troubles trying to install both kernel and world, which made impossible for me to install FreeBSD on target i386 machines.
> Can anyone kindly confirm that it's a supported procedure to compile FreeBSD for a Tier1 architecture by using another Tier1-architecture machine? Maybe I didn't understood documentation or I'm missing some essential steps in the build process?

as you already found out this does not work as the crossbuild process
will build the native host tools in /usr/obj and the target system
binaries in /usr/obj/i386.

On recent RELENG_7 or HEAD machines you should be able to build 
in an i386 chroot.  This would produce a clean /usr/obj you
can copy to your i386 machines and install from there.

The hack to enable building in an i386 chroot is to set UNAME_m
and UNAME_p to i386. I use following in the chroots .cshrc

 	setenv  UNAME_m i386
 	setenv  UNAME_p i386

This will avoid any crossbuild magic and you will be able to build
as if on an i386 machine.

This of course only works for the amd64, i386 combination.

Greetings
Christian

-- 
Christian Kratzer                      CK Software GmbH
Email:   ck@cksoft.de                  Schwarzwaldstr. 31
Phone:   +49 7452 889 135              D-71131 Jettingen
Fax:     +49 7452 889 136              HRB 245288, Amtsgericht Stuttgart
Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian Kratzer
From andrew.hotlab at hotmail.com  Fri Jan 16 02:24:47 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Fri Jan 16 02:25:06 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
Message-ID: <COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>


> Date: Fri, 16 Jan 2009 10:32:39 +0100
> From: ck-lists@cksoft.de
>
> On Wed, 14 Jan 2009, Andrew Hotlab wrote:
>
>> At this time, I've tried to build RELENG_7_1 for the i386 architecture using an amd64
>> machine (running RELENG_7_0 for amd64) then, exporting /usr/src and /usr/obj via
>> NFS in read-only mode to target machines, I've experienced a lot of troubles trying to
>> install both kernel and world, which made impossible for me to install FreeBSD on
>> target i386 machines.
>> Can anyone kindly confirm that it's a supported procedure to compile FreeBSD for
>> a Tier1 architecture by using another Tier1-architecture machine? Maybe I didn't
>> understood documentation or I'm missing some essential steps in the build process?
>
> as you already found out this does not work as the crossbuild process
> will build the native host tools in /usr/obj and the target system
> binaries in /usr/obj/i386.
>
> On recent RELENG_7 or HEAD machines you should be able to build
> in an i386 chroot. This would produce a clean /usr/obj you
> can copy to your i386 machines and install from there.
>
Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the
amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook)
# cd /usr/src
# make buildworld TARGET=i386
# make installworld TARGET=i386 DESTDIR=/path-to-jail
# cd etc/
# make distribution DESTDIR=/path-to-jail
# mount -t devfs devfs /path-to-jail/dev

> The hack to enable building in an i386 chroot is to set UNAME_m
> and UNAME_p to i386. I use following in the chroots .cshrc
>
> setenv UNAME_m i386
> setenv UNAME_p i386
>
> This will avoid any crossbuild magic and you will be able to build
> as if on an i386 machine.
>
> This of course only works for the amd64, i386 combination.
Wonderful, I'll try this as soon as possible. Thank you!


_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
From ck-lists at cksoft.de  Fri Jan 16 02:57:03 2009
From: ck-lists at cksoft.de (Christian Kratzer)
Date: Fri Jan 16 02:57:10 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
	<COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
Message-ID: <alpine.BSF.2.00.0901161154340.14974@tapio.cksoft.de>

Hi,

On Fri, 16 Jan 2009, Andrew Hotlab wrote:
</snipp>
> Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the
> amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook)
> # cd /usr/src
> # make buildworld TARGET=i386
> # make installworld TARGET=i386 DESTDIR=/path-to-jail
> # cd etc/
> # make distribution DESTDIR=/path-to-jail
> # mount -t devfs devfs /path-to-jail/dev

yes that should do it but I think you can skip the cd etc/ part.
make distribution should work from /usr/src

>> The hack to enable building in an i386 chroot is to set UNAME_m
>> and UNAME_p to i386. I use following in the chroots .cshrc
>>
>> setenv UNAME_m i386
>> setenv UNAME_p i386
>>
>> This will avoid any crossbuild magic and you will be able to build
>> as if on an i386 machine.
>>
>> This of course only works for the amd64, i386 combination.
> Wonderful, I'll try this as soon as possible. Thank you!

let us know if it works out.

Greetings
Christian

-- 
Christian Kratzer                      CK Software GmbH
Email:   ck@cksoft.de                  Schwarzwaldstr. 31
Phone:   +49 7452 889 135              D-71131 Jettingen
Fax:     +49 7452 889 136              HRB 245288, Amtsgericht Stuttgart
Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian Kratzer
From avg at icyb.net.ua  Fri Jan 16 05:17:35 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Jan 16 05:17:42 2009
Subject: smb(4): address format
In-Reply-To: <20090115.110824.298933043.imp@bsdimp.com>
References: <496C8C6A.2030708@icyb.net.ua>	<FC7CC7A3-18D5-4408-8F52-62B9DF189A74@lassitu.de>
	<20090115.110824.298933043.imp@bsdimp.com>
Message-ID: <497088E6.4020908@icyb.net.ua>

on 15/01/2009 20:08 M. Warner Losh said the following:
> The format that is preferred on FreeBSD is xxxxxxxx0b.  That's the
> format that the existing IIC bridge drivers use and deal with.  I've
> not looked at the SMB drivers, but I went through all the iic bridge
> drivers in the 6.x time frame and made sure they were all consistent.
> If I missed the smb drivers, that's my bad.
> 
> I could find no evidence that there was a format that was more
> preferred apart from the dozen data sheets that I'd read at the time
> which used the xxxxxxx0b.

What about the attached patch.
It brings ichsmb in line with this format and also adds a simple check
into smb(4).

-- 
Andriy Gapon
-------------- next part --------------
diff --git a/sys/dev/ichsmb/ichsmb.c b/sys/dev/ichsmb/ichsmb.c
index 9c60df7..75863e4 100644
--- a/sys/dev/ichsmb/ichsmb.c
+++ b/sys/dev/ichsmb/ichsmb.c
@@ -182,7 +182,7 @@ ichsmb_quick(device_t dev, u_char slave, int how)
 		mtx_lock(&sc->mutex);
 		sc->ich_cmd = ICH_HST_CNT_SMB_CMD_QUICK;
 		bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-		    (slave << 1) | (how == SMB_QREAD ?
+		    slave | (how == SMB_QREAD ?
 	    		ICH_XMIT_SLVA_READ : ICH_XMIT_SLVA_WRITE));
 		bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
 		    ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd);
@@ -208,7 +208,7 @@ ichsmb_sendb(device_t dev, u_char slave, char byte)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_WRITE);
+	    slave | ICH_XMIT_SLVA_WRITE);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, byte);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
 	    ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd);
@@ -230,7 +230,7 @@ ichsmb_recvb(device_t dev, u_char slave, char *byte)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_READ);
+	    slave | ICH_XMIT_SLVA_READ);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
 	    ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd);
 	if ((smb_error = ichsmb_wait(sc)) == SMB_ENOERR)
@@ -253,7 +253,7 @@ ichsmb_writeb(device_t dev, u_char slave, char cmd, char byte)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE_DATA;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_WRITE);
+	    slave | ICH_XMIT_SLVA_WRITE);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, byte);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
@@ -277,7 +277,7 @@ ichsmb_writew(device_t dev, u_char slave, char cmd, short word)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_WORD_DATA;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_WRITE);
+	    slave | ICH_XMIT_SLVA_WRITE);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, word & 0xff);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D1, word >> 8);
@@ -301,7 +301,7 @@ ichsmb_readb(device_t dev, u_char slave, char cmd, char *byte)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE_DATA;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_READ);
+	    slave | ICH_XMIT_SLVA_READ);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
 	    ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd);
@@ -324,7 +324,7 @@ ichsmb_readw(device_t dev, u_char slave, char cmd, short *word)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_WORD_DATA;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_READ);
+	    slave | ICH_XMIT_SLVA_READ);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
 	    ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd);
@@ -352,7 +352,7 @@ ichsmb_pcall(device_t dev, u_char slave, char cmd, short sdata, short *rdata)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_PROC_CALL;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_WRITE);
+	    slave | ICH_XMIT_SLVA_WRITE);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, sdata & 0xff);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D1, sdata >> 8);
@@ -403,7 +403,7 @@ ichsmb_bwrite(device_t dev, u_char slave, char cmd, u_char count, char *buf)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BLOCK;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_WRITE);
+	    slave | ICH_XMIT_SLVA_WRITE);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, count);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_BLOCK_DB, buf[0]);
@@ -434,7 +434,7 @@ ichsmb_bread(device_t dev, u_char slave, char cmd, u_char *count, char *buf)
 	mtx_lock(&sc->mutex);
 	sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BLOCK;
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA,
-	    (slave << 1) | ICH_XMIT_SLVA_READ);
+	    slave | ICH_XMIT_SLVA_READ);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd);
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, *count); /* XXX? */
 	bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT,
diff --git a/sys/dev/smbus/smb.c b/sys/dev/smbus/smb.c
index 6fce9b2..6e991ea 100644
--- a/sys/dev/smbus/smb.c
+++ b/sys/dev/smbus/smb.c
@@ -195,6 +195,10 @@ smbioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread *t
 
 	parent = device_get_parent(smbdev);
 
+	/* Make sure that LSB bit is cleared. */
+	if (s->slave & 0x1)
+		return (EINVAL);
+
 	/* Allocate the bus. */
 	if ((error = smbus_request_bus(parent, smbdev,
 			(flags & O_NONBLOCK) ? SMB_DONTWAIT : (SMB_WAIT | SMB_INTR))))
From andrew.hotlab at hotmail.com  Fri Jan 16 17:25:57 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Fri Jan 16 17:26:09 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <alpine.BSF.2.00.0901161154340.14974@tapio.cksoft.de>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
	<COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
	<alpine.BSF.2.00.0901161154340.14974@tapio.cksoft.de>
Message-ID: <COL112-W175CF96ECD901BFDE619C3F6D50@phx.gbl>


> Date: Fri, 16 Jan 2009 11:56:55 +0100
> From: ck-lists@cksoft.de
>
> On Fri, 16 Jan 2009, Andrew Hotlab wrote:
>
>> Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the
>> amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook)
>> # cd /usr/src
>> # make buildworld TARGET=i386
>> # make installworld TARGET=i386 DESTDIR=/path-to-jail
>> # cd etc/
>> # make distribution DESTDIR=/path-to-jail
>> # mount -t devfs devfs /path-to-jail/dev
>
> yes that should do it but I think you can skip the cd etc/ part.
> make distribution should work from /usr/src
>
>>> The hack to enable building in an i386 chroot is to set UNAME_m
>>> and UNAME_p to i386. I use following in the chroots .cshrc
>>> [...]
>>> This of course only works for the amd64, i386 combination.
>> Wonderful, I'll try this as soon as possible. Thank you!
>
> let us know if it works out.

I've build and exported RELENG_7_0 into an i386 jail running on amd64 hardware, then I
mounted sources and binaries on a RELENG_6_4/i386 machine and I have been able to
successfully upgrade without any trouble!! (only some warnings were displayed installing
the kernel, but that's a correct behaviour of the upgrade procedure, as pointed out in this
post: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057963.html)

Thank you so much, Christian!

I'm thinking that it would be a great thing to prepare some materials explaining the methods
for maintaining a managed FreeBSD infrastructure in a corporate production environment. A
lot of sysadmins are afraid that they'll have to spend so much time in software management
tasks if they put FreeBSD in production for business applications, but it seems that only a little
of knowledge is required to manage such and environment obtaining a good TCO.

At present time I'm too much engaged with a lot of projects to be able to produce any docs,
but I'll surely advocate FreeBSD in such business scenarios!


_________________________________________________________________
More than messages?check out the rest of the Windows Live?.
http://www.microsoft.com/windows/windowslive/
From andrew.hotlab at hotmail.com  Sat Jan 17 04:07:07 2009
From: andrew.hotlab at hotmail.com (Andrew Hotlab)
Date: Sat Jan 17 04:07:23 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <alpine.BSF.2.00.0901161154340.14974@tapio.cksoft.de>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>
	<alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
	<COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
	<alpine.BSF.2.00.0901161154340.14974@tapio.cksoft.de> 
Message-ID: <COL112-W793EB5F8F7B85E402C0789F6D50@phx.gbl>


> From: andrew.hotlab@hotmail.com
> Date: Sat, 17 Jan 2009 01:25:53 +0000
>
>>
>> On Fri, 16 Jan 2009, Andrew Hotlab wrote:
>>
>>> Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the
>>> amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook)
>>> # cd /usr/src
>>> # make buildworld TARGET=i386
>>> # make installworld TARGET=i386 DESTDIR=/path-to-jail
>>> # cd etc/
>>> # make distribution DESTDIR=/path-to-jail
>>> # mount -t devfs devfs /path-to-jail/dev
>>
>> yes that should do it but I think you can skip the cd etc/ part.
>> make distribution should work from /usr/src
>>
I missed to write that the sequence of commands that I had to issue in order to create the
i386 jail was a little different from what I wrote yesterday. I had to issue the following
command to successfully make distribution:
# make distribution TARGET=i386 DESTDIR=/path-to-jail

Greetings.

Andrew


_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
From pho at freebsd.org  Sun Jan 18 00:48:29 2009
From: pho at freebsd.org (Peter Holm)
Date: Sun Jan 18 00:49:06 2009
Subject: stress2 is now in projects
Message-ID: <20090118082145.GA18067@x2.osted.lan>

The Kernel Stress Test Suite (stress2) is now in svn:
svn://svn.freebsd.org/base/projects/stress2

The purpose of the test suite is to expose design and implementation
problems in the kernel, which may lead to panics or deadlocks.

The key functionality of this test suite is that it runs a random
number of test programs for a random period, in random incarnations
and in random sequence. This very simple idea is implemented in the
"run" test program, which controls the behavior of all the other
test programs.

To simplify writing test programs, a test harness is implemented
as a library that handles running the test programs.  All the creator
of new test programs has to implement are three procedures: setup(),
cleanup() and test().


Usage should be straight forward:

cd projects/stress2
make
sh ./run.sh

The "run.sh" script accepts an optional configuration file in order to test specific areas.
For example:

./run.sh vfs.sh


More details in projects/stress2/README.
Documentation may be found in projects/stress2/doc.

Please have me in mind when you find a problem that can panic the
kernel, as I collect regression test scenarios in projects/stress2/misc.

- Peter
From des at des.no  Sun Jan 18 04:11:28 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun Jan 18 04:11:36 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118082145.GA18067@x2.osted.lan> (Peter Holm's message of
	"Sun, 18 Jan 2009 09:21:45 +0100")
References: <20090118082145.GA18067@x2.osted.lan>
Message-ID: <86iqocstjm.fsf@ds4.des.no>

Peter Holm <pho@freebsd.org> writes:
> The key functionality of this test suite is that it runs a random
> number of test programs for a random period, in random incarnations
> and in random sequence.

In other words, it's non-deterministic and non-reproducable.

You should at the very least allow the user to specify the random seed.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From pho at freebsd.org  Sun Jan 18 05:10:30 2009
From: pho at freebsd.org (Peter Holm)
Date: Sun Jan 18 05:10:38 2009
Subject: stress2 is now in projects
In-Reply-To: <86iqocstjm.fsf@ds4.des.no>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
Message-ID: <20090118131028.GA26179@x2.osted.lan>

On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote:
> Peter Holm <pho@freebsd.org> writes:
> > The key functionality of this test suite is that it runs a random
> > number of test programs for a random period, in random incarnations
> > and in random sequence.
> 
> In other words, it's non-deterministic and non-reproducable.
> 

Yes, by design.

> You should at the very least allow the user to specify the random seed.
> 

Yes, it would be interesting to see if this is enough to reproduce a
problem in a deterministic way. I'll look into this.

> DES
> -- 
> Dag-Erling Sm?rgrav - des@des.no

-- 
Peter Holm
From kostikbel at gmail.com  Sun Jan 18 05:48:17 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Jan 18 05:48:25 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118131028.GA26179@x2.osted.lan>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<20090118131028.GA26179@x2.osted.lan>
Message-ID: <20090118132819.GS48057@deviant.kiev.zoral.com.ua>

On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote:
> On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote:
> > Peter Holm <pho@freebsd.org> writes:
> > > The key functionality of this test suite is that it runs a random
> > > number of test programs for a random period, in random incarnations
> > > and in random sequence.
> > 
> > In other words, it's non-deterministic and non-reproducable.
> > 
> 
> Yes, by design.
> 
> > You should at the very least allow the user to specify the random seed.
> > 
> 
> Yes, it would be interesting to see if this is enough to reproduce a
> problem in a deterministic way. I'll look into this.

I shall state from my experience using it (or, rather, inspecting bug
reports generated by stress2), that in fact it is quite repeatable.
I.e., when  looking into one area, you almost always get _that_ problem,
together with 2-3 related issues.

Due to the nature of the tests and kernel undeterministic operations,
I think that use of the same random seed gains nothing in regard with
repeatability of the tests.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090118/eccd54c0/attachment.pgp
From kris at FreeBSD.org  Sun Jan 18 05:52:30 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Sun Jan 18 05:52:36 2009
Subject: stress2 is now in projects
In-Reply-To: <86iqocstjm.fsf@ds4.des.no>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
Message-ID: <49733419.5000407@FreeBSD.org>

Dag-Erling Sm?rgrav wrote:
> Peter Holm <pho@freebsd.org> writes:
>> The key functionality of this test suite is that it runs a random
>> number of test programs for a random period, in random incarnations
>> and in random sequence.
> 
> In other words, it's non-deterministic and non-reproducable.
> 
> You should at the very least allow the user to specify the random seed.
> 
> DES

I doubt this will help at all since the test suite is (by design) 
massively parallel, so you're at the mercy of small timing changes.

Kris
From pho at freebsd.org  Sun Jan 18 06:09:27 2009
From: pho at freebsd.org (Peter Holm)
Date: Sun Jan 18 06:09:34 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118132819.GS48057@deviant.kiev.zoral.com.ua>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<20090118131028.GA26179@x2.osted.lan>
	<20090118132819.GS48057@deviant.kiev.zoral.com.ua>
Message-ID: <20090118140924.GA27264@x2.osted.lan>

On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote:
> On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote:
> > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote:
> > > Peter Holm <pho@freebsd.org> writes:
> > > > The key functionality of this test suite is that it runs a random
> > > > number of test programs for a random period, in random incarnations
> > > > and in random sequence.
> > > 
> > > In other words, it's non-deterministic and non-reproducable.
> > > 
> > 
> > Yes, by design.
> > 
> > > You should at the very least allow the user to specify the random seed.
> > > 
> > 
> > Yes, it would be interesting to see if this is enough to reproduce a
> > problem in a deterministic way. I'll look into this.
> 
> I shall state from my experience using it (or, rather, inspecting bug
> reports generated by stress2), that in fact it is quite repeatable.
> I.e., when  looking into one area, you almost always get _that_ problem,
> together with 2-3 related issues.
> 
> Due to the nature of the tests and kernel undeterministic operations,
> I think that use of the same random seed gains nothing in regard with
> repeatability of the tests.

It is an old issue that has come up many times: It would be so great 
if it was possible to some how record the exact sequence that lead up 
to a panic and play it back.

But on the other hand, as you say, it *is* repeatable. The only
issue is that it may take 5 minutes or 5 hours.

But I'm still game to see if it is possible at all (in single user 
mode with no network activity etc.)

- Peter
From bakul at bitblocks.com  Sun Jan 18 12:17:45 2009
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun Jan 18 12:17:51 2009
Subject: stress2 is now in projects 
In-Reply-To: Your message of "Sun, 18 Jan 2009 15:09:24 +0100."
	<20090118140924.GA27264@x2.osted.lan> 
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<20090118131028.GA26179@x2.osted.lan>
	<20090118132819.GS48057@deviant.kiev.zoral.com.ua>
	<20090118140924.GA27264@x2.osted.lan>
Message-ID: <20090118201202.674665B61@mail.bitblocks.com>

On Sun, 18 Jan 2009 15:09:24 +0100 Peter Holm <pho@freebsd.org>  wrote:
> On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote:
> > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote:
> > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote:
> > > > Peter Holm <pho@freebsd.org> writes:
> > > > > The key functionality of this test suite is that it runs a random
> > > > > number of test programs for a random period, in random incarnations
> > > > > and in random sequence.
> > > > 
> > > > In other words, it's non-deterministic and non-reproducable.
> > > > 
> > > 
> > > Yes, by design.
> > > 
> > > > You should at the very least allow the user to specify the random seed.
> > > > 
> > > 
> > > Yes, it would be interesting to see if this is enough to reproduce a
> > > problem in a deterministic way. I'll look into this.
> > 
> > I shall state from my experience using it (or, rather, inspecting bug
> > reports generated by stress2), that in fact it is quite repeatable.
> > I.e., when  looking into one area, you almost always get _that_ problem,
> > together with 2-3 related issues.
> > 
> > Due to the nature of the tests and kernel undeterministic operations,
> > I think that use of the same random seed gains nothing in regard with
> > repeatability of the tests.
> 
> It is an old issue that has come up many times: It would be so great 
> if it was possible to some how record the exact sequence that lead up 
> to a panic and play it back.
> 
> But on the other hand, as you say, it *is* repeatable. The only
> issue is that it may take 5 minutes or 5 hours.
> 
> But I'm still game to see if it is possible at all (in single user 
> mode with no network activity etc.)

Allowing a user to specify the random seed (and *always*
reporting the random seed of every test) can't hurt and it
may actually gain you repeatability in some cases.  Most bugs
are typically of garden variety, not dependent on some
complex interactions between parallel programs (or worse, on
processor heisenbugs). You can always try repeating a failing
test on a more deterministic set up like qemu etc.

One trick I have used in the past is to record "significant"
events in one or more ring buffers using some cheap encoding.
You have then access to past N events during any post kernel
crash analysis.  This has far less of an overhead than debug
printfs and you can even leave it enabled in production use.
From alfred at freebsd.org  Sun Jan 18 12:31:34 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Sun Jan 18 12:31:40 2009
Subject: stress2 is now in projects
In-Reply-To: <49733419.5000407@FreeBSD.org>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<49733419.5000407@FreeBSD.org>
Message-ID: <20090118203134.GF60686@elvis.mu.org>

* Kris Kennaway <kris@FreeBSD.org> [090118 05:52] wrote:
> Dag-Erling Sm??rgrav wrote:
> >Peter Holm <pho@freebsd.org> writes:
> >>The key functionality of this test suite is that it runs a random
> >>number of test programs for a random period, in random incarnations
> >>and in random sequence.
> >
> >In other words, it's non-deterministic and non-reproducable.
> >
> >You should at the very least allow the user to specify the random seed.
> >
> >DES
> 
> I doubt this will help at all since the test suite is (by design) 
> massively parallel, so you're at the mercy of small timing changes.

If the start and stop times of the scripts were recorded one could
synch with the original potentially between runs, at least on the
same hardware it ran.

Basically, replay the suite based on time instead of random.

-Alfred
From kris at FreeBSD.org  Sun Jan 18 14:05:36 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Sun Jan 18 14:05:42 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118203134.GF60686@elvis.mu.org>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<49733419.5000407@FreeBSD.org>
	<20090118203134.GF60686@elvis.mu.org>
Message-ID: <4973A7AD.8050106@FreeBSD.org>

Alfred Perlstein wrote:
> * Kris Kennaway <kris@FreeBSD.org> [090118 05:52] wrote:
>> Dag-Erling Sm??rgrav wrote:
>>> Peter Holm <pho@freebsd.org> writes:
>>>> The key functionality of this test suite is that it runs a random
>>>> number of test programs for a random period, in random incarnations
>>>> and in random sequence.
>>> In other words, it's non-deterministic and non-reproducable.
>>>
>>> You should at the very least allow the user to specify the random seed.
>>>
>>> DES
>> I doubt this will help at all since the test suite is (by design) 
>> massively parallel, so you're at the mercy of small timing changes.
> 
> If the start and stop times of the scripts were recorded one could
> synch with the original potentially between runs, at least on the
> same hardware it ran.
> 
> Basically, replay the suite based on time instead of random.
> 
> -Alfred
> 
> 

Since the goal of the stress test is effectively to exploit race 
conditions, I'm still skeptical there is a way to make that happen 
deterministically.  Anyway as Kostik says, problems discovered by 
stress2 do tend to be reproducible given suitable runtime.

Kris
From peter at holm.cc  Sun Jan 18 14:25:00 2009
From: peter at holm.cc (Peter Holm)
Date: Sun Jan 18 14:25:08 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<20090118131028.GA26179@x2.osted.lan>
	<20090118132819.GS48057@deviant.kiev.zoral.com.ua>
	<20090118140924.GA27264@x2.osted.lan>
	<20090118201202.674665B61@mail.bitblocks.com>
Message-ID: <20090118222456.GA42363@x2.osted.lan>

On Sun, Jan 18, 2009 at 12:12:02PM -0800, Bakul Shah wrote:
> On Sun, 18 Jan 2009 15:09:24 +0100 Peter Holm <pho@freebsd.org>  wrote:
> > On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote:
> > > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote:
> > > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote:
> > > > > Peter Holm <pho@freebsd.org> writes:
> > > > > > The key functionality of this test suite is that it runs a random
> > > > > > number of test programs for a random period, in random incarnations
> > > > > > and in random sequence.
> > > > > 
> > > > > In other words, it's non-deterministic and non-reproducable.
> > > > > 
> > > > 
> > > > Yes, by design.
> > > > 
> > > > > You should at the very least allow the user to specify the random seed.
> > > > > 
> > > > 
> > > > Yes, it would be interesting to see if this is enough to reproduce a
> > > > problem in a deterministic way. I'll look into this.
> > > 
> > > I shall state from my experience using it (or, rather, inspecting bug
> > > reports generated by stress2), that in fact it is quite repeatable.
> > > I.e., when  looking into one area, you almost always get _that_ problem,
> > > together with 2-3 related issues.
> > > 
> > > Due to the nature of the tests and kernel undeterministic operations,
> > > I think that use of the same random seed gains nothing in regard with
> > > repeatability of the tests.
> > 
> > It is an old issue that has come up many times: It would be so great 
> > if it was possible to some how record the exact sequence that lead up 
> > to a panic and play it back.
> > 
> > But on the other hand, as you say, it *is* repeatable. The only
> > issue is that it may take 5 minutes or 5 hours.
> > 
> > But I'm still game to see if it is possible at all (in single user 
> > mode with no network activity etc.)
> 
> Allowing a user to specify the random seed (and *always*
> reporting the random seed of every test) can't hurt and it
> may actually gain you repeatability in some cases.  Most bugs
> are typically of garden variety, not dependent on some

Ah, yes if that was the case. But most of the problems I encounter are
typically lock related.

> complex interactions between parallel programs (or worse, on
> processor heisenbugs). You can always try repeating a failing
> test on a more deterministic set up like qemu etc.
> 

Different hardware also seems to play a big role in finding bugs:
Number of CPUs etc.

> One trick I have used in the past is to record "significant"
> events in one or more ring buffers using some cheap encoding.
> You have then access to past N events during any post kernel
> crash analysis.  This has far less of an overhead than debug
> printfs and you can even leave it enabled in production use.

-- 
Peter Holm
From peter at holm.cc  Sun Jan 18 14:29:14 2009
From: peter at holm.cc (Peter Holm)
Date: Sun Jan 18 14:29:21 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118203134.GF60686@elvis.mu.org>
References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no>
	<49733419.5000407@FreeBSD.org>
	<20090118203134.GF60686@elvis.mu.org>
Message-ID: <20090118222908.GA42845@x2.osted.lan>

On Sun, Jan 18, 2009 at 12:31:34PM -0800, Alfred Perlstein wrote:
> * Kris Kennaway <kris@FreeBSD.org> [090118 05:52] wrote:
> > Dag-Erling Sm??rgrav wrote:
> > >Peter Holm <pho@freebsd.org> writes:
> > >>The key functionality of this test suite is that it runs a random
> > >>number of test programs for a random period, in random incarnations
> > >>and in random sequence.
> > >
> > >In other words, it's non-deterministic and non-reproducable.
> > >
> > >You should at the very least allow the user to specify the random seed.
> > >
> > >DES
> > 
> > I doubt this will help at all since the test suite is (by design) 
> > massively parallel, so you're at the mercy of small timing changes.
> 
> If the start and stop times of the scripts were recorded one could
> synch with the original potentially between runs, at least on the
> same hardware it ran.
> 
> Basically, replay the suite based on time instead of random.
> 

During the more than 10 years I have used this test suite with
FreeBSD I have always prioritized the ability to panic the kernel.
I have never looked much into a method of re-creating a test stream.

As I see it, it is a *slight* inconvenience that a panic or deadlock
is not 100% reproducible in time.  A fix for any problem still
needs a thorough test (measured in days), IMHO.

Several methods exists, as I see it, to create a test stream. One
could for example generate the random work list first and then
execute the tests after that.

After a panic you would the have the work list that created the
problem. But would re-running the work list reproduce the panic? I
seriously doubt that.

But there is only one way to find out. It should not be that
hard to create deterministic execution of the the tests.

- Peter

> -Alfred
From bugmaster at FreeBSD.org  Mon Jan 19 03:06:56 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jan 19 03:07:25 2009
Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org
Message-ID: <200901191106.n0JB6sNQ062904@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/120749  arch       [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

From das at FreeBSD.ORG  Mon Jan 19 12:36:10 2009
From: das at FreeBSD.ORG (David Schultz)
Date: Mon Jan 19 12:36:16 2009
Subject: RFC: MI strlen()
In-Reply-To: <4966B5D4.7040709@delphij.net>
References: <4966B5D4.7040709@delphij.net>
Message-ID: <20090119200402.GA26878@zim.MIT.EDU>

On Thu, Jan 08, 2009, Xin LI wrote:
> Here is a new implementation of strlen() which employed the bitmask
> skill in order to achieve better performance on modern hardware.  For
> common case, this would be a 5.2x boost on FreeBSD/amd64.  The code is
> intended for MI use when there is no hand-optimized assembly.

I ran some microbenchmarks on amd64, which show that the version
of strlen() in libc is up to twice as fast as yours for short
strings (< 4 bytes), but your implementation is nearly 5 times as
fast for longer strings.

As Bruce pointed out, gcc will almost use its builtin
strlen(). However, that may change in the future, and nobody has
suggested that your version would actually hurt anything, so I
think you should commit it.

Benchmark results:
	  http://www.freebsd.org/~das/strlen.gif

I ran this on a Wolfdale core using word-aligned ASCII strings and
an adaptive number of iterations. As you can see, the gcc builtin
is always slower than your code, but faster than our current libc
implementation. I can't explain why the builtin is faster for
strings of length 10 than it is for strings of length 1, but the
results are repeatable. Another interesting thing to note is that
your implementation is the only one that gets less throughput when
the string no longer fits in the L2 cache. This suggests that
either the other two are so slow that they can't use the full
memory bandwidth, or they are more effective at triggering the
CPU's prefetch heuristics.
From ghostviewer at web.de  Mon Jan 19 16:56:51 2009
From: ghostviewer at web.de (=?ISO-8859-15?Q?rainer_herrend=F6rfer?=)
Date: Mon Jan 19 16:56:58 2009
Subject: bge0: Firmware handshake timed out
Message-ID: <49751AC8.7080901@web.de>

Hi,

I just tried to install amd64 7.1 Release on a HP Compaq 6715b laptop. 
No NICs were found.

dmesg:
...
bge0: <Broadcom BCM5754/5787 A2 ASIC rev. 0xb002> mem 
0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16
bge0: Firmware handshake timed out, found 0x4b657654
bge0: Firmware handshake timed out, found 0x4b657654
bge0: RX CPU self-diagnostics failed!
bge0: chip initialization failed
device_attach: bge0 attach returned 6
...

I tried 7.0 amd64 with the same result.
Another odd thing:
Boot with acpi disabled ends with hang up. Last lines on the screen:

...
Timecounters tics every 1.000msec
md0: Preloaded image </boot/mfsroot> 4194304 bytes at 0xffffffff80c4be40
Trying to mount root from ufs:/dev/md0

On the other hand linux runs without any problems, no changes in BIOS or 
elsewhere. So Hardware should be o.k..

Any hints?

-- 

kind regards

rainer herrendoerfer

From kosuru.pavan at gmail.com  Tue Jan 20 23:27:31 2009
From: kosuru.pavan at gmail.com (pavan kosuru)
Date: Tue Jan 20 23:27:37 2009
Subject: Reg:SendMail Not working
Message-ID: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com>

Hi ,
 I am trying to send SMTP mail using the mail() function in php but unable
send to the destination I intended to. I wanted send mail using the php
script which is running fine in one server but not in my localmachine.In my
local machine it just returning the succes code and I m not receving any
mails. I configured the sendmail as well as postfix. Some one help me


  ------        Pavan ...
From remko at FreeBSD.org  Wed Jan 21 05:00:23 2009
From: remko at FreeBSD.org (Remko Lodder)
Date: Wed Jan 21 05:00:28 2009
Subject: Reg:SendMail Not working
In-Reply-To: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com>
References: <1ed07a9e0901202303o465cba12wfbcdb10b759cada7@mail.gmail.com>
Message-ID: <f03553e10669d03872480bc5cd4f25b7.squirrel@galain.elvandar.org>


Dear Pavan,

On Wed, January 21, 2009 8:03 am, pavan kosuru wrote:
> Hi ,
>  I am trying to send SMTP mail using the mail() function in php but unable
> send to the destination I intended to. I wanted send mail using the php
> script which is running fine in one server but not in my localmachine.In
> my
> local machine it just returning the succes code and I m not receving any
> mails. I configured the sendmail as well as postfix. Some one help me
>
>
>   ------        Pavan ...

Thank you for your interest in the FreeBSD Operating System. FreeBSD is an
open source BSD licensed operating system which can be extended by third
party tools. One of these tools is the PHP application set. We can try to
give you support for FreeBSD as much as possible within our volunteer time
and technical knowledge, that is the operating system. It is much harder
for us to support you with "PHP" kind of problems, since that is not
within our scope.

PHP Mail() functionality uses /usr/sbin/sendmail as far as i can remember,
which might require a running sendmail version. Can you please check with
``ps auxww | grep sendmail'' whether sendmail is being listed in the
process list?

One simple thing to know whether the sendmail application works or not, is
by seeing if you get daily periodic emails from the system maintenance
scripts. If that is being received, I suggest that you look at the mail()
documentation from PHP and potentially set the correct parameters. Also
note that php.ini has some mentionings of where and how mail should be
send.

Also note that the -arch list is not for questions like these, questions
like this, if applicable should be send to the questions@FreeBSD.org
mailinglist.

Again thanks for your interest in FreeBSD and the willingness to share
knowledge!

Best Regards,
Remko
>


-- 
/"\   Best regards,                      | remko@FreeBSD.org
\ /   Remko Lodder                       | remko@EFnet
 X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News


From jhb at freebsd.org  Wed Jan 21 06:19:03 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 06:19:20 2009
Subject: Enumerable I2C busses
In-Reply-To: <4963AFE3.5080607@freebsd.org>
References: <4929C6D8.7090305@freebsd.org>
	<20081124.105800.-267230932.imp@bsdimp.com>
	<4963AFE3.5080607@freebsd.org>
Message-ID: <200901210843.33247.jhb@freebsd.org>

On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
> M. Warner Losh wrote:
> > In message: <492AC8DE.6050902@freebsd.org>
> >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> > : M. Warner Losh wrote:
> > : > In message: <4929C6D8.7090305@freebsd.org>
> > : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> > : > : Rafa? Jaworowski wrote:
> > : > : > 
> > : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
> > : > : > 
> > : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> > : > : >>> The current I2C bus mechanism does not support the bus adding 
its own
> > : > : >>> children [...]
> > : > : >>
> > : > : >> That's because the I2C protocol does not support device 
enumeration or
> > : > : >> identification.  You have to know in advance what kind of devices 
are
> > : > : >> attached and at what address.  Even worse, it is not uncommon for
> > : > : >> similar but not entirely compatible devices to use the same I2C 
address
> > : > : >> (for instance, every I2C-capable RTC chip uses the same address, 
even
> > : > : >> though they have different feature sets)
> > : > : > 
> > : > : > Well, hard-coded addresses and conflicting assignments between 
vendors 
> > : > : > do not technically prevent from scanning the bus; actually, our 
current 
> > : > : > iicbus code can do bus scaning when compiled with a diag define. 
The 
> > : > : > problem however is some slave devices are not well-behaved, and 
they 
> > : > : > don't like to be read/written to other than in very specific 
scenario: 
> > : > : > if polled during bus scan strange effects occur e.g. they 
disappear from 
> > : > : > the bus, or do not react to consecutive requests etc.
> > : > : 
> > : > : All of this is true, but perhaps my question was badly worded. What 
I am 
> > : > : trying to figure out is how to shove information from an out-of-band 
> > : > : source (Open Firmware, in this case) into newbus without disrupting 
> > : > : existing code. In that way, my question is not I2C specific -- we 
run 
> > : > : into the same issue with the Open Firmware nexus node and 
pseudo-devices 
> > : > : like cryptosoft that attach themselves.
> > : > 
> > : > You are looking at the problem incorrectly.  In newbus, a case like
> > : > this the i2c bus should be a subclass (say i2c_of) that is derived
> > : > from the normal i2c bus stuff, but replaces the hints insertion of
> > : > devices with OF enumeration of devices.  The OF higher levels will
> > : > already know to attach this kind of i2c bus to certain i2c
> > : > controllers, or always on certain platforms.
> > : 
> > : Yes, this is exactly what I wanted to do, like how ofw_pci works.
> > : 
> > : > : What I want to do is to have the I2C bus add the children that the 
> > : > : firmware says it has. What the firmware cannot tell in advance, 
however, 
> > : > : is which FreeBSD driver is responsible for those devices, and so the 
I2C 
> > : > : bus driver can't know that without a translation table that I would 
> > : > : prefer not to hack in to the bus driver.
> > : > 
> > : > This is the bigger problem.  Today, we are stuck with a lame table
> > : > that will translate the OF provided properties into FreeBSD driver
> > : > names.
> > : 
> > : At the moment, I don't believe Apple uses any of the current very small 
> > : number of I2C device drivers in tree. So I may skip the table for the 
> > : time being, assuming the hack below is OK. In future, this may change, 
> > : since G5 systems require software thermal control. But that will be the 
> > : subject of another mail to this list...
> > : 
> > : > : It seems reasonable to allow devices to use a real probe routine to 
look 
> > : > : at the firmware's name and compatible properties, like we allow on 
other 
> > : > : Open Firmware busses. The trouble is that existing drivers don't do 
> > : > : this, because they expect to be attached with hints, so they will 
attach 
> > : > : to all devices. I'm trying to figure out how to avoid this.
> > : > : 
> > : > : My basic question comes down to whether there is a good way in 
newbus to 
> > : > : handle busses that may be wholly or partially enumerated by firmware 
or 
> > : > : some other method, and may also have devices that can only attach 
> > : > : themselves if told to by hints.
> > : > 
> > : > Yes.  This is a bit of a problem.  The problem is that the existing
> > : > hints mechanism combines device tree and driver tree into one, and in
> > : > such a scenario, we wind up with the problem that you have.
> > : > 
> > : > One could make the probe routines return BUS_PROBE_GENERIC, and that
> > : > would help somewhat.  One could also have the probe routine check to
> > : > see if a specific driver is assigned to the device or not.  That would
> > : > also help, but does mean changing all the i2c bus attached drivers in
> > : > the tree.
> > : 
> > : I think changing existing I2C drivers may be unavoidable. Would there be 
> > : any objection to changing the MI iicbus drivers to return 
> > : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been 
> > : introduced (by you) to solve more or less exactly this problem. By my 
> > : count, the relevant files are:
> > : dev/iicbus/ds133x.c
> > : dev/iicbus/icee.c
> > : dev/iicbus/ad7418.c
> > : dev/iicbus/iicsmb.c
> > : dev/iicbus/ds1672.c
> > : dev/iicbus/if_ic.c
> > : dev/iicbus/iic.c
> > : 
> > : I would also like to change iicbus_probe to return -1000 like 
> > : dev/pci/pci.c to allow it to be overridden by a subclass. Please let me 
> > : know if this is a terrible idea or if I have forgotten any I2C device 
> > : drivers.
> >
> > Short term, this is the right fix.  There was an objection, I think by
> > Marcel, to this approach.  However, his objections were part of a
> > larger set of objections and I think that we're working to solve
> > those.
> >
> > Warner
> >   
> This is now in the tree. Now for part 2, which I had not considered 
> previously: connecting the I2C bus layer to the I2C host adapters.
> 
> Right now, we have the following:
> kiic/other i2c adapters
> ---iicbus
> ---ofw_iicbus
> 
> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
> attaches, and everything after that is wonderful. The issue is how best 
> to attach the iicbus modules to kiic. Current I2C controllers contain a 
> line like this:
> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
> 
> This explicitly specifies that you want the standard driver, so we need 
> additional glue to allow the ofw_iicbus driver to attach. One solution 
> is that each relevant host adapter can add an additional DRIVER_MODULE 
> line with the ofw_iicbus driver and class, which would have to exported 
> in a header somewhere. This is pretty ugly. Another solution is for the 
> ofw_iicbus module to grow a list of the names of interesting adapters. 
> This is worse.
> 
> The third option is to do what we do for pci, where all PCI adapters are 
> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
> something, and then move the DRIVER_MODULE logic for new code into the 
> bus modules, as is done for PCI. This decreases the amount of 
> information in the device names, but seems a bit cleaner. Thoughts?
> -Nathan

If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
functionality) similar to the OF-aware PCI bus, then I would go the PCI route 
and just call it iicbus but give it a higher probe priority.

-- 
John Baldwin
From jhb at freebsd.org  Wed Jan 21 06:19:09 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 06:19:42 2009
Subject: Two drivers, one physical device: How to deal with that?
In-Reply-To: <20081229143221.X1076@desktop>
References: <20081229212020.GA1809@curry.mchp.siemens.de>
	<20081229143221.X1076@desktop>
Message-ID: <200901210847.05858.jhb@freebsd.org>

On Monday 29 December 2008 7:35:21 pm Jeff Roberson wrote:
> On Mon, 29 Dec 2008, Andre Albsmeier wrote:
> 
> > Hello,
> >
> > I have written a driver which attaches to the host bridge in
> > order to periodically read the appropriate registers and
> > inform the user about ECC errors (ECC-Monitor). No I have
> > run across a mainboard where the host bridge is already
> > taken by the agp driver. Of course, I can detach the agp
> > driver and attach myself and everything is working but
> > what is if someone does not want to loose the agp
> > functionality?
> >
> > How does one deal with the case when two separate drivers
> > have to access the same device (the host bridge in my case)?
> >
> > I assume, the correct way would be to join the AGP and
> > ECC functionality in one driver but maybe there are other
> > tricks I am not aware of?
> 
> Well I don't think it would be correct to merge two conceptually seperate 
> drivers into one just to share the same device.  It sounds like the right 
> solution is to make a generic layer the attaches to the host bridge and 
> arbitrates access to it.  Then allow other device to find and communicate 
> with this generic layer.  For the host bridge this doesn't have to be 
> particularly fancy.

This is already the case in 7.0 and later where hostb(4) always attaches to 
host bridges and agp(4) attaches to the hostb(4) devices.

-- 
John Baldwin
From jhb at freebsd.org  Wed Jan 21 06:19:18 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 06:19:45 2009
Subject: smb(4): address format
In-Reply-To: <497088E6.4020908@icyb.net.ua>
References: <496C8C6A.2030708@icyb.net.ua>
	<20090115.110824.298933043.imp@bsdimp.com>
	<497088E6.4020908@icyb.net.ua>
Message-ID: <200901210857.22204.jhb@freebsd.org>

On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote:
> on 15/01/2009 20:08 M. Warner Losh said the following:
> > The format that is preferred on FreeBSD is xxxxxxxx0b.  That's the
> > format that the existing IIC bridge drivers use and deal with.  I've
> > not looked at the SMB drivers, but I went through all the iic bridge
> > drivers in the 6.x time frame and made sure they were all consistent.
> > If I missed the smb drivers, that's my bad.
> > 
> > I could find no evidence that there was a format that was more
> > preferred apart from the dozen data sheets that I'd read at the time
> > which used the xxxxxxx0b.
> 
> What about the attached patch.
> It brings ichsmb in line with this format and also adds a simple check
> into smb(4).

Commit!

-- 
John Baldwin
From jhb at freebsd.org  Wed Jan 21 06:19:28 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 06:19:49 2009
Subject: stress2 is now in projects
In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com>
References: <20090118082145.GA18067@x2.osted.lan>
	<20090118140924.GA27264@x2.osted.lan>
	<20090118201202.674665B61@mail.bitblocks.com>
Message-ID: <200901210900.29226.jhb@freebsd.org>

On Sunday 18 January 2009 3:12:02 pm Bakul Shah wrote:
> Allowing a user to specify the random seed (and *always*
> reporting the random seed of every test) can't hurt and it
> may actually gain you repeatability in some cases.  Most bugs
> are typically of garden variety, not dependent on some
> complex interactions between parallel programs (or worse, on
> processor heisenbugs). You can always try repeating a failing
> test on a more deterministic set up like qemu etc.

Actually, all the bugs I've used stress2 for were race conditions and locking 
bugs for which having a set random seed would not have helped.

> One trick I have used in the past is to record "significant"
> events in one or more ring buffers using some cheap encoding.
> You have then access to past N events during any post kernel
> crash analysis.  This has far less of an overhead than debug
> printfs and you can even leave it enabled in production use.

man ktr

-- 
John Baldwin
From avg at icyb.net.ua  Wed Jan 21 06:21:02 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Jan 21 06:21:10 2009
Subject: smb(4): address format
In-Reply-To: <200901210857.22204.jhb@freebsd.org>
References: <496C8C6A.2030708@icyb.net.ua>
	<20090115.110824.298933043.imp@bsdimp.com>
	<497088E6.4020908@icyb.net.ua> <200901210857.22204.jhb@freebsd.org>
Message-ID: <49772F44.1030806@icyb.net.ua>

on 21/01/2009 15:57 John Baldwin said the following:
> On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote:
>> on 15/01/2009 20:08 M. Warner Losh said the following:
>>> The format that is preferred on FreeBSD is xxxxxxxx0b.  That's the
>>> format that the existing IIC bridge drivers use and deal with.  I've
>>> not looked at the SMB drivers, but I went through all the iic bridge
>>> drivers in the 6.x time frame and made sure they were all consistent.
>>> If I missed the smb drivers, that's my bad.
>>>
>>> I could find no evidence that there was a format that was more
>>> preferred apart from the dozen data sheets that I'd read at the time
>>> which used the xxxxxxx0b.
>> What about the attached patch.
>> It brings ichsmb in line with this format and also adds a simple check
>> into smb(4).
> 
> Commit!
> 

I guess this would also need a note in UPDATING and some HEADS UP in
current@.

-- 
Andriy Gapon
From jhb at freebsd.org  Wed Jan 21 06:36:49 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 06:36:57 2009
Subject: smb(4): address format
In-Reply-To: <49772F44.1030806@icyb.net.ua>
References: <496C8C6A.2030708@icyb.net.ua> <200901210857.22204.jhb@freebsd.org>
	<49772F44.1030806@icyb.net.ua>
Message-ID: <200901210936.28773.jhb@freebsd.org>

On Wednesday 21 January 2009 9:20:52 am Andriy Gapon wrote:
> on 21/01/2009 15:57 John Baldwin said the following:
> > On Friday 16 January 2009 8:17:26 am Andriy Gapon wrote:
> >> on 15/01/2009 20:08 M. Warner Losh said the following:
> >>> The format that is preferred on FreeBSD is xxxxxxxx0b.  That's the
> >>> format that the existing IIC bridge drivers use and deal with.  I've
> >>> not looked at the SMB drivers, but I went through all the iic bridge
> >>> drivers in the 6.x time frame and made sure they were all consistent.
> >>> If I missed the smb drivers, that's my bad.
> >>>
> >>> I could find no evidence that there was a format that was more
> >>> preferred apart from the dozen data sheets that I'd read at the time
> >>> which used the xxxxxxx0b.
> >> What about the attached patch.
> >> It brings ichsmb in line with this format and also adds a simple check
> >> into smb(4).
> > 
> > Commit!
> > 
> 
> I guess this would also need a note in UPDATING and some HEADS UP in
> current@.

Sure, though I had a hard time getting people to test the locking changes to 
the smbus(4) drivers, so I doubt many current@ users actually use smbus(4).

-- 
John Baldwin
From nwhitehorn at freebsd.org  Wed Jan 21 07:44:56 2009
From: nwhitehorn at freebsd.org (Nathan Whitehorn)
Date: Wed Jan 21 07:45:27 2009
Subject: Enumerable I2C busses
In-Reply-To: <200901210843.33247.jhb@freebsd.org>
References: <4929C6D8.7090305@freebsd.org>
	<20081124.105800.-267230932.imp@bsdimp.com>
	<4963AFE3.5080607@freebsd.org> <200901210843.33247.jhb@freebsd.org>
Message-ID: <49773596.2050700@freebsd.org>

John Baldwin wrote:
> On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
>> M. Warner Losh wrote:
>>> In message: <492AC8DE.6050902@freebsd.org>
>>>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
>>> : M. Warner Losh wrote:
>>> : > In message: <4929C6D8.7090305@freebsd.org>
>>> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
>>> : > : Rafa? Jaworowski wrote:
>>> : > : > 
>>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
>>> : > : > 
>>> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
>>> : > : >>> The current I2C bus mechanism does not support the bus adding 
> its own
>>> : > : >>> children [...]
>>> : > : >>
>>> : > : >> That's because the I2C protocol does not support device 
> enumeration or
>>> : > : >> identification.  You have to know in advance what kind of devices 
> are
>>> : > : >> attached and at what address.  Even worse, it is not uncommon for
>>> : > : >> similar but not entirely compatible devices to use the same I2C 
> address
>>> : > : >> (for instance, every I2C-capable RTC chip uses the same address, 
> even
>>> : > : >> though they have different feature sets)
>>> : > : > 
>>> : > : > Well, hard-coded addresses and conflicting assignments between 
> vendors 
>>> : > : > do not technically prevent from scanning the bus; actually, our 
> current 
>>> : > : > iicbus code can do bus scaning when compiled with a diag define. 
> The 
>>> : > : > problem however is some slave devices are not well-behaved, and 
> they 
>>> : > : > don't like to be read/written to other than in very specific 
> scenario: 
>>> : > : > if polled during bus scan strange effects occur e.g. they 
> disappear from 
>>> : > : > the bus, or do not react to consecutive requests etc.
>>> : > : 
>>> : > : All of this is true, but perhaps my question was badly worded. What 
> I am 
>>> : > : trying to figure out is how to shove information from an out-of-band 
>>> : > : source (Open Firmware, in this case) into newbus without disrupting 
>>> : > : existing code. In that way, my question is not I2C specific -- we 
> run 
>>> : > : into the same issue with the Open Firmware nexus node and 
> pseudo-devices 
>>> : > : like cryptosoft that attach themselves.
>>> : > 
>>> : > You are looking at the problem incorrectly.  In newbus, a case like
>>> : > this the i2c bus should be a subclass (say i2c_of) that is derived
>>> : > from the normal i2c bus stuff, but replaces the hints insertion of
>>> : > devices with OF enumeration of devices.  The OF higher levels will
>>> : > already know to attach this kind of i2c bus to certain i2c
>>> : > controllers, or always on certain platforms.
>>> : 
>>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
>>> : 
>>> : > : What I want to do is to have the I2C bus add the children that the 
>>> : > : firmware says it has. What the firmware cannot tell in advance, 
> however, 
>>> : > : is which FreeBSD driver is responsible for those devices, and so the 
> I2C 
>>> : > : bus driver can't know that without a translation table that I would 
>>> : > : prefer not to hack in to the bus driver.
>>> : > 
>>> : > This is the bigger problem.  Today, we are stuck with a lame table
>>> : > that will translate the OF provided properties into FreeBSD driver
>>> : > names.
>>> : 
>>> : At the moment, I don't believe Apple uses any of the current very small 
>>> : number of I2C device drivers in tree. So I may skip the table for the 
>>> : time being, assuming the hack below is OK. In future, this may change, 
>>> : since G5 systems require software thermal control. But that will be the 
>>> : subject of another mail to this list...
>>> : 
>>> : > : It seems reasonable to allow devices to use a real probe routine to 
> look 
>>> : > : at the firmware's name and compatible properties, like we allow on 
> other 
>>> : > : Open Firmware busses. The trouble is that existing drivers don't do 
>>> : > : this, because they expect to be attached with hints, so they will 
> attach 
>>> : > : to all devices. I'm trying to figure out how to avoid this.
>>> : > : 
>>> : > : My basic question comes down to whether there is a good way in 
> newbus to 
>>> : > : handle busses that may be wholly or partially enumerated by firmware 
> or 
>>> : > : some other method, and may also have devices that can only attach 
>>> : > : themselves if told to by hints.
>>> : > 
>>> : > Yes.  This is a bit of a problem.  The problem is that the existing
>>> : > hints mechanism combines device tree and driver tree into one, and in
>>> : > such a scenario, we wind up with the problem that you have.
>>> : > 
>>> : > One could make the probe routines return BUS_PROBE_GENERIC, and that
>>> : > would help somewhat.  One could also have the probe routine check to
>>> : > see if a specific driver is assigned to the device or not.  That would
>>> : > also help, but does mean changing all the i2c bus attached drivers in
>>> : > the tree.
>>> : 
>>> : I think changing existing I2C drivers may be unavoidable. Would there be 
>>> : any objection to changing the MI iicbus drivers to return 
>>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been 
>>> : introduced (by you) to solve more or less exactly this problem. By my 
>>> : count, the relevant files are:
>>> : dev/iicbus/ds133x.c
>>> : dev/iicbus/icee.c
>>> : dev/iicbus/ad7418.c
>>> : dev/iicbus/iicsmb.c
>>> : dev/iicbus/ds1672.c
>>> : dev/iicbus/if_ic.c
>>> : dev/iicbus/iic.c
>>> : 
>>> : I would also like to change iicbus_probe to return -1000 like 
>>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please let me 
>>> : know if this is a terrible idea or if I have forgotten any I2C device 
>>> : drivers.
>>>
>>> Short term, this is the right fix.  There was an objection, I think by
>>> Marcel, to this approach.  However, his objections were part of a
>>> larger set of objections and I think that we're working to solve
>>> those.
>>>
>>> Warner
>>>   
>> This is now in the tree. Now for part 2, which I had not considered 
>> previously: connecting the I2C bus layer to the I2C host adapters.
>>
>> Right now, we have the following:
>> kiic/other i2c adapters
>> ---iicbus
>> ---ofw_iicbus
>>
>> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
>> attaches, and everything after that is wonderful. The issue is how best 
>> to attach the iicbus modules to kiic. Current I2C controllers contain a 
>> line like this:
>> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
>>
>> This explicitly specifies that you want the standard driver, so we need 
>> additional glue to allow the ofw_iicbus driver to attach. One solution 
>> is that each relevant host adapter can add an additional DRIVER_MODULE 
>> line with the ofw_iicbus driver and class, which would have to exported 
>> in a header somewhere. This is pretty ugly. Another solution is for the 
>> ofw_iicbus module to grow a list of the names of interesting adapters. 
>> This is worse.
>>
>> The third option is to do what we do for pci, where all PCI adapters are 
>> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
>> something, and then move the DRIVER_MODULE logic for new code into the 
>> bus modules, as is done for PCI. This decreases the amount of 
>> information in the device names, but seems a bit cleaner. Thoughts?
>> -Nathan
> 
> If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
> functionality) similar to the OF-aware PCI bus, then I would go the PCI route 
> and just call it iicbus but give it a higher probe priority.
> 

Which it is. What I meant was the bridge devices to which iicbus 
attaches. For pci, they all end up with the same name (pcib) so that the 
pci layer knows to attach to them. For I2C, they are called 
iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the 
standard iicbus to itself, instead of letting it and any firmware-aware 
versions probe.
-Nathan
From Andre.Albsmeier at siemens.com  Wed Jan 21 09:08:42 2009
From: Andre.Albsmeier at siemens.com (Andre Albsmeier)
Date: Wed Jan 21 09:08:53 2009
Subject: Two drivers, one physical device: How to deal with that?
In-Reply-To: <200901210847.05858.jhb@freebsd.org>
References: <20081229212020.GA1809@curry.mchp.siemens.de>
	<20081229143221.X1076@desktop> <200901210847.05858.jhb@freebsd.org>
Message-ID: <20090121170838.GB94880@curry.mchp.siemens.de>

On Wed, 21-Jan-2009 at 08:47:05 -0500, John Baldwin wrote:
> On Monday 29 December 2008 7:35:21 pm Jeff Roberson wrote:
> > On Mon, 29 Dec 2008, Andre Albsmeier wrote:
> > 
> > > Hello,
> > >
> > > I have written a driver which attaches to the host bridge in
> > > order to periodically read the appropriate registers and
> > > inform the user about ECC errors (ECC-Monitor). No I have
> > > run across a mainboard where the host bridge is already
> > > taken by the agp driver. Of course, I can detach the agp
> > > driver and attach myself and everything is working but
> > > what is if someone does not want to loose the agp
> > > functionality?
> > >
> > > How does one deal with the case when two separate drivers
> > > have to access the same device (the host bridge in my case)?
> > >
> > > I assume, the correct way would be to join the AGP and
> > > ECC functionality in one driver but maybe there are other
> > > tricks I am not aware of?
> > 
> > Well I don't think it would be correct to merge two conceptually seperate 
> > drivers into one just to share the same device.  It sounds like the right 
> > solution is to make a generic layer the attaches to the host bridge and 
> > arbitrates access to it.  Then allow other device to find and communicate 
> > with this generic layer.  For the host bridge this doesn't have to be 
> > particularly fancy.
> 
> This is already the case in 7.0 and later where hostb(4) always attaches to 
> host bridges and agp(4) attaches to the hostb(4) devices.

Thanks for the hint. I will try this as soon as I got
my first 7.x system running.

	-Andre

-- 
Es ist den Untertanen untersagt, den Massstab ihrer beschraenkten
Einsicht an die Handlungen der Obrigkeit anzulegen.
(Friedrich Wilhelm, Kurfuerst von Brandenburg, 1620 - 1688)
From sjs at netapp.com  Wed Jan 21 10:47:01 2009
From: sjs at netapp.com (Steve Sears)
Date: Wed Jan 21 10:47:08 2009
Subject: mtx_trylock and td_locks
Message-ID: <C59CD068.30508%sjs@netapp.com>

I just discovered something that I would think would be documented
somewhere, but my best google'ing turns up nary a mention of it.

In debug builds thread->td_locks is incremented and decremented with
mtx_lock, mtx_trylock, and mtx_unlock.

However, if LOCK_DEBUG = 0 then mtx_lock() and mtx_unlock become inline
routines that don't modify thread->td_locks. mtx_trylock() doesn't have a
non-debug inline version, so it still increments the thread value.

This means mtx_trylock() should not be used with mtx_unlock(), but rather
should always be paired with mtx_unlock_flags() to ensure thread->td_locks
receives proper accounting.

Is this by design? Or a bug?

mtx_trylock is not heavily used, so it's easy to understand that it may not
have had as much attention as the other locking routines.

Thanks,


 -Steve

From jhb at freebsd.org  Wed Jan 21 12:09:32 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 12:09:43 2009
Subject: Enumerable I2C busses
In-Reply-To: <49773596.2050700@freebsd.org>
References: <4929C6D8.7090305@freebsd.org> <200901210843.33247.jhb@freebsd.org>
	<49773596.2050700@freebsd.org>
Message-ID: <200901211110.33961.jhb@freebsd.org>

On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote:
> John Baldwin wrote:
> > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
> >> M. Warner Losh wrote:
> >>> In message: <492AC8DE.6050902@freebsd.org>
> >>>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> >>> : M. Warner Losh wrote:
> >>> : > In message: <4929C6D8.7090305@freebsd.org>
> >>> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> >>> : > : Rafa? Jaworowski wrote:
> >>> : > : > 
> >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
> >>> : > : > 
> >>> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> >>> : > : >>> The current I2C bus mechanism does not support the bus adding 
> > its own
> >>> : > : >>> children [...]
> >>> : > : >>
> >>> : > : >> That's because the I2C protocol does not support device 
> > enumeration or
> >>> : > : >> identification.  You have to know in advance what kind of 
devices 
> > are
> >>> : > : >> attached and at what address.  Even worse, it is not uncommon 
for
> >>> : > : >> similar but not entirely compatible devices to use the same I2C 
> > address
> >>> : > : >> (for instance, every I2C-capable RTC chip uses the same 
address, 
> > even
> >>> : > : >> though they have different feature sets)
> >>> : > : > 
> >>> : > : > Well, hard-coded addresses and conflicting assignments between 
> > vendors 
> >>> : > : > do not technically prevent from scanning the bus; actually, our 
> > current 
> >>> : > : > iicbus code can do bus scaning when compiled with a diag define. 
> > The 
> >>> : > : > problem however is some slave devices are not well-behaved, and 
> > they 
> >>> : > : > don't like to be read/written to other than in very specific 
> > scenario: 
> >>> : > : > if polled during bus scan strange effects occur e.g. they 
> > disappear from 
> >>> : > : > the bus, or do not react to consecutive requests etc.
> >>> : > : 
> >>> : > : All of this is true, but perhaps my question was badly worded. 
What 
> > I am 
> >>> : > : trying to figure out is how to shove information from an 
out-of-band 
> >>> : > : source (Open Firmware, in this case) into newbus without 
disrupting 
> >>> : > : existing code. In that way, my question is not I2C specific -- we 
> > run 
> >>> : > : into the same issue with the Open Firmware nexus node and 
> > pseudo-devices 
> >>> : > : like cryptosoft that attach themselves.
> >>> : > 
> >>> : > You are looking at the problem incorrectly.  In newbus, a case like
> >>> : > this the i2c bus should be a subclass (say i2c_of) that is derived
> >>> : > from the normal i2c bus stuff, but replaces the hints insertion of
> >>> : > devices with OF enumeration of devices.  The OF higher levels will
> >>> : > already know to attach this kind of i2c bus to certain i2c
> >>> : > controllers, or always on certain platforms.
> >>> : 
> >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
> >>> : 
> >>> : > : What I want to do is to have the I2C bus add the children that the 
> >>> : > : firmware says it has. What the firmware cannot tell in advance, 
> > however, 
> >>> : > : is which FreeBSD driver is responsible for those devices, and so 
the 
> > I2C 
> >>> : > : bus driver can't know that without a translation table that I 
would 
> >>> : > : prefer not to hack in to the bus driver.
> >>> : > 
> >>> : > This is the bigger problem.  Today, we are stuck with a lame table
> >>> : > that will translate the OF provided properties into FreeBSD driver
> >>> : > names.
> >>> : 
> >>> : At the moment, I don't believe Apple uses any of the current very 
small 
> >>> : number of I2C device drivers in tree. So I may skip the table for the 
> >>> : time being, assuming the hack below is OK. In future, this may change, 
> >>> : since G5 systems require software thermal control. But that will be 
the 
> >>> : subject of another mail to this list...
> >>> : 
> >>> : > : It seems reasonable to allow devices to use a real probe routine 
to 
> > look 
> >>> : > : at the firmware's name and compatible properties, like we allow on 
> > other 
> >>> : > : Open Firmware busses. The trouble is that existing drivers don't 
do 
> >>> : > : this, because they expect to be attached with hints, so they will 
> > attach 
> >>> : > : to all devices. I'm trying to figure out how to avoid this.
> >>> : > : 
> >>> : > : My basic question comes down to whether there is a good way in 
> > newbus to 
> >>> : > : handle busses that may be wholly or partially enumerated by 
firmware 
> > or 
> >>> : > : some other method, and may also have devices that can only attach 
> >>> : > : themselves if told to by hints.
> >>> : > 
> >>> : > Yes.  This is a bit of a problem.  The problem is that the existing
> >>> : > hints mechanism combines device tree and driver tree into one, and 
in
> >>> : > such a scenario, we wind up with the problem that you have.
> >>> : > 
> >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and that
> >>> : > would help somewhat.  One could also have the probe routine check to
> >>> : > see if a specific driver is assigned to the device or not.  That 
would
> >>> : > also help, but does mean changing all the i2c bus attached drivers 
in
> >>> : > the tree.
> >>> : 
> >>> : I think changing existing I2C drivers may be unavoidable. Would there 
be 
> >>> : any objection to changing the MI iicbus drivers to return 
> >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been 
> >>> : introduced (by you) to solve more or less exactly this problem. By my 
> >>> : count, the relevant files are:
> >>> : dev/iicbus/ds133x.c
> >>> : dev/iicbus/icee.c
> >>> : dev/iicbus/ad7418.c
> >>> : dev/iicbus/iicsmb.c
> >>> : dev/iicbus/ds1672.c
> >>> : dev/iicbus/if_ic.c
> >>> : dev/iicbus/iic.c
> >>> : 
> >>> : I would also like to change iicbus_probe to return -1000 like 
> >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please let 
me 
> >>> : know if this is a terrible idea or if I have forgotten any I2C device 
> >>> : drivers.
> >>>
> >>> Short term, this is the right fix.  There was an objection, I think by
> >>> Marcel, to this approach.  However, his objections were part of a
> >>> larger set of objections and I think that we're working to solve
> >>> those.
> >>>
> >>> Warner
> >>>   
> >> This is now in the tree. Now for part 2, which I had not considered 
> >> previously: connecting the I2C bus layer to the I2C host adapters.
> >>
> >> Right now, we have the following:
> >> kiic/other i2c adapters
> >> ---iicbus
> >> ---ofw_iicbus
> >>
> >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
> >> attaches, and everything after that is wonderful. The issue is how best 
> >> to attach the iicbus modules to kiic. Current I2C controllers contain a 
> >> line like this:
> >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
> >>
> >> This explicitly specifies that you want the standard driver, so we need 
> >> additional glue to allow the ofw_iicbus driver to attach. One solution 
> >> is that each relevant host adapter can add an additional DRIVER_MODULE 
> >> line with the ofw_iicbus driver and class, which would have to exported 
> >> in a header somewhere. This is pretty ugly. Another solution is for the 
> >> ofw_iicbus module to grow a list of the names of interesting adapters. 
> >> This is worse.
> >>
> >> The third option is to do what we do for pci, where all PCI adapters are 
> >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
> >> something, and then move the DRIVER_MODULE logic for new code into the 
> >> bus modules, as is done for PCI. This decreases the amount of 
> >> information in the device names, but seems a bit cleaner. Thoughts?
> >> -Nathan
> > 
> > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
> > functionality) similar to the OF-aware PCI bus, then I would go the PCI 
route 
> > and just call it iicbus but give it a higher probe priority.
> > 
> 
> Which it is. What I meant was the bridge devices to which iicbus 
> attaches. For pci, they all end up with the same name (pcib) so that the 
> pci layer knows to attach to them. For I2C, they are called 
> iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the 
> standard iicbus to itself, instead of letting it and any firmware-aware 
> versions probe.

I'm a bit torn on that one, especially since you have weird cases like one of 
the via parts that has both smbus and iicbus children.

The other option would be to fix the attaching to subclasses thing (that 
should make all pci drivers attach to cardbus0 devices since cardbus inherits 
from pci, for example) and then you could have what would basically be an 
abstract base class "iicbridge" with no devmethods that all bridge drivers 
inherit from, and iicbus would attach to that.

-- 
John Baldwin
From imp at bsdimp.com  Wed Jan 21 12:30:05 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 21 12:30:12 2009
Subject: Enumerable I2C busses
In-Reply-To: <200901211110.33961.jhb@freebsd.org>
References: <200901210843.33247.jhb@freebsd.org> <49773596.2050700@freebsd.org>
	<200901211110.33961.jhb@freebsd.org>
Message-ID: <20090121.132805.1108816677.imp@bsdimp.com>

In message: <200901211110.33961.jhb@freebsd.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote:
: > John Baldwin wrote:
: > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
: > >> M. Warner Losh wrote:
: > >>> In message: <492AC8DE.6050902@freebsd.org>
: > >>>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > >>> : M. Warner Losh wrote:
: > >>> : > In message: <4929C6D8.7090305@freebsd.org>
: > >>> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > >>> : > : Rafa? Jaworowski wrote:
: > >>> : > : > 
: > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
: > >>> : > : > 
: > >>> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > >>> : > : >>> The current I2C bus mechanism does not support the bus adding 
: > > its own
: > >>> : > : >>> children [...]
: > >>> : > : >>
: > >>> : > : >> That's because the I2C protocol does not support device 
: > > enumeration or
: > >>> : > : >> identification.  You have to know in advance what kind of 
: devices 
: > > are
: > >>> : > : >> attached and at what address.  Even worse, it is not uncommon 
: for
: > >>> : > : >> similar but not entirely compatible devices to use the same I2C 
: > > address
: > >>> : > : >> (for instance, every I2C-capable RTC chip uses the same 
: address, 
: > > even
: > >>> : > : >> though they have different feature sets)
: > >>> : > : > 
: > >>> : > : > Well, hard-coded addresses and conflicting assignments between 
: > > vendors 
: > >>> : > : > do not technically prevent from scanning the bus; actually, our 
: > > current 
: > >>> : > : > iicbus code can do bus scaning when compiled with a diag define. 
: > > The 
: > >>> : > : > problem however is some slave devices are not well-behaved, and 
: > > they 
: > >>> : > : > don't like to be read/written to other than in very specific 
: > > scenario: 
: > >>> : > : > if polled during bus scan strange effects occur e.g. they 
: > > disappear from 
: > >>> : > : > the bus, or do not react to consecutive requests etc.
: > >>> : > : 
: > >>> : > : All of this is true, but perhaps my question was badly worded. 
: What 
: > > I am 
: > >>> : > : trying to figure out is how to shove information from an 
: out-of-band 
: > >>> : > : source (Open Firmware, in this case) into newbus without 
: disrupting 
: > >>> : > : existing code. In that way, my question is not I2C specific -- we 
: > > run 
: > >>> : > : into the same issue with the Open Firmware nexus node and 
: > > pseudo-devices 
: > >>> : > : like cryptosoft that attach themselves.
: > >>> : > 
: > >>> : > You are looking at the problem incorrectly.  In newbus, a case like
: > >>> : > this the i2c bus should be a subclass (say i2c_of) that is derived
: > >>> : > from the normal i2c bus stuff, but replaces the hints insertion of
: > >>> : > devices with OF enumeration of devices.  The OF higher levels will
: > >>> : > already know to attach this kind of i2c bus to certain i2c
: > >>> : > controllers, or always on certain platforms.
: > >>> : 
: > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
: > >>> : 
: > >>> : > : What I want to do is to have the I2C bus add the children that the 
: > >>> : > : firmware says it has. What the firmware cannot tell in advance, 
: > > however, 
: > >>> : > : is which FreeBSD driver is responsible for those devices, and so 
: the 
: > > I2C 
: > >>> : > : bus driver can't know that without a translation table that I 
: would 
: > >>> : > : prefer not to hack in to the bus driver.
: > >>> : > 
: > >>> : > This is the bigger problem.  Today, we are stuck with a lame table
: > >>> : > that will translate the OF provided properties into FreeBSD driver
: > >>> : > names.
: > >>> : 
: > >>> : At the moment, I don't believe Apple uses any of the current very 
: small 
: > >>> : number of I2C device drivers in tree. So I may skip the table for the 
: > >>> : time being, assuming the hack below is OK. In future, this may change, 
: > >>> : since G5 systems require software thermal control. But that will be 
: the 
: > >>> : subject of another mail to this list...
: > >>> : 
: > >>> : > : It seems reasonable to allow devices to use a real probe routine 
: to 
: > > look 
: > >>> : > : at the firmware's name and compatible properties, like we allow on 
: > > other 
: > >>> : > : Open Firmware busses. The trouble is that existing drivers don't 
: do 
: > >>> : > : this, because they expect to be attached with hints, so they will 
: > > attach 
: > >>> : > : to all devices. I'm trying to figure out how to avoid this.
: > >>> : > : 
: > >>> : > : My basic question comes down to whether there is a good way in 
: > > newbus to 
: > >>> : > : handle busses that may be wholly or partially enumerated by 
: firmware 
: > > or 
: > >>> : > : some other method, and may also have devices that can only attach 
: > >>> : > : themselves if told to by hints.
: > >>> : > 
: > >>> : > Yes.  This is a bit of a problem.  The problem is that the existing
: > >>> : > hints mechanism combines device tree and driver tree into one, and 
: in
: > >>> : > such a scenario, we wind up with the problem that you have.
: > >>> : > 
: > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and that
: > >>> : > would help somewhat.  One could also have the probe routine check to
: > >>> : > see if a specific driver is assigned to the device or not.  That 
: would
: > >>> : > also help, but does mean changing all the i2c bus attached drivers 
: in
: > >>> : > the tree.
: > >>> : 
: > >>> : I think changing existing I2C drivers may be unavoidable. Would there 
: be 
: > >>> : any objection to changing the MI iicbus drivers to return 
: > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been 
: > >>> : introduced (by you) to solve more or less exactly this problem. By my 
: > >>> : count, the relevant files are:
: > >>> : dev/iicbus/ds133x.c
: > >>> : dev/iicbus/icee.c
: > >>> : dev/iicbus/ad7418.c
: > >>> : dev/iicbus/iicsmb.c
: > >>> : dev/iicbus/ds1672.c
: > >>> : dev/iicbus/if_ic.c
: > >>> : dev/iicbus/iic.c
: > >>> : 
: > >>> : I would also like to change iicbus_probe to return -1000 like 
: > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please let 
: me 
: > >>> : know if this is a terrible idea or if I have forgotten any I2C device 
: > >>> : drivers.
: > >>>
: > >>> Short term, this is the right fix.  There was an objection, I think by
: > >>> Marcel, to this approach.  However, his objections were part of a
: > >>> larger set of objections and I think that we're working to solve
: > >>> those.
: > >>>
: > >>> Warner
: > >>>   
: > >> This is now in the tree. Now for part 2, which I had not considered 
: > >> previously: connecting the I2C bus layer to the I2C host adapters.
: > >>
: > >> Right now, we have the following:
: > >> kiic/other i2c adapters
: > >> ---iicbus
: > >> ---ofw_iicbus
: > >>
: > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
: > >> attaches, and everything after that is wonderful. The issue is how best 
: > >> to attach the iicbus modules to kiic. Current I2C controllers contain a 
: > >> line like this:
: > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
: > >>
: > >> This explicitly specifies that you want the standard driver, so we need 
: > >> additional glue to allow the ofw_iicbus driver to attach. One solution 
: > >> is that each relevant host adapter can add an additional DRIVER_MODULE 
: > >> line with the ofw_iicbus driver and class, which would have to exported 
: > >> in a header somewhere. This is pretty ugly. Another solution is for the 
: > >> ofw_iicbus module to grow a list of the names of interesting adapters. 
: > >> This is worse.
: > >>
: > >> The third option is to do what we do for pci, where all PCI adapters are 
: > >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
: > >> something, and then move the DRIVER_MODULE logic for new code into the 
: > >> bus modules, as is done for PCI. This decreases the amount of 
: > >> information in the device names, but seems a bit cleaner. Thoughts?
: > >> -Nathan
: > > 
: > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
: > > functionality) similar to the OF-aware PCI bus, then I would go the PCI 
: route 
: > > and just call it iicbus but give it a higher probe priority.
: > > 
: > 
: > Which it is. What I meant was the bridge devices to which iicbus 
: > attaches. For pci, they all end up with the same name (pcib) so that the 
: > pci layer knows to attach to them. For I2C, they are called 
: > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the 
: > standard iicbus to itself, instead of letting it and any firmware-aware 
: > versions probe.
: 
: I'm a bit torn on that one, especially since you have weird cases like one of 
: the via parts that has both smbus and iicbus children.
: 
: The other option would be to fix the attaching to subclasses thing (that 
: should make all pci drivers attach to cardbus0 devices since cardbus inherits 
: from pci, for example) and then you could have what would basically be an 
: abstract base class "iicbridge" with no devmethods that all bridge drivers 
: inherit from, and iicbus would attach to that.

Right now, the only bug that I know about with the cardbus vs pci
thing is that kldload doesn't necessarily probe/attach pci drivers on
a cardbus bus.  Otherwise, it works perfectly.  This is the only
reason that we have driver lines with cardbus attachments in the pci
drivers at all...

Warner
From jhb at freebsd.org  Wed Jan 21 15:11:18 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 21 15:11:25 2009
Subject: Enumerable I2C busses
In-Reply-To: <20090121.132805.1108816677.imp@bsdimp.com>
References: <200901210843.33247.jhb@freebsd.org>
	<200901211110.33961.jhb@freebsd.org>
	<20090121.132805.1108816677.imp@bsdimp.com>
Message-ID: <200901211542.08461.jhb@freebsd.org>

On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote:
> In message: <200901211110.33961.jhb@freebsd.org>
>             John Baldwin <jhb@FreeBSD.org> writes:
> : On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote:
> : > John Baldwin wrote:
> : > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
> : > >> M. Warner Losh wrote:
> : > >>> In message: <492AC8DE.6050902@freebsd.org>
> : > >>>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : > >>> : M. Warner Losh wrote:
> : > >>> : > In message: <4929C6D8.7090305@freebsd.org>
> : > >>> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : > >>> : > : Rafa? Jaworowski wrote:
> : > >>> : > : > 
> : > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
> : > >>> : > : > 
> : > >>> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
> : > >>> : > : >>> The current I2C bus mechanism does not support the bus 
adding 
> : > > its own
> : > >>> : > : >>> children [...]
> : > >>> : > : >>
> : > >>> : > : >> That's because the I2C protocol does not support device 
> : > > enumeration or
> : > >>> : > : >> identification.  You have to know in advance what kind of 
> : devices 
> : > > are
> : > >>> : > : >> attached and at what address.  Even worse, it is not 
uncommon 
> : for
> : > >>> : > : >> similar but not entirely compatible devices to use the same 
I2C 
> : > > address
> : > >>> : > : >> (for instance, every I2C-capable RTC chip uses the same 
> : address, 
> : > > even
> : > >>> : > : >> though they have different feature sets)
> : > >>> : > : > 
> : > >>> : > : > Well, hard-coded addresses and conflicting assignments 
between 
> : > > vendors 
> : > >>> : > : > do not technically prevent from scanning the bus; actually, 
our 
> : > > current 
> : > >>> : > : > iicbus code can do bus scaning when compiled with a diag 
define. 
> : > > The 
> : > >>> : > : > problem however is some slave devices are not well-behaved, 
and 
> : > > they 
> : > >>> : > : > don't like to be read/written to other than in very specific 
> : > > scenario: 
> : > >>> : > : > if polled during bus scan strange effects occur e.g. they 
> : > > disappear from 
> : > >>> : > : > the bus, or do not react to consecutive requests etc.
> : > >>> : > : 
> : > >>> : > : All of this is true, but perhaps my question was badly worded. 
> : What 
> : > > I am 
> : > >>> : > : trying to figure out is how to shove information from an 
> : out-of-band 
> : > >>> : > : source (Open Firmware, in this case) into newbus without 
> : disrupting 
> : > >>> : > : existing code. In that way, my question is not I2C specific -- 
we 
> : > > run 
> : > >>> : > : into the same issue with the Open Firmware nexus node and 
> : > > pseudo-devices 
> : > >>> : > : like cryptosoft that attach themselves.
> : > >>> : > 
> : > >>> : > You are looking at the problem incorrectly.  In newbus, a case 
like
> : > >>> : > this the i2c bus should be a subclass (say i2c_of) that is 
derived
> : > >>> : > from the normal i2c bus stuff, but replaces the hints insertion 
of
> : > >>> : > devices with OF enumeration of devices.  The OF higher levels 
will
> : > >>> : > already know to attach this kind of i2c bus to certain i2c
> : > >>> : > controllers, or always on certain platforms.
> : > >>> : 
> : > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
> : > >>> : 
> : > >>> : > : What I want to do is to have the I2C bus add the children that 
the 
> : > >>> : > : firmware says it has. What the firmware cannot tell in 
advance, 
> : > > however, 
> : > >>> : > : is which FreeBSD driver is responsible for those devices, and 
so 
> : the 
> : > > I2C 
> : > >>> : > : bus driver can't know that without a translation table that I 
> : would 
> : > >>> : > : prefer not to hack in to the bus driver.
> : > >>> : > 
> : > >>> : > This is the bigger problem.  Today, we are stuck with a lame 
table
> : > >>> : > that will translate the OF provided properties into FreeBSD 
driver
> : > >>> : > names.
> : > >>> : 
> : > >>> : At the moment, I don't believe Apple uses any of the current very 
> : small 
> : > >>> : number of I2C device drivers in tree. So I may skip the table for 
the 
> : > >>> : time being, assuming the hack below is OK. In future, this may 
change, 
> : > >>> : since G5 systems require software thermal control. But that will 
be 
> : the 
> : > >>> : subject of another mail to this list...
> : > >>> : 
> : > >>> : > : It seems reasonable to allow devices to use a real probe 
routine 
> : to 
> : > > look 
> : > >>> : > : at the firmware's name and compatible properties, like we 
allow on 
> : > > other 
> : > >>> : > : Open Firmware busses. The trouble is that existing drivers 
don't 
> : do 
> : > >>> : > : this, because they expect to be attached with hints, so they 
will 
> : > > attach 
> : > >>> : > : to all devices. I'm trying to figure out how to avoid this.
> : > >>> : > : 
> : > >>> : > : My basic question comes down to whether there is a good way in 
> : > > newbus to 
> : > >>> : > : handle busses that may be wholly or partially enumerated by 
> : firmware 
> : > > or 
> : > >>> : > : some other method, and may also have devices that can only 
attach 
> : > >>> : > : themselves if told to by hints.
> : > >>> : > 
> : > >>> : > Yes.  This is a bit of a problem.  The problem is that the 
existing
> : > >>> : > hints mechanism combines device tree and driver tree into one, 
and 
> : in
> : > >>> : > such a scenario, we wind up with the problem that you have.
> : > >>> : > 
> : > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and 
that
> : > >>> : > would help somewhat.  One could also have the probe routine 
check to
> : > >>> : > see if a specific driver is assigned to the device or not.  That 
> : would
> : > >>> : > also help, but does mean changing all the i2c bus attached 
drivers 
> : in
> : > >>> : > the tree.
> : > >>> : 
> : > >>> : I think changing existing I2C drivers may be unavoidable. Would 
there 
> : be 
> : > >>> : any objection to changing the MI iicbus drivers to return 
> : > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have 
been 
> : > >>> : introduced (by you) to solve more or less exactly this problem. By 
my 
> : > >>> : count, the relevant files are:
> : > >>> : dev/iicbus/ds133x.c
> : > >>> : dev/iicbus/icee.c
> : > >>> : dev/iicbus/ad7418.c
> : > >>> : dev/iicbus/iicsmb.c
> : > >>> : dev/iicbus/ds1672.c
> : > >>> : dev/iicbus/if_ic.c
> : > >>> : dev/iicbus/iic.c
> : > >>> : 
> : > >>> : I would also like to change iicbus_probe to return -1000 like 
> : > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please 
let 
> : me 
> : > >>> : know if this is a terrible idea or if I have forgotten any I2C 
device 
> : > >>> : drivers.
> : > >>>
> : > >>> Short term, this is the right fix.  There was an objection, I think 
by
> : > >>> Marcel, to this approach.  However, his objections were part of a
> : > >>> larger set of objections and I think that we're working to solve
> : > >>> those.
> : > >>>
> : > >>> Warner
> : > >>>   
> : > >> This is now in the tree. Now for part 2, which I had not considered 
> : > >> previously: connecting the I2C bus layer to the I2C host adapters.
> : > >>
> : > >> Right now, we have the following:
> : > >> kiic/other i2c adapters
> : > >> ---iicbus
> : > >> ---ofw_iicbus
> : > >>
> : > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
> : > >> attaches, and everything after that is wonderful. The issue is how 
best 
> : > >> to attach the iicbus modules to kiic. Current I2C controllers contain 
a 
> : > >> line like this:
> : > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
> : > >>
> : > >> This explicitly specifies that you want the standard driver, so we 
need 
> : > >> additional glue to allow the ofw_iicbus driver to attach. One 
solution 
> : > >> is that each relevant host adapter can add an additional 
DRIVER_MODULE 
> : > >> line with the ofw_iicbus driver and class, which would have to 
exported 
> : > >> in a header somewhere. This is pretty ugly. Another solution is for 
the 
> : > >> ofw_iicbus module to grow a list of the names of interesting 
adapters. 
> : > >> This is worse.
> : > >>
> : > >> The third option is to do what we do for pci, where all PCI adapters 
are 
> : > >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
> : > >> something, and then move the DRIVER_MODULE logic for new code into 
the 
> : > >> bus modules, as is done for PCI. This decreases the amount of 
> : > >> information in the device names, but seems a bit cleaner. Thoughts?
> : > >> -Nathan
> : > > 
> : > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
> : > > functionality) similar to the OF-aware PCI bus, then I would go the 
PCI 
> : route 
> : > > and just call it iicbus but give it a higher probe priority.
> : > > 
> : > 
> : > Which it is. What I meant was the bridge devices to which iicbus 
> : > attaches. For pci, they all end up with the same name (pcib) so that the 
> : > pci layer knows to attach to them. For I2C, they are called 
> : > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the 
> : > standard iicbus to itself, instead of letting it and any firmware-aware 
> : > versions probe.
> : 
> : I'm a bit torn on that one, especially since you have weird cases like one 
of 
> : the via parts that has both smbus and iicbus children.
> : 
> : The other option would be to fix the attaching to subclasses thing (that 
> : should make all pci drivers attach to cardbus0 devices since cardbus 
inherits 
> : from pci, for example) and then you could have what would basically be an 
> : abstract base class "iicbridge" with no devmethods that all bridge drivers 
> : inherit from, and iicbus would attach to that.
> 
> Right now, the only bug that I know about with the cardbus vs pci
> thing is that kldload doesn't necessarily probe/attach pci drivers on
> a cardbus bus.  Otherwise, it works perfectly.  This is the only
> reason that we have driver lines with cardbus attachments in the pci
> drivers at all...

That is the bug though. :)  I've looked at it and I think I know how to fix 
it, I just haven't gotten around to it.  I think device_probe_and_attach() 
needs to actually walk up the inheritance list of the current 'bus' driver, 
but only if all of the drivers for the current 'bus' failed to probe (or 
there are no drivers).

-- 
John Baldwin
From imp at bsdimp.com  Wed Jan 21 15:30:09 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 21 15:30:16 2009
Subject: Enumerable I2C busses
In-Reply-To: <200901211542.08461.jhb@freebsd.org>
References: <200901211110.33961.jhb@freebsd.org>
	<20090121.132805.1108816677.imp@bsdimp.com>
	<200901211542.08461.jhb@freebsd.org>
Message-ID: <20090121.162950.1552132922.imp@bsdimp.com>

In message: <200901211542.08461.jhb@freebsd.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote:
: > In message: <200901211110.33961.jhb@freebsd.org>
: >             John Baldwin <jhb@FreeBSD.org> writes:
: > : On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote:
: > : > John Baldwin wrote:
: > : > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
: > : > >> M. Warner Losh wrote:
: > : > >>> In message: <492AC8DE.6050902@freebsd.org>
: > : > >>>             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > : > >>> : M. Warner Losh wrote:
: > : > >>> : > In message: <4929C6D8.7090305@freebsd.org>
: > : > >>> : >             Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > : > >>> : > : Rafa? Jaworowski wrote:
: > : > >>> : > : > 
: > : > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Sm?rgrav wrote:
: > : > >>> : > : > 
: > : > >>> : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes:
: > : > >>> : > : >>> The current I2C bus mechanism does not support the bus 
: adding 
: > : > > its own
: > : > >>> : > : >>> children [...]
: > : > >>> : > : >>
: > : > >>> : > : >> That's because the I2C protocol does not support device 
: > : > > enumeration or
: > : > >>> : > : >> identification.  You have to know in advance what kind of 
: > : devices 
: > : > > are
: > : > >>> : > : >> attached and at what address.  Even worse, it is not 
: uncommon 
: > : for
: > : > >>> : > : >> similar but not entirely compatible devices to use the same 
: I2C 
: > : > > address
: > : > >>> : > : >> (for instance, every I2C-capable RTC chip uses the same 
: > : address, 
: > : > > even
: > : > >>> : > : >> though they have different feature sets)
: > : > >>> : > : > 
: > : > >>> : > : > Well, hard-coded addresses and conflicting assignments 
: between 
: > : > > vendors 
: > : > >>> : > : > do not technically prevent from scanning the bus; actually, 
: our 
: > : > > current 
: > : > >>> : > : > iicbus code can do bus scaning when compiled with a diag 
: define. 
: > : > > The 
: > : > >>> : > : > problem however is some slave devices are not well-behaved, 
: and 
: > : > > they 
: > : > >>> : > : > don't like to be read/written to other than in very specific 
: > : > > scenario: 
: > : > >>> : > : > if polled during bus scan strange effects occur e.g. they 
: > : > > disappear from 
: > : > >>> : > : > the bus, or do not react to consecutive requests etc.
: > : > >>> : > : 
: > : > >>> : > : All of this is true, but perhaps my question was badly worded. 
: > : What 
: > : > > I am 
: > : > >>> : > : trying to figure out is how to shove information from an 
: > : out-of-band 
: > : > >>> : > : source (Open Firmware, in this case) into newbus without 
: > : disrupting 
: > : > >>> : > : existing code. In that way, my question is not I2C specific -- 
: we 
: > : > > run 
: > : > >>> : > : into the same issue with the Open Firmware nexus node and 
: > : > > pseudo-devices 
: > : > >>> : > : like cryptosoft that attach themselves.
: > : > >>> : > 
: > : > >>> : > You are looking at the problem incorrectly.  In newbus, a case 
: like
: > : > >>> : > this the i2c bus should be a subclass (say i2c_of) that is 
: derived
: > : > >>> : > from the normal i2c bus stuff, but replaces the hints insertion 
: of
: > : > >>> : > devices with OF enumeration of devices.  The OF higher levels 
: will
: > : > >>> : > already know to attach this kind of i2c bus to certain i2c
: > : > >>> : > controllers, or always on certain platforms.
: > : > >>> : 
: > : > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
: > : > >>> : 
: > : > >>> : > : What I want to do is to have the I2C bus add the children that 
: the 
: > : > >>> : > : firmware says it has. What the firmware cannot tell in 
: advance, 
: > : > > however, 
: > : > >>> : > : is which FreeBSD driver is responsible for those devices, and 
: so 
: > : the 
: > : > > I2C 
: > : > >>> : > : bus driver can't know that without a translation table that I 
: > : would 
: > : > >>> : > : prefer not to hack in to the bus driver.
: > : > >>> : > 
: > : > >>> : > This is the bigger problem.  Today, we are stuck with a lame 
: table
: > : > >>> : > that will translate the OF provided properties into FreeBSD 
: driver
: > : > >>> : > names.
: > : > >>> : 
: > : > >>> : At the moment, I don't believe Apple uses any of the current very 
: > : small 
: > : > >>> : number of I2C device drivers in tree. So I may skip the table for 
: the 
: > : > >>> : time being, assuming the hack below is OK. In future, this may 
: change, 
: > : > >>> : since G5 systems require software thermal control. But that will 
: be 
: > : the 
: > : > >>> : subject of another mail to this list...
: > : > >>> : 
: > : > >>> : > : It seems reasonable to allow devices to use a real probe 
: routine 
: > : to 
: > : > > look 
: > : > >>> : > : at the firmware's name and compatible properties, like we 
: allow on 
: > : > > other 
: > : > >>> : > : Open Firmware busses. The trouble is that existing drivers 
: don't 
: > : do 
: > : > >>> : > : this, because they expect to be attached with hints, so they 
: will 
: > : > > attach 
: > : > >>> : > : to all devices. I'm trying to figure out how to avoid this.
: > : > >>> : > : 
: > : > >>> : > : My basic question comes down to whether there is a good way in 
: > : > > newbus to 
: > : > >>> : > : handle busses that may be wholly or partially enumerated by 
: > : firmware 
: > : > > or 
: > : > >>> : > : some other method, and may also have devices that can only 
: attach 
: > : > >>> : > : themselves if told to by hints.
: > : > >>> : > 
: > : > >>> : > Yes.  This is a bit of a problem.  The problem is that the 
: existing
: > : > >>> : > hints mechanism combines device tree and driver tree into one, 
: and 
: > : in
: > : > >>> : > such a scenario, we wind up with the problem that you have.
: > : > >>> : > 
: > : > >>> : > One could make the probe routines return BUS_PROBE_GENERIC, and 
: that
: > : > >>> : > would help somewhat.  One could also have the probe routine 
: check to
: > : > >>> : > see if a specific driver is assigned to the device or not.  That 
: > : would
: > : > >>> : > also help, but does mean changing all the i2c bus attached 
: drivers 
: > : in
: > : > >>> : > the tree.
: > : > >>> : 
: > : > >>> : I think changing existing I2C drivers may be unavoidable. Would 
: there 
: > : be 
: > : > >>> : any objection to changing the MI iicbus drivers to return 
: > : > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have 
: been 
: > : > >>> : introduced (by you) to solve more or less exactly this problem. By 
: my 
: > : > >>> : count, the relevant files are:
: > : > >>> : dev/iicbus/ds133x.c
: > : > >>> : dev/iicbus/icee.c
: > : > >>> : dev/iicbus/ad7418.c
: > : > >>> : dev/iicbus/iicsmb.c
: > : > >>> : dev/iicbus/ds1672.c
: > : > >>> : dev/iicbus/if_ic.c
: > : > >>> : dev/iicbus/iic.c
: > : > >>> : 
: > : > >>> : I would also like to change iicbus_probe to return -1000 like 
: > : > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please 
: let 
: > : me 
: > : > >>> : know if this is a terrible idea or if I have forgotten any I2C 
: device 
: > : > >>> : drivers.
: > : > >>>
: > : > >>> Short term, this is the right fix.  There was an objection, I think 
: by
: > : > >>> Marcel, to this approach.  However, his objections were part of a
: > : > >>> larger set of objections and I think that we're working to solve
: > : > >>> those.
: > : > >>>
: > : > >>> Warner
: > : > >>>   
: > : > >> This is now in the tree. Now for part 2, which I had not considered 
: > : > >> previously: connecting the I2C bus layer to the I2C host adapters.
: > : > >>
: > : > >> Right now, we have the following:
: > : > >> kiic/other i2c adapters
: > : > >> ---iicbus
: > : > >> ---ofw_iicbus
: > : > >>
: > : > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority, 
: > : > >> attaches, and everything after that is wonderful. The issue is how 
: best 
: > : > >> to attach the iicbus modules to kiic. Current I2C controllers contain 
: a 
: > : > >> line like this:
: > : > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
: > : > >>
: > : > >> This explicitly specifies that you want the standard driver, so we 
: need 
: > : > >> additional glue to allow the ofw_iicbus driver to attach. One 
: solution 
: > : > >> is that each relevant host adapter can add an additional 
: DRIVER_MODULE 
: > : > >> line with the ofw_iicbus driver and class, which would have to 
: exported 
: > : > >> in a header somewhere. This is pretty ugly. Another solution is for 
: the 
: > : > >> ofw_iicbus module to grow a list of the names of interesting 
: adapters. 
: > : > >> This is worse.
: > : > >>
: > : > >> The third option is to do what we do for pci, where all PCI adapters 
: are 
: > : > >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or 
: > : > >> something, and then move the DRIVER_MODULE logic for new code into 
: the 
: > : > >> bus modules, as is done for PCI. This decreases the amount of 
: > : > >> information in the device names, but seems a bit cleaner. Thoughts?
: > : > >> -Nathan
: > : > > 
: > : > > If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same 
: > : > > functionality) similar to the OF-aware PCI bus, then I would go the 
: PCI 
: > : route 
: > : > > and just call it iicbus but give it a higher probe priority.
: > : > > 
: > : > 
: > : > Which it is. What I meant was the bridge devices to which iicbus 
: > : > attaches. For pci, they all end up with the same name (pcib) so that the 
: > : > pci layer knows to attach to them. For I2C, they are called 
: > : > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the 
: > : > standard iicbus to itself, instead of letting it and any firmware-aware 
: > : > versions probe.
: > : 
: > : I'm a bit torn on that one, especially since you have weird cases like one 
: of 
: > : the via parts that has both smbus and iicbus children.
: > : 
: > : The other option would be to fix the attaching to subclasses thing (that 
: > : should make all pci drivers attach to cardbus0 devices since cardbus 
: inherits 
: > : from pci, for example) and then you could have what would basically be an 
: > : abstract base class "iicbridge" with no devmethods that all bridge drivers 
: > : inherit from, and iicbus would attach to that.
: > 
: > Right now, the only bug that I know about with the cardbus vs pci
: > thing is that kldload doesn't necessarily probe/attach pci drivers on
: > a cardbus bus.  Otherwise, it works perfectly.  This is the only
: > reason that we have driver lines with cardbus attachments in the pci
: > drivers at all...
: 
: That is the bug though. :)  I've looked at it and I think I know how to fix 
: it, I just haven't gotten around to it.  I think device_probe_and_attach() 
: needs to actually walk up the inheritance list of the current 'bus' driver, 
: but only if all of the drivers for the current 'bus' failed to probe (or 
: there are no drivers).

But why then does it work with the normal probe and only fail on the
load?

Warner
From dougb at FreeBSD.org  Wed Jan 21 22:17:08 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Jan 21 22:17:15 2009
Subject: Cross compiling FreeBSD
In-Reply-To: <COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
References: <COL112-W14559CEDAEB8C5373A03B4F6D60@phx.gbl>	<alpine.BSF.2.00.0901161027550.14974@tapio.cksoft.de>
	<COL112-W780FD46B6DB58A4A4DD545F6D40@phx.gbl>
Message-ID: <4978093A.5060504@FreeBSD.org>

Andrew Hotlab wrote:
> Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the
> amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook)
> # cd /usr/src
> # make buildworld TARGET=i386
> # make installworld TARGET=i386 DESTDIR=/path-to-jail
> # cd etc/
> # make distribution DESTDIR=/path-to-jail

You can replace those last two lines with:

mergemaster -i -A i386 -D /path-to-jail

In previous incarnations mergemaster was less than completely
effective *cough* in cross-build applications, but thanks to prodding
from Sam and help from Ruslan it works now (where "now" means -current
and 7-stable after the 7.1 release).


hth,

Doug

-- 

    This .signature sanitized for your protection
From jhb at freebsd.org  Thu Jan 22 07:42:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Jan 22 07:42:39 2009
Subject: Enumerable I2C busses
In-Reply-To: <20090121.162950.1552132922.imp@bsdimp.com>
References: <200901211110.33961.jhb@freebsd.org>
	<200901211542.08461.jhb@freebsd.org>
	<20090121.162950.1552132922.imp@bsdimp.com>
Message-ID: <200901221041.38286.jhb@freebsd.org>

On Wednesday 21 January 2009 6:29:50 pm M. Warner Losh wrote:
> In message: <200901211542.08461.jhb@freebsd.org>
>             John Baldwin <jhb@FreeBSD.org> writes:
> : On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote:
> : > Right now, the only bug that I know about with the cardbus vs pci
> : > thing is that kldload doesn't necessarily probe/attach pci drivers on
> : > a cardbus bus.  Otherwise, it works perfectly.  This is the only
> : > reason that we have driver lines with cardbus attachments in the pci
> : > drivers at all...
> : 
> : That is the bug though. :)  I've looked at it and I think I know how to 
fix 
> : it, I just haven't gotten around to it.  I think device_probe_and_attach() 
> : needs to actually walk up the inheritance list of the current 'bus' 
driver, 
> : but only if all of the drivers for the current 'bus' failed to probe (or 
> : there are no drivers).
> 
> But why then does it work with the normal probe and only fail on the
> load?

I think it has to do with the fact that we attempt to store parents of 
devclasses and walk that tree, when instead we should probably walk the 
inheritance tree of the parent device's driver instead.

That is, instead of doing this:

	for (; dc; dc = dc->parent) {
	}

It should be something more like this:

	driver_t parent_driver;

	parent_driver = device_get_driver(bus);
	for (dc = driver_first_devclass(parent_driver); dc;
	    dc = driver_next_devclass(parent_driver, dc)) {
	}

driver_first_devclass() would be the devclass of the parent driver, and 
driver_next_devclass() (which may be all we really need) would have to 
iterate over the parent superclasses of 'parent_driver'.  It might be a bit 
tricky to do anything more than a very simple first-pass of depth-first 
though for the traversal.  Doing a full superclass traversal in a sane order 
(since kobj supports multiple inheritance) might prove very problematic.

-- 
John Baldwin
From julian at elischer.org  Sat Jan 24 17:15:30 2009
From: julian at elischer.org (Julian Elischer)
Date: Sat Jan 24 17:15:38 2009
Subject: need for another mutex type/flag?
Message-ID: <497BA91D.805@elischer.org>

Currently we have:
spin locks..
you really don't want to hold these for
any time at all, and this is enforced to some extent in the waiter.

regular mutexes..
You can hold these for as long as you want but teh shorter
the better and you can't sleep when holding them. The
"shortness" of the time of holding the mutex is not enforced.

"Sleeps" (including sx-locks and friends)
   You may hold these or be descheduled for really long periods of time.


Now it occurs to me that there is a subclass of regular mutexes,
usage, which is where you want to use a mutex to guard some small
but critical structure, and that you know that access to that 
structure will be quick, and that you can guarantee that you will
not acquire any other locks (which could introduce unknown delay)
while hoding the lock.

One way of thinking about this is that this lock would always be
a leaf node on the tree of lock orders.
I would like to be able to add a flag to a mutex
that tags it as a 'leaf' mutex. As a result it would be illegal
to take any other mutex while holding a leaf mutex. Somewhat
similar to the way that it is illegal to take aregular
mutex while holding a spin mutex..


In netgraph I have a stipulation that is hard to specify which
is that  you MAY take a mutex in a netgraph node if you can guarantee
that the mutex WILL be satisfied very quickly, but it'd
be nice to be able to specify "you may only take 'leaf' mutexes within 
an netgraph node".


thoughts? (especially from jhb and other locking types).


From kmacy at freebsd.org  Sat Jan 24 20:25:42 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sat Jan 24 20:25:49 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497BA91D.805@elischer.org>
References: <497BA91D.805@elischer.org>
Message-ID: <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>

The adaptive spinning of regular mutexes already satisfies your need
for "short" hold. You might wish to add a thread flag used when
INVARIANTS is enabled that is set when a leaf mutex is acquired and
checked on all mutex acquisitions.

-Kip

On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> wrote:
> Currently we have:
> spin locks..
> you really don't want to hold these for
> any time at all, and this is enforced to some extent in the waiter.
>
> regular mutexes..
> You can hold these for as long as you want but teh shorter
> the better and you can't sleep when holding them. The
> "shortness" of the time of holding the mutex is not enforced.
>
> "Sleeps" (including sx-locks and friends)
>  You may hold these or be descheduled for really long periods of time.
>
>
> Now it occurs to me that there is a subclass of regular mutexes,
> usage, which is where you want to use a mutex to guard some small
> but critical structure, and that you know that access to that structure will
> be quick, and that you can guarantee that you will
> not acquire any other locks (which could introduce unknown delay)
> while hoding the lock.
>
> One way of thinking about this is that this lock would always be
> a leaf node on the tree of lock orders.
> I would like to be able to add a flag to a mutex
> that tags it as a 'leaf' mutex. As a result it would be illegal
> to take any other mutex while holding a leaf mutex. Somewhat
> similar to the way that it is illegal to take aregular
> mutex while holding a spin mutex..
>
>
> In netgraph I have a stipulation that is hard to specify which
> is that  you MAY take a mutex in a netgraph node if you can guarantee
> that the mutex WILL be satisfied very quickly, but it'd
> be nice to be able to specify "you may only take 'leaf' mutexes within an
> netgraph node".
>
>
> thoughts? (especially from jhb and other locking types).
>
>
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
From phk at phk.freebsd.dk  Sun Jan 25 00:18:46 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun Jan 25 00:18:52 2009
Subject: need for another mutex type/flag? 
In-Reply-To: Your message of "Sat, 24 Jan 2009 15:49:49 PST."
	<497BA91D.805@elischer.org> 
Message-ID: <23211.1232871523@critter.freebsd.dk>

In message <497BA91D.805@elischer.org>, Julian Elischer writes:

>I would like to be able to add a flag to a mutex
>that tags it as a 'leaf' mutex. As a result it would be illegal
>to take any other mutex while holding a leaf mutex.

I second that, even if the flag is purely documentary, it is a
good idea.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
From julian at elischer.org  Sun Jan 25 00:45:31 2009
From: julian at elischer.org (Julian Elischer)
Date: Sun Jan 25 00:45:37 2009
Subject: need for another mutex type/flag?
In-Reply-To: <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
Message-ID: <497C235E.5090807@elischer.org>

Kip Macy wrote:
> The adaptive spinning of regular mutexes already satisfies your need
> for "short" hold. You might wish to add a thread flag used when
> INVARIANTS is enabled that is set when a leaf mutex is acquired and
> checked on all mutex acquisitions.

ummm that was what I was asking for.. an official designation of a 
'leaf' mutex...

> 
> -Kip
> 
> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> wrote:
>> Currently we have:
>> spin locks..
>> you really don't want to hold these for
>> any time at all, and this is enforced to some extent in the waiter.
>>
>> regular mutexes..
>> You can hold these for as long as you want but teh shorter
>> the better and you can't sleep when holding them. The
>> "shortness" of the time of holding the mutex is not enforced.
>>
>> "Sleeps" (including sx-locks and friends)
>>  You may hold these or be descheduled for really long periods of time.
>>
>>
>> Now it occurs to me that there is a subclass of regular mutexes,
>> usage, which is where you want to use a mutex to guard some small
>> but critical structure, and that you know that access to that structure will
>> be quick, and that you can guarantee that you will
>> not acquire any other locks (which could introduce unknown delay)
>> while hoding the lock.
>>
>> One way of thinking about this is that this lock would always be
>> a leaf node on the tree of lock orders.
>> I would like to be able to add a flag to a mutex
>> that tags it as a 'leaf' mutex. As a result it would be illegal
>> to take any other mutex while holding a leaf mutex. Somewhat
>> similar to the way that it is illegal to take aregular
>> mutex while holding a spin mutex..
>>
>>
>> In netgraph I have a stipulation that is hard to specify which
>> is that  you MAY take a mutex in a netgraph node if you can guarantee
>> that the mutex WILL be satisfied very quickly, but it'd
>> be nice to be able to specify "you may only take 'leaf' mutexes within an
>> netgraph node".
>>
>>
>> thoughts? (especially from jhb and other locking types).
>>
>>
>> _______________________________________________
>> freebsd-arch@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>>

From julian at elischer.org  Sun Jan 25 00:50:32 2009
From: julian at elischer.org (Julian Elischer)
Date: Sun Jan 25 00:50:39 2009
Subject: need for another mutex type/flag?
In-Reply-To: <23211.1232871523@critter.freebsd.dk>
References: <23211.1232871523@critter.freebsd.dk>
Message-ID: <497C249C.5060507@elischer.org>

Poul-Henning Kamp wrote:
> In message <497BA91D.805@elischer.org>, Julian Elischer writes:
> 
>> I would like to be able to add a flag to a mutex
>> that tags it as a 'leaf' mutex. As a result it would be illegal
>> to take any other mutex while holding a leaf mutex.
> 
> I second that, even if the flag is purely documentary, it is a
> good idea.
> 

Even purely documentary would be good but given the option, I'd
like it to scream when Witness is enabled and you try get
another mutex....

there are certain contexts (e.g. in most netgraph nodes)
where we really want the authors to only take such locks
and taking more unpredictable mutexes plays havoc with
netgraph response times as a system as a whole, since if
one node blocks, teh thread doesn't get to go off and service other nodes.

From kmacy at freebsd.org  Sun Jan 25 01:11:54 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sun Jan 25 01:12:01 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497C235E.5090807@elischer.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org>
Message-ID: <3c1674c90901250111w34f9d016xb8e812cf46433970@mail.gmail.com>

On Sun, Jan 25, 2009 at 8:31 AM, Julian Elischer <julian@elischer.org> wrote:
> Kip Macy wrote:
>>
>> The adaptive spinning of regular mutexes already satisfies your need
>> for "short" hold. You might wish to add a thread flag used when
>> INVARIANTS is enabled that is set when a leaf mutex is acquired and
>> checked on all mutex acquisitions.
>
> ummm that was what I was asking for.. an official designation of a 'leaf'
> mutex...

uhm ...  I was explaining a way to implement it without WITNESS.

-Kip

>
>>
>> -Kip
>>
>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org>
>> wrote:
>>>
>>> Currently we have:
>>> spin locks..
>>> you really don't want to hold these for
>>> any time at all, and this is enforced to some extent in the waiter.
>>>
>>> regular mutexes..
>>> You can hold these for as long as you want but teh shorter
>>> the better and you can't sleep when holding them. The
>>> "shortness" of the time of holding the mutex is not enforced.
>>>
>>> "Sleeps" (including sx-locks and friends)
>>>  You may hold these or be descheduled for really long periods of time.
>>>
>>>
>>> Now it occurs to me that there is a subclass of regular mutexes,
>>> usage, which is where you want to use a mutex to guard some small
>>> but critical structure, and that you know that access to that structure
>>> will
>>> be quick, and that you can guarantee that you will
>>> not acquire any other locks (which could introduce unknown delay)
>>> while hoding the lock.
>>>
>>> One way of thinking about this is that this lock would always be
>>> a leaf node on the tree of lock orders.
>>> I would like to be able to add a flag to a mutex
>>> that tags it as a 'leaf' mutex. As a result it would be illegal
>>> to take any other mutex while holding a leaf mutex. Somewhat
>>> similar to the way that it is illegal to take aregular
>>> mutex while holding a spin mutex..
>>>
>>>
>>> In netgraph I have a stipulation that is hard to specify which
>>> is that  you MAY take a mutex in a netgraph node if you can guarantee
>>> that the mutex WILL be satisfied very quickly, but it'd
>>> be nice to be able to specify "you may only take 'leaf' mutexes within an
>>> netgraph node".
>>>
>>>
>>> thoughts? (especially from jhb and other locking types).
>>>
>>>
>>> _______________________________________________
>>> freebsd-arch@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>>>
>
>
From julian at elischer.org  Sun Jan 25 01:18:55 2009
From: julian at elischer.org (Julian Elischer)
Date: Sun Jan 25 01:19:02 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090124224716.X983@desktop>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
Message-ID: <497C2E82.6010600@elischer.org>

Jeff Roberson wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
>> Kip Macy wrote:
>>> The adaptive spinning of regular mutexes already satisfies your need
>>> for "short" hold. You might wish to add a thread flag used when
>>> INVARIANTS is enabled that is set when a leaf mutex is acquired and
>>> checked on all mutex acquisitions.
>>
>> ummm that was what I was asking for.. an official designation of a 
>> 'leaf' mutex...
> 
> It'd be much easier to add the flag as a mtx_init() flag and have 
> witness check it.  It'd only take 15 minutes to do properly.

more or less what I was suggesting.

> 
> What is the case you have where you can not acquire non leaf mutexes?
> 
An example is netgraph. In netgraph you have one (or a small number) 
thread which is processing on behalf of a number of nodes which may be
doing work on behalf of completely different entities.
If such a worker thread blocks then other work becomes starved..

A similar example might be made for geom I expect. If a worker thread 
blocks other work can be starved.

Now you still in these modules need some way to synchronize
between threads to protect local resources etc. So you still
want to be able to use mutexes for this but you wnat to be able to
tell the module author "yes you can use mutexes but you can't
do so in a way that introduces any threat of undetirminsitic blocking".

i.e. once you have mutex in your node, to do something, do it quickly
and drop teh mutex, and do NOT go acquiring something that
might sleep on us.

I'm already worried about people getting mbufs etc in netgraph,
and it may turn out that we are already hitting this without
knowing it..


From jroberson at jroberson.net  Sun Jan 25 01:20:41 2009
From: jroberson at jroberson.net (Jeff Roberson)
Date: Sun Jan 25 01:20:47 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497C235E.5090807@elischer.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org>
Message-ID: <20090124224716.X983@desktop>

On Sun, 25 Jan 2009, Julian Elischer wrote:

> Kip Macy wrote:
>> The adaptive spinning of regular mutexes already satisfies your need
>> for "short" hold. You might wish to add a thread flag used when
>> INVARIANTS is enabled that is set when a leaf mutex is acquired and
>> checked on all mutex acquisitions.
>
> ummm that was what I was asking for.. an official designation of a 'leaf' 
> mutex...

It'd be much easier to add the flag as a mtx_init() flag and have witness 
check it.  It'd only take 15 minutes to do properly.

What is the case you have where you can not acquire non leaf mutexes?

Thanks,
Jeff

>
>> 
>> -Kip
>> 
>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> 
>> wrote:
>>> Currently we have:
>>> spin locks..
>>> you really don't want to hold these for
>>> any time at all, and this is enforced to some extent in the waiter.
>>> 
>>> regular mutexes..
>>> You can hold these for as long as you want but teh shorter
>>> the better and you can't sleep when holding them. The
>>> "shortness" of the time of holding the mutex is not enforced.
>>> 
>>> "Sleeps" (including sx-locks and friends)
>>>  You may hold these or be descheduled for really long periods of time.
>>> 
>>> 
>>> Now it occurs to me that there is a subclass of regular mutexes,
>>> usage, which is where you want to use a mutex to guard some small
>>> but critical structure, and that you know that access to that structure 
>>> will
>>> be quick, and that you can guarantee that you will
>>> not acquire any other locks (which could introduce unknown delay)
>>> while hoding the lock.
>>> 
>>> One way of thinking about this is that this lock would always be
>>> a leaf node on the tree of lock orders.
>>> I would like to be able to add a flag to a mutex
>>> that tags it as a 'leaf' mutex. As a result it would be illegal
>>> to take any other mutex while holding a leaf mutex. Somewhat
>>> similar to the way that it is illegal to take aregular
>>> mutex while holding a spin mutex..
>>> 
>>> 
>>> In netgraph I have a stipulation that is hard to specify which
>>> is that  you MAY take a mutex in a netgraph node if you can guarantee
>>> that the mutex WILL be satisfied very quickly, but it'd
>>> be nice to be able to specify "you may only take 'leaf' mutexes within an
>>> netgraph node".
>>> 
>>> 
>>> thoughts? (especially from jhb and other locking types).
>>> 
>>> 
>>> _______________________________________________
>>> freebsd-arch@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>>> 
>
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
From alfred at freebsd.org  Sun Jan 25 01:37:28 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Sun Jan 25 01:37:34 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090124224716.X983@desktop>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
Message-ID: <20090125092838.GC87077@elvis.mu.org>

* Jeff Roberson <jroberson@jroberson.net> [090125 01:21] wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
> >Kip Macy wrote:
> >>The adaptive spinning of regular mutexes already satisfies your need
> >>for "short" hold. You might wish to add a thread flag used when
> >>INVARIANTS is enabled that is set when a leaf mutex is acquired and
> >>checked on all mutex acquisitions.
> >
> >ummm that was what I was asking for.. an official designation of a 'leaf' 
> >mutex...
> 
> It'd be much easier to add the flag as a mtx_init() flag and have witness 
> check it.  It'd only take 15 minutes to do properly.
> 
> What is the case you have where you can not acquire non leaf mutexes?

Jeff, I think that Julian really wants to prevent a sleep inside
his context.  Right now, I think we only check for mutexes held
before a sleep that arne't sleepable.  It might make sense to allow
one to just mark a thread non-sleepable even though no mutex is
held.

Julian, is that right?

> 
> Thanks,
> Jeff
> 
> >
> >>
> >>-Kip
> >>
> >>On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> 
> >>wrote:
> >>>Currently we have:
> >>>spin locks..
> >>>you really don't want to hold these for
> >>>any time at all, and this is enforced to some extent in the waiter.
> >>>
> >>>regular mutexes..
> >>>You can hold these for as long as you want but teh shorter
> >>>the better and you can't sleep when holding them. The
> >>>"shortness" of the time of holding the mutex is not enforced.
> >>>
> >>>"Sleeps" (including sx-locks and friends)
> >>> You may hold these or be descheduled for really long periods of time.
> >>>
> >>>
> >>>Now it occurs to me that there is a subclass of regular mutexes,
> >>>usage, which is where you want to use a mutex to guard some small
> >>>but critical structure, and that you know that access to that structure 
> >>>will
> >>>be quick, and that you can guarantee that you will
> >>>not acquire any other locks (which could introduce unknown delay)
> >>>while hoding the lock.
> >>>
> >>>One way of thinking about this is that this lock would always be
> >>>a leaf node on the tree of lock orders.
> >>>I would like to be able to add a flag to a mutex
> >>>that tags it as a 'leaf' mutex. As a result it would be illegal
> >>>to take any other mutex while holding a leaf mutex. Somewhat
> >>>similar to the way that it is illegal to take aregular
> >>>mutex while holding a spin mutex..
> >>>
> >>>
> >>>In netgraph I have a stipulation that is hard to specify which
> >>>is that  you MAY take a mutex in a netgraph node if you can guarantee
> >>>that the mutex WILL be satisfied very quickly, but it'd
> >>>be nice to be able to specify "you may only take 'leaf' mutexes within an
> >>>netgraph node".
> >>>
> >>>
> >>>thoughts? (especially from jhb and other locking types).
> >>>
> >>>
> >>>_______________________________________________
> >>>freebsd-arch@freebsd.org mailing list
> >>>http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> >>>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> >>>
> >
> >_______________________________________________
> >freebsd-arch@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> >
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-- 
- Alfred Perlstein
From alfred at freebsd.org  Sun Jan 25 01:42:28 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Sun Jan 25 01:42:35 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497C2E82.6010600@elischer.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
	<497C2E82.6010600@elischer.org>
Message-ID: <20090125092712.GB87077@elvis.mu.org>

* Julian Elischer <julian@elischer.org> [090125 01:19] wrote:
> Jeff Roberson wrote:
> >On Sun, 25 Jan 2009, Julian Elischer wrote:
> >
> >>Kip Macy wrote:
> >>>The adaptive spinning of regular mutexes already satisfies your need
> >>>for "short" hold. You might wish to add a thread flag used when
> >>>INVARIANTS is enabled that is set when a leaf mutex is acquired and
> >>>checked on all mutex acquisitions.
> >>
> >>ummm that was what I was asking for.. an official designation of a 
> >>'leaf' mutex...
> >
> >It'd be much easier to add the flag as a mtx_init() flag and have 
> >witness check it.  It'd only take 15 minutes to do properly.
> 
> more or less what I was suggesting.
> 
> >
> >What is the case you have where you can not acquire non leaf mutexes?
> >
> An example is netgraph. In netgraph you have one (or a small number) 
> thread which is processing on behalf of a number of nodes which may be
> doing work on behalf of completely different entities.
> If such a worker thread blocks then other work becomes starved..
> 
> A similar example might be made for geom I expect. If a worker thread 
> blocks other work can be starved.
> 
> Now you still in these modules need some way to synchronize
> between threads to protect local resources etc. So you still
> want to be able to use mutexes for this but you wnat to be able to
> tell the module author "yes you can use mutexes but you can't
> do so in a way that introduces any threat of undetirminsitic blocking".
> 
> i.e. once you have mutex in your node, to do something, do it quickly
> and drop teh mutex, and do NOT go acquiring something that
> might sleep on us.
> 
> I'm already worried about people getting mbufs etc in netgraph,
> and it may turn out that we are already hitting this without
> knowing it..

You could probably easily add this to witness_warn, basically
check a count in the thread that's recursive for not allowing
sleeps.

Currently, whenever a proceess would sleep, witness checks the
list of locks that the thread holds for locks that shouldn't
be slept on.

You could pretty easily add a check here too.

-- 
- Alfred Perlstein
From ed at 80386.nl  Sun Jan 25 01:43:44 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sun Jan 25 01:43:51 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497BA91D.805@elischer.org>
References: <497BA91D.805@elischer.org>
Message-ID: <20090125094342.GD41248@hoeg.nl>

Hello Julian,

I thought we already supported something like that. Isn't
THREAD_NO_SLEEPING() and THREAD_SLEEPING_OK() exactly what you describe?

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090125/db1b64fc/attachment.pgp
From ed at 80386.nl  Sun Jan 25 01:49:02 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sun Jan 25 01:49:08 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090125094342.GD41248@hoeg.nl>
References: <497BA91D.805@elischer.org> <20090125094342.GD41248@hoeg.nl>
Message-ID: <20090125094901.GE41248@hoeg.nl>

* Ed Schouten <ed@80386.nl> wrote:
> I thought we already supported something like that. Isn't
> THREAD_NO_SLEEPING() and THREAD_SLEEPING_OK() exactly what you describe?

Oh wait, never mind. That only prevents a thread from sleeping on a
sleepqueue.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090125/a1630a5a/attachment.pgp
From julian at elischer.org  Sun Jan 25 22:53:41 2009
From: julian at elischer.org (Julian Elischer)
Date: Sun Jan 25 22:53:47 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090125092838.GC87077@elvis.mu.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
	<20090125092838.GC87077@elvis.mu.org>
Message-ID: <497D5DF8.8000706@elischer.org>

Alfred Perlstein wrote:
> * Jeff Roberson <jroberson@jroberson.net> [090125 01:21] wrote:
>> On Sun, 25 Jan 2009, Julian Elischer wrote:
>>
>>> Kip Macy wrote:
>>>> The adaptive spinning of regular mutexes already satisfies your need
>>>> for "short" hold. You might wish to add a thread flag used when
>>>> INVARIANTS is enabled that is set when a leaf mutex is acquired and
>>>> checked on all mutex acquisitions.
>>> ummm that was what I was asking for.. an official designation of a 'leaf' 
>>> mutex...
>> It'd be much easier to add the flag as a mtx_init() flag and have witness 
>> check it.  It'd only take 15 minutes to do properly.
>>
>> What is the case you have where you can not acquire non leaf mutexes?
> 
> Jeff, I think that Julian really wants to prevent a sleep inside
> his context.  Right now, I think we only check for mutexes held
> before a sleep that arne't sleepable.  It might make sense to allow
> one to just mark a thread non-sleepable even though no mutex is
> held.
> 
> Julian, is that right?

basically, though I don't know the details of implementation..
I just know that mutexes per se aren't bad for netgraph but
that node authors need some guidance on how to use them and
some way to prove to them when they do the wrong thing.

> 
>> Thanks,
>> Jeff
>>
>>>> -Kip
>>>>
>>>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@elischer.org> 
>>>> wrote:
>>>>> Currently we have:
>>>>> spin locks..
>>>>> you really don't want to hold these for
>>>>> any time at all, and this is enforced to some extent in the waiter.
>>>>>
>>>>> regular mutexes..
>>>>> You can hold these for as long as you want but teh shorter
>>>>> the better and you can't sleep when holding them. The
>>>>> "shortness" of the time of holding the mutex is not enforced.
>>>>>
>>>>> "Sleeps" (including sx-locks and friends)
>>>>> You may hold these or be descheduled for really long periods of time.
>>>>>
>>>>>
>>>>> Now it occurs to me that there is a subclass of regular mutexes,
>>>>> usage, which is where you want to use a mutex to guard some small
>>>>> but critical structure, and that you know that access to that structure 
>>>>> will
>>>>> be quick, and that you can guarantee that you will
>>>>> not acquire any other locks (which could introduce unknown delay)
>>>>> while hoding the lock.
>>>>>
>>>>> One way of thinking about this is that this lock would always be
>>>>> a leaf node on the tree of lock orders.
>>>>> I would like to be able to add a flag to a mutex
>>>>> that tags it as a 'leaf' mutex. As a result it would be illegal
>>>>> to take any other mutex while holding a leaf mutex. Somewhat
>>>>> similar to the way that it is illegal to take aregular
>>>>> mutex while holding a spin mutex..
>>>>>
>>>>>
>>>>> In netgraph I have a stipulation that is hard to specify which
>>>>> is that  you MAY take a mutex in a netgraph node if you can guarantee
>>>>> that the mutex WILL be satisfied very quickly, but it'd
>>>>> be nice to be able to specify "you may only take 'leaf' mutexes within an
>>>>> netgraph node".
>>>>>
>>>>>
>>>>> thoughts? (especially from jhb and other locking types).
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> freebsd-arch@freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>>>>>
>>> _______________________________________________
>>> freebsd-arch@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>>>
>> _______________________________________________
>> freebsd-arch@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> 

From alfred at freebsd.org  Mon Jan 26 02:51:41 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Mon Jan 26 02:51:47 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497D5DF8.8000706@elischer.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
	<20090125092838.GC87077@elvis.mu.org>
	<497D5DF8.8000706@elischer.org>
Message-ID: <20090126105140.GL5889@elvis.mu.org>

* Julian Elischer <julian@elischer.org> [090125 22:53] wrote:
> Alfred Perlstein wrote:
> >
> >Jeff, I think that Julian really wants to prevent a sleep inside
> >his context.  Right now, I think we only check for mutexes held
> >before a sleep that arne't sleepable.  It might make sense to allow
> >one to just mark a thread non-sleepable even though no mutex is
> >held.
> >
> >Julian, is that right?
> 
> basically, though I don't know the details of implementation..
> I just know that mutexes per se aren't bad for netgraph but
> that node authors need some guidance on how to use them and
> some way to prove to them when they do the wrong thing.

The way to add the assertion you want would be to keep a count
inside of the thread structure "td_nosleep", set to 0 at thread
creation, then you can do this:

TD_SLEEP_NO(td);  /* td->td_nosleep++ */
call_some_untrusted_code();
TD_SLEEP_OK(td);  /* td->td_nosleep-- */

Then add this to subr_witness.c:witness_warn():

   if (flags & WARN_SLEEPOK && td->td_nosleep != 0) {
      printf("Sleeping in unsleepable context.\n");
      n++;   /* this variable is local to witness_warn() 
                and triggers an ASSERT at the end */
   }

I could have sworn we already had such a feature, but it appears
that it's only accessable if you're holding a lock, if you added
this counter, then you could catch sleeps without needing a lock
held.

-Alfred
From bugmaster at FreeBSD.org  Mon Jan 26 03:06:53 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jan 26 03:07:24 2009
Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org
Message-ID: <200901261106.n0QB6qdV024199@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/120749  arch       [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

From jhb at freebsd.org  Mon Jan 26 06:58:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Jan 26 06:58:52 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090126105140.GL5889@elvis.mu.org>
References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org>
	<20090126105140.GL5889@elvis.mu.org>
Message-ID: <200901260936.18232.jhb@freebsd.org>

On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote:
> * Julian Elischer <julian@elischer.org> [090125 22:53] wrote:
> > Alfred Perlstein wrote:
> > >
> > >Jeff, I think that Julian really wants to prevent a sleep inside
> > >his context.  Right now, I think we only check for mutexes held
> > >before a sleep that arne't sleepable.  It might make sense to allow
> > >one to just mark a thread non-sleepable even though no mutex is
> > >held.
> > >
> > >Julian, is that right?
> > 
> > basically, though I don't know the details of implementation..
> > I just know that mutexes per se aren't bad for netgraph but
> > that node authors need some guidance on how to use them and
> > some way to prove to them when they do the wrong thing.
> 
> The way to add the assertion you want would be to keep a count
> inside of the thread structure "td_nosleep", set to 0 at thread
> creation, then you can do this:
> 
> TD_SLEEP_NO(td);  /* td->td_nosleep++ */
> call_some_untrusted_code();
> TD_SLEEP_OK(td);  /* td->td_nosleep-- */
> 
> Then add this to subr_witness.c:witness_warn():
> 
>    if (flags & WARN_SLEEPOK && td->td_nosleep != 0) {
>       printf("Sleeping in unsleepable context.\n");
>       n++;   /* this variable is local to witness_warn() 
>                 and triggers an ASSERT at the end */
>    }
> 
> I could have sworn we already had such a feature, but it appears
> that it's only accessable if you're holding a lock, if you added
> this counter, then you could catch sleeps without needing a lock
> held.

We have this feature already for sleeping, but I think Julian isn't worried 
about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code 
from acquiring any other locks.  It's easy to add a MTX_LEAF, I'm just not 
sure if we really want to micro-manage the code that much.  WITNESS will 
already catch any LORs, and if they are acquiring a rarely-contested lock 
then they aren't going to back up traffic in the common case.

-- 
John Baldwin
From jhb at freebsd.org  Mon Jan 26 06:58:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Jan 26 06:58:53 2009
Subject: need for another mutex type/flag?
In-Reply-To: <20090126105140.GL5889@elvis.mu.org>
References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org>
	<20090126105140.GL5889@elvis.mu.org>
Message-ID: <200901260936.18232.jhb@freebsd.org>

On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote:
> * Julian Elischer <julian@elischer.org> [090125 22:53] wrote:
> > Alfred Perlstein wrote:
> > >
> > >Jeff, I think that Julian really wants to prevent a sleep inside
> > >his context.  Right now, I think we only check for mutexes held
> > >before a sleep that arne't sleepable.  It might make sense to allow
> > >one to just mark a thread non-sleepable even though no mutex is
> > >held.
> > >
> > >Julian, is that right?
> > 
> > basically, though I don't know the details of implementation..
> > I just know that mutexes per se aren't bad for netgraph but
> > that node authors need some guidance on how to use them and
> > some way to prove to them when they do the wrong thing.
> 
> The way to add the assertion you want would be to keep a count
> inside of the thread structure "td_nosleep", set to 0 at thread
> creation, then you can do this:
> 
> TD_SLEEP_NO(td);  /* td->td_nosleep++ */
> call_some_untrusted_code();
> TD_SLEEP_OK(td);  /* td->td_nosleep-- */
> 
> Then add this to subr_witness.c:witness_warn():
> 
>    if (flags & WARN_SLEEPOK && td->td_nosleep != 0) {
>       printf("Sleeping in unsleepable context.\n");
>       n++;   /* this variable is local to witness_warn() 
>                 and triggers an ASSERT at the end */
>    }
> 
> I could have sworn we already had such a feature, but it appears
> that it's only accessable if you're holding a lock, if you added
> this counter, then you could catch sleeps without needing a lock
> held.

We have this feature already for sleeping, but I think Julian isn't worried 
about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code 
from acquiring any other locks.  It's easy to add a MTX_LEAF, I'm just not 
sure if we really want to micro-manage the code that much.  WITNESS will 
already catch any LORs, and if they are acquiring a rarely-contested lock 
then they aren't going to back up traffic in the common case.

-- 
John Baldwin
From jhb at freebsd.org  Mon Jan 26 06:58:45 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Jan 26 06:58:55 2009
Subject: Trimming the default /boot/device.hints
Message-ID: <200901260947.32870.jhb@freebsd.org>

After the changes to make hints always reserve device names, soem folks ran 
into issues with devices changing names due to previously unused hints now 
always being honored (e.g. hints for non-existent ISA le(4) cards always 
reserving le0).  What I would like to do to help minimize this further is to 
trim the default set of hints.  The number of machines that will run 8.0 that 
have ISA slots is incredibly small, probably zero.  To that end, I would like 
to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
driver uses an identify routine to always add itself.  Note that end-users 
can always add hints back later if desired/needed.  However, changing the 
defaults means that some hardware may no longer work out of the box.  My 
guess though is that the set of such hardware is the empty set.

If we wanted, we could go further and assume that all machines have either 
PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
fdc0, ppc0, and some other devices).

Here is the proposed diff:

--- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints
+++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints
@@ -13,7 +13,6 @@
 hint.atkbd.0.irq="1"
 hint.psm.0.at="atkbdc"
 hint.psm.0.irq="12"
-hint.vga.0.at="isa"
 hint.sc.0.at="isa"
 hint.sc.0.flags="0x100"
 hint.uart.0.at="isa"
@@ -23,13 +22,5 @@
 hint.uart.1.at="isa"
 hint.uart.1.port="0x2F8"
 hint.uart.1.irq="3"
-hint.uart.2.at="isa"
-hint.uart.2.disabled="1"
-hint.uart.2.port="0x3E8"
-hint.uart.2.irq="5"
-hint.uart.3.at="isa"
-hint.uart.3.disabled="1"
-hint.uart.3.port="0x2E8"
-hint.uart.3.irq="9"
 hint.ppc.0.at="isa"
 hint.ppc.0.irq="7"
--- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints
+++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints
@@ -13,21 +13,12 @@
 hint.ata.1.at="isa"
 hint.ata.1.port="0x170"
 hint.ata.1.irq="15"
-hint.adv.0.at="isa"
-hint.adv.0.disabled="1"
-hint.bt.0.at="isa"
-hint.bt.0.disabled="1"
-hint.aha.0.at="isa"
-hint.aha.0.disabled="1"
-hint.aic.0.at="isa"
-hint.aic.0.disabled="1"
 hint.atkbdc.0.at="isa"
 hint.atkbdc.0.port="0x060"
 hint.atkbd.0.at="atkbdc"
 hint.atkbd.0.irq="1"
 hint.psm.0.at="atkbdc"
 hint.psm.0.irq="12"
-hint.vga.0.at="isa"
 hint.sc.0.at="isa"
 hint.sc.0.flags="0x100"
 hint.apm.0.disabled="1"
@@ -39,41 +30,8 @@
 hint.uart.1.at="isa"
 hint.uart.1.port="0x2F8"
 hint.uart.1.irq="3"
-hint.uart.2.at="isa"
-hint.uart.2.disabled="1"
-hint.uart.2.port="0x3E8"
-hint.uart.2.irq="5"
-hint.uart.3.at="isa"
-hint.uart.3.disabled="1"
-hint.uart.3.port="0x2E8"
-hint.uart.3.irq="9"
 hint.ppc.0.at="isa"
 hint.ppc.0.irq="7"
-hint.ed.0.at="isa"
-hint.ed.0.disabled="1"
-hint.ed.0.port="0x280"
-hint.ed.0.irq="10"
-hint.ed.0.maddr="0xd8000"
-hint.cs.0.at="isa"
-hint.cs.0.disabled="1"
-hint.cs.0.port="0x300"
-hint.sn.0.at="isa"
-hint.sn.0.disabled="1"
-hint.sn.0.port="0x300"
-hint.sn.0.irq="10"
-hint.ie.0.at="isa"
-hint.ie.0.disabled="1"
-hint.ie.0.port="0x300"
-hint.ie.0.irq="10"
-hint.ie.0.maddr="0xd0000"
-hint.fe.0.at="isa"
-hint.fe.0.disabled="1"
-hint.fe.0.port="0x300"
-hint.le.0.at="isa"
-hint.le.0.disabled="1"
-hint.le.0.port="0x280"
-hint.le.0.irq="10"
-hint.le.0.drq="0"
 hint.atrtc.0.at="isa"
 hint.atrtc.0.port="0x70"
 hint.atrtc.0.irq="8"


-- 
John Baldwin
From rink at FreeBSD.org  Mon Jan 26 07:31:40 2009
From: rink at FreeBSD.org (Rink Springer)
Date: Mon Jan 26 07:31:51 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901260947.32870.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
Message-ID: <20090126151558.GA41388@rink.nu>

On Mon, Jan 26, 2009 at 09:47:32AM -0500, John Baldwin wrote:
> If we wanted, we could go further and assume that all machines have either 
> PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
> of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
> fdc0, ppc0, and some other devices).
> 
> Here is the proposed diff:

This diff makes sense to me - besides, it's always possible to enter the
hints at the loader prompt if desired to get a device to work and adding
that to a local loader.conf later; I don't think these defaults are
worth the clutter since almost nobody probably has these devices
anyway...


Regards,

-- 
Rink P.W. Springer                                - http://rink.nu
"Chance favours the prepared mind"
- Penn
From julian at elischer.org  Mon Jan 26 10:05:21 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jan 26 10:05:28 2009
Subject: need for another mutex type/flag?
In-Reply-To: <200901260936.18232.jhb@freebsd.org>
References: <497BA91D.805@elischer.org>
	<497D5DF8.8000706@elischer.org>	<20090126105140.GL5889@elvis.mu.org>
	<200901260936.18232.jhb@freebsd.org>
Message-ID: <497DFB61.1010602@elischer.org>

John Baldwin wrote:
> On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote:
>> * Julian Elischer <julian@elischer.org> [090125 22:53] wrote:
>>> Alfred Perlstein wrote:
>>>> Jeff, I think that Julian really wants to prevent a sleep inside
>>>> his context.  Right now, I think we only check for mutexes held
>>>> before a sleep that arne't sleepable.  It might make sense to allow
>>>> one to just mark a thread non-sleepable even though no mutex is
>>>> held.
>>>>
>>>> Julian, is that right?
>>> basically, though I don't know the details of implementation..
>>> I just know that mutexes per se aren't bad for netgraph but
>>> that node authors need some guidance on how to use them and
>>> some way to prove to them when they do the wrong thing.
>> The way to add the assertion you want would be to keep a count
>> inside of the thread structure "td_nosleep", set to 0 at thread
>> creation, then you can do this:
>>
>> TD_SLEEP_NO(td);  /* td->td_nosleep++ */
>> call_some_untrusted_code();
>> TD_SLEEP_OK(td);  /* td->td_nosleep-- */
>>
>> Then add this to subr_witness.c:witness_warn():
>>
>>    if (flags & WARN_SLEEPOK && td->td_nosleep != 0) {
>>       printf("Sleeping in unsleepable context.\n");
>>       n++;   /* this variable is local to witness_warn() 
>>                 and triggers an ASSERT at the end */
>>    }
>>
>> I could have sworn we already had such a feature, but it appears
>> that it's only accessable if you're holding a lock, if you added
>> this counter, then you could catch sleeps without needing a lock
>> held.
> 
> We have this feature already for sleeping, but I think Julian isn't worried 
> about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code 
> from acquiring any other locks.  It's easy to add a MTX_LEAF, I'm just not 
> sure if we really want to micro-manage the code that much.  WITNESS will 
> already catch any LORs, and if they are acquiring a rarely-contested lock 
> then they aren't going to back up traffic in the common case.
> 

maybe what I want is to be able to label a lock as "fleeting"
By which I mean that the work that would be done while holding this 
lock would be fleeting (momentary) in nature.

An example f a fleeting lock would be something that gains the lock
in order to safely switch two pointers. no malloc is required and
nothing is going to take a long time.

locks that are NOT momentary include holding the process list lock 
while allocating a large buffer (series of them) and dumping the
contents of all processes and things like that.

one might almost say that a fleeting lock might be gotten while 
holding another fleeting lock, but that is pushing it for me..

From julian at elischer.org  Mon Jan 26 10:15:34 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jan 26 10:15:41 2009
Subject: need for another mutex type/flag?
In-Reply-To: <200901260936.18232.jhb@freebsd.org>
References: <497BA91D.805@elischer.org>
	<497D5DF8.8000706@elischer.org>	<20090126105140.GL5889@elvis.mu.org>
	<200901260936.18232.jhb@freebsd.org>
Message-ID: <497DFB61.1010602@elischer.org>

John Baldwin wrote:
> On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote:
>> * Julian Elischer <julian@elischer.org> [090125 22:53] wrote:
>>> Alfred Perlstein wrote:
>>>> Jeff, I think that Julian really wants to prevent a sleep inside
>>>> his context.  Right now, I think we only check for mutexes held
>>>> before a sleep that arne't sleepable.  It might make sense to allow
>>>> one to just mark a thread non-sleepable even though no mutex is
>>>> held.
>>>>
>>>> Julian, is that right?
>>> basically, though I don't know the details of implementation..
>>> I just know that mutexes per se aren't bad for netgraph but
>>> that node authors need some guidance on how to use them and
>>> some way to prove to them when they do the wrong thing.
>> The way to add the assertion you want would be to keep a count
>> inside of the thread structure "td_nosleep", set to 0 at thread
>> creation, then you can do this:
>>
>> TD_SLEEP_NO(td);  /* td->td_nosleep++ */
>> call_some_untrusted_code();
>> TD_SLEEP_OK(td);  /* td->td_nosleep-- */
>>
>> Then add this to subr_witness.c:witness_warn():
>>
>>    if (flags & WARN_SLEEPOK && td->td_nosleep != 0) {
>>       printf("Sleeping in unsleepable context.\n");
>>       n++;   /* this variable is local to witness_warn() 
>>                 and triggers an ASSERT at the end */
>>    }
>>
>> I could have sworn we already had such a feature, but it appears
>> that it's only accessable if you're holding a lock, if you added
>> this counter, then you could catch sleeps without needing a lock
>> held.
> 
> We have this feature already for sleeping, but I think Julian isn't worried 
> about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code 
> from acquiring any other locks.  It's easy to add a MTX_LEAF, I'm just not 
> sure if we really want to micro-manage the code that much.  WITNESS will 
> already catch any LORs, and if they are acquiring a rarely-contested lock 
> then they aren't going to back up traffic in the common case.
> 

maybe what I want is to be able to label a lock as "fleeting"
By which I mean that the work that would be done while holding this 
lock would be fleeting (momentary) in nature.

An example f a fleeting lock would be something that gains the lock
in order to safely switch two pointers. no malloc is required and
nothing is going to take a long time.

locks that are NOT momentary include holding the process list lock 
while allocating a large buffer (series of them) and dumping the
contents of all processes and things like that.

one might almost say that a fleeting lock might be gotten while 
holding another fleeting lock, but that is pushing it for me..

From alfred at freebsd.org  Mon Jan 26 12:38:24 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Mon Jan 26 12:38:31 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901260947.32870.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
Message-ID: <20090126203824.GO5889@elvis.mu.org>

There's no way to conditionally include them based on if
ISA is present?

* John Baldwin <jhb@freebsd.org> [090126 06:59] wrote:
> After the changes to make hints always reserve device names, soem folks ran 
> into issues with devices changing names due to previously unused hints now 
> always being honored (e.g. hints for non-existent ISA le(4) cards always 
> reserving le0).  What I would like to do to help minimize this further is to 
> trim the default set of hints.  The number of machines that will run 8.0 that 
> have ISA slots is incredibly small, probably zero.  To that end, I would like 
> to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
> most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
> driver uses an identify routine to always add itself.  Note that end-users 
> can always add hints back later if desired/needed.  However, changing the 
> defaults means that some hardware may no longer work out of the box.  My 
> guess though is that the set of such hardware is the empty set.
> 
> If we wanted, we could go further and assume that all machines have either 
> PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
> of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
> fdc0, ppc0, and some other devices).
> 
> Here is the proposed diff:
> 
> --- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints
> +++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints
> @@ -13,7 +13,6 @@
>  hint.atkbd.0.irq="1"
>  hint.psm.0.at="atkbdc"
>  hint.psm.0.irq="12"
> -hint.vga.0.at="isa"
>  hint.sc.0.at="isa"
>  hint.sc.0.flags="0x100"
>  hint.uart.0.at="isa"
> @@ -23,13 +22,5 @@
>  hint.uart.1.at="isa"
>  hint.uart.1.port="0x2F8"
>  hint.uart.1.irq="3"
> -hint.uart.2.at="isa"
> -hint.uart.2.disabled="1"
> -hint.uart.2.port="0x3E8"
> -hint.uart.2.irq="5"
> -hint.uart.3.at="isa"
> -hint.uart.3.disabled="1"
> -hint.uart.3.port="0x2E8"
> -hint.uart.3.irq="9"
>  hint.ppc.0.at="isa"
>  hint.ppc.0.irq="7"
> --- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints
> +++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints
> @@ -13,21 +13,12 @@
>  hint.ata.1.at="isa"
>  hint.ata.1.port="0x170"
>  hint.ata.1.irq="15"
> -hint.adv.0.at="isa"
> -hint.adv.0.disabled="1"
> -hint.bt.0.at="isa"
> -hint.bt.0.disabled="1"
> -hint.aha.0.at="isa"
> -hint.aha.0.disabled="1"
> -hint.aic.0.at="isa"
> -hint.aic.0.disabled="1"
>  hint.atkbdc.0.at="isa"
>  hint.atkbdc.0.port="0x060"
>  hint.atkbd.0.at="atkbdc"
>  hint.atkbd.0.irq="1"
>  hint.psm.0.at="atkbdc"
>  hint.psm.0.irq="12"
> -hint.vga.0.at="isa"
>  hint.sc.0.at="isa"
>  hint.sc.0.flags="0x100"
>  hint.apm.0.disabled="1"
> @@ -39,41 +30,8 @@
>  hint.uart.1.at="isa"
>  hint.uart.1.port="0x2F8"
>  hint.uart.1.irq="3"
> -hint.uart.2.at="isa"
> -hint.uart.2.disabled="1"
> -hint.uart.2.port="0x3E8"
> -hint.uart.2.irq="5"
> -hint.uart.3.at="isa"
> -hint.uart.3.disabled="1"
> -hint.uart.3.port="0x2E8"
> -hint.uart.3.irq="9"
>  hint.ppc.0.at="isa"
>  hint.ppc.0.irq="7"
> -hint.ed.0.at="isa"
> -hint.ed.0.disabled="1"
> -hint.ed.0.port="0x280"
> -hint.ed.0.irq="10"
> -hint.ed.0.maddr="0xd8000"
> -hint.cs.0.at="isa"
> -hint.cs.0.disabled="1"
> -hint.cs.0.port="0x300"
> -hint.sn.0.at="isa"
> -hint.sn.0.disabled="1"
> -hint.sn.0.port="0x300"
> -hint.sn.0.irq="10"
> -hint.ie.0.at="isa"
> -hint.ie.0.disabled="1"
> -hint.ie.0.port="0x300"
> -hint.ie.0.irq="10"
> -hint.ie.0.maddr="0xd0000"
> -hint.fe.0.at="isa"
> -hint.fe.0.disabled="1"
> -hint.fe.0.port="0x300"
> -hint.le.0.at="isa"
> -hint.le.0.disabled="1"
> -hint.le.0.port="0x280"
> -hint.le.0.irq="10"
> -hint.le.0.drq="0"
>  hint.atrtc.0.at="isa"
>  hint.atrtc.0.port="0x70"
>  hint.atrtc.0.irq="8"
> 
> 
> -- 
> John Baldwin
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-- 
- Alfred Perlstein
From jhb at freebsd.org  Mon Jan 26 13:57:26 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Jan 26 13:57:32 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090126203824.GO5889@elvis.mu.org>
References: <200901260947.32870.jhb@freebsd.org>
	<20090126203824.GO5889@elvis.mu.org>
Message-ID: <200901261640.59239.jhb@freebsd.org>

On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote:
> There's no way to conditionally include them based on if
> ISA is present?

No, but I dare you to show me a box with ISA expansion slots that you plan to 
run 8.0 on. :)  Or rather, I dare you to show me _enough_ of said boxes to 
where removing these hints from the default set will inconvenience more users 
than the folks having their ethernet come up as le1 in vmware guests. :)

-- 
John Baldwin
From alfred at freebsd.org  Mon Jan 26 14:02:42 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Mon Jan 26 14:02:49 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901261640.59239.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
	<20090126203824.GO5889@elvis.mu.org>
	<200901261640.59239.jhb@freebsd.org>
Message-ID: <20090126220229.GR5889@elvis.mu.org>

* John Baldwin <jhb@freebsd.org> [090126 13:57] wrote:
> On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote:
> > There's no way to conditionally include them based on if
> > ISA is present?
> 
> No, but I dare you to show me a box with ISA expansion slots that you plan to 
> run 8.0 on. :)  Or rather, I dare you to show me _enough_ of said boxes to 
> where removing these hints from the default set will inconvenience more users 
> than the folks having their ethernet come up as le1 in vmware guests. :)

I agree with you, I was just wondering if it was just a matter of
a few lines of code somehow so that some enthusiast who wants to play
with FreeBSD on some old piece of junk doesn't get some cryptic
error that sort of reduces them to "toggling in load.conf tunables
at the console". :)

no big deal.

-- 
- Alfred Perlstein
From jhb at freebsd.org  Mon Jan 26 14:36:57 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Jan 26 14:37:02 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090126220229.GR5889@elvis.mu.org>
References: <200901260947.32870.jhb@freebsd.org>
	<200901261640.59239.jhb@freebsd.org>
	<20090126220229.GR5889@elvis.mu.org>
Message-ID: <200901261736.32442.jhb@freebsd.org>

On Monday 26 January 2009 5:02:29 pm Alfred Perlstein wrote:
> * John Baldwin <jhb@freebsd.org> [090126 13:57] wrote:
> > On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote:
> > > There's no way to conditionally include them based on if
> > > ISA is present?
> > 
> > No, but I dare you to show me a box with ISA expansion slots that you plan 
to 
> > run 8.0 on. :)  Or rather, I dare you to show me _enough_ of said boxes to 
> > where removing these hints from the default set will inconvenience more 
users 
> > than the folks having their ethernet come up as le1 in vmware guests. :)
> 
> I agree with you, I was just wondering if it was just a matter of
> a few lines of code somehow so that some enthusiast who wants to play
> with FreeBSD on some old piece of junk doesn't get some cryptic
> error that sort of reduces them to "toggling in load.conf tunables
> at the console". :)

Heh, well, what will happen is that their device won't work until they either 
edit /boot/device.hints and reboot, or toggle in the tunables at the loader 
prompt.  :-P

-- 
John Baldwin
From rwatson at FreeBSD.org  Tue Jan 27 07:10:49 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Jan 27 07:10:56 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497C249C.5060507@elischer.org>
References: <23211.1232871523@critter.freebsd.dk>
	<497C249C.5060507@elischer.org>
Message-ID: <alpine.BSF.2.00.0901271509290.5592@fledge.watson.org>

On Sun, 25 Jan 2009, Julian Elischer wrote:

> Even purely documentary would be good but given the option, I'd like it to 
> scream when Witness is enabled and you try get another mutex....
>
> there are certain contexts (e.g. in most netgraph nodes) where we really 
> want the authors to only take such locks and taking more unpredictable 
> mutexes plays havoc with netgraph response times as a system as a whole, 
> since if one node blocks, teh thread doesn't get to go off and service other 
> nodes.

I thought lots of Netgraph nodes liked to do things like call m_pullup() and 
m_prepend()?  Disallowing acquiring mutexes will prevent them from doing that.

Robert N M Watson
Computer Laboratory
University of Cambridge
From julian at elischer.org  Tue Jan 27 10:26:31 2009
From: julian at elischer.org (Julian Elischer)
Date: Tue Jan 27 10:26:49 2009
Subject: need for another mutex type/flag?
In-Reply-To: <alpine.BSF.2.00.0901271509290.5592@fledge.watson.org>
References: <23211.1232871523@critter.freebsd.dk>	<497C249C.5060507@elischer.org>
	<alpine.BSF.2.00.0901271509290.5592@fledge.watson.org>
Message-ID: <497F51D6.1000903@elischer.org>

Robert Watson wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
>> Even purely documentary would be good but given the option, I'd like 
>> it to scream when Witness is enabled and you try get another mutex....
>>
>> there are certain contexts (e.g. in most netgraph nodes) where we 
>> really want the authors to only take such locks and taking more 
>> unpredictable mutexes plays havoc with netgraph response times as a 
>> system as a whole, since if one node blocks, teh thread doesn't get to 
>> go off and service other nodes.
> 
> I thought lots of Netgraph nodes liked to do things like call m_pullup() 
> and m_prepend()?  Disallowing acquiring mutexes will prevent them from 
> doing that.

I think I mentioned that in another mail.
The problem I see is that some module writers are tempted to
just use a mutex in their node without thinking about what the
result will be.  My understanding is that the mbuf allocation
code has been tuned to within an inch of its life to try
keep it's waits to a minimum.  I am worried about it,
but I am more worried about a netgraph node waiting on something
that is depending on some piece of hardware such as what I think
HPS had in his suggested patch for the bluetooth code..

> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

From deischen at freebsd.org  Tue Jan 27 11:46:16 2009
From: deischen at freebsd.org (Daniel Eischen)
Date: Tue Jan 27 11:46:22 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497F51D6.1000903@elischer.org>
References: <23211.1232871523@critter.freebsd.dk>
	<497C249C.5060507@elischer.org>
	<alpine.BSF.2.00.0901271509290.5592@fledge.watson.org>
	<497F51D6.1000903@elischer.org>
Message-ID: <Pine.GSO.4.64.0901271428360.5736@sea.ntplx.net>

On Tue, 27 Jan 2009, Julian Elischer wrote:

> Robert Watson wrote:
>> On Sun, 25 Jan 2009, Julian Elischer wrote:
>> 
>>> Even purely documentary would be good but given the option, I'd like it to 
>>> scream when Witness is enabled and you try get another mutex....
>>> 
>>> there are certain contexts (e.g. in most netgraph nodes) where we really 
>>> want the authors to only take such locks and taking more unpredictable 
>>> mutexes plays havoc with netgraph response times as a system as a whole, 
>>> since if one node blocks, teh thread doesn't get to go off and service 
>>> other nodes.
>> 
>> I thought lots of Netgraph nodes liked to do things like call m_pullup() 
>> and m_prepend()?  Disallowing acquiring mutexes will prevent them from 
>> doing that.
>
> I think I mentioned that in another mail.
> The problem I see is that some module writers are tempted to
> just use a mutex in their node without thinking about what the
> result will be.  My understanding is that the mbuf allocation
> code has been tuned to within an inch of its life to try
> keep it's waits to a minimum.  I am worried about it,
> but I am more worried about a netgraph node waiting on something
> that is depending on some piece of hardware such as what I think
> HPS had in his suggested patch for the bluetooth code..

I thought all you wanted to mandate that the netgraph code
itself didn't nest any mutexes.  If it doesn't hold any of
its own mutexes while calling m_prepend(), etc, then is
that still a problem?

-- 
DE
From rwatson at FreeBSD.org  Tue Jan 27 12:09:22 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Jan 27 12:09:29 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497F51D6.1000903@elischer.org>
References: <23211.1232871523@critter.freebsd.dk>
	<497C249C.5060507@elischer.org>
	<alpine.BSF.2.00.0901271509290.5592@fledge.watson.org>
	<497F51D6.1000903@elischer.org>
Message-ID: <alpine.BSF.2.00.0901272001310.51605@fledge.watson.org>


On Tue, 27 Jan 2009, Julian Elischer wrote:

> Robert Watson wrote:
>> On Sun, 25 Jan 2009, Julian Elischer wrote:
>> 
>>> Even purely documentary would be good but given the option, I'd like it to 
>>> scream when Witness is enabled and you try get another mutex....
>>> 
>>> there are certain contexts (e.g. in most netgraph nodes) where we really 
>>> want the authors to only take such locks and taking more unpredictable 
>>> mutexes plays havoc with netgraph response times as a system as a whole, 
>>> since if one node blocks, teh thread doesn't get to go off and service 
>>> other nodes.
>> 
>> I thought lots of Netgraph nodes liked to do things like call m_pullup() 
>> and m_prepend()?  Disallowing acquiring mutexes will prevent them from 
>> doing that.
>
> I think I mentioned that in another mail. The problem I see is that some 
> module writers are tempted to just use a mutex in their node without 
> thinking about what the result will be.  My understanding is that the mbuf 
> allocation code has been tuned to within an inch of its life to try keep 
> it's waits to a minimum.  I am worried about it, but I am more worried about 
> a netgraph node waiting on something that is depending on some piece of 
> hardware such as what I think HPS had in his suggested patch for the 
> bluetooth code..

Right, but what I'm saying is: if we have a MTX_LEAFNODE flag for mtx_init(9), 
it won't work for any code that holds the lock over a call to the mbuf 
routines.  I am happy with us adding a MTX_LEAFNODE flag and would use it 
myself, I just not sure it will work for Netgraph node mutexes.

The case you're talking about is generally problematic for mutexes anyway -- 
in principle we divide the world of sleeping into two categories: sleeps of 
strictly "bounded" length that generall correspond to the sleeps associated 
with mutex or rwlock acquire, and sleeps of potentially "unbounded" length, 
such as those associated with msleep(9), cv_wait(9), sx(9), lockmgr(9), etc. 
If you try to perform an unbounded sleep while holding a mutex, then WITNESS 
will already complain about sleeping while holding a lock.

The tricky case is the "may sleep" case, in which case we already have a 
WITNESS call you can do to say this code may sleep, even though it doesn't in 
the common case, so warn if this is called with a mutex held so that we can 
catch that happening".  For example, mb_reclaim does this so that any attempt 
to call it with a mutex held will throw up a red flag:

/*
  * This is the protocol drain routine.
  *
  * No locks should be held when this is called.  The drain routines have to
  * presently acquire some locks which raises the possibility of lock order
  * reversal.
  */
static void
mb_reclaim(void *junk)
{
         struct domain *dp;
         struct protosw *pr;

         WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK | WARN_PANIC, NULL,
             "mb_reclaim()");

         for (dp = domains; dp != NULL; dp = dp->dom_next)
                 for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
                         if (pr->pr_drain != NULL)
                                 (*pr->pr_drain)();
}

If there is a common or unconditional call to msleep(9) in code called by 
Netgraph with a mutex held, however, then it should already be displaying a 
warning when that happens.  If you want to simulate this effect without a lock 
necessarily be held, you can do what the softclock() code does:

                                 THREAD_NO_SLEEPING();
                                 c_func(c_arg);
                                 THREAD_SLEEPING_OK();

This causes WITNESS to complain loudly if the callout handler attempts to 
perform an unbounded sleep (i.e., msleep(), cv_wait(), etc).  Splitting the 
world into bounded an unbounded sleeps is quite useful, and is entirely about 
the sort of deadlock/cascading delay scenario you have in mind: code inside a 
mutex-protected block is essentially a critical section, and should never wait 
a long time, especially given that ithreads may acquire mutexes leading to 
potential deadlocks if msleep() is effectively waiting on an interrupt that 
will never be delivered -- if we allow ithreads to wait on msleep(), which we 
don't because of the above mechanisms.

Robert N M Watson
Computer Laboratory
University of Cambridge
From imp at bsdimp.com  Tue Jan 27 22:39:53 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue Jan 27 22:40:00 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901260947.32870.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
Message-ID: <20090127.233903.-432839944.imp@bsdimp.com>

In message: <200901260947.32870.jhb@freebsd.org>
            John Baldwin <jhb@freebsd.org> writes:
: After the changes to make hints always reserve device names, soem folks ran 
: into issues with devices changing names due to previously unused hints now 
: always being honored (e.g. hints for non-existent ISA le(4) cards always 
: reserving le0).  What I would like to do to help minimize this further is to 
: trim the default set of hints.  The number of machines that will run 8.0 that 
: have ISA slots is incredibly small, probably zero.  To that end, I would like 
: to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
: most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
: driver uses an identify routine to always add itself.  Note that end-users 
: can always add hints back later if desired/needed.  However, changing the 
: defaults means that some hardware may no longer work out of the box.  My 
: guess though is that the set of such hardware is the empty set.

Your guess likely would be incorrect.  There's still a number of
embedded machines that have pc-104 busses attached to them.  However,
the set is getting much smaller...

: If we wanted, we could go further and assume that all machines have either 
: PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
: of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
: fdc0, ppc0, and some other devices).

A pure PNPBIOS enumerated system is almost working today.  It works on
x86 most of the time.  I've run systems that had only minimal hints
for sio2 and sio3 and a couple of other minor variants.

: Here is the proposed diff:

I don't like this change.  However, you've hit on part of the reason I
don't like the change.  I don't think it goes far enough, and at the
same time loses valuable history.

To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
comments to the top that this is for systems that don't have PNPBIOS
or ACPI or that there's problems with those.

To address the former, I'd propose something more like:

hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.atkbd.0.at="atkbdc"
hint.psm.0.at="atkbdc"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.1.port="0x2F8"

Not sure that the 'sc' lines are needed, but I was too chicken to try
without them.  They used to be needed...  The above wires up
everything that isn't on the ISA bus, and gives hints that uart0
should be the one at 0x3f8, etc.

Warner

: --- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints
: +++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints
: @@ -13,7 +13,6 @@
:  hint.atkbd.0.irq="1"
:  hint.psm.0.at="atkbdc"
:  hint.psm.0.irq="12"
: -hint.vga.0.at="isa"
:  hint.sc.0.at="isa"
:  hint.sc.0.flags="0x100"
:  hint.uart.0.at="isa"
: @@ -23,13 +22,5 @@
:  hint.uart.1.at="isa"
:  hint.uart.1.port="0x2F8"
:  hint.uart.1.irq="3"
: -hint.uart.2.at="isa"
: -hint.uart.2.disabled="1"
: -hint.uart.2.port="0x3E8"
: -hint.uart.2.irq="5"
: -hint.uart.3.at="isa"
: -hint.uart.3.disabled="1"
: -hint.uart.3.port="0x2E8"
: -hint.uart.3.irq="9"
:  hint.ppc.0.at="isa"
:  hint.ppc.0.irq="7"
: --- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints
: +++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints
: @@ -13,21 +13,12 @@
:  hint.ata.1.at="isa"
:  hint.ata.1.port="0x170"
:  hint.ata.1.irq="15"
: -hint.adv.0.at="isa"
: -hint.adv.0.disabled="1"
: -hint.bt.0.at="isa"
: -hint.bt.0.disabled="1"
: -hint.aha.0.at="isa"
: -hint.aha.0.disabled="1"
: -hint.aic.0.at="isa"
: -hint.aic.0.disabled="1"
:  hint.atkbdc.0.at="isa"
:  hint.atkbdc.0.port="0x060"
:  hint.atkbd.0.at="atkbdc"
:  hint.atkbd.0.irq="1"
:  hint.psm.0.at="atkbdc"
:  hint.psm.0.irq="12"
: -hint.vga.0.at="isa"
:  hint.sc.0.at="isa"
:  hint.sc.0.flags="0x100"
:  hint.apm.0.disabled="1"
: @@ -39,41 +30,8 @@
:  hint.uart.1.at="isa"
:  hint.uart.1.port="0x2F8"
:  hint.uart.1.irq="3"
: -hint.uart.2.at="isa"
: -hint.uart.2.disabled="1"
: -hint.uart.2.port="0x3E8"
: -hint.uart.2.irq="5"
: -hint.uart.3.at="isa"
: -hint.uart.3.disabled="1"
: -hint.uart.3.port="0x2E8"
: -hint.uart.3.irq="9"
:  hint.ppc.0.at="isa"
:  hint.ppc.0.irq="7"
: -hint.ed.0.at="isa"
: -hint.ed.0.disabled="1"
: -hint.ed.0.port="0x280"
: -hint.ed.0.irq="10"
: -hint.ed.0.maddr="0xd8000"
: -hint.cs.0.at="isa"
: -hint.cs.0.disabled="1"
: -hint.cs.0.port="0x300"
: -hint.sn.0.at="isa"
: -hint.sn.0.disabled="1"
: -hint.sn.0.port="0x300"
: -hint.sn.0.irq="10"
: -hint.ie.0.at="isa"
: -hint.ie.0.disabled="1"
: -hint.ie.0.port="0x300"
: -hint.ie.0.irq="10"
: -hint.ie.0.maddr="0xd0000"
: -hint.fe.0.at="isa"
: -hint.fe.0.disabled="1"
: -hint.fe.0.port="0x300"
: -hint.le.0.at="isa"
: -hint.le.0.disabled="1"
: -hint.le.0.port="0x280"
: -hint.le.0.irq="10"
: -hint.le.0.drq="0"
:  hint.atrtc.0.at="isa"
:  hint.atrtc.0.port="0x70"
:  hint.atrtc.0.irq="8"
: 
: 
: -- 
: John Baldwin
: _______________________________________________
: freebsd-arch@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-arch
: To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
: 
From imp at bsdimp.com  Tue Jan 27 22:42:29 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue Jan 27 22:42:37 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090126203824.GO5889@elvis.mu.org>
References: <200901260947.32870.jhb@freebsd.org>
	<20090126203824.GO5889@elvis.mu.org>
Message-ID: <20090127.233943.1750429792.imp@bsdimp.com>

In message: <20090126203824.GO5889@elvis.mu.org>
            Alfred Perlstein <alfred@freebsd.org> writes:
: There's no way to conditionally include them based on if
: ISA is present?

ISA is always present.

Warner
From imp at bsdimp.com  Tue Jan 27 22:45:17 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue Jan 27 22:45:24 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090126220229.GR5889@elvis.mu.org>
References: <20090126203824.GO5889@elvis.mu.org>
	<200901261640.59239.jhb@freebsd.org>
	<20090126220229.GR5889@elvis.mu.org>
Message-ID: <20090127.234412.-1417606075.imp@bsdimp.com>

In message: <20090126220229.GR5889@elvis.mu.org>
            Alfred Perlstein <alfred@freebsd.org> writes:
: * John Baldwin <jhb@freebsd.org> [090126 13:57] wrote:
: > On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote:
: > > There's no way to conditionally include them based on if
: > > ISA is present?
: > 
: > No, but I dare you to show me a box with ISA expansion slots that you plan to 
: > run 8.0 on. :)  Or rather, I dare you to show me _enough_ of said boxes to 
: > where removing these hints from the default set will inconvenience more users 
: > than the folks having their ethernet come up as le1 in vmware guests. :)
: 
: I agree with you, I was just wondering if it was just a matter of
: a few lines of code somehow so that some enthusiast who wants to play
: with FreeBSD on some old piece of junk doesn't get some cryptic
: error that sort of reduces them to "toggling in load.conf tunables
: at the console". :)

They'll get nothing.

Warner
From phk at phk.freebsd.dk  Wed Jan 28 00:54:15 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed Jan 28 00:54:21 2009
Subject: need for another mutex type/flag? 
In-Reply-To: Your message of "Tue, 27 Jan 2009 20:09:21 GMT."
	<alpine.BSF.2.00.0901272001310.51605@fledge.watson.org> 
Message-ID: <29725.1233132852@critter.freebsd.dk>

In message <alpine.BSF.2.00.0901272001310.51605@fledge.watson.org>, Robert Wats
on writes:

>Right, but what I'm saying is: if we have a MTX_LEAFNODE flag for mtx_init(9), 
>it won't work for any code that holds the lock over a call to the mbuf 
>routines.  I am happy with us adding a MTX_LEAFNODE flag and would use it 
>myself, I just not sure it will work for Netgraph node mutexes.

100% agreement there, the kind of usage I expected for this was the
3-line protected regions that grab a reference count og stick something
onto a list etc.

Memory allocation and similar would not apply.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
From rwatson at FreeBSD.org  Wed Jan 28 01:00:33 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Jan 28 01:00:44 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497DFB61.1010602@elischer.org>
References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org>
	<20090126105140.GL5889@elvis.mu.org>
	<200901260936.18232.jhb@freebsd.org>
	<497DFB61.1010602@elischer.org>
Message-ID: <alpine.BSF.2.00.0901280858380.59876@fledge.watson.org>


On Mon, 26 Jan 2009, Julian Elischer wrote:

> maybe what I want is to be able to label a lock as "fleeting" By which I 
> mean that the work that would be done while holding this lock would be 
> fleeting (momentary) in nature.
>
> An example f a fleeting lock would be something that gains the lock in order 
> to safely switch two pointers. no malloc is required and nothing is going to 
> take a long time.
>
> locks that are NOT momentary include holding the process list lock while 
> allocating a large buffer (series of them) and dumping the contents of all 
> processes and things like that.
>
> one might almost say that a fleeting lock might be gotten while holding 
> another fleeting lock, but that is pushing it for me..

It was probably clear from my previous e-mail, but just in case it wasn't: we 
already do this.  Mutexes and rwlocks (and rmlocks for that matter) fall into 
the category you call "fleeting", which are allowed to be held over one 
another (subject to lock order), but never over "non-fleeting" locks such as 
sx and lockmgr locks.  This is comparable to the upper/lower half kernel 
concept that existed previously: one is allowed to wait for the other, but not 
vice versa; we allow ithreads to acquire mutexes and rwlocks, but not sx locks 
because that might involve waiting for themselves.

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Wed Jan 28 01:00:33 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Jan 28 01:00:44 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497DFB61.1010602@elischer.org>
References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org>
	<20090126105140.GL5889@elvis.mu.org>
	<200901260936.18232.jhb@freebsd.org>
	<497DFB61.1010602@elischer.org>
Message-ID: <alpine.BSF.2.00.0901280858380.59876@fledge.watson.org>


On Mon, 26 Jan 2009, Julian Elischer wrote:

> maybe what I want is to be able to label a lock as "fleeting" By which I 
> mean that the work that would be done while holding this lock would be 
> fleeting (momentary) in nature.
>
> An example f a fleeting lock would be something that gains the lock in order 
> to safely switch two pointers. no malloc is required and nothing is going to 
> take a long time.
>
> locks that are NOT momentary include holding the process list lock while 
> allocating a large buffer (series of them) and dumping the contents of all 
> processes and things like that.
>
> one might almost say that a fleeting lock might be gotten while holding 
> another fleeting lock, but that is pushing it for me..

It was probably clear from my previous e-mail, but just in case it wasn't: we 
already do this.  Mutexes and rwlocks (and rmlocks for that matter) fall into 
the category you call "fleeting", which are allowed to be held over one 
another (subject to lock order), but never over "non-fleeting" locks such as 
sx and lockmgr locks.  This is comparable to the upper/lower half kernel 
concept that existed previously: one is allowed to wait for the other, but not 
vice versa; we allow ithreads to acquire mutexes and rwlocks, but not sx locks 
because that might involve waiting for themselves.

Robert N M Watson
Computer Laboratory
University of Cambridge
From jhb at freebsd.org  Wed Jan 28 06:31:25 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 28 06:31:32 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090127.233903.-432839944.imp@bsdimp.com>
References: <200901260947.32870.jhb@freebsd.org>
	<20090127.233903.-432839944.imp@bsdimp.com>
Message-ID: <200901280930.50727.jhb@freebsd.org>

On Wednesday 28 January 2009 1:39:03 am M. Warner Losh wrote:
> In message: <200901260947.32870.jhb@freebsd.org>
>             John Baldwin <jhb@freebsd.org> writes:
> : After the changes to make hints always reserve device names, soem folks ran 
> : into issues with devices changing names due to previously unused hints now 
> : always being honored (e.g. hints for non-existent ISA le(4) cards always 
> : reserving le0).  What I would like to do to help minimize this further is to 
> : trim the default set of hints.  The number of machines that will run 8.0 that 
> : have ISA slots is incredibly small, probably zero.  To that end, I would like 
> : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
> : most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
> : driver uses an identify routine to always add itself.  Note that end-users 
> : can always add hints back later if desired/needed.  However, changing the 
> : defaults means that some hardware may no longer work out of the box.  My 
> : guess though is that the set of such hardware is the empty set.
> 
> Your guess likely would be incorrect.  There's still a number of
> embedded machines that have pc-104 busses attached to them.  However,
> the set is getting much smaller...

Yes, but do any of those devices have 'adv0', 'bt0', 'aha0', 'aic0', 'ed0',
'cs0', 'sn0', 'ie0', 'fe0', or 'le0' on the PC-104 bus?  If not, then the
set remains empty.  I'm not removing support for ISA devices.  I'm removing
hints for a specific set of ISA add-on cards.
 
> : If we wanted, we could go further and assume that all machines have either 
> : PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
> : of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
> : fdc0, ppc0, and some other devices).
> 
> A pure PNPBIOS enumerated system is almost working today.  It works on
> x86 most of the time.  I've run systems that had only minimal hints
> for sio2 and sio3 and a couple of other minor variants.

Yes, many of my machines also work fine with only a syscons hint.  The issue
is if we still want to support machines that have neither ACPI nor PnPBIOS
(or where someone has to disable both) out of the box.

> : Here is the proposed diff:
> 
> I don't like this change.  However, you've hit on part of the reason I
> don't like the change.  I don't think it goes far enough, and at the
> same time loses valuable history.
> 
> To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
> comments to the top that this is for systems that don't have PNPBIOS
> or ACPI or that there's problems with those.

These are already present in /sys/<arch>/conf/NOTES.  We already have all
the various historical hints already documented there.  The real issue is
what set of hints we will include in the default set to support hardware
out of the box.  The reason I have not gone further and assumed PnPBIOS
or ACPI is that it is a separate question, and I'd rather do this in stages.

> To address the former, I'd propose something more like:
> 
> hint.fd.0.at="fdc0"
> hint.fd.0.drive="0"
> hint.fd.1.at="fdc0"
> hint.fd.1.drive="1"
> hint.atkbd.0.at="atkbdc"
> hint.psm.0.at="atkbdc"
> hint.sc.0.at="isa"
> hint.sc.0.flags="0x100"
> hint.uart.0.port="0x3F8"
> hint.uart.0.flags="0x10"
> hint.uart.1.port="0x2F8"
> 
> Not sure that the 'sc' lines are needed, but I was too chicken to try
> without them.  They used to be needed...  The above wires up
> everything that isn't on the ISA bus, and gives hints that uart0
> should be the one at 0x3f8, etc.

I think the fd lines are very much not needed since fdc can enumerate floppy
drives on its own.  The rest of the hints don't actually work aside from
sc0 as hints require an 'at' hint before they wire anything.  The sc0 hints
are still required, though it would be nice to fix syscons to not need a hint
and just always add a device in an identify routine instead.

-- 
John Baldwin
From imp at bsdimp.com  Wed Jan 28 08:51:43 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 28 08:51:49 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901280930.50727.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
	<20090127.233903.-432839944.imp@bsdimp.com>
	<200901280930.50727.jhb@freebsd.org>
Message-ID: <20090128.094840.-1264100779.imp@bsdimp.com>

In message: <200901280930.50727.jhb@freebsd.org>
            John Baldwin <jhb@freebsd.org> writes:
: On Wednesday 28 January 2009 1:39:03 am M. Warner Losh wrote:
: > In message: <200901260947.32870.jhb@freebsd.org>
: >             John Baldwin <jhb@freebsd.org> writes:
: > : After the changes to make hints always reserve device names, soem folks ran 
: > : into issues with devices changing names due to previously unused hints now 
: > : always being honored (e.g. hints for non-existent ISA le(4) cards always 
: > : reserving le0).  What I would like to do to help minimize this further is to 
: > : trim the default set of hints.  The number of machines that will run 8.0 that 
: > : have ISA slots is incredibly small, probably zero.  To that end, I would like 
: > : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
: > : most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
: > : driver uses an identify routine to always add itself.  Note that end-users 
: > : can always add hints back later if desired/needed.  However, changing the 
: > : defaults means that some hardware may no longer work out of the box.  My 
: > : guess though is that the set of such hardware is the empty set.
: > 
: > Your guess likely would be incorrect.  There's still a number of
: > embedded machines that have pc-104 busses attached to them.  However,
: > the set is getting much smaller...
: 
: Yes, but do any of those devices have 'adv0', 'bt0', 'aha0', 'aic0', 'ed0',
: 'cs0', 'sn0', 'ie0', 'fe0', or 'le0' on the PC-104 bus?  If not, then the
: set remains empty.  I'm not removing support for ISA devices.  I'm removing
: hints for a specific set of ISA add-on cards.

Right, PC-104 is ISA and has the same devices.  And the cards
connected typically aren't those drivers, but can be (esp ed0 or cs0).
Many older SBCs have these wired into the isa bus w/o the need for an
external card.  These are unlikely to run 8 well, and more modern
cards with PC-104 bus have all the basics on the PCI bus.  My comment
wasn't meant as a "don't do it" but rather a note that the embedded
world significantly lags the desktop/server/laptop market.

: > : If we wanted, we could go further and assume that all machines have either 
: > : PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
: > : of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
: > : fdc0, ppc0, and some other devices).
: > 
: > A pure PNPBIOS enumerated system is almost working today.  It works on
: > x86 most of the time.  I've run systems that had only minimal hints
: > for sio2 and sio3 and a couple of other minor variants.
: 
: Yes, many of my machines also work fine with only a syscons hint.  The issue
: is if we still want to support machines that have neither ACPI nor PnPBIOS
: (or where someone has to disable both) out of the box.

We can't have it both ways easily.  I think we need to have a more
complete file that matches the drivers that are in GENERIC, even if we
don't turn them all on by default.  I'm cool with having such people
have to copy over additional files to make them work.  Such machines
are going to be very rare, since it is impossible to turn off PnPBIOS
tables in the BIOS, and it has been present since the 486 era of
machines at least (don't have any 386s to check).  PNPBIOS tends to be
used in the embedded world a lot since there's a bigger variety of
BIOSes that are present there due to cost issues...

: > : Here is the proposed diff:
: > 
: > I don't like this change.  However, you've hit on part of the reason I
: > don't like the change.  I don't think it goes far enough, and at the
: > same time loses valuable history.
: > 
: > To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
: > comments to the top that this is for systems that don't have PNPBIOS
: > or ACPI or that there's problems with those.
: 
: These are already present in /sys/<arch>/conf/NOTES.  We already have all
: the various historical hints already documented there.  The real issue is
: what set of hints we will include in the default set to support hardware
: out of the box.  The reason I have not gone further and assumed PnPBIOS
: or ACPI is that it is a separate question, and I'd rather do this in stages.

I still think it would be a good idea to have them all in an
easy-to-deploy file that people can copy to /boot/device.hints.

: > To address the former, I'd propose something more like:
: > 
: > hint.fd.0.at="fdc0"
: > hint.fd.0.drive="0"
: > hint.fd.1.at="fdc0"
: > hint.fd.1.drive="1"
: > hint.atkbd.0.at="atkbdc"
: > hint.psm.0.at="atkbdc"
: > hint.sc.0.at="isa"
: > hint.sc.0.flags="0x100"
: > hint.uart.0.port="0x3F8"
: > hint.uart.0.flags="0x10"
: > hint.uart.1.port="0x2F8"
: > 
: > Not sure that the 'sc' lines are needed, but I was too chicken to try
: > without them.  They used to be needed...  The above wires up
: > everything that isn't on the ISA bus, and gives hints that uart0
: > should be the one at 0x3f8, etc.
: 
: I think the fd lines are very much not needed since fdc can enumerate floppy
: drives on its own.  The rest of the hints don't actually work aside from
: sc0 as hints require an 'at' hint before they wire anything.  The sc0 hints
: are still required, though it would be nice to fix syscons to not need a hint
: and just always add a device in an identify routine instead.

I know that on my PNPBIOS enumerated embedded board that the fdc
driver didn't add the fd devices without those lines as recently as
6.2.  To be honest, I've not tested it recently since I haven't booted
FreeBSD on a system with a floppy in quite some time.  Code inspection
suggests that they are still needed:
	/*
	 * Probe and attach any children.  We should probably detect
	 * devices from the BIOS unless overridden.
	 */
	name = device_get_nameunit(dev);
	i = 0;
	while ((resource_find_match(&i, &dname, &dunit, "at", name)) == 0) {
		resource_int_value(dname, dunit, "drive", &dunit);
		fdc_add_child(dev, dname, dunit);
	}


We should add back in the 'at' isa lines for uart 0 and 1 to my list
then to make wiring work.

I'm neutral on the identify routine approach.  In general, we
shouldn't have that.  Instead, shouldn't sc match some PNP device and
attach to that only when the VGA hardware is actually present?  I ran
into problems on really low-end boards that had no VGA hardware, but I
can't recall the details at the moment.  Soekris boards are the most
widely available in this class, although there are others.

hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.atkbd.0.at="atkbdc"
hint.psm.0.at="atkbdc"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"

Warner
From gad at FreeBSD.org  Wed Jan 28 11:14:42 2009
From: gad at FreeBSD.org (Garance A Drosehn)
Date: Wed Jan 28 11:14:48 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090127.233903.-432839944.imp@bsdimp.com>
References: <200901260947.32870.jhb@freebsd.org>
	<20090127.233903.-432839944.imp@bsdimp.com>
Message-ID: <p06240807c5a64df6e188@[128.113.24.47]>

At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
>I don't like this change.  However, you've hit on part of the reason I
>don't like the change.  I don't think it goes far enough, and at the
>same time loses valuable history.
>
>To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
>comments to the top that this is for systems that don't have PNPBIOS
>or ACPI or that there's problems with those.

Admittedly I know almost nothing about the hints themselves, but I
like this idea.  We already supply multiple kernel files, even though
everything is documented in NOTES.  We do it because it's convenient
and it costs us nothing.

We could even install the LEGACY.hints file as /boot/legacy.hints,
and then if someone has a problem we can say  "go into the boot
loader, and type 'include /boot/legacy.hints'.  If that doesn't
solve your problem, then your problem is not related to this big
change to /boot/device.hints".  And if it *does* solve their problem,
they can just look at 'dmesg' after they boot up, and get a good idea
of what lines they need to add to /boot/device.hints.

I don't see how this would cost us much (compared to *not* having a
legacy.hints file), and yet it might make things much easier if it
turns out that too many hints had been removed.

-- 
Garance Alistair Drosehn     =               drosehn@rpi.edu
Senior Systems Programmer               or   gad@FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
From imp at bsdimp.com  Wed Jan 28 11:27:41 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 28 11:27:48 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <p06240807c5a64df6e188@[128.113.24.47]>
References: <200901260947.32870.jhb@freebsd.org>
	<20090127.233903.-432839944.imp@bsdimp.com>
	<p06240807c5a64df6e188@[128.113.24.47]>
Message-ID: <20090128.122411.1626285557.imp@bsdimp.com>

In message: <p06240807c5a64df6e188@[128.113.24.47]>
            Garance A Drosehn <gad@FreeBSD.org> writes:
: At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
: >I don't like this change.  However, you've hit on part of the reason I
: >don't like the change.  I don't think it goes far enough, and at the
: >same time loses valuable history.
: >
: >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
: >comments to the top that this is for systems that don't have PNPBIOS
: >or ACPI or that there's problems with those.
: 
: Admittedly I know almost nothing about the hints themselves, but I
: like this idea.  We already supply multiple kernel files, even though
: everything is documented in NOTES.  We do it because it's convenient
: and it costs us nothing.
: 
: We could even install the LEGACY.hints file as /boot/legacy.hints,
: and then if someone has a problem we can say  "go into the boot
: loader, and type 'include /boot/legacy.hints'.  If that doesn't
: solve your problem, then your problem is not related to this big
: change to /boot/device.hints".  And if it *does* solve their problem,
: they can just look at 'dmesg' after they boot up, and get a good idea
: of what lines they need to add to /boot/device.hints.
: 
: I don't see how this would cost us much (compared to *not* having a
: legacy.hints file), and yet it might make things much easier if it
: turns out that too many hints had been removed.

Actually, that's a very clever idea you've stumbled into.  The boot
loader already know if acpi is involved, and could trivially be
augmented to know if there's PNP data.  If neither of them are in
place, it could automatically load legacy.hints...

But the cheap 'get the file there' is a good idea.

Warner
From jhb at freebsd.org  Wed Jan 28 12:41:36 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 28 12:42:00 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090128.122411.1626285557.imp@bsdimp.com>
References: <200901260947.32870.jhb@freebsd.org>
	<p06240807c5a64df6e188@[128.113.24.47]>
	<20090128.122411.1626285557.imp@bsdimp.com>
Message-ID: <200901281540.30546.jhb@freebsd.org>

On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote:
> In message: <p06240807c5a64df6e188@[128.113.24.47]>
>             Garance A Drosehn <gad@FreeBSD.org> writes:
> : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
> : >I don't like this change.  However, you've hit on part of the reason I
> : >don't like the change.  I don't think it goes far enough, and at the
> : >same time loses valuable history.
> : >
> : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
> : >comments to the top that this is for systems that don't have PNPBIOS
> : >or ACPI or that there's problems with those.
> : 
> : Admittedly I know almost nothing about the hints themselves, but I
> : like this idea.  We already supply multiple kernel files, even though
> : everything is documented in NOTES.  We do it because it's convenient
> : and it costs us nothing.
> : 
> : We could even install the LEGACY.hints file as /boot/legacy.hints,
> : and then if someone has a problem we can say  "go into the boot
> : loader, and type 'include /boot/legacy.hints'.  If that doesn't
> : solve your problem, then your problem is not related to this big
> : change to /boot/device.hints".  And if it *does* solve their problem,
> : they can just look at 'dmesg' after they boot up, and get a good idea
> : of what lines they need to add to /boot/device.hints.
> : 
> : I don't see how this would cost us much (compared to *not* having a
> : legacy.hints file), and yet it might make things much easier if it
> : turns out that too many hints had been removed.
> 
> Actually, that's a very clever idea you've stumbled into.  The boot
> loader already know if acpi is involved, and could trivially be
> augmented to know if there's PNP data.  If neither of them are in
> place, it could automatically load legacy.hints...
> 
> But the cheap 'get the file there' is a good idea.

What I'm worried about I guess is how long we have to maintain this.  Also, 
why do we have hints for ed0 but not ex0?  That is, the current list is 
rather arbitrary and only caters to certain rare hardware and not to other 
rare hardware.  I'd rather just do a simple clean break and drop all of the 
rare hardware.  I don't really think there will be anyone who actually 
_needs_ to include /boot/legacy.hints, but we will be stuck with this very 
arbitrary file forever.

Also, none of the hints I'm proposing to remove are relevant to the 
non-PnPBIOS case.  They are all devices that the PnPBIOS would not enumerate 
anyway.

The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs.  
For the PnPBIOS case I could possibly see the case for a legacy.hints (though 
I'd rather have an x86 isa0 driver that added suitable devices explicitly if 
there was no ACPI or PnPBIOS), but the primary motivation for the recent 
changes to the hints code was to allow for the graceful coexistence of those 
hints with ACPI and PnPBIOS.  That is, it should be perfectly fine to use 
that sort of legacy.hints by default, and not require the users to manually 
load it for the non-(ACPI or PnPBIOS) case.  In that case, legacy.hints 
basically degenerates back into device.hints, which is basically what I 
proposed at the very beginning.

-- 
John Baldwin
From das at FreeBSD.ORG  Wed Jan 28 12:52:25 2009
From: das at FreeBSD.ORG (David Schultz)
Date: Wed Jan 28 12:52:32 2009
Subject: need for another mutex type/flag?
In-Reply-To: <497C2E82.6010600@elischer.org>
References: <497BA91D.805@elischer.org>
	<3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com>
	<497C235E.5090807@elischer.org> <20090124224716.X983@desktop>
	<497C2E82.6010600@elischer.org>
Message-ID: <20090128205521.GA63687@zim.MIT.EDU>

On Sun, Jan 25, 2009, Julian Elischer wrote:
> Jeff Roberson wrote:
> >What is the case you have where you can not acquire non leaf mutexes?
> >
> An example is netgraph. In netgraph you have one (or a small number) 
> thread which is processing on behalf of a number of nodes which may be
> doing work on behalf of completely different entities.
> If such a worker thread blocks then other work becomes starved..

It sounds like acquiring non-leaf mutexes here is a red herring;
the real issue is that you don't want worker threads to block for
long periods of time. Adding an arbitrary rule about mutexes
doesn't seem like the right approach: it isn't needed for
correctness, it breaks modularity (because you can only call
routines if you can guarantee that they follow the rule;
cf. Robert's comments), and it may need to be violated on
occasion. Tools like dtrace are great for tracking down
performance problems associated with lock contention, and they
don't require adding unnecessary magic to the locking API.

On a related note, one thing that might help performance is to add
a way to create dynamically-sized worker thread pools. This
doesn't help when you have high contention for the same resource
(as all the threads block on the same mutex), but it does help
when you have contention for multiple resources, and several
threads may be blocked at any given time. .NET's ThreadPool and
many commercial application servers have APIs to do things like
this, and kern/vfs_aio.c has a special-purpose thread pool to
handle blocking I/O. Note that I'm not familiar with the guts of
netgraph, so you should take this with a grain of salt and come up
with your own opinion about this idea.
From imp at bsdimp.com  Wed Jan 28 13:45:48 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 28 13:45:55 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901281540.30546.jhb@freebsd.org>
References: <p06240807c5a64df6e188@[128.113.24.47]>
	<20090128.122411.1626285557.imp@bsdimp.com>
	<200901281540.30546.jhb@freebsd.org>
Message-ID: <20090128.144307.-1398303613.imp@bsdimp.com>

In message: <200901281540.30546.jhb@freebsd.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote:
: > In message: <p06240807c5a64df6e188@[128.113.24.47]>
: >             Garance A Drosehn <gad@FreeBSD.org> writes:
: > : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
: > : >I don't like this change.  However, you've hit on part of the reason I
: > : >don't like the change.  I don't think it goes far enough, and at the
: > : >same time loses valuable history.
: > : >
: > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
: > : >comments to the top that this is for systems that don't have PNPBIOS
: > : >or ACPI or that there's problems with those.
: > : 
: > : Admittedly I know almost nothing about the hints themselves, but I
: > : like this idea.  We already supply multiple kernel files, even though
: > : everything is documented in NOTES.  We do it because it's convenient
: > : and it costs us nothing.
: > : 
: > : We could even install the LEGACY.hints file as /boot/legacy.hints,
: > : and then if someone has a problem we can say  "go into the boot
: > : loader, and type 'include /boot/legacy.hints'.  If that doesn't
: > : solve your problem, then your problem is not related to this big
: > : change to /boot/device.hints".  And if it *does* solve their problem,
: > : they can just look at 'dmesg' after they boot up, and get a good idea
: > : of what lines they need to add to /boot/device.hints.
: > : 
: > : I don't see how this would cost us much (compared to *not* having a
: > : legacy.hints file), and yet it might make things much easier if it
: > : turns out that too many hints had been removed.
: > 
: > Actually, that's a very clever idea you've stumbled into.  The boot
: > loader already know if acpi is involved, and could trivially be
: > augmented to know if there's PNP data.  If neither of them are in
: > place, it could automatically load legacy.hints...
: > 
: > But the cheap 'get the file there' is a good idea.
: 
: What I'm worried about I guess is how long we have to maintain this.

Forever.

: Also, why do we have hints for ed0 but not ex0?

ex0 has an identify routine, and ed0 doesn't.

: That is, the current list is 
: rather arbitrary and only caters to certain rare hardware and not to other 
: rare hardware.  I'd rather just do a simple clean break and drop all of the 
: rare hardware.  I don't really think there will be anyone who actually 
: _needs_ to include /boot/legacy.hints, but we will be stuck with this very 
: arbitrary file forever.

Why does it matter that we have to keep this around forever?  Why not
clean up the drivers from GENERIC then?  It seems like we're only
solving part of the problem...

: Also, none of the hints I'm proposing to remove are relevant to the 
: non-PnPBIOS case.  They are all devices that the PnPBIOS would not enumerate 
: anyway.

Not necessarily.  Many of them would be enumerated for built-in
devices (as opposed to ISA add-in cards).

: The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs.  
: For the PnPBIOS case I could possibly see the case for a legacy.hints (though 
: I'd rather have an x86 isa0 driver that added suitable devices explicitly if 
: there was no ACPI or PnPBIOS), but the primary motivation for the recent 
: changes to the hints code was to allow for the graceful coexistence of those 
: hints with ACPI and PnPBIOS.  That is, it should be perfectly fine to use 
: that sort of legacy.hints by default, and not require the users to manually 
: load it for the non-(ACPI or PnPBIOS) case.  In that case, legacy.hints 
: basically degenerates back into device.hints, which is basically what I 
: proposed at the very beginning.

The problem is that we still need to have a minimal device.hints for
things like the atkbdc and fdc, plus the hack for uart.  That's why I
suggested copying the current device.hints to legacy.hints (maybe
augmenting it to be more real) and then slashing device.hints to the
bone.

Warner
From gad at FreeBSD.org  Wed Jan 28 13:51:29 2009
From: gad at FreeBSD.org (Garance A Drosehn)
Date: Wed Jan 28 13:51:37 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901281540.30546.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
	<p06240807c5a64df6e188@[128.113.24.47]>
	<20090128.122411.1626285557.imp@bsdimp.com>
	<200901281540.30546.jhb@freebsd.org>
Message-ID: <p06240809c5a67f58748d@[128.113.24.47]>

At 3:40 PM -0500 1/28/09, John Baldwin wrote:
>On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote:
>  > In message: <p06240807c5a64df6e188@[128.113.24.47]>
>  >             Garance A Drosehn <gad@FreeBSD.org> writes:
>  > :
>>  : We could even install the LEGACY.hints file as /boot/legacy.hints,
>>  : and then if someone has a problem we can say  "go into the boot
>>  : loader, and type 'include /boot/legacy.hints'.  If that doesn't
>>  : solve your problem, then your problem is not related to this big
>>  : change to /boot/device.hints".  And if it *does* solve their problem,
>>  : they can just look at 'dmesg' after they boot up, and get a good idea
>>  : of what lines they need to add to /boot/device.hints.
>>  :
>>  : I don't see how this would cost us much (compared to *not* having a
>>  : legacy.hints file), and yet it might make things much easier if it
>>  : turns out that too many hints had been removed.
>>
>>  Actually, that's a very clever idea you've stumbled into.  The boot
>>  loader already know if acpi is involved, and could trivially be
>>  augmented to know if there's PNP data.  If neither of them are in
>>  place, it could automatically load legacy.hints...
>>
>>  But the cheap 'get the file there' is a good idea.
>
>What I'm worried about I guess is how long we have to maintain this.  Also,
>why do we have hints for ed0 but not ex0?  That is, the current list is
>rather arbitrary and only caters to certain rare hardware and not to other
>rare hardware.  I'd rather just do a simple clean break and drop all of the
>rare hardware.  I don't really think there will be anyone who actually
>_needs_ to include /boot/legacy.hints, but we will be stuck with this very
>arbitrary file forever.

I don't see why we would be stuck with it forever.  The only way the
user will *use* the file is if they explicitly type
   "include /boot/legacy.hints"
before 'boot' while in the boot loader.  Every time they boot, they
will have to go through these extra steps.  Nothing will automatically
use the file for them.

The proposal is to remove a lot of lines.  You then say "if this *does*
cause a problem, they can always type in the 5 lines of hints that they
need" -- assuming they know exactly which hints they need to type as
they reboot into 8.0-RELEASE for the first time (which is when we are
the most likely to see this hit non-developer users).  Once a non-
developer is in that situation, do you want to talk them through figuring
out which hints they need, and then having them type in those lines?
Or do you want to say:

   "Huh.  I'm not sure what your problem is, but trying typing in
    this one line to the boot loader.  If that works, then we can
    figure out what lines need to be added to your personal
    device.hints file for your specific hardware --- and you will
    never again have to type in 'include /boot/legacy.hints'".

I'm not saying we keep installing the legacy.hints file forever.  But
it might be awfully convenient to have it there for 8.0-release and
maybe 8.1-release (since we know many people won't really install
8.x-stable until 8.1-release).  After that, we simply stop installing
the file.

And if we do have this convenient file there, then we can justify
removing even more lines from default device.hints file, the one
which is always automatically sourced for all users.  A legacy.hints
file just seems to be an extremely low-cost safety measure as we make
the transition.

Btw, I do very much like the idea of making device.hints smaller.

-- 
Garance Alistair Drosehn     =               drosehn@rpi.edu
Senior Systems Programmer               or   gad@FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
From jhb at freebsd.org  Wed Jan 28 14:20:53 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 28 14:21:00 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090128.144307.-1398303613.imp@bsdimp.com>
References: <p06240807c5a64df6e188@[128.113.24.47]>
	<200901281540.30546.jhb@freebsd.org>
	<20090128.144307.-1398303613.imp@bsdimp.com>
Message-ID: <200901281720.40491.jhb@freebsd.org>

On Wednesday 28 January 2009 4:43:07 pm M. Warner Losh wrote:
> In message: <200901281540.30546.jhb@freebsd.org>
>             John Baldwin <jhb@FreeBSD.org> writes:
> : On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote:
> : > In message: <p06240807c5a64df6e188@[128.113.24.47]>
> : >             Garance A Drosehn <gad@FreeBSD.org> writes:
> : > : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
> : > : >I don't like this change.  However, you've hit on part of the reason 
I
> : > : >don't like the change.  I don't think it goes far enough, and at the
> : > : >same time loses valuable history.
> : > : >
> : > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
> : > : >comments to the top that this is for systems that don't have PNPBIOS
> : > : >or ACPI or that there's problems with those.
> : > : 
> : > : Admittedly I know almost nothing about the hints themselves, but I
> : > : like this idea.  We already supply multiple kernel files, even though
> : > : everything is documented in NOTES.  We do it because it's convenient
> : > : and it costs us nothing.
> : > : 
> : > : We could even install the LEGACY.hints file as /boot/legacy.hints,
> : > : and then if someone has a problem we can say  "go into the boot
> : > : loader, and type 'include /boot/legacy.hints'.  If that doesn't
> : > : solve your problem, then your problem is not related to this big
> : > : change to /boot/device.hints".  And if it *does* solve their problem,
> : > : they can just look at 'dmesg' after they boot up, and get a good idea
> : > : of what lines they need to add to /boot/device.hints.
> : > : 
> : > : I don't see how this would cost us much (compared to *not* having a
> : > : legacy.hints file), and yet it might make things much easier if it
> : > : turns out that too many hints had been removed.
> : > 
> : > Actually, that's a very clever idea you've stumbled into.  The boot
> : > loader already know if acpi is involved, and could trivially be
> : > augmented to know if there's PNP data.  If neither of them are in
> : > place, it could automatically load legacy.hints...
> : > 
> : > But the cheap 'get the file there' is a good idea.
> : 
> : What I'm worried about I guess is how long we have to maintain this.
> 
> Forever.

Ah, yes, that is what I'd like to avoid. :(

> : Also, why do we have hints for ed0 but not ex0?
> 
> ex0 has an identify routine, and ed0 doesn't.

fe0 doesn't have an identify routine nor hints in the default set.  We don't 
ship hints for sound blaster ISA cards by default either not all of which are 
PnP (mine wasn't).  The point being that the set of ISA adapters with hints 
in the current device.hints is an arbitrary subset.

> : That is, the current list is 
> : rather arbitrary and only caters to certain rare hardware and not to other 
> : rare hardware.  I'd rather just do a simple clean break and drop all of 
the 
> : rare hardware.  I don't really think there will be anyone who actually 
> : _needs_ to include /boot/legacy.hints, but we will be stuck with this very 
> : arbitrary file forever.
> 
> Why does it matter that we have to keep this around forever?  Why not
> clean up the drivers from GENERIC then?  It seems like we're only
> solving part of the problem...

The motivation for cleaning up hints is that our default set of hints has 
resulted in extra fallout for other folks in combination with my hint-wiring 
changes which I only committed after several people asked me to commit them.  
To that end, I am simply trying to engage in the smallest possible change 
that is also self-consistent.  Dropping all non-PnPBIOS/ACPI hints seems to 
fit that bill.

> : Also, none of the hints I'm proposing to remove are relevant to the 
> : non-PnPBIOS case.  They are all devices that the PnPBIOS would not 
enumerate 
> : anyway.
> 
> Not necessarily.  Many of them would be enumerated for built-in
> devices (as opposed to ISA add-in cards).

PNP devices are not PNPBIOS devices.  No BIOS is going to have an ed0 device 
or ie0 device in the PNPBIOS table or ACPI namespace.

> : The PnPBIOS related hints are an entirely separate ball of wax from ISA 
NICs.  
> : For the PnPBIOS case I could possibly see the case for a legacy.hints 
(though 
> : I'd rather have an x86 isa0 driver that added suitable devices explicitly 
if 
> : there was no ACPI or PnPBIOS), but the primary motivation for the recent 
> : changes to the hints code was to allow for the graceful coexistence of 
those 
> : hints with ACPI and PnPBIOS.  That is, it should be perfectly fine to use 
> : that sort of legacy.hints by default, and not require the users to 
manually 
> : load it for the non-(ACPI or PnPBIOS) case.  In that case, legacy.hints 
> : basically degenerates back into device.hints, which is basically what I 
> : proposed at the very beginning.
> 
> The problem is that we still need to have a minimal device.hints for
> things like the atkbdc and fdc, plus the hack for uart.  That's why I
> suggested copying the current device.hints to legacy.hints (maybe
> augmenting it to be more real) and then slashing device.hints to the
> bone.

These are all devices that I count as PNPBIOS devices.  I can put back the fd0 
and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS 
devices.  To me at least there is a distinction.

-- 
John Baldwin
From imp at bsdimp.com  Wed Jan 28 14:42:44 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Jan 28 14:42:52 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901281720.40491.jhb@freebsd.org>
References: <200901281540.30546.jhb@freebsd.org>
	<20090128.144307.-1398303613.imp@bsdimp.com>
	<200901281720.40491.jhb@freebsd.org>
Message-ID: <20090128.154209.1492588688.imp@bsdimp.com>

In message: <200901281720.40491.jhb@freebsd.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: fe0 doesn't have an identify routine nor hints in the default set.  We don't 
: ship hints for sound blaster ISA cards by default either not all of which are 
: PnP (mine wasn't).  The point being that the set of ISA adapters with hints 
: in the current device.hints is an arbitrary subset.

Yes.  It represents the terminal state of GENERIC when it was
converted to hints.  I still don't understand your resistance to
having a fully populated hints file hanging around as legacy.hints.
It is so utterly cheap to do that I can't believe you'd argue about
doing it.

: PNP devices are not PNPBIOS devices.  No BIOS is going to have an ed0 device 
: or ie0 device in the PNPBIOS table or ACPI namespace.

I'm sorry, but you think I'm confused when I'm not.  You are not
correct here.  There *ARE* PNPBIOS entires for ed/ne2000 devices on
some boards.  I had a board that has them on it at Timing Solutions,
and I believe I have at least two laptops that have various PNPBIOS
entries for things like ethernet controllers (ne2000) and SCSI
controllers (sym based).  These are not ADD-IN cards that enumerate
with PNP.  These are built-in devices that enumerate with PNPBIOS.

I'll keep repeating this until you understand that there are such
things.

Of course, I'm not sure it is relevant.

: These are all devices that I count as PNPBIOS devices.  I can put back the fd0 
: and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS 
: devices.  To me at least there is a distinction.

You have to put back the fd0 and fd1 devices, since they are only
enumerated for ACPI right now.  They aren't enumerated for pnpbios at
all.

So how far are we from what I posted?

# $FreeBSD$
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.atkbd.0.at="atkbdc"
hint.psm.0.at="atkbdc"
hint.vga.0.at="isa"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"

Warner
From jhb at freebsd.org  Wed Jan 28 14:59:02 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jan 28 14:59:08 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090128.154209.1492588688.imp@bsdimp.com>
References: <200901281540.30546.jhb@freebsd.org>
	<200901281720.40491.jhb@freebsd.org>
	<20090128.154209.1492588688.imp@bsdimp.com>
Message-ID: <200901281758.47741.jhb@freebsd.org>

On Wednesday 28 January 2009 5:42:09 pm M. Warner Losh wrote:
> : These are all devices that I count as PNPBIOS devices.  I can put back the 
fd0 
> : and fd1 hints, but the rest of the devices being removed are all 
non-PNPBIOS 
> : devices.  To me at least there is a distinction.
> 
> You have to put back the fd0 and fd1 devices, since they are only
> enumerated for ACPI right now.  They aren't enumerated for pnpbios at
> all.
> 
> So how far are we from what I posted?

I don't know, but I give up, do whatever you want.  I'm not going to mess with 
it anymore.

> # $FreeBSD$
> hint.fd.0.at="fdc0"
> hint.fd.0.drive="0"
> hint.fd.1.at="fdc0"
> hint.fd.1.drive="1"
> hint.atkbd.0.at="atkbdc"
> hint.psm.0.at="atkbdc"
> hint.vga.0.at="isa"

These three aren't actually needed on PnPBIOS/ACPI systems.

> hint.sc.0.at="isa"
> hint.sc.0.flags="0x100"
> hint.uart.0.at="isa"
> hint.uart.0.port="0x3F8"
> hint.uart.0.flags="0x10"
> hint.uart.1.at="isa"
> hint.uart.1.port="0x2F8"

-- 
John Baldwin
From imp at bsdimp.com  Fri Jan 30 08:33:23 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri Jan 30 08:33:30 2009
Subject: svn commit: r187132 - head/usr.bin/make
In-Reply-To: <20090130.085130.-4349483.imp@bsdimp.com>
References: <200901130653.n0D6rrNX092719@svn.freebsd.org>
	<20090130015518.GA20404@hades.panopticon>
	<20090130.085130.-4349483.imp@bsdimp.com>
Message-ID: <20090130.093052.-2022808221.imp@bsdimp.com>

OMG!  There's too much make output now, and the recent changes broke
useful make features.  All but one were eventually fixed.  I just
fixed the -s breakage.

I'm planning on committing the following, if it passes code review and
item #3 below.

First, there was absolutely no reason to introduce -Q.  -v is
otherwise unused and matches the 'opt-in' debugging that's present in
the rest of make and the build system and other utilities like cp and
mv which will tell you what they are doing only if asked.

Second, the extra always on debug introduces a performance penalty.
Usually, one has to have good justification for doing this.

Third, I'd like to collect votes on this.  Do you like the new
debugging, or would you rather see it just when asked.  I'll let the
majority rule as to whether to commit this patch.  Please let me know
privately.  I'll tally the results and commit based on it.

Finally, if there's any real, persuasive argument that should override
the vote, I'd like to hear it.

Thank you for your time.

Warner


Index: job.c
===================================================================
--- job.c	(revision 187843)
+++ job.c	(working copy)
@@ -2362,7 +2362,7 @@
 	makeErrors = 0;
 
 	lastNode = NULL;
-	if ((maxJobs == 1 && fifoFd < 0) || is_posix || beQuiet) {
+	if ((maxJobs == 1 && fifoFd < 0) || is_posix || !beVerbose) {
 		/*
 		 * If only one job can run at a time, there's no need for a
 		 * banner, no is there?
Index: main.c
===================================================================
--- main.c	(revision 187921)
+++ main.c	(working copy)
@@ -126,7 +126,6 @@
 Boolean		mfAutoDeps;	/* .MAKEFILEDEPS target seen */
 Boolean		beSilent;	/* -s flag */
 Boolean		beVerbose;	/* -v flag */
-Boolean		beQuiet;	/* -Q flag */
 Boolean		compatMake;	/* -B argument */
 int		debug;		/* -d flag */
 Boolean		ignoreErrors;	/* -i flag */
@@ -517,11 +516,6 @@
 			printGraphOnly = TRUE;
 			debug |= DEBUG_GRAPH1;
 			break;
-		case 'Q':
-			beQuiet = TRUE;
-			beVerbose = FALSE;
-			MFLAGS_append("-Q", NULL);
-			break;
 		case 'q':
 			queryFlag = TRUE;
 			/* Kind of nonsensical, wot? */
@@ -532,7 +526,7 @@
 			MFLAGS_append("-r", NULL);
 			break;
 		case 's':
-			beQuiet = TRUE;
+			beVerbose = FALSE;
 			beSilent = TRUE;
 			MFLAGS_append("-s", NULL);
 			break;
@@ -542,7 +536,6 @@
 			break;
 		case 'v':
 			beVerbose = TRUE;
-			beQuiet = FALSE;
 			MFLAGS_append("-v", NULL);
 			break;
 		case 'x':
Index: globals.h
===================================================================
--- globals.h	(revision 187843)
+++ globals.h	(working copy)
@@ -76,7 +76,6 @@
 extern Boolean	ignoreErrors;	/* True if should ignore all errors */
 extern Boolean	beSilent;	/* True if should print no commands */
 extern Boolean	beVerbose;	/* True if should print extra cruft */
-extern Boolean	beQuiet;	/* True if want quiet headers with -j */
 extern Boolean	noExecute;	/* True if should execute nothing */
 extern Boolean	allPrecious;	/* True if every target is precious */
 extern Boolean	is_posix;	/* .POSIX target seen */
From obrien at freebsd.org  Sat Jan 31 02:10:13 2009
From: obrien at freebsd.org (David O'Brien)
Date: Sat Jan 31 02:10:31 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <200901260947.32870.jhb@freebsd.org>
References: <200901260947.32870.jhb@freebsd.org>
Message-ID: <20090131093130.GA17896@dragon.NUXI.org>

On Mon, Jan 26, 2009 at 09:47:32AM -0500, John Baldwin wrote:
> After the changes to make hints always reserve device names, soem folks ran 
> into issues with devices changing names due to previously unused hints now 
> always being honored (e.g. hints for non-existent ISA le(4) cards always 
> reserving le0).  What I would like to do to help minimize this further is to 
> trim the default set of hints.  The number of machines that will run 8.0 that 
> have ISA slots is incredibly small, probably zero.

For AMD64 machines its definitely zero.

> To that end, I would like 
> to remove all hints for ISA adapters from i386 and amd64 (amd64 already
> has most of them removed).
..
> If we wanted, we could go further and assume that all machines have
> either PnPBIOS or ACPI and remove most of the other hints as well.

At least for amd64, I'd like to see all the hints removed.  We should
make these assumptions.

For i386 you're getting some resistance, but I don't see any reason to
not do this for amd64.

-- 
-- David  (obrien@FreeBSD.org)
From imp at bsdimp.com  Sat Jan 31 20:27:23 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat Jan 31 20:27:30 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090131093130.GA17896@dragon.NUXI.org>
References: <200901260947.32870.jhb@freebsd.org>
	<20090131093130.GA17896@dragon.NUXI.org>
Message-ID: <20090131.212608.-1522433384.imp@bsdimp.com>

In message: <20090131093130.GA17896@dragon.NUXI.org>
            "David O'Brien" <obrien@freebsd.org> writes:
: At least for amd64, I'd like to see all the hints removed.  We should
: make these assumptions.

We can't remove all hints, unless we require ACPI.  The floppy drives
don't enumerate properly without hints in the PNPBIOS case.  I don't
know if the floppies enumerate correctly for ACPI, but the code that's
there seems to assume that enumerating via _FDE might fail sometimes
and the fallback method is hints.  This suggests that keeping the fd
hints is a good thing.

We also want hints to wire down uart0 and uart1 to their traditional
COM1 and COM2 places.  At least that's been an oft-reported bug when
we don't.

My current 'hints' file is thus:

hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"

I'm too chicken to remove the hint.sc.0 hints, but maybe they can go.

As for the i386 stuff, John and I realized we were being too grumpy,
stopped grumping and worked it out later.  Apart from some really
minor tweaks, I believe John is going to go ahead and commit basically
what he proposed.  While one can run the above hints on x86 as well,
we're not going to push things that far just yet.  Maybe with 9 that
will be the default and we'll have a 'LEGACY' kernel with all the
gunk...  or maybe we'll just let it die...  For now, we'll keep the
extra stuff I suggested removing since it means we can still have one
kernel that boots the basics on non-enumerated systems.

Warner
From obrien at FreeBSD.org  Sat Jan 31 20:44:10 2009
From: obrien at FreeBSD.org (David O'Brien)
Date: Sat Jan 31 20:44:15 2009
Subject: Trimming the default /boot/device.hints
In-Reply-To: <20090131.212608.-1522433384.imp@bsdimp.com>
References: <200901260947.32870.jhb@freebsd.org>
	<20090131093130.GA17896@dragon.NUXI.org>
	<20090131.212608.-1522433384.imp@bsdimp.com>
Message-ID: <20090201044402.GA95647@dragon.NUXI.org>

On Sat, Jan 31, 2009 at 09:26:08PM -0700, M. Warner Losh wrote:
> In message: <20090131093130.GA17896@dragon.NUXI.org>
>             "David O'Brien" <obrien@freebsd.org> writes:
> : At least for amd64, I'd like to see all the hints removed.  We should
> : make these assumptions.
> 
> We can't remove all hints, unless we require ACPI.

For the most part we do for amd64.  Is there reason not to?

> The floppy drives
> don't enumerate properly without hints in the PNPBIOS case.  I don't
> know if the floppies enumerate correctly for ACPI, but the code that's
> there seems to assume that enumerating via _FDE might fail sometimes
> and the fallback method is hints.  This suggests that keeping the fd
> hints is a good thing.
> 
> We also want hints to wire down uart0 and uart1 to their traditional
> COM1 and COM2 places.  At least that's been an oft-reported bug when
> we don't.
> 
> My current 'hints' file is thus:
> hint.fd.0.at="fdc0"
> hint.fd.0.drive="0"
> hint.fd.1.at="fdc0"
> hint.fd.1.drive="1"
> hint.sc.0.at="isa"
> hint.sc.0.flags="0x100"
> hint.uart.0.at="isa"
> hint.uart.0.port="0x3F8"
> hint.uart.0.flags="0x10"
> hint.uart.1.at="isa"
> hint.uart.1.port="0x2F8"

That would be a great compromise hints file for amd64 given you are
right - I have seen a few motherboards have issues with which com
port is at which addresses.  

-- 
-- David  (obrien@FreeBSD.org)