Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/11/13 12:03 PM, Richard Yao wrote: Is there any possibility that these quirks could be added to the upcoming 9.2 release? I think so but we need to act fast. Pools composed of affected disks will suffer from performance issues until they are reformatted with the correct block size. In addition, a certain benchmarking site, whose benchmarks are often fodder for trolls, uses the Intel X25-M in its benchmarks. Adding the quirk to 9.2 would eliminate an unfair handicap on FreeBSD from their next set of benchmarks. Actually I'm not 100% sure here: the current FreeBSD ZFS code does not handle stripesize at all, and thus if you create a pool with the patch, they will still be ashift=9. Justin (gibbs@) have a patchset to address this by the way, but since it's not yet in HEAD I wouldn't expect it be incorporated in 9.2... Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJSCwOnAAoJEG80Jeu8UPuz4o8H/3D58PVp5lBJ9wpQ/+4YSDAF LdzbhSg5FoRLLgEFKd6q4sbkZglBR5lImWcL/zhGa1KHiq3G6iCstjhfJDQzLnsd tNYnZ9tBCd4AeD/TIFvuLpOJckeXL1TPBSDjXj0xt9rcMCviULma7cr95cswISMD ahK1Io6mVbiGQrCgRmHrUBhnuZfou5nOxPi45l0Lfqq32iJFfgHfmDiCr0mCKkuU sufMeRWS/tjMkl8sVZxP7qncGxbhzVueQeQQ6eJkyv5EQCES6QMZM8xFXfeI//Z4 bDzD37rvt/HRlhPpex0UcpmbYY9dGJJrOALEAPfexMcc++gvLCmYqNfj0ypDj90= =JfHW -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Make ZFS use the physical sector size when computing initial ashift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/13 02:02, Dag-Erling Smrgrav wrote: The attached patch causes ZFS to base the minimum transfer size for a new vdev on the GEOM provider's stripesize (physical sector size) rather than sectorsize (logical sector size), provided that stripesize is a power of two larger than sectorsize and smaller than or equal to VDEV_PAD_SIZE. This should eliminate the need for ivoras@'s gnop trick when creating ZFS pools on Advanced Format drives. I think there are multiple versions of this (I also have one[1]) but the concern is that if one creates a pool with ashift=9, and now ashift=12, the pool gets unimportable. So there need a way to disable this behavior. Another thing (not really related to the automatic detection) is that we need a way to manually override this setting from command line when creating the pool, this is under active discussion at Illumos mailing list right now. [1] https://github.com/trueos/trueos/commit/3d2e3a38faad8df4acf442b055c5e98ab873fb26 Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJR3ZgAAAoJEG80Jeu8UPuzM6kIALu3Ud4uu+kdcsp+zNS54iw6 Etx2xWOjbHhJ1PZ0BKJ4R5/BOfpW4b1DrarPtpZLxoyg55GwlEVCH8Cia9ucznfP KgFGwzztQlsiI5hcWD6RVNkAx/2o7sSynbprxxP1UdEdmH7f5MWVpNwjGE2KiIpA 0TxfTu8Sg0/QB7h3pGWt5sJSuwyogewvHIfTAgHEqnQdYPXxpadH7PS7shSJVdim z2C9GoyLVQ6BMxXzQDcmA+fllgMZVKXROG7SxDFNDTWPnZ9HMZp2OJKELLtuZB1y Iaq/gd3uPR2ZzPxw2OjdYKe7khWtmuU5Ox6+natsOKCqfoAfCjArA8zJZYsZoMI= =Nd1V -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Make ZFS use the physical sector size when computing initial ashift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/13 10:38, Justin T. Gibbs wrote: [snip] I'm sure lots of folks have some solution to this. Here is an old version of what we use at Spectra: http://people.freebsd.org/~gibbs/zfs_patches/zfs_auto_ashift.diff The above patch is missing some cleanup that was motivated by my discussions with George Wilson about this change in April. I'll dig that up later tonight. Even if you don't read the full diff, please read the included checkin comment since it explains the motivation behind this particular solution. This is on my list of things to upstream in the next week or so after I add logic to the userspace tools to report whether or not the TLVs in a pool are using an optimal allocation size. This is only possible if you actually make ZFS fully aware of logical, physical, and the configured allocation size. All of the other patches I've seen just treat physical as logical. Yes, me too. Your version is superior. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJR3aQzAAoJEG80Jeu8UPuzHn8H/1ZpoTqAQ4+mgQOttOwXgBcr 2Fgh52ztW8fCEQSeIosxXKO06hP7HxFfTPvmeeWyjT8zIpSUSFV6G0NclebKDncP huGFofvx3BKPRmfzZp4iZx1wWQUxSHTmv6ceDwvP7P8GJ0mON+SrZxmmwUjKrf7V W9Sazl0p8e0nxSQykLyjjrkaBx5Iv+aUxu8Alomwy9BmpM8+gd2yutvzghW5L36L 0CvAtIMXdlc+eUdAqa/2rOk/nMOA9sfWVW0gkKYCZk6wvj2DMzjii05UechZ4Z+l 6nEU3UdVsbTX73CABZv4my4JAWc5Yk1s/cWrxtn68AfK8LMPFJCJcVXXOSckMWI= =351W -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Importing tradcpp (traditional (KR-style) C macro preprocessor) into base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/13 15:11, Baptiste Daroussin wrote: Hi, I have been working in importing tradcpp (developped by David A. Holland from NetBSD) into the ports tree, it is a traditional (KR-style) C macro preprocessor BSD licensed. I first worked on it so that imake can work properly without gcc. I discovered that some part of the base system still needs a traditional preprocessor, like (calendar), what I propose it to import tradcpp into the base system (not the version in port right now but what will become version 0.2). It mostly behave like gcpp, and I'm able to properly use calendar along with tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff Any objections against me importing it? Looking at the manual page, it looks like that the only reason is to support #include's? I think it would be better to just fix it than importing a new (old) preprocessor... Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRt6ZKAAoJEG80Jeu8UPuzrX4IAJj1hg/+Vh8oGuc2vVeuAU0W 6brYFkZFlgIicyC2k6BFuVU6jTyn3KelFyMxVgzk2S/5fI6lHh6YCHB/XRCDEzHg GG1TELsFKOgAUsA1xp/uDIKTJKqR2Wef2J3oaCl2L5FL0z/cySopPMLOcd08MiCA wOgr3qcPAfaxROOQJaZTs6lbUOs1zKB7RrtuCaYUB5fEwJ4uZwyKmkZtqEAK7WGT 8gDA78nfKxOLHE4XOBE1McO3sFrCQQoj+uAKS0tbRt4+qAD8rRq4T8H5BEk+eNqF NSPjFRKFrTXKSTnK4U+MBOcw7DhlOcabAz9Lpl6nD5hOzz2mUk4YG3pH/jY9zhg= =dsBw -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Importing tradcpp (traditional (KR-style) C macro preprocessor) into base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/13 15:50, Eitan Adler wrote: [...] - limited subset in the man page does not explain what limit. - It doesn't seem to support #ifdef at all Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I don't think there is valid usage for ifdef). Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRt6vsAAoJEG80Jeu8UPuz/EkH/jY8jLItQ6ESfeujLw+72mQ3 Hmitiotg7UHj4ltUs1gazrc5/OGqxZaIOSiAM4aeNa1QDh4WVKaRgFrNg1R1QQCX VLZAzDa9lmSCL9P2RIy7zLgsmY8WsPNKzS051mOEpVDTB56MmXedmllZF//qMaXa S6oMi+nXZXcOlmhyAKRc8J3SAdT40OQDniX2MasE5KnjNL0wE7sZgVK2i4mkT7Tp KTOg0zu0Ezv7kxny/Kbh3curllKyKb+9ca5C4rfmcK41M4GXhQRMqrm3of1uS+3Z 8mSb57cqK3xBJO2JATt46chUlXfT2lxG8/ByiJs8zziT2+G++jEFGTnyzH5DTKY= =vL2S -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: potential future proofing fix for aicasm build.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/02/13 00:19, Dimitry Andric wrote:
On May 1, 2013, at 18:44, Alfred Perlstein alf...@ixsystems.com
wrote:
I took a shot at fixing this issue with building aicasm as part
of buildkernel of an older 9.0 src on a machine running HEAD.
aicasm.o: In function `__getCurrentRuneLocale':
/usr/include/runetype.h:96: undefined reference to
`_ThreadRuneLocale'
I don't understand this error message... It seems like a linker
error, but it also seems to refer to an incorrect include file? Is
this during linking or compiling?
This is because the locale code being a macro:
#if defined(__NO_TLS) || defined(__RUNETYPE_INTERNAL)
extern const _RuneLocale *__getCurrentRuneLocale(void);
#else
extern _Thread_local const _RuneLocale *_ThreadRuneLocale;
static __inline const _RuneLocale *__getCurrentRuneLocale(void)
{
if (_ThreadRuneLocale)
return _ThreadRuneLocale;
if (_CurrentRuneLocale)
return _CurrentRuneLocale;
return _DefaultRuneLocale;
}
#endif /* __NO_TLS || __RUNETYPE_INTERNAL */
What really puzzles me is that why the build picks up headers from the
running system.
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJRgqkDAAoJEG80Jeu8UPuzwvUH/2M+HDzKA9neXXYb6SKzrNX2
DVqw66ygatDj6QqwmMvZvU4+kGLNR6KEOQGNF4f0mMJmfg+GLzDFE5s769J/Be+1
4WMr1luWwgwrYlYhMrA8/CXYUWI2O9mhNfhLQHD8z3lJ6yxJgPy3h9J3jwzmU/W8
p58Dp8raABgKcK9DKE47QSXiiEXHuJUdSJXBPCoEFg09s+PnhrduQ1Vd9vfK9As0
G1HUmn+S/LWxRCB2wzZAC3FjZQHblXEvmfZzxCqUZr5AP3jtlHTHDUtJTCxxclgg
sGLmdvqnn6/3BBXIhcxXVka3CKzbuCyIeGCBhTsSbLnuKB+FXbid9ibSrIlFA2s=
=vdoK
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: copyinstr()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/8/13 6:15 PM, Vijay Singh wrote: Hi, I was looking for some help with copyinstr() on an amd64 platform. My from address happens to be in the kernel (stack). I am getting an EFAULT, and I am wondering how to fix that. Since you are doing a copy*in*str, I think from address would be the uaddr? In that case, it should be a userland address... Would using memory from malloc() make a difference? Maybe not... EFAULT means the address is not valid. Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJRY7LMAAoJEG80Jeu8UPuzXRcH+gOoKAIelHbF2tp78HHgp0+b zuRF+Cj8mBOxJEyS3zpKEVKdq8HgYEJRq39Tkp2c60xwYOUcU0HRU6ixTJ0whZFo Gbx7tBbp4+89TtkPVm/u/JlqeToQNuQSFJBxNGi1qOjPpJQfuClPQ9EI4N4LDesh g8B7D5N4YoIUhLkg2FEix7c3XrzTeDRCfXYsfHna4f3VMrlNze0R61TpRqh6qx8/ eJDBA25m6+Y6129qo8wdkOZWLT6ZSIPrc6WgQuCP3jTYJemhiM1RdTFLqM87PNBd EGuL1+FGgDUzhieJoOx/FhD01Cypc7/Qs6pxaF1BGxpCaL0SPFyBJ+WBnv9A7DA= =iMeL -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/21/13 10:53, Mark Saad wrote: All So Xin's patch works so far I see no unexpected issues; can I get a MFC ? Also on a unrelated MFC request would someone be willing to merge stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly applied and I saw no issues. Thanks for confirming, I'll MFC the changes asap. On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd adr...@freebsd.org wrote: On 20 February 2013 12:01, Mark Saad nones...@longcount.org wrote: Xin I am rebuilding now, I'll let you know how it works. As I've said before, if someone wants to take ownership of 6.x and backport changes / push them into STABLE_6, be my guest. Yahoo was doing that for some unsupported old releases for a while. They'd still stay unsupported.. well, as long as there's not a big group of 6.x users standing up and taking ownership. (Same can be said of what's going to happen to 7.x soon.) Adrian - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRJoHmAAoJEG80Jeu8UPuzxhoIALGAOjkBM5zSiHrvY8QNos+9 CgGOA4TVldVl6uru3ZmJhxXmHuiBc5RGnnY8tJ8wzh9QfBhIRmcj7uEhBPj29P+Y WkaUkyvCfNc1Eg2tLV+RkQWR6mWvJs1thSZ/sOllAEMrvPvniFJrlzE3marGHXvK D6zHtKRc2LORiwa0MkuUa49HjZyTspgEfz73VRwXur8ERdJqjCGZLFOOmgIyQ+rW 3bRXry0MnUN/hHnrs0jAN2OB69gEhpQb/rJnYT4WeR0tAzPxvVLgTzkf6LILmBw9 BIXOCIwWMPZJTKTsSc/2R09rK3Cur2ZhIpUDw2gNqiSZXBFyEmQDqWp5V4wd4M4= =WSgz -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SA-13:02/libc and FreeBSD 6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/20/13 09:29, Mark Saad wrote:
All I was wondering if anyone knows, off hand if SA-13:02/libc
applies to FreeBSD 6-STABLE and if it would be committed to the
6-STABLE branch ?
The patch itself won't apply, there were many changes after the last
6-STABLE branch.
Here is a patch backported for stable/6 but I do not have time to set
up a testing environment for it, if you do, please let me know if the
patch worked or not, thanks!
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR
lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid
/X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y
GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh
WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv
8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8=
=m/h0
-END PGP SIGNATURE-
diff --git a/lib/libc/gen/glob.c b/lib/libc/gen/glob.c
index 8e5ee69..5549311 100644
--- a/lib/libc/gen/glob.c
+++ b/lib/libc/gen/glob.c
@@ -93,6 +93,25 @@ __FBSDID($FreeBSD$);
#include collate.h
+/*
+ * glob(3) expansion limits. Stop the expansion if any of these limits
+ * is reached. This caps the runtime in the face of DoS attacks. See
+ * also CVE-2010-2632
+ */
+#defineGLOB_LIMIT_BRACE128 /* number of brace calls */
+#defineGLOB_LIMIT_PATH 65536 /* number of path elements */
+#defineGLOB_LIMIT_READDIR 16384 /* number of readdirs */
+#defineGLOB_LIMIT_STAT 1024/* number of stat system calls
*/
+#defineGLOB_LIMIT_STRING ARG_MAX /* maximum total size for paths
*/
+
+struct glob_limit {
+ size_t l_brace_cnt;
+ size_t l_path_lim;
+ size_t l_readdir_cnt;
+ size_t l_stat_cnt;
+ size_t l_string_cnt;
+};
+
#defineDOLLAR '$'
#defineDOT '.'
#defineEOS '\0'
@@ -144,7 +163,7 @@ typedef char Char;
static int compare(const void *, const void *);
-static int g_Ctoc(const Char *, char *, u_int);
+static int g_Ctoc(const Char *, char *, size_t);
static int g_lstat(Char *, struct stat *, glob_t *);
static DIR *g_opendir(Char *, glob_t *);
static Char*g_strchr(Char *, wchar_t);
@@ -152,34 +171,34 @@ static Char *g_strchr(Char *, wchar_t);
static Char*g_strcat(Char *, const Char *);
#endif
static int g_stat(Char *, struct stat *, glob_t *);
-static int glob0(const Char *, glob_t *, int *);
-static int glob1(Char *, glob_t *, int *);
-static int glob2(Char *, Char *, Char *, Char *, glob_t *, int *);
-static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *, int *);
-static int globextend(const Char *, glob_t *, int *);
-static const Char *
+static int glob0(const Char *, glob_t *, struct glob_limit *);
+static int glob1(Char *, glob_t *, struct glob_limit *);
+static int glob2(Char *, Char *, Char *, Char *, glob_t *,
+struct glob_limit *);
+static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *,
+struct glob_limit *);
+static int globextend(const Char *, glob_t *, struct glob_limit *);
+static const Char *
globtilde(const Char *, Char *, size_t, glob_t *);
-static int globexp1(const Char *, glob_t *, int *);
-static int globexp2(const Char *, const Char *, glob_t *, int *, int *);
+static int globexp1(const Char *, glob_t *, struct glob_limit *);
+static int globexp2(const Char *, const Char *, glob_t *, int *,
+struct glob_limit *);
static int match(Char *, Char *, Char *);
#ifdef DEBUG
static void qprintf(const char *, Char *);
#endif
int
-glob(pattern, flags, errfunc, pglob)
- const char *pattern;
- int flags, (*errfunc)(const char *, int);
- glob_t *pglob;
+glob(const char *pattern, int flags, int (*errfunc)(const char *, int), glob_t
*pglob)
{
- const u_char *patnext;
- int limit;
+ struct glob_limit limit = { 0, 0, 0, 0, 0 };
+ const char *patnext;
Char *bufnext, *bufend, patbuf[MAXPATHLEN], prot;
mbstate_t mbs;
wchar_t wc;
size_t clen;
- patnext = (u_char *) pattern;
+ patnext = pattern;
if (!(flags GLOB_APPEND)) {
pglob-gl_pathc = 0;
pglob-gl_pathv = NULL;
@@ -187,11 +206,10 @@ glob(pattern, flags, errfunc, pglob)
pglob-gl_offs = 0;
}
if (flags GLOB_LIMIT) {
- limit = pglob-gl_matchc;
- if (limit == 0)
- limit = ARG_MAX;
- } else
- limit = 0;
+ limit.l_path_lim = pglob-gl_matchc;
+ if (limit.l_path_lim == 0
Re: Chicken and egg, encrypted root FS on remote server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/19/13 10:58 PM, Paul Schenkeveld wrote:
Ideally I'd like the server to start, do minimal network config,
run a minimal ssh client (dropbear?) and wait for someone to log
in, provide the passphrase to unlock the root filesystem and then
mount the root filesystem and do a normal startup.
At work I have something like this, basically the setup have a small /
that is not encrypted, and I have a script called 'geli0' that starts
network, sshd and waits for the GELI provider be unlocked or someone
hit enter on console (and then unlock from console, of course).
I'm not sure if this is even near your requirement nor it's intended
for use by general public. Be sure to change ada0s1d to match your
system by the way.
#!/bin/sh
#
# PROVIDE: geli0
# BEFORE: disks
# REQUIRE: initrandom
# KEYWORD: nojail
. /etc/rc.subr
name=geli0
start_cmd=geli0_start
stop_cmd=:
required_modules=geom_eli:g_eli
geli0_start()
{
fsck -py / || fsck -fy /
mount -uw /
/etc/rc.d/hostid start
/etc/rc.d/hostname start
/etc/rc.d/devd start
/etc/rc.d/netif start
/etc/rc.d/routing start
/etc/rc.d/sshd start
echo -n Waiting ada0s1d to be available, press enter to
continue...
while true; do
if [ -e /dev/ada0s1d.eli ]; then
break
fi
read -t 5 dummy break
done
/etc/rc.d/sshd stop
/etc/rc.d/routing stop
/etc/rc.d/netif stop
/etc/rc.d/devd stop
}
load_rc_config $name
run_rc_command $1
=
Cheers,
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJRJHk2AAoJEG80Jeu8UPuz1mgH/Rjsk0NgHn6r/mNB+G00OizR
BOprd4wuctvNn/zr/syjM/UqixWI1WIXBDQAICZWTml938i5Mg65bi+qdszmRwbS
zzlSRUJ/N6oYQvUPnuCxjtIU3gvCKplt0bBz/RxRVNSzqMEgOTuta9Kd0IVU2MZW
zVZ0rmClScTA2zgGGFmQCZc1ot5CZfa66psSkdQIwLOvxp2o1ZHzMh5+owG8R0ys
8DE+aQ4d57Vt/JoRQW2W1OIfestOmf1uqL7HsnELL1nF0BTtG8GThfy+RzGAA3mm
vUKXFwiLwon+gJath2eIT2s/tCz5rKPisiXeBqAYUSWUNTqTWf2CXmfMXeL4+TM=
=gcTR
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fixing grep -D skip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/18/13 08:39, John Baldwin wrote: I (disclaimer: not bsdgrep person) have just tested that bsdgrep handle this case just fine. The non-blocking part is required to make the code function, otherwise the system will block on open() if fifo don't have another opener. I'd say Yes for this p Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQ+eW5AAoJEG80Jeu8UPuzB3IH/RmhJionoEWRtczBy2ccA8sl XG1OIvSR60vWNFAGooOF2I66J8xF0/+f/4xDwN3C56kIweN3XgvxSmOCCM3aUab3 eaAdOIoWAkNb3r4iMxFCJNo6YKuiLTiw8vEdcqjXsqrHzzAMtk81jqSpw0ZkVJM2 upPWF9EItlyKDSOfLCVZiL9qxUxppV+xTpVpMd1F/ud7cQMBaAiU2/pyOgcZDLet GVp4dninbxn3+YN7DU/yvjBnhWWVCrHfbOl5C6zNgrfzfLDyxrP+G67DHCFF9VnU 1l31FOXdd6ThChxfiH3F6QZ7KL0ncDd1pH+qvaoQo7KZBq6jEoiwplaq6qKP4xk= =zQj9 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fixing grep -D skip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/18/13 08:39, John Baldwin wrote: On Thursday, January 17, 2013 9:33:53 pm David Xu wrote: I am trying to fix a bug in GNU grep, the bug is if you want to skip FIFO file, it will not work, for example: grep -D skip aaa . it will be stucked on a FIFO file. Here is the patch: http://people.freebsd.org/~davidxu/patch/grep.c.diff2 Is it fine to be committed ? I think the first part definitely looks fine. My guess is the non-blocking change is als probably fine, but that should be run by the bsdgrep person at least. I (disclaimer: not bsdgrep person) have just tested that bsdgrep handle this case just fine. The non-blocking part is required to make the code function, otherwise the system will block on open() if fifo don't have another opener. I'd say Yes for this p Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die a -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQ+eW5AAoJEG80Jeu8UPuzaPkH/RPnvBg5pDPxmbSXWF3T22s3 XTPNfDns416g6dqig+E+YOhamu+Pz8xFC6JCu3DzPbNcb+OGRh14LBFeZQ6xn648 yxn1j0Y2ZsmjoppMAWg+wuwLtOYX0pK69zZzOxQMepBeA/rkA26hJA/3j6VTPu/X hLFP+bRy+wt8Ni39PuSrBywuPmwg82de+Fuf8WVVVwXgXHnK+yc/Pb1JWgiU6kzz r1tyCAh2rXcM4mg++LUoeYZZhrLuxWKKPrXkzGSbz7NSPXJccwf5rx/ZPB2EysVv Z/CA6wS2jqsOUbyelM01jtvrY6Q6llLIIEc3aGPcjYZbqy/B0VLwyGnR+rElKBo= =M7oI -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kgzip(1) is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/15/13 13:27, dte...@freebsd.org wrote: Hello, I have been sad of-late because kgzip(1) no longer produces a usable kernel. All versions of 9.x suffer this. And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. I think this is i386 only? Also, are you trying to avoid loader(8)? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQ9dYOAAoJEG80Jeu8UPuzPwoH/RRR+SATnzoH/tXz1o+qvg/4 9i5EnGp0lcwhQWHaCvC9vmxFPhDFDQIK6RGjUqzi5IIpRhtgO8sdcLYjYD4sMVVS U/XGNGXeL57EzVwwCmAc1zYXoVHvj8s+ZiEuThF8bXU3L81VxPfosVLp+xdQhyx4 5nOPEjsOtYOx+snBknBR6l1r7Z6bH7Y8pyvXFrz4PV7d5V/i8cIDNFBsjfefuTYL u98ZzXCfQGnMGNRXn+gJ0M+r1r4SxzNWSnfMDBem54EjKrHXReUsmy4ID03VV8R5 RnNK/pupPYEAuK46UcQxjv89fEV/CVUAAshX415QzOdj9qL4Te2TLOUKmBW8c1Y= =uZJa -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: watchdogd, jemalloc, and mlockall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/3/12 11:38 AM, Ian Lepore wrote: In an attempt to un-hijack the thread about memory usage increase between 6.4 and 9.x, I'm starting a new thread here related to my recent discovery that watchdogd uses a lot more memory since it began using mlockall(2). I tried statically linking watchdogd and it made a small difference in RSS, presumably because it doesn't wire down all of libc and libm. Speaking for this, the last time I brought this up, someone (can't remember, I think it was phk@) argued that the shared library would use only one copy of memory, while statically linked ones would be duplicated and thus use more memory. I haven't yet tried to prove or challenge that, though. Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJQlXeTAAoJEG80Jeu8UPuz7AUIAJOn67ETS7uHuIaPNByr9R6l S6l8uhwqTOsF+4jmuuDmjI25uiCAN4a3OU8i4n/ZGuarlip2Rr4BFWf+FUkkzdyk qButTuWC/agpuKofJ/7UubTXIEhpViWY/J2mqQTwgk+zeQ0bl2yjaqaR4hH3/ivi DQ3FWGzBhWD0Ohx/B0f33i9wvc5mCTTR5oxM78xvrQIPejG3lQHcwgmsd5XLgAuW 54UEEnklxAYLDf9eCsDo9nSsXQBKidmZop3ELtg08gUxtu5Ncf1+QraLxjdFzdr7 RrmQgcR4QrVtQeezWCRx2Y8VzGl0rtOunmQguNgkwRLo3KQlIU4IhpnaNrNez74= =HAd6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 10/27/12 2:17 PM, hiren panchasara wrote: [removing the CC list] On Wed, Oct 24, 2012 at 3:36 PM, Pedro Giffuni p...@freebsd.org wrote: (cc'ing -ports and cutting most of the rest) From: Eitan Adler . On 24 October 2012 13:24, Fernando Apesteguía wrote: Also related to that, what about writing a section about redports[1] in the porter's handbook[2]? This is a good documentation task... but we need more *coding* tasks as well. We do need to port and test patch (1) from NetBSD or DragonFly to replace GNU patch, and this shouldn't be difficult. Hi Pedro / List, I am not part of google summer of code but I've tried to port patch(1) from NetBSD into FreeBSD head. I hope that is okay. Patching was trivial and It _seems_ to be working fine. I would appreciate any ideas around how to test the changes and how to proceed further. I've a version of OpenBSD patch(1) at: http://svnweb.freebsd.org/base/user/delphij/patch/ But I don't have much time to work on it lately, so I wouldn't mind if someone more energized to take over the lead :) Note that if this is intended to replace the current FreeBSD half-GNU patch(1), please make sure that the features are all in your version before proceeding. Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJQjLx4AAoJEG80Jeu8UPuzfsgIAKRpxxX2+KYHeHNCiFOVOyd4 V39XPaVocxHajjtGagWTZ4VfFWKhWMwz2vl94wjApkBpDGpE6Vt6/17g8xyAZJ4a krNF+TobXR2LFjUffDgKBNwouwqxnaPk1fm3M0+HJJPCc+O79Im5pEZfOf3J1atV k4Z2qliYjphPXUFjq/6+vUWPt2N35OyxQAtDJrRWGD6j8sKE/uzmGF4jIKibY0Sx Z5wx3q06xdXpvHFFqKU7AZvTu0Jz22S2MEMTV+0OJdOAka8BDWsM9UwIlSdD90VT VgWjv3M0+eZLa7vxhXEzEw/uLfeDsBmuT7zq6CUHFRaMvVGLN99yZu97tpwvy6E= =sHUs -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: system hangs during dump + compress usb2-drive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/29/12 10:49 PM, Jin Guojun wrote: In FreeBSD 8.3 release (possibly in earlier release), dump a file system has 2-3GB or more content can cause system hang in a specific case (pipe to compression): dump FS-on-SATA-drive usb-drive OK dump FS-on-SATA-drive | anyCompress sata-drive OK mv a-large-dump-file from STAT drive to a USB drive OK dump small-FS-on-SATA-drive | anyCompress usb-drive OK small -- 1.8GB or less dump large-FS-on-SATA-drive | anyCompress usb-drive hang content is 3GB or larger (did not try around 2GB yet) When system hangs, no sub system, such video, network, etc, will function. Typically, the unfinished compressed dump file is around 1.5-2.7GB, so guessing dumped file content is close to or over 2GB when failure occurred. Has anyone encountered the same problem? Because this usually takes a few hours to occur, this is hard to watch how/when it happens. Is any way to debug or determine what status the system is? For starters I'd use a different console for doing procstat -kk -a and see what the system is doing. (Perhaps also top) I *think* that if it's just hanging for some time, it's probably because the system is trying to take a snapshot? It takes time on UFS when creating and removing the snapshot. Just a guess... Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBCAAGBQJQaKaIAAoJEG80Jeu8UPuzfH4IAL3k2M/KHV39FrI0U4lZ1yu/ bFbJJubQHzjfNbDrI4er1Xg6S0sN0DNnRoD/bQFKKHvQpfqcCUOwUtpq0kssyfLY 4XQOF9nhcyvL/INz6ArtI7EhKh/2cADb+1zp+NMsFyqvn3F09VPvx6h9z6ufaian LlAA6uisZSl/eGv5uNGGcudiUxSALql8UniZVHJvyO+pCjOAwL+MBxfqQ4LW3DEy ngvkvCeQ2nK/k0oQDq5jt9A9+D+7b3+Wo+4sMkIN7uTMgPpET4JSgWgxkzG1xM+l VMTAUHiqdeKp2JbWot1sRE5K7SiLPDmVGXEa0w+duBbvtuk8M/uXLootky0y1Oc= =zTBM -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: posix_fadvise64?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/18/12 12:55 AM, Wojciech Puchar wrote: i tried to compile xfsprogs from ports linking fails with missing posix_fadvise64 man posix_fadvise gives me manual, but what is fadvise64? Looking at Linux manual page I believe you can just replace it with posix_fadvise. On *BSD off_t is always 64-bit. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBCAAGBQJQL03lAAoJEG80Jeu8UPuzs38H/3mM3SSpzdpDJggiigLLfLZo ijBp9mzR052Ar5v8qlAVsY8KZPY/gtCHvsApEsWJ3CRqNqzaPstczlHmUR2BpTOb n2UkLKx8ktl5cQDBq4E9CCojGnJwhr6J8JTSHKa4ahse/1+1+HcifFV1z06QjPE+ fTkzSPD7gBsLa6hphs0gqnUq0uSoPQimToYBkqMvnn3UQiwZD6fIEfu70sLg/HSe 5g8E4kXtSmXHAKbWGAwleNStPP6Wptxeg9bVbVxUQ4R7PJJEPU+6zx14yEqQs0go QHgqZRE4IRpD6+z/n3P/fm5cw0J9xadj/q1CXl1cFS1E6ne9Y/QdnNGF+8dpMwk= =k2lu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
On 07/12/12 09:36, Bill Crisp wrote:
Good Morning!
This was also posted to the FreeBSD forums:
I have been researching CVE-2012-0217 and while I have patched the kernels
on servers with 7.3/8.2 that I have, I would like to see if anyone knows
for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are
out of support from looking at the documentation. I have looked at the code
in trap.c to see if the current patch would work with 6.3 source but it
won't based on what I saw. I am also aware of upgrading as an option to
resolve this unfortunately in some cases I have this is not possible right
now.
I believe that 6.x are vulnerable. You will have to backport the change
(something like this against sys/amd64/amd64/trap.c, in syscall() right
after
PTRACESTOP_SC(p, td, S_PT_SCX);
Add:
+ /*
+* If the user-supplied value of %rip is not a canonical
+* address, then some CPUs will trigger a ring 0 #GP during
+* the sysret instruction. However, the fault handler would
+* execute with the user's %gs and %rsp in ring 0 which would
+* not be safe. Instead, preemptively kill the thread with a
+* SIGBUS.
+*/
+ if (td-td_frame-tf_rip= VM_MAXUSER_ADDRESS) {
+ ksiginfo_init_trap(ksi);
+ ksi.ksi_signo = SIGBUS;
+ ksi.ksi_code = BUS_OBJERR;
+ ksi.ksi_trapno = T_PROTFLT;
+ ksi.ksi_addr = (void *)td-td_frame-tf_rip;
+ trapsignal(td,ksi);
+ }
Right before:
WITNESS_WARN(...)
Cheers,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BIO_DELETE equivalent for file on FFS filesystem
On Sat, Jun 16, 2012 at 12:01 PM, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 5:49 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: file to take 900MB or... can i call some system function to punch holes? I think you can only truncate the file at this time, pretty much like brk() works for memory. BAD. suppose i keep windoze VM image on filesystem which takes 10GB but uses 5GB. i could write simple program to find out what blocks are unused and then...do nothing. What if you cp it? That would be a dd(1) unless we teach cp(1) how to do sparse. I think what he wanted is to tell the OS I don't need block XX - YY anymore and the OS creates a sparse hole, which is not available at this time. Cheers, -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BIO_DELETE equivalent for file on FFS filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/12 08:06, Wojciech Puchar wrote: is it possible. suppose i have 1GB file with my data and 100 1 megabyte parts of it is no longer needed. i could reorganize that file to take 900MB or... can i call some system function to punch holes? I think you can only truncate the file at this time, pretty much like brk() works for memory. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP2UJAAAoJEG80Jeu8UPuzvaMH/Rb0IwPZV1xyapMoSv71FQPz 0yhAMLamNBEIRf2mvBZHp9ASLBRDYZsDtU+EAFelS56hBkuYywSb//m+cTeQpqT3 Wz5713DRtrpi6X7KrGCFmtpzhCiYyS11YLBGWIe6PjBFNdF+dveNGh5TPy4bKmVy j4cx+a3mHEdXOinayUzfPI1wpxF1eI/6cIiP0G5wy0VAApbk5qgE4PVlqZa8zKFF 4sePD6vsYTQ+3PVMwkfeJiX8E1ZMKAo/boD8Hw3jU24kY5n4bC+Qcqvm/JCFArGr QfA0K+TZ7R86lfs7yyjhmnf3fSBZVTOG4anYOAeOqgghORL43JhGjKZcDRw2CjM= =Y8H3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/12 12:02, Guy Helmer wrote:
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad
entries in the grp list due to memory allocation failures while
building a new entry.
Before committing, I wanted to run it past others to see if
there were any problems with it.
%%% @@ -477,6 +475,13 @@ if (len 0) { grp-ng_str[strpos] =
(char *) malloc(len + 1); + if
(grp-ng_str[strpos] == NULL)
{ + for (freepos = 0;
freepos strpos; freepos++) +
if (grp-ng_str[freepos] != NULL) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); + } bcopy(spos,
grp-ng_str[strpos], len + 1);
%%%
Like this?
if (len 0) { grp-ng_str[strpos] = (char *) malloc(len + 1); +
if (grp-ng_str[strpos] == NULL) { +
int freepos; + for
(freepos = 0; freepos strpos; freepos++) +
free(grp-ng_str[freepos]); +
free(grp); +return(1); +
} bcopy(spos, grp-ng_str[strpos], len + 1); }
There are a few return without space between the keyword and
return value.
Do you recommend I fix all those instances in the file, or just the
instances in this patch?
I'd recommend fixing them all (note that you could run into a bigger
commit as the switch() is not style(9) conformant at this time) and we
normally do it in two different commits (one style, and another
functional) when possible.
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPupePAAoJEG80Jeu8UPuz52wH/RVJXpCyea+ep08XDx82D7tG
us+ujKa1aNOUumzwJRsJ4SNVBiyc+hqCtb8s7FjjeF4/SJk8oei/I1/M1JIyMuIh
FawSB8rNJCbn/u9Od19iOeh/f/IDeCN+q8OrUK5mqQ7G1KDcHs12h86AFlm9HA7K
8UyxneTkPfKhED6hkgSll6bqYAJLeR5jJ3CCGvBeXxNgzJyyAhICWv0UgzUpcY9d
l2beuIXc57toDaLrbWkooLfQclDWPWyyPXq7okexQAq8OUjqmQFE+EhcYsIbtBkH
uBW67jhH81MZf/Ryl83VeqT9IChOySAU0YiwOQxaxdlqR53VAenAY0sWS1QvuX8=
=drgy
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad entries
in the grp list due to memory allocation failures while building a
new entry.
Before committing, I wanted to run it past others to see if there
were any problems with it.
%%%
@@ -477,6 +475,13 @@
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos strpos; freepos++)
+ if
(grp-ng_str[freepos] != NULL)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
%%%
The if (grp-ng_str[freepos] != NULL) here seems to be unnecessary to
me because in most cases these are false, and free() does the test
regardless. Also, I think freepos can be declared within this scope
level.
There are a few return without space between the keyword and return value.
Other than these it looks fine to me. Thanks for working on this!
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPttaYAAoJEG80Jeu8UPuzFEsH/i7JwIPdk15sP3E2/YpesYQu
veavnS6tebylFhniKukN4GRsS5mpbs9AmnxbNUBfF7InlzcnxOeUX9mHJepxbZQX
Bz8wgsvfxlrrseIyscdwm7b4XQK3dLv+VwpbQ4fqACOX1kGEQ/GsIc65JLyp2Gzo
fRLkHRAO5s3FVT5f11vsy2Ry16AmQhL2Sg9+mrGqeIbhppmDCgWfoF+rmD/7fn15
0OuJNn/S3Cz3zo+ZHI9OE1W8mkMox4kznQmv6vH/hM3Gk1cY9h66UybuBWsY31dI
WF5Y5WoJBuncFlDxGkaZv2jiRAqgkfWILVWKcjyejtGgVYPEWAjIgHLyyVk7H4g=
=ewU+
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers?
scbus8 target 14 lun 0 da14: HPT DISK 0_14 4.00 Fixed Direct Access SCSI-0 device da14: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da15 at hpt27xx0 bus 0 scbus8 target 15 lun 0 da15: HPT DISK 0_15 4.00 Fixed Direct Access SCSI-0 device da15: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da16 at hpt27xx0 bus 0 scbus8 target 16 lun 0 da16: HPT DISK 0_16 4.00 Fixed Direct Access SCSI-0 device da16: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) da17 at hpt27xx0 bus 0 scbus8 target 17 lun 0 da17: HPT DISK 0_17 4.00 Fixed Direct Access SCSI-0 device da17: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da18 at hpt27xx0 bus 0 scbus8 target 18 lun 0 da18: HPT DISK 0_18 4.00 Fixed Direct Access SCSI-0 device da18: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da19 at hpt27xx0 bus 0 scbus8 target 19 lun 0 da19: HPT DISK 0_19 4.00 Fixed Direct Access SCSI-0 device da19: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da20 at hpt27xx0 bus 0 scbus8 target 20 lun 0 da20: HPT DISK 0_20 4.00 Fixed Direct Access SCSI-0 device da20: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da21 at hpt27xx0 bus 0 scbus8 target 21 lun 0 da21: HPT DISK 0_21 4.00 Fixed Direct Access SCSI-0 device da21: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da22 at hpt27xx0 bus 0 scbus8 target 22 lun 0 da22: HPT DISK 0_22 4.00 Fixed Direct Access SCSI-0 device da22: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) On Thu, Apr 19, 2012 at 12:29 AM, Xin Li delp...@delphij.net wrote: On 04/12/12 10:14, Barkley Vowk wrote: I've got a Highpoint 2760A card that I'd like a FreeBSD driver for, I've got a machine and disks available if someone wants to tackle that. Please try loading 'hpt27xx.ko' on boot. Cheers, ___ freebsd-hardw...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPkf3OAAoJEG80Jeu8UPuzAzcH/1GqBOF9QAx8DtSD8wpO3bAo ryS5hUgdr6wCuFvPZqIIel3eS8+U1nL/sVDuOdI2Z52S/PTXg56nDLaR6+HKns3v Bv/rrftLlMouQDawfB53Qa0dHLjZiU0oiQ+k5Ocol7Y57+PTLYpUxRfhti6mFMSg bdsQGpmY+jmshhTWki8PF5W8tDu8ucaSrGwUG4yOuXZZ7oZvMsT4K4Sz+LkGFg6s XAOTVNhYRuRoY9o7rTazMH3PATu9K7oxLRnR0WQcKMAcjpI+Df4QNgguVOMhPYMj j+MId0x8iZQe8JdkAx1UjNUWOjDJvQgqJfhYvC6FQ4iHdTuaea+vKTpw0dK8U1A= =mPEE -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/12/12 10:14, Barkley Vowk wrote: I've got a Highpoint 2760A card that I'd like a FreeBSD driver for, I've got a machine and disks available if someone wants to tackle that. Please try loading 'hpt27xx.ko' on boot. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPj77sAAoJEG80Jeu8UPuzoW4H/2KsdmWsV/HEERSkyPY/XX/B jJtEAZFFI6X4aYYqANyPXWWBA6mRy586GkZZNlClCw2v4cBxXAnWBWL49tcuJ0UP wURQt9/HU6P+EqbRSVZ98KhvufjvecjLavr9x6wCJ+L8pvc7trnD25l/Z0hTA96Y hIpwTcK/m0IXYopmC0WioPfyZWJx2Uu+DgrUUV6mXOZc9oDDf53v10rbGpQoNUZg GvKfL2Ql0rHZ13EJkjZdURcUj94Nas7pBgumGwedrsKs0NGnjRNmMlYSRzonqe0Z uBaWzqEiB01qNThfCpt0tnAS55wYU+QWmvF9hVSApSwmeCsrneluhyUjf9QJ8M8= =gUd0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memmem small optimalisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 02/14/12 10:25, Bernard van Gastel wrote: Hi all, I was looking through the sources of memmove at [1], and saw a (very) small optimization opportunity. The 'memcmp' also compares the current character, but the current character is already checked (first part of the condition). As we already know the size of the string is greater as 1 (it is checked before the loop), it is possible to replace the memcmp with (possible doing the decrease of s_len once outside the loop): memcpy(cur[1], cs[1], s_len-1) Am I missing something? E.g. is readability more important as speed? This made me wonder what generally the tradeoff is that has to be taken into account in these cases? Did you benchmarked the change? Changes like this has to be done very carefully since it's possible that the extra time spent on addition and subtractions, when multiple by the length of the long string, may actually defeat the benefit of one less byte worth memory compare because the effect of CPU's data cache. I think it would be worthy to explore if we could use a more advanced algorithm here by the way. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPRukLAAoJEG80Jeu8UPuzKlcIAJP+1tL4HfHfAOou39azwBwC DvTOw6XJziv3Pau0GmemE27cWRYHJDGiUzUI95IPFuoCfF/UuHwA8FV5x+wo7dId 3sYyNsqc2Hk9HGw0O5SifaJ5182/2jdJGbMVLl7z1tRlw29HRjubYnvAEizvrMpa IE0O2kvm9LhRlpy8Grnd4sa8WxJ4AGUpCDcAGcDrqM+GcDC5jvd+qO5HgD/yRNqd sXzNfDXtY6vIPND4hyLMJpsTTReTfsWJGL8pYI8T9IqK+/vy2+AzalL9FKoBgOAE z1qkl565J6S4au6v60smNNb0+rIvrPoQrYs8ot4Dl2g8vMKDetj7rGTH3zorKvM= =2Nw3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nologin size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/15/12 11:28, Ansar Mohammed wrote: Hello all, I am trying to build a minimal size FreeBSD 9 installation and I noticed that the size of nologin is almost 200k. I built FreeBSD from source so I checked the distribution, and it's also 200k. So I went back to the source and just compiled nologin.c and it came up to 5k. The Makefile have described why it's statically linked: # It is important that nologin be statically linked for security # reasons. A dynamic non-setuid binary can be linked against a trojan # libc by setting LD_LIBRARY_PATH appropriately. Both sshd(8) and # login(1) make it possible to log in with an unsanitized environment, # rendering a dynamic nologin binary virtually useless. NO_SHARED= YES Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEbBAEBCAAGBQJPPA7RAAoJEG80Jeu8UPuz2k0H8wbyLWS6+V0ebKJzPtB1BZzP o6VWo6sXrG5sMb7kegQdtouYjjfCh1XGxj8jT/nCdOcmXFTvta4GaEnwNZjT3IJp bhIRU3sh7G3AOs9WjXlDhwyPCuLp3LdWPu6/4kjdME3VZp6YQRn6SSHtS/OAG/nS HJtlee64Udlkj1OVIPKENpdSdv4dzJt5afSsK0Ju9HH+vrpFKv5fwUWcXVCFya4R iPiU+hDlVUG0ivjK7Aa12rKavrJxmuC6am7KansLF9LsjTHm8zBxswPgJwVEXO9v xIoFHnbfUHLi9r/NAUICudpPmoNfp8M8MNei+n2KQwPK4FsHdiIGcIkfQCsrJQ== =4yw1 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Eitan,
On 01/20/12 15:25, Eitan Adler wrote:
I figure this isn't wanted?
Since this is modeled after Linux's dup3() system call, would you
please also add a compat entry for it? By the way:
On Thu, Jan 12, 2012 at 10:07 PM, Eitan Adler
li...@eitanadler.com wrote:
Okay - here is version 2 (compile and run tested) Index:
sys/kern/syscalls.master
===
- --- sys/kern/syscalls.master(revision 229830)
+++ sys/kern/syscalls.master(working copy) @@ -951,5 +951,6
@@ off_t offset, off_t len); } 531AUE_NULLSTD {
int posix_fadvise(int fd, off_t offset, \ off_t len, int advice);
} +532AUE_NULLSTD { int dup3(u_int from, u_int
to, int flags); }
I think we want audit here?
; Please copy any additions and changes to the following
compatability tables: ; sys/compat/freebsd32/syscalls.master
Index: sys/compat/freebsd32/syscalls.master
===
- --- sys/compat/freebsd32/syscalls.master(revision 229830)
+++ sys/compat/freebsd32/syscalls.master(working copy) @@
-997,3 +997,4 @@ uint32_t offset1, uint32_t offset2,\ uint32_t
len1, uint32_t len2, \ int advice); } +532AUE_NULLSTD
{ int dup3(u_int from, u_int to, int flags); }
Ditto...
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8Z+kYACgkQOfuToMruuMBe/ACfQ9aR5OfPZTS3q/AVNheUDliQ
nIYAnjp/5qblxlOLDAvB6AferlpFQjOa
=lTV+
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: crypto.ko module problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/22/11 12:30, aram baghomian wrote: Hi If you can remember i wanted to add my custom hash algorithm to the opencrypto project, after i added it and compile my kernel source( by your advise),i load the crypto.ko module using kldload and give this error. link_elf: symbol MYHASHUpdate undefined MYHASHUpdate is one of my hash functions that i add to the source. what should i do that i forget? Looks like it's expecting something that is not linked into your module? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOzAfcAAoJEATO+BI/yjfB4JcIAIB6dwTlsvj9djUdKGkRI8ix G/pJaZIONh3mUVV7TLdsl2OUtzDTmvGbV1hh1LCo/cmKfZMUOWJWoH6Sx+LnMQYR ftfHnpFk4bQP/38aP3yTHjGX1mGzhCFWCyHYm4d45Jl+ukjRwlZw7eeTzDTFYtF9 cJe/fRs8GGWIDh3MvLC5ZjMInPneOJk4jEKv0SARbDk+bG23q//xf5HQkml4Q35g 2sxaE7750IDtqER/9cKxtd4Akr1blRkp0jOxzH3vkgubjY63k2fCj9mXNKxR82wb rx9igsYzOjl6rLpv0agJINpyl1gXHrl28ielJAmbWT5uwfEawG1LJw/N57o5EY8= =Gkm6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: crypto.ko module problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [Added -hackers@ back to Cc list] On 11/22/11 13:13, aram baghomian wrote: I add myhash.c address in '/sys/conf/files' and my make process done completely whitout any error. I don't know is there any place that i should add my hash program address.(i searched all the /sys/conf files for same algorithms such as rmd160 and SHA256) If you are compiling a kernel module, it would be /sys/modules/*/Makefile (for your exact case would be /sys/modules/crypto/Makefile I think). Date: Tue, 22 Nov 2011 12:58:02 -0800 From: delp...@delphij.net To: aram_baghom...@hotmail.com CC: d...@delphij.net Subject: Re: crypto.ko module problem On 11/22/11 12:49, aram baghomian wrote: I can understand what do you want to refer. Well be more specific -- check if you have everything included in your Makefile, my guess is there is some .c missing. Date: Tue, 22 Nov 2011 12:36:44 -0800 From: delp...@delphij.net To: aram_baghom...@hotmail.com CC: freebsd-hackers@freebsd.org Subject: Re: crypto.ko module problem On 11/22/11 12:30, aram baghomian wrote: Hi If you can remember i wanted to add my custom hash algorithm to the opencrypto project, after i added it and compile my kernel source( by your advise),i load the crypto.ko module using kldload and give this error. link_elf: symbol MYHASHUpdate undefined MYHASHUpdate is one of my hash functions that i add to the source. what should i do that i forget? Looks like it's expecting something that is not linked into your module? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOzBLRAAoJEATO+BI/yjfBgxQH/A36S+IZt/V0D/LcDZWcBubC CoHSoVCBkMcyFIa4SF7MJvuLT1zCec+lsPr9/E7GGVqLqFy/XyaMC0TpHi4J+hg2 xOvwvEkSPWmwe9SoEpo91BpL+hK5P/uTQ+MBoMBV4kz+eI7VbLZpRFjlEOh2ZhGK kWuRRsHZWXSiPDsZW4Pbcmt6HxhvvCjGHN/RPrQ4lmcU52SBgvvexXiJeTXdcZ4F 9hO3oPLBXat4aypX9BeGvqi6vydOiqXdIsFKBd3LG3V4l+QIjb9Rs2epciYNXgQi u6cspLayVcnyNxEoA9j09Mi/iuGxy7qcGc/YsnEo0K0tzi25ZW2w/TJX+2Nmg7Y= =vzBy -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: crypto.ko module problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/22/11 14:25, aram baghomian wrote: one more question. the crypto.ko module need zlib.ko module for dependence, how can i config kernel to load zlib.ko before crypto.ko in boot time? Add a dependency, something like: MODULE_DEPEND(crypto, zlib, 1, 1, 1); (Note I think crypto.ko already do that though). From: aram_baghom...@hotmail.com To: d...@delphij.net Subject: RE: crypto.ko module problem Date: Tue, 22 Nov 2011 21:57:40 + I add my hash program address to /sys/modules/crypto/Makefile and recompile the module. it loaded successfully. Thanks alot. Date: Tue, 22 Nov 2011 13:23:30 -0800 From: delp...@delphij.net To: aram_baghom...@hotmail.com; freebsd-hackers@freebsd.org CC: d...@delphij.net Subject: Re: crypto.ko module problem [Added -hackers@ back to Cc list] On 11/22/11 13:13, aram baghomian wrote: I add myhash.c address in '/sys/conf/files' and my make process done completely whitout any error. I don't know is there any place that i should add my hash program address.(i searched all the /sys/conf files for same algorithms such as rmd160 and SHA256) If you are compiling a kernel module, it would be /sys/modules/*/Makefile (for your exact case would be /sys/modules/crypto/Makefile I think). Date: Tue, 22 Nov 2011 12:58:02 -0800 From: delp...@delphij.net To: aram_baghom...@hotmail.com CC: d...@delphij.net Subject: Re: crypto.ko module problem On 11/22/11 12:49, aram baghomian wrote: I can understand what do you want to refer. Well be more specific -- check if you have everything included in your Makefile, my guess is there is some .c missing. Date: Tue, 22 Nov 2011 12:36:44 -0800 From: delp...@delphij.net To: aram_baghom...@hotmail.com CC: freebsd-hackers@freebsd.org Subject: Re: crypto.ko module problem On 11/22/11 12:30, aram baghomian wrote: Hi If you can remember i wanted to add my custom hash algorithm to the opencrypto project, after i added it and compile my kernel source( by your advise),i load the crypto.ko module using kldload and give this error. link_elf: symbol MYHASHUpdate undefined MYHASHUpdate is one of my hash functions that i add to the source. what should i do that i forget? Looks like it's expecting something that is not linked into your module? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOzCOoAAoJEATO+BI/yjfBisEH/2ompnPAk5Doi5VACeJ8zZaz kfuYfq8HHoit5WzbDsXFt5A+uii5brafTKxFYRVb0zB6BmjnFbgIxqCebSw3jNll TBjzhnSI5g1O43n2/XAQT2RjIJdfWnZqfBI0JLpZqjedObMbmQiyAyxz2bpDPV7H gtb/ElUa17bRVCwjoAy2iKC9hvwIixjMhcWvlrg49kVJyFFd6gVjBxUplS2SMEfv ZTLDIY8ZeQGCIolVZv8gcjeT1ToSmKQHIGL5V25bb22TVCX/oONuhfM46A/cOaSN Jsj06Hp/BkDMlYA2mFYAXyQ+OotuW9lz+JVC12o8EBoFpILVNcbAuMVKLa4a6hs= =JXyV -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NASM in FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/30/11 10:52, Colin Barnabas wrote: Is there a particular reason that nasm comes standard with FreeBSD and not fasm? I think FreeBSD doesn't come standard with nasm either (the base system uses GNU as). If you're looking for fasm port it's located at lang/fasm (not in devel/) and I believe that package is also available for supported platforms... Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOhgQ6AAoJEATO+BI/yjfBy3oIAJNcCFWOiDlActQHza62q7bC xdug+sx2JvfJronP4jTm7LQ7jp6NeLvoH9qynWFMPpUiac00ZWqNNBhjWCtH7eop UwSn35EfiZ7dorU81h+3MO1IHPJtlRM6nsNp719kt5ok5JTVKzQrKAtG0dZv/p/U PDCTbylOPIVJ4tu1/0pnplMiyltAeqeZJeFQaIIqcCol722HRyUg3KCSoASJw5cd dY3vRlDNZOp/6DRMAGiQyK6mMPCTZQxykDvlTQi0YZu/SbWY0IjK3vApkGXE1HpX AV6Yu76nvC5EftX+yPV2FzZ60c/cS2Qu6Ji6IrMg8/DmZa8V1E41qESfpIFVN84= =k6N0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sizeof(size_t) and other semantic types on 32 bit systems?
2011/9/30 Lev Serebryakov l...@freebsd.org: Hello, Hackers. I was surprised, when I discover that size_t are 32-bit wide on 32-bit (i386) system. Which semantic type should I use, for example, for storing GEOM size in bytes in system-independent way? I could use uint64_t, of course, but I don't like this solution, as it very low-level (ok, not so low-level as unsigned long long, to be honest). off_t? Cheers, -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Switching to [KMGTPE]i prefixes?
On Tue, Mar 29, 2011 at 2:51 PM, Alexander Best arun...@freebsd.org wrote: On Fri Mar 25 11, Xin LI wrote: On Fri, Mar 25, 2011 at 3:32 PM, Alexander Best arun...@freebsd.org wrote: On Fri Mar 25 11, Xin LI wrote: FYI I have a patch and I have incorporated some of Alexander's idea. Difference: - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an assertion. I think it doesn't make sense to return since this is an API violation and we should just tell the caller explicitly; actually i vote for removing all asserts in humanize_number.c and return -1 based upon the later checks. the existing assert(buf != NULL); assert(suffix != NULL); checks aren't really needed, since buf and suffix are also checked later on. so just having: Well, one of my believes is that a program should crash as early as possible, and with clear statement about Why I crashed, when it's compiled with debugging aids, like assertions. To test or not to test these cases in a release binary on the other hand really depends on whether there is security or other bad implications. This generally makes developers' life easier, as they don't have to pursue into the code to find out why the program crashed, etc. Unlike system calls, humanize_number(3) does not indicate what's wrong via errno, e.g. it tells you No I can't rather than a reason of Why I can't do that. Assertions here gives it an opportunity to say it loudly. If however the program is compiled with -DNDEBUG, these assertions would became no-op. At this stage, in my opinion, only basic tests should be done and we fall back to returning -1, or at least, not crash the program in a mysterious way. For this reasons, I think the assertion here against flags is right, it does not hurt if we proceed with both flags set, as we do not access undefined memory nor overwrite undefined memory. Furthermore, these values are more likely to be hard-wired at caller, where the assertion should catch the case. if (scale = 0 || (scale = maxscale (scale (HN_AUTOSCALE | HN_GETSCALE)) == 0)) return (-1); I think this one is good to have for both assertion and tests. Note that I think it should be scale 0 here, scale == 0 seems to be a valid value. if (buf == NULL || suffix == NULL) return (-1); This duplication is necessary in my opinion. It's a protection against NULL pointer deference at runtime. if ((flags (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) return (-1); I'd vote no for this one for the reason above. - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them while keeping divisor intact; good idea. however i think you should add a comment to point out that the default behavior is !DIVISOR_1000 !HN_IEC_PREFIXES. one has to look very closely to find out. Will do. #define HN_DECIMAL 0x01 #define HN_NOSPACE 0x02 #define HN_B 0x04 #define HN_DIVISOR_1000 0x08 #define HN_IEC_PREFIXES 0x40 #define HN_GETSCALE 0x10 #define HN_AUTOSCALE 0x20 Thinking again and I think we are just fine to use HN_IEC_PREFIXES == 0x10 here. I don't think there is a reason why we can't use 0x10 for flags. Here is what in my mind. I have stolen some comments from your version of patch to explain the meaning of the HN_IEC_PREFIXES option as well. any plans to commit this patch? I think I should be able to commit a final version by Friday, still need some polishing... Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Switching to [KMGTPE]i prefixes?
FYI I have a patch and I have incorporated some of Alexander's idea.
Difference:
- Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an
assertion. I think it doesn't make sense to return since this is an
API violation and we should just tell the caller explicitly;
- DIVISOR_1000 and !1000 cases use just same prefixes, so merge them
while keeping divisor intact;
- Make prefixes table consistently long. I have no strong opinion on
this one, though, it's just what my original version used and I can
change it to the way Alexander did if there is an advantage of doing
that way.
(Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I
have sorted them by value but HN_IEC_PREFIXES should really belong to
the flags group).
Cheers,
--
Xin LI delp...@delphij.net http://www.delphij.net
Index: humanize_number.c
===
--- humanize_number.c (revision 220009)
+++ humanize_number.c (working copy)
@@ -54,29 +54,31 @@
assert(buf != NULL);
assert(suffix != NULL);
assert(scale = 0);
+ assert(!((flags HN_DIVISOR_1000) (flags HN_IEC_PREFIXES)));
remainder = 0;
- if (flags HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
- divisor = 1000;
+ if (flags HN_IEC_PREFIXES) {
+ baselen = 2;
+ divisor = 1024;
if (flags HN_B)
- prefixes = B\0k\0M\0G\0T\0P\0E;
+ prefixes = B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei;
else
- prefixes = \0\0k\0M\0G\0T\0P\0E;
+ prefixes = \0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei;
} else {
- /*
- * binary multiplies
- * XXX IEC 60027-2 recommends Ki, Mi, Gi...
- */
- divisor = 1024;
+ baselen = 1;
+ if (flags HN_DIVISOR_1000)
+ divisor = 1000;
+ else
+ divisor = 1024;
+
if (flags HN_B)
- prefixes = B\0K\0M\0G\0T\0P\0E;
+ prefixes = B\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E;
else
- prefixes = \0\0K\0M\0G\0T\0P\0E;
+ prefixes = \0\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E;
}
-#define SCALE2PREFIX(scale) (prefixes[(scale) 1])
+#define SCALE2PREFIX(scale) (prefixes[(scale) * 3])
maxscale = 7;
if (scale = maxscale
@@ -91,10 +93,10 @@
if (quotient 0) {
sign = -1;
quotient = -quotient;
- baselen = 3; /* sign, digit, prefix */
+ baselen += 2; /* sign, digit */
} else {
sign = 1;
- baselen = 2; /* digit, prefix */
+ baselen += 1; /* digit */
}
if (flags HN_NOSPACE)
sep = ;
Index: libutil.h
===
--- libutil.h (revision 220009)
+++ libutil.h (working copy)
@@ -223,6 +223,7 @@
#define HN_GETSCALE 0x10
#define HN_AUTOSCALE 0x20
+#define HN_IEC_PREFIXES 0x40
/* hexdump(3) */
#define HD_COLUMN_MASK 0xff
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Switching to [KMGTPE]i prefixes?
On Fri, Mar 25, 2011 at 3:32 PM, Alexander Best arun...@freebsd.org wrote:
On Fri Mar 25 11, Xin LI wrote:
FYI I have a patch and I have incorporated some of Alexander's idea.
Difference:
- Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an
assertion. I think it doesn't make sense to return since this is an
API violation and we should just tell the caller explicitly;
actually i vote for removing all asserts in humanize_number.c and return -1
based upon the later checks.
the existing
assert(buf != NULL);
assert(suffix != NULL);
checks aren't really needed, since buf and suffix are also checked later on.
so
just having:
Well, one of my believes is that a program should crash as early as
possible, and with clear statement about Why I crashed, when it's
compiled with debugging aids, like assertions. To test or not to test
these cases in a release binary on the other hand really depends on
whether there is security or other bad implications. This generally
makes developers' life easier, as they don't have to pursue into the
code to find out why the program crashed, etc.
Unlike system calls, humanize_number(3) does not indicate what's wrong
via errno, e.g. it tells you No I can't rather than a reason of Why
I can't do that. Assertions here gives it an opportunity to say it
loudly.
If however the program is compiled with -DNDEBUG, these assertions
would became no-op. At this stage, in my opinion, only basic tests
should be done and we fall back to returning -1, or at least, not
crash the program in a mysterious way.
For this reasons, I think the assertion here against flags is right,
it does not hurt if we proceed with both flags set, as we do not
access undefined memory nor overwrite undefined memory. Furthermore,
these values are more likely to be hard-wired at caller, where the
assertion should catch the case.
if (scale = 0 || (scale = maxscale
(scale (HN_AUTOSCALE | HN_GETSCALE)) == 0))
return (-1);
I think this one is good to have for both assertion and tests. Note
that I think it should be scale 0 here, scale == 0 seems to be a
valid value.
if (buf == NULL || suffix == NULL)
return (-1);
This duplication is necessary in my opinion. It's a protection
against NULL pointer deference at runtime.
if ((flags (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0)
return (-1);
I'd vote no for this one for the reason above.
- DIVISOR_1000 and !1000 cases use just same prefixes, so merge them
while keeping divisor intact;
good idea. however i think you should add a comment to point out that the
default behavior is !DIVISOR_1000 !HN_IEC_PREFIXES. one has to look very
closely to find out.
Will do.
#define HN_DECIMAL 0x01
#define HN_NOSPACE 0x02
#define HN_B 0x04
#define HN_DIVISOR_1000 0x08
#define HN_IEC_PREFIXES 0x40
#define HN_GETSCALE 0x10
#define HN_AUTOSCALE 0x20
Thinking again and I think we are just fine to use HN_IEC_PREFIXES ==
0x10 here. I don't think there is a reason why we can't use 0x10 for
flags.
Here is what in my mind. I have stolen some comments from your
version of patch to explain the meaning of the HN_IEC_PREFIXES option
as well.
--
Xin LI delp...@delphij.net http://www.delphij.net
Index: humanize_number.c
===
--- humanize_number.c (revision 220009)
+++ humanize_number.c (working copy)
@@ -42,45 +42,59 @@
#include locale.h
#include libutil.h
+static const int maxscale = 7;
+
int
humanize_number(char *buf, size_t len, int64_t quotient,
const char *suffix, int scale, int flags)
{
const char *prefixes, *sep;
- int i, r, remainder, maxscale, s1, s2, sign;
+ int i, r, remainder, s1, s2, sign;
int64_t divisor, max;
size_t baselen;
assert(buf != NULL);
assert(suffix != NULL);
assert(scale = 0);
+ assert(scale maxscale || (((scale (HN_AUTOSCALE | HN_GETSCALE)) != 0)));
+ assert(!((flags HN_DIVISOR_1000) (flags HN_IEC_PREFIXES)));
remainder = 0;
- if (flags HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
- divisor = 1000;
- if (flags HN_B)
- prefixes = B\0k\0M\0G\0T\0P\0E;
- else
- prefixes = \0\0k\0M\0G\0T\0P\0E;
- } else {
+ if (flags HN_IEC_PREFIXES) {
+ baselen = 2;
/*
- * binary multiplies
- * XXX IEC 60027-2 recommends Ki, Mi, Gi...
+ * Use the prefixes for power of two recommended by
+ * the International Electrotechnical Commission
+ * (IEC) in IEC 8-3 (superseeding IEC 60027-2)
+ * (i.e. Ki, Mi, Gi...).
+ *
+ * HN_IEC_PREFIXES implies a divisor of 1024 here
+ * (use of HN_DIVISOR_1000 would have triggered
+ * an assertion earlier).
*/
divisor = 1024;
if (flags HN_B)
- prefixes = B\0K\0M\0G\0T\0P\0E;
+ prefixes = B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei;
else
- prefixes = \0\0K\0M\0G\0T\0P\0E;
+ prefixes = \0\0Ki\0Mi
Re: Switching to [KMGTPE]i prefixes?
On Fri, Mar 25, 2011 at 2:50 PM, Warner Losh i...@bsdimp.com wrote: How did you guys deal with programs like df that now need to do special buffer size hacks to get consistent results? I think it doesn't really matter - caller have to specify using IEC prefixes explicitly, so old binaries won't be broken. They must be updated to use the IEC prefixes. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is it possible to have file removed upon process exit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/28/10 20:43, Garrett Cooper wrote: On Thu, Nov 25, 2010 at 12:14 PM, Xin LI delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, One pretty common way of having an i-node of a file removed when process exit is to unlink() it while holding a descriptor of the file. This approach, however, have a side effect that other processes would not be able to access the file via its name. For certain applications it is sometimes desirable to (e.g. for unix domain sockets) have file removed when the process quit, regardless whether the process is quit cleanly. Is there a clean way to do this? Does it have to be nameless and/or unique? Not nameless. Speaking for uniqueness, I think it's unrelated (not good nor bad) for the use case. The name should be predictable (e.g. can be configured, so non-child process can find it), though. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM82JTAAoJEATO+BI/yjfBefYH/21GeUneFBCiTRUYqgjA6AIc QB9D5zqFFNEOWK4fEfa78MnmS7mDGUojfuU36eRsppHYErZ8wLC0evapc/Q45c07 BisQZB4pETNGk+Qv61f9Dd18+bZk+XfqJ5RALAvKiuv1gu0DN/XqTW5PHK25c1YQ nx187Uf6gB8sRHrCt/k5OZQ6hq/ACdWQOA2SvWYbgpPt3WbBRp2D3/qELATUyCRw b10Egkh+c4ovewbmX7tvXYJpOKANp59iFA/q5k/YVEY9MKYTog2ARmkzqPDi4g2B U7ertGMjXgWASfWKwp+mFjjf7stcsPlqpql/MHWMF4fm9Z1TpI91nQ9/wX4UCEs= =uXVP -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Is it possible to have file removed upon process exit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, One pretty common way of having an i-node of a file removed when process exit is to unlink() it while holding a descriptor of the file. This approach, however, have a side effect that other processes would not be able to access the file via its name. For certain applications it is sometimes desirable to (e.g. for unix domain sockets) have file removed when the process quit, regardless whether the process is quit cleanly. Is there a clean way to do this? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM7sO9AAoJEATO+BI/yjfBlRQH/3zzmh6OtmMJs0CWNsH9eOQk mpSi5BJE9HHIbzPCMSGvujFn/HjQa5K752/A0J7Gulu/2wNYnY6013tuypnHZy0+ tPMVWWWpj3otqJuvcxBMeqNisA9RL+DS2ZMbUQs3t7vd9qHkJE1Honb97nFQ/o57 bUAYFUoFEjBgYiF0JrPQOXxHZacOhEtHrTj9qbtrZM+qcGZl01cTDfHTd7aP5yJ+ HnZVh/0CKMdcOH/9tI04pZ+beK9RwaPVLS0NxIfsVIx+1o1zP3rHIaEWczM21SsU gDDzQ6ypBE3dEJbQ7OH0UqezjLpX7JKUpSSjC4FRnL4VDZrUAH8Nh6wT+gcncc0= =1W2r -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 11/15/10 10:24, Alexander Best wrote: hi there, any thoughts on this patch? it changes the semantics of gzip so that it is consistent with the semantics of bzip2, xz and for more important GNU gzip. Could you please elaborate more about the GNU gzip behavior? By the way I also found some difference between BSD gzip and GNU gzip: touch foo ln -s foo.nonexistent foo.gz gzip foo gzip: could not create output: foo.gz: File exists /usr/local/bin/gzip foo gzip: foo.gz already exists; do you wish to overwrite (y or n)? ^C (case 1) echo | /usr/local/bin/gzip foo gzip: foo.gz already exists;not overwritten gzip -f foo gzip: could not create output: foo.gz: File exists /usr/local/bin/gzip -f foo (succeeded; case 2). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM4Z3cAAoJEATO+BI/yjfBLGoIAKcvx+bH6L0pJqLSv34bii6G 1FwXmPQqeIs+B5K8wNMmWblWLidJc2xkXxFCdJKsoZmgS6Hcakg6r1CzZ7tkjMAP CqYMG3cgkCiqZpgZ8QY3E3tmdxMqYk3EyII+TUv2xSNvUp8A7TPvC2vwS1eD3GzO OACbH/ULSJ30iMXi/A6nPkvEWesuExGplfpzzfJ0yCySKj/3HyXV87HxVw46LFYj XsG3F7WWUkVrIzCFGLgaN0ULRZlz30Fq4ODnm4sAnUJQx0hzHGUDmYkgLxqh50t5 AN81GC06I6XZttqIaM1FNm5Dp27Vh6uVfYd21lJ+g5ee5kXM6Fd03jSJOqZJiro= =QEEo -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /stand/camcontrol
2010/9/2 Dag-Erling Smørgrav d...@des.no: Xin LI delp...@gmail.com writes: My 2 cents: I think we don't really need to care about the size for rescue binary after the splitfs VFS layer have been introduced to libstand? Build of release split MFSROOT was 2006-ish and I feel that this can be gone. This is /stand, not /rescue; /rescue has a full camcontrol. Oh you are right. But MFSROOT have /stand (for sysinstall), not /rescue, I think? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /stand/camcontrol
2010/9/1 Dag-Erling Smørgrav d...@des.no: Consider the following commit: r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines Provide an option to make camcontrol `minimalistic': if the (env/make) variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be built that only knows the rescan and reset subcommands. The resulting code is small enough to still fit onto the boot floppy. This makes /stand/camcontrol completely useless. Do we still care about fitting sysinstall on a floppy? The full camcontrol is about 100 kB larger than the pared-down version, but I'm not sure the difference is that big when it's crunched with the rest of /stand. text data bss dec hex filename 268751 26464 54112 349327 5548f camcontrol-crunch 355122 27064 58904 441090 6bb02 camcontrol-full My 2 cents: I think we don't really need to care about the size for rescue binary after the splitfs VFS layer have been introduced to libstand? Build of release split MFSROOT was 2006-ish and I feel that this can be gone. One of my hope is that we can add bzip2 or even 7zip support to loader, though, which may not fit a floppy though. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: porting cputick2usec() to userland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/09/01 16:03, Alexander Best wrote: hi there, there was a thread some time ago related to porting cputick2usec() to userland [1]. however it seems the idea got lost at some point. i remember uqs working on an implementation, but can't remember the details. a few people including uqs and jhb liked the idea. any comments on that? I think uqs@ actually have a patch but can't seem to access his git repository anymore for some reason :-/ cheers. alex [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70400.html - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMfuB/AAoJEATO+BI/yjfBnwoIAJF+Wu3E8m92PkNmmpdwymU1 BFbtzxZ//MIDmOkrW5qnIjfQPpcnizXX12Le8/6YFbBjP2fDqsn06CwVb6BKX6Kb bJfzMLKIEN/zaGVNmteduHLPL7Y0xv8TKUspk2B7wfpgk3aLCuUH00e3kSHsriwm Cwyoqn+GQs4GC2056bV3LL7PdQec6vfaQtBlBN9+WavHQFbaJsBAOqx+Ekkvu8t7 PcRQlvLyp3ledsO5ezJjlnMsyvu4JAbAv+/RFiODLhLlpiJpa0y8T8cqnA5FLTIj ZAvtW/Adu28H2aMvhRWHT0JzoOVbZWsuK2FCgw9gY4KYXlePeTUk+EJlfN+YWtE= =f55Y -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Winbond Watchdog
2010/8/7 Dag-Erling Smørgrav d...@des.no: Xin LI delp...@delphij.net writes: I'm still polishing up the driver, there seems to be no way to figure out the base port address directly (datasheet said it's either 0x2e and 0x4e) so for now I have its device identify method to do some dirty hacks (outb/inb directly) and only check if with appropriate key entered to the port we will get non-0xff value. Sounds gross, but if there's no other way, I guess it'll have to do. I imagine you check the PCI id etc. first? It's not a PCI device unfortunately (at least, not the one I have encountered on my Supermicro board). I have a code snapshot at: http://people.freebsd.org/~delphij/for_review/winbondwd/ But there are some good features in bz@'s driver which I would like to bring in. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Winbond Watchdog [Was Re: Supermicro BIOS's watchdog feature?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/01 00:12, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: Dag-Erling Smørgrav d...@des.no writes: Perhaps the motherboard has additional watchdog hardware? If you disable the watchdog in BIOS, does ichwd still work? If I kill -9 watchdogd the system do reset itself so I think ichwd(4) really works even if BIOS setting is 'Disabled' (but I'm not sure if this method is right? Looking at the code I think the answer is probably Yes though) Yes. This confirms my hypothesis, which is that your motherboard has additional watchdog hardware, and that the BIOS setting controls that, not the ichwd watchdog timer. Just disable the watchdog in BIOS and use ichwd instead. Thanks, you are absolutely correct that they are using another watchdog (on Winbond Super I/O chip). With help from some datasheets floating around the Internet and playing with the motherboard a little bit, now I have a first cut of a watchdog(9) interfaced driver for the chip and have confirmed working on the motherboard. I'm still polishing up the driver, there seems to be no way to figure out the base port address directly (datasheet said it's either 0x2e and 0x4e) so for now I have its device identify method to do some dirty hacks (outb/inb directly) and only check if with appropriate key entered to the port we will get non-0xff value. I'm not sure if that would be acceptable? I'll try to further read the spec and see if we have some better way of doing this and publish the driver code hopefully in the next week. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMXUv9AAoJEATO+BI/yjfBd3QIAMi3JV5+kQA9Mq6VJvs307jM GStdcuG0zXfXIsS4H4r8VYdphUD8aTk10QNCXBLnXSW5fZjFMlyEocpPlSn1Jtah TM1uApjc5rrAIdM9S0GQxPUdJLvc7O3okTsQRnze0Nv8EvO0p6ZQinRjMJT/1qfH CuggvbTsAO9Yg5N65CsbHIUgPm1vu5a/uyFVN7nhpWtzaCuex+mB0n1r5qObPqY2 UaiF/s3SFssJtx27cwCo4KuuLhX9aI/qaDzjpmpBXIGY//gGYjW5cd180bW8V744 abWfVExqQqtdRLXqacrjWeUyrRE27pZ6ghj/6cRBwK018GLweFntX9p5SJ9S3Rs= =cK+Y -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lint(1) improvements from OpenBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/25 02:39, Frederic Culot wrote: Hi, I noticed on the the FreeBSD list of projects and ideas an item related to lint(1) and the port of improvements from the OpenBSD project: http://www.freebsd.org/projects/ideas/ideas.html#p-lint I would like to know more about this project but unfortunately no technical contact was specified on the web page, hence I write to the hackers list. Does someone have more information related to this project (what improvements does the text refer to)? Has someone started working on it? I think it's talking about OpenBSD's xlint (src/usr.bin/xlint). No I am not aware of anyone working on this. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMTi3/AAoJEATO+BI/yjfBxMAIAK5Hz21ipEJFMao1U0BXUEun WGofq+cokgXYA94JsfOrl/KmwwaEetZVp21Gc1yyL+Kp4ZYvzpv+eEzdm98TH5rv wHJp298j/hs0gxkrDP2XqnIrjd+YCuJg19CbZ7rEC6SeuAJ4mEJR1DW6dpmM7TSa lZnGgTnZp6SMUY2knU2GQfQjd+f0IXP370ksjSF3CPMwaKHzKoCLLWHR9uBacGjb QLPU4AvmExxfTa6icsfCVNNcIeFdq6653Hq9HJdsvGbkX623PMxzcG/BfeIETDUo /zwOnx1Pp27cpvVNf7K6tqt2aNZlr2Fjxq9mz4hy6yAnVmJiqX2vz1Z2jAN6lrw= =YWXj -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel modules into static kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/19 20:50, Tim Judd wrote: Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? Yes. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRd0KAAoJEATO+BI/yjfB9EEH/38i8b0LdphAnpKEmKO0u1eU tCqM0LiSd8iJM3ZxilBvrIVofDXEqQW6PoDZ3m3KTRu39muZRqhRB1aVt3vbTCev xhDFEAgVrC0G16/JI9OE3h4Qtg0WT85Oyt/pZOTpzlaSXySByYyLHL2WbcC2FAMg t1R3ej35jqdmo2heSq3TnuRHQ6ykeqWqtHN18SMFrs+ywC6FYvgpR7rA2gsSa194 tiHEleR0IiBeklksHX38GPwWytYhgVwOAEdy+6JlFqcHAulFON47jjhq/9YAa6sq xAYBoJStnIVqIf4pjvzMzUrn07DUVbs9P4xbgJkTU0NXuuFvyaiH0VgzuU/zHt8= =Q7Yq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using lex in a shared library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/07/02 16:34, Matthew Fleming wrote:
On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper yanef...@gmail.com wrote:
On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming mdf...@gmail.com wrote:
I have the following Makefile for a shared library at $work:
ISI_TOP=../..
LIB=isi_date
SHLIB_MAJOR=1
SHLIB_MINOR=0
SRCS= date.c date_parser.new.c lex.yy.c
INCS= date.h
INCLUDEDIR= /usr/include/isi_date
YFLAGS+=-vt
FLEX= /usr/bin/flex
LDADD= -ll
CLEANFILES+=date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \
check_date.log test
lex.yy.c: date_lexer.new.l
${FLEX} $
CFLAGS+=-I${.CURDIR}
#CFLAGS+= -g
.include ${ISI_TOP}/isi.lib.mk
This builds fine as on i386. I'm trying to get all our user-space to
be 64-bit clean, and I run into an error when building on amd64:
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld:
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a(libyywrap.o):
relocation R_X86_64_32 can not be used when making a shared object;
recompile with -fPIC
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a:
could not read symbols: Bad value
The following diff makes the compile work, but I have no idea (yet)
whether this will run, if it's the right solution, etc.
Index: usr.bin/lex/lib/Makefile
===
--- usr.bin/lex/lib/Makefile(revision 153343)
+++ usr.bin/lex/lib/Makefile(working copy)
@@ -4,11 +4,16 @@
LIB=ln
SRCS= libmain.c libyywrap.c
-NO_PIC=
+#NO_PIC=
+SHLIB_MAJOR= 1
+SHLIB_MINOR= 0
+
.if ${MK_INSTALLLIB} != no
LINKS= ${LIBDIR}/libln.a ${LIBDIR}/libl.a
LINKS+=${LIBDIR}/libln.a ${LIBDIR}/libfl.a
+LINKS+=${LIBDIR}/libln.so ${LIBDIR}/libl.so
+LINKS+=${LIBDIR}/libln${LIB_SUFFIX}.so
${LIBDIR}/libl${LIB_SUFFIX}.so
.endif
.if ${MK_PROFILE} != no
The static-only version was done on purpose:
Revision 1.2: download - view: text, markup, annotated - select for diffs
Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman
Branches: MAIN
CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE,
RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE,
RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP,
RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0
Branch point for: RELENG_2_1_0
Diff to: previous 1.1: preferred, colored
Changes since revision 1.1: +2 -8 lines
We really, really /don't/ want to have a shared lex library. Also,
current users should note that the old 1.1.5 lex can't process the
new scan.l, so you have to copy initscan.c to obj/scan.c before it will
build.
Garrett Wollman probably has more information about why this was done.
I think that fixing the lib to build with the appropriate options (not
-m32, or CPUTYPE = some 32-bit x86 variant, etc) is what really needs
to be done here.
I guess I'm still confused. The isi_date library compiles fine if
it's for i386, but switching to amd64 gives this error. Since I
didn't specify any -m32 flags or anything, and it's essentially using
the standard bsd.lib.mk magic, I am trying to figure out why the
32-bit isi_date.1.so built and the 64-bit one won't. Was the 32-bit
version building successfully an unfortunate fluke? What build flags
would get the shared library to link with -ll?
I think that amd64 requires a static library be compiled with -fPIC if
it's being linked into shared object. This should not be done for
normal static libraries, though, as this could give some performance
penalty when it's not needed (i.e. a static binary).
Unfortunately, I didn't write this library, and I don't know anything
about lex(1), so if I need my own yywrap() that might be fine, but I
wouldn't have the first clue what to put in there. :-(
I think you could probably just change the code and use %option noyywrap
in the .l file? (do your code call yywrap() directly?)
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMLnvNAAoJEATO+BI/yjfB5Z0IAKLkyPPdzjeA0XJiLC3yTPRl
qzMHis5eo9rfFZgFpUzc22AQqxtu6pCYeovnESPiMkxG4r+Y20qQelJWEJs0nADT
AOAqv1dftwnd+WDbdkUOdBwELOOghJerlPClrn8XV5WiBVSf0GUNWeITXbOUEe3n
Urk5rINfoDwgXO1Xg/uxrEVsvJlCpzoKhS6ioQ8MW0QoBLk7WNujNakYqTYMCbLe
yaVkB44ab8Epka+LyjCWQcGtevwE+YX847malrAhtW4RChMEvIzZ9o76vAWPAo6q
8DRjRdN1xtC9hx3yH97kv3nFNMnvYRVCOTiVuatQKDCri60WyQ7vlhyi/zCw5jg=
=Vzkj
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using lex in a shared library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/07/02 16:52, Xin LI wrote:
On 2010/07/02 16:34, Matthew Fleming wrote:
On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper yanef...@gmail.com wrote:
On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming mdf...@gmail.com wrote:
I have the following Makefile for a shared library at $work:
ISI_TOP=../..
LIB=isi_date
SHLIB_MAJOR=1
SHLIB_MINOR=0
SRCS= date.c date_parser.new.c lex.yy.c
INCS= date.h
INCLUDEDIR= /usr/include/isi_date
YFLAGS+=-vt
FLEX= /usr/bin/flex
LDADD= -ll
CLEANFILES+=date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \
check_date.log test
lex.yy.c: date_lexer.new.l
${FLEX} $
CFLAGS+=-I${.CURDIR}
#CFLAGS+= -g
.include ${ISI_TOP}/isi.lib.mk
This builds fine as on i386. I'm trying to get all our user-space to
be 64-bit clean, and I run into an error when building on amd64:
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld:
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a(libyywrap.o):
relocation R_X86_64_32 can not be used when making a shared object;
recompile with -fPIC
/data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a:
could not read symbols: Bad value
The following diff makes the compile work, but I have no idea (yet)
whether this will run, if it's the right solution, etc.
Index: usr.bin/lex/lib/Makefile
===
--- usr.bin/lex/lib/Makefile(revision 153343)
+++ usr.bin/lex/lib/Makefile(working copy)
@@ -4,11 +4,16 @@
LIB=ln
SRCS= libmain.c libyywrap.c
-NO_PIC=
+#NO_PIC=
+SHLIB_MAJOR= 1
+SHLIB_MINOR= 0
+
.if ${MK_INSTALLLIB} != no
LINKS= ${LIBDIR}/libln.a ${LIBDIR}/libl.a
LINKS+=${LIBDIR}/libln.a ${LIBDIR}/libfl.a
+LINKS+=${LIBDIR}/libln.so ${LIBDIR}/libl.so
+LINKS+=${LIBDIR}/libln${LIB_SUFFIX}.so
${LIBDIR}/libl${LIB_SUFFIX}.so
.endif
.if ${MK_PROFILE} != no
The static-only version was done on purpose:
Revision 1.2: download - view: text, markup, annotated - select for diffs
Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman
Branches: MAIN
CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE,
RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE,
RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP,
RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0
Branch point for: RELENG_2_1_0
Diff to: previous 1.1: preferred, colored
Changes since revision 1.1: +2 -8 lines
We really, really /don't/ want to have a shared lex library. Also,
current users should note that the old 1.1.5 lex can't process the
new scan.l, so you have to copy initscan.c to obj/scan.c before it will
build.
Garrett Wollman probably has more information about why this was done.
I think that fixing the lib to build with the appropriate options (not
-m32, or CPUTYPE = some 32-bit x86 variant, etc) is what really needs
to be done here.
I guess I'm still confused. The isi_date library compiles fine if
it's for i386, but switching to amd64 gives this error. Since I
didn't specify any -m32 flags or anything, and it's essentially using
the standard bsd.lib.mk magic, I am trying to figure out why the
32-bit isi_date.1.so built and the 64-bit one won't. Was the 32-bit
version building successfully an unfortunate fluke? What build flags
would get the shared library to link with -ll?
I think that amd64 requires a static library be compiled with -fPIC if
it's being linked into shared object. This should not be done for
normal static libraries, though, as this could give some performance
penalty when it's not needed (i.e. a static binary).
Unfortunately, I didn't write this library, and I don't know anything
about lex(1), so if I need my own yywrap() that might be fine, but I
wouldn't have the first clue what to put in there. :-(
I think you could probably just change the code and use %option noyywrap
in the .l file? (do your code call yywrap() directly?)
I mean that the -ll can be just removed for most .l files that have
noyywrap.
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMLnwpAAoJEATO+BI/yjfBWqYIAIIWXmxVQd4M50KGu95aqlcm
cfNKfyNzVfskdIj6Bcv5R/rRBAcqzdO+lPFdOupe0yMLFe0RUXiakNrI/NsMwKDx
T/JErNiOgIUnsAKzkeV720nd73o1oTFGwIfqJ0XoNzYwl+bPU1JWG6cognXSlJha
MCVVO8Rh/91Sle0KUb51dhCC+LFES+F9zzDMrPb1cGihN2CLZgaLvdDVbLYuRXn3
SZd62lE2dCZiILy7fy3nJRhybDJf/9hvu4WWFlmNPGt95U6Nzo9KBx9/MHMuvGCm
kt7BUxj/zxR2PW9gBhn7ao8AtOkwA5qKSm07xb3w0LL6xXtgZDQpXQNwMIZP57g=
=Ilvp
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http
Supermicro BIOS's watchdog feature?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Is there anybody used the Supermicro's BIOS watchdog feature (reboot if no OS activities)? It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro BIOS needs some special treatments which is beyond what ichwd(4) and watchdogd(8) would do... Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMKwf0AAoJEATO+BI/yjfB+uYH/j9c0VKgq84HUufNztoLvsJ8 zYNaj9xV+mKDSxTEeQsQelqqUkmwfEF/ibF8N6sSUZ9IH1fOVZTxu/NdTQQ4Vf9c VZQB6gusBl3xL4/uYHubLwVLsZVYb6i/CiodFJ5h+5sv4rvQAy9thQARmyw+Lfpx ID3zAxrAkwoCCjABEEppRpEXxzchb/Bvs4g40d+15Rk+aDqEG8HGtsw5QgXN+eZ+ eu/hXg+Z+j9A+RiBYB93kA1+o85e6C7v4hybtnXIXctGHxklt82QiGYMz2x1c1Jp ZVbHfVqM+Kqdl7Cn2S3TCiBXR+zkaB9mwcDHXqu9iBgPxv5nrwZZPfmDhsC9QdM= =TcIK -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Supermicro BIOS's watchdog feature?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/06/30 14:49, Dag-Erling Smørgrav wrote: Matthew Jacob m...@feral.com writes: Xin LI delp...@delphij.net writes: It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro BIOS needs some special treatments which is beyond what ichwd(4) and watchdogd(8) would do... What do mean special treatment? The watchdog timer can be disabled in hardware (by pulling the speaker pin high during boot, IIRC). Even if it is enabled, it can be caught and ignored by the SMM firmware. Some BIOSes have options to enable or disable the watchdog timer, which I assume means that they flip a bit that tells the firmware to either catch it or pass it through. Unfortunately, although it is possible for the ichwd driver to detect programatically (by checking an MSR) if the watchdog timer is disabled in hardware, it is not possible to determine whether it is disabled in firmware. Hmm... Sorry I think I didn't described the behavior accurately. Currently if I enable the Watch Dog option in BIOS, the system reboots after ~5 mins regardless whether I have ichwd(4) and watchdogd(8) loaded. Looking at the boot -v output, ichwd would disable the watchdog and watchdogd would enable it, pat it as expected, but this won't stop the system from rebooting by the watchdog. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMK788AAoJEATO+BI/yjfBPHkH/jWIZEX9/tmL50AgXzkfEEXU zNn+d2CAGA/+6wUt73aizKq1dk0eIz5ze9V+RR59cjJH4ftXLg2Tn34Ed2OYNTZZ JxFP7go4RIO1P5a3WIM6A8MVykUCIv+JhfXR3yG8Fy0h9DbmL2zwLPlqYPLBAXOK y+2DKYXqmA94qetPmrrm8b4WDRD9a7dwH26E+D8AslPJcABynjrdv0Ou8MLKC3g7 K+3YcgaCP2dowyy0gJzfNi2WTJyPmEtLsmFGzw14enP5tpDNU0t6yR4rkPbHkQSM 6BRF7gwZiAQoa4Az/S72RvjVR+OXehJGNNJLM6YRTH4fB2QiZ3YdmJ3WyeUE/TU= =EA7X -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Supermicro BIOS's watchdog feature?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/06/30 15:19, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: Hmm... Sorry I think I didn't described the behavior accurately. Currently if I enable the Watch Dog option in BIOS, the system reboots after ~5 mins regardless whether I have ichwd(4) and watchdogd(8) loaded. Perhaps the motherboard has additional watchdog hardware? If you disable the watchdog in BIOS, does ichwd still work? If I kill -9 watchdogd the system do reset itself so I think ichwd(4) really works even if BIOS setting is 'Disabled' (but I'm not sure if this method is right? Looking at the code I think the answer is probably Yes though) Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMK9SYAAoJEATO+BI/yjfBUYIH/jPJX3kEZt7o9sia7+H21SBX xtuRZ+bz7q0dPKmdpHVPuWZNUB7mauFgtlZdUcu7gx1bKLb8XrOO7FuUmh6n8QXy MwzeCVnZCW8EbSthkOaJf7KnQjC6QebcRtSJr9buldYv7U5AW7YpzDyOwk7AhjOc YBK12GSkmz/b9FtURh6NECtzY3v5W8cquHGHhLMVFe1t7/gKF2KVOHE8MEKjGG8a dlG6JE4SJtFT7Y3utHZqHoDZkuI3SBdXY31PYFoUY31LSJ5cSkzA/3eYbB7l1WL6 BjhLAb1qeBwYyF3nzWYPtv/dtWs0dlxEtUGu2XFXr/vejCQ2VNdkGJN1FGkAjY4= =fvdq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proposed change to style(9): require yoda style if statements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/05/13 14:26, Garance A Drosehn wrote: At 10:36 PM +0300 5/11/10, Eitan Adler wrote: My proposal is simple: require that any if statement that compares a constant to a mutable variable be written as if (constant == variable) instead of if (variable == constant) this prevents an extremely common programming error if (variable = constant) I did this for awhile in my own programming, long enough ago that there was no cool yoda name connected to it. But I found that in some situations it makes the code harder to read, so I don't do it as much any more. I don't mind if people do it, but I do not think it should be an official recommendation in style(9). Or to say it another way, I'd be annoyed if an otherwise-correct patch was asked to be rewritten just because the developer used (variable == constant) instead of (constant == variable). I used to use this style of programming a lot but gave up ~7 years ago when I found that some C++ compiler can be confused in very ugly manner (due to type mismatch), not to mention that using this style sometimes makes the code harder to read. It turns out that modern compilers are more sensitive about this type of mistakes, and, more importantly, making code more readable would usually save debugging time. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL7Ig/AAoJEATO+BI/yjfBiQwH/R6nlA5DciXXHfl1XDxDMe81 fnmOCgCAbidKySiwlmKJhsfLuZgKQX/jVqO2Z28X+0cOQVqLw2bZ9hlfyZ306uGy vwYDXzs+E805T+S9UArKe7jJdoeuQajJ7w+Z0eJfCjFBgb9KCW/KTIaPaFJJtvbS azVB0q7tuZGd2xPj6iNmuxteeN1B0aixYNov5cGtSs3anH9rwFPFqJAntN8nRWTm 0W9ocOgi/cNYfNMuapvxSsRv2IJiAe+EpikpRhDJT2ushFnQ1ML4a2Mgld7sz+jn YvYHUi5LAnyl7oIS5hxF7d7ADINmPuKnoBNbgiYoMLpNjsE1thAsXPFv8SWI3qs= =ngfR -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BIO_FLUSH and ips(4)
Hi, On Sat, Apr 24, 2010 at 8:20 PM, YONETANI Tomokazu qhwt+f...@les.ath.cx wrote: Hello. The ServeRAID driver, or ips(4), seems to distinguish read or write requests with a macro called ips_read_request(), which is defined as #define ips_read_request(iobuf) ((iobuf)-bio_cmd == BIO_READ) in its strategy routine and a few other places. So when the request is BIO_FLUSH, the ips driver issues a write command (IPS_WRITE_CMD) with length == 0, right? My question is, do ServeRAID controllers treat 0-byte write command as a sync-to-disk request, or is there any command for that purpose? There's a command called IPS_CACHE_FLUSH_CMD defined in ipsreg.h, but it's not used anywhere in the normal code path. It seems Linux driver is using it (on shutdown/reset) but I'm not sure if this would have some side effect, etc.? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Error checking in ioctl(2)?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/04/22 17:45, Garrett Cooper wrote:
On Thu, Apr 22, 2010 at 4:36 PM, Matthew Fleming
matthew.flem...@isilon.com wrote:
Hi hackers,
I realize that this isn't 100% userland code, so the checks should
be minimalized, but when looking at the ioctl(2) syscall code (at
least I think it is... there's another dupe hanging around in
sys/dev/hptmv/ioctl.c), I had some questions related to the error
handling not being done in the code:
if (size 0) {
if (com IOC_VOID) {
/* Integer argument. */
arg = (intptr_t)uap-data;
data = (void *)arg;
size = 0;
} else
data = malloc((u_long)size, M_IOCTLOPS,
M_WAITOK); /* XXX: can fail -- do we care? */
malloc(9) with M_WAITOK cannot return NULL. So the rest of your XXX
comments are not at issue.
Also, free(9) is documented to do the right thing when asked to
free(NULL).
copyin/copyout are really just bcopy but unlike most kernel code they
are allowed to take a page fault. They deal with this by setting a
function pointer in PCB_ONFAULT, which is used in trap() to set a return
instruction pointer.
Matt,
Awesome. I can see I need to do a bit more reading in malloc(3) :)...
Thanks for the info!
It's actually malloc(9)... I personally feels it pretty confusing at
the beginning when I learned about it.
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL0O76AAoJEATO+BI/yjfBOr4H/jTKZ4MSw4ukOsAGmSsRKz9Z
J2Jw/8DH7Kv1VZD8Dsvzma8/gF94YqbaBNsiz1/bKLF0zJrecpEucvglmEzbhthP
eep5SJHMK2mKnX+RgfIrGr/iQoK03kmXW74UcIYAeLhgibFZ7gqnqnnIay1pObic
+GUCHFAV7XW+mHs9sITCNg4d4DprBn2m7VtccPRtIaHfLsRHo9xjI6Zhendf/D4H
5r+ZO0ndU4snmk7BPrHpjiP+KDfyZM0gaC6IOf+t7gUfHqf0/uOrLiQavTUqBw4K
WqMLUok1orbLa1oV/wITeYbcdPbvbNCp4B+ZSU0PngERbmJYqg+DrYLZ0572Lxo=
=zYtp
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: To sendmail or to postfix that is the question?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/10 08:47, Steven Hartland wrote: A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? No, but the m4 based configuration would make your life easier. 2. Is postfix that much easier? Yes, I would highly recommend using postfix if you don't want to spend a lot of time on mail server. As a bonus postfix have better track record in terms of security. 3. What would people use for: 3.1. POP / IMAP support? Dovecot or cyrus-imapd. I'd personally recommend dovecot for new deployments, since it supports features like using different storage for different subfolders (i.e. use Mailbox for archive, etc). 3.2. Web Mail? Connecting from IMAP: squirrelmail, roundcube, etc., I'm not a big fan of web mail though. 3.2. AV / Spam filtering? amavisd-new + clamav. Note that clamav is somewhat CPU hungry if you have high e-mail volume, consider deploying multiple layer of delivery system (multiple MX serving anti-spam purpose, and deliver to a group of backend system; this could be an overkill for small to medium sized companies, though). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLl+8CAAoJEATO+BI/yjfBX1wIAJgT8QPLi7H2iS2RBJ8J2JDr 62ngaY0q099b8ajCgiIPWm7IMyvlEyIf3FVde9tbQls2UiojDkJR8Frd/rNGBfja mF/6tMSs77skN3vyoZzX1hj98rMbLx7ccPUwzZTFxgOsoRXpFKu+V+t9TDfqiRh5 3gSBlyinqTuoQzpO9PPjRACzY0sZLtTsyy2GoX52HeSjKn4kh2SogTcf1I9Y/+cq Eap91F4J8vKmqHh4Eqm5qAJ+WT2JwkwQpnHAjG6bej4x05kmNE6OLT7O83dip1Ga RzafJRgCPIgkSeh7f/v+rCv653jxSNswo1kJ+6HfDKkUc4l+naoP+ZKL1bo2RKo= =G5Ri -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tiny lib/libkvm/kvm_proc.c correction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/05 11:26, Alexander Best wrote: hi there. does this look right? Not to me, the value is not to be used this way and the comments above the code explained the same thing. I think we should use cputick2usec but it's not available to userland (one have to copy cpu_tick_frequency and friends). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLkV1EAAoJEATO+BI/yjfBvhcH/3LD5SOscV7wmzVazQtvhOpd C4xhRlnlZEniI8qrKP1L55Q9eTntxzcWZPhmImb5UspSX6a5aRsWHrySlD82Vjgy u/n/tz/YbhGV4QasmRxrXOF8wrPh3ie0W6912hFHmMZ6shgfm9GvoAlltnCcnnNp O330syWOVqf/q+9y5FOXIschYPs8HmAP7Fy5pMragpzdmpg5uCBdKXbekvfqiscN qPOOrzzyvkmXS3rKBY5vnRHqJTaOveSuE6KEjN1x/D0ZJ71kY6tLwZCCMc9wNlJB Dv/U3ZPo4lUki2tZTOi9bo4KEkLR/3zrFQ5VeaDhYI/FHCQTFB1jhNoahU2WlB0= =JOn5 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tiny lib/libkvm/kvm_proc.c correction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/05 11:59, Alexander Best wrote: Xin LI schrieb am 2010-03-05: On 2010/03/05 11:26, Alexander Best wrote: hi there. does this look right? Not to me, the value is not to be used this way and the comments above the code explained the same thing. I think we should use cputick2usec but it's not available to userland (one have to copy cpu_tick_frequency and friends). damn you're right. i completely overlooked that comment. would it be worth making cputick2usec available to userland? is kvm_proc.c the only candidate in need of converting cpu ticks to usecs? I'm not sure how to do that unfortunately, is there a way to expose a kernel variable to userland which also works on a crash dump? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLkWvQAAoJEATO+BI/yjfB1zYH/jNcRww4bePZqVl7zM9zUsyA a6LZ9JivHSgxmMfcLSrqJMBdLdTFgSPFkP7bADKMDoSE/qY6zDMFbid+GVqn1XGk 8jTJiiTXmMkb24+43oQPvVgw3XPoSJJdrJIOlHPr3rzIkHFE0M0ivMETA95WBEQJ uPHQcCSLSRAgdLju+PzfOTq4UiCZ4SXdLfbw+xrLB4IVKzjgtKQL1XYXL5Lgpc94 +OVV30471gZyjJM79aiVYzNs6ZMKTrxxHbUJujgFM3irfJrxVf52XNTa0vmBI6aW yL58dQo+q1/KnzLOpK+T7+c33ZUKakSzkMCxN/IJdUteOHqquZSS0EEEcAkDGKI= =IN3b -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: svn commit: r204615 - head/sbin/newfs
On Tue, Mar 2, 2010 at 7:19 PM, Maxim Sobolev sobo...@freebsd.org wrote: Xin LI wrote: On Tue, Mar 2, 2010 at 6:05 PM, Maxim Sobolev sobo...@freebsd.org wrote: Author: sobomax Date: Wed Mar 3 02:05:09 2010 New Revision: 204615 URL: http://svn.freebsd.org/changeset/base/204615 Log: Teach newfs(8) to understand size modifiers for all options taking size or size-like argument. I.e. -s 32k instead of -s 32768. Size parsing function has been shamelessly stolen from the truncate(1). I'm sure many sysadmins out there will appreciate this small improvement. Bikeshed: why not expand_number()? I did not know that function existed, but even if I did, I am really not sure if adding dependency on external library just to save 200 bytes of code worth it. Considering that newfs(8) is often embedded into various space-tight/custom things, adding dependency could cause more harm than good. In any case, I do not feel strongly about that, so I can change it to use libutil if people feel like it. [Moved from svn-all@ to -hack...@] I'd prefer depending on libutil since it's installed as a /lib library which is usually available, as libutil is not something easily avoidable. By the way I'm curious why these (humanize and friends) are not available as libc function? Because they are not part of POSIX perhaps? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: about libstdc++ ,change the defaule allocator
2010/1/13 Jiandong Lu lujiandong1...@yahoo.com.cn: hello,everyone. I get the current source code from svn,and successfully build world. c++'s standard library is from gnu. This library privodes many allocators: bitmap_allocator_base malloc_allocator_base mt_allocator_base new_allocator_base pool_allocator_base I want to know how to set a default allocator,and how to change it. I have read the Makefile: /usr/src/gnu/lib/libstdc++/Makefile I have no idea why you will think the allocator is being changed here... The standard and portable way to override the allocator is at the point you instance C++ templates by specifing Allocator parameter. If, however, you want to globally change the default allocator without touching all your source files, the only way is to make modification on c++allocator.h, which is, in my opinion, never permitted by the standard and banned by god. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: uiomove and mutex
On Mon, Jan 11, 2010 at 11:22 AM, H.Fazaeli faza...@sepehrs.com wrote: dear gurus man mutex(9) states that: No mutexes should be held (except for Giant) across functions which access memory in userspace, such as copyin(9), copyout(9), uiomove(9), fuword(9), etc. No locks are needed when calling these functions. can someone pls. explain why it is so? These routines MAY yield control. Mutexes should never be held when the calling thread is going to sleep, etc., since they are not supposed to be held for long time, and holding mutex while sleeping may cause deadlock or livelock if it has been slept due to someone else sleeping and requires the mutex to be awaken. Suppose I have a kernel buffer to which kernel writes and userland processes read via a character device. In the device read method, If we unlock the mutex just before uiomove, is it guaranteed that kernel does not write to the buffer in the middle of uiomove? If yes, how? What is the solution in such a situation? rwlocks? an intermediate buffer? This really depends on the nature of your operation and there is no generic solution. If the memory block is managed by the driver, it would be probably something like this (just an example to demonstrate the idea): (define a temporary pointer, say p) - hold the mutex - p = the block - remove the block from your buffer queue - unhold the mutex - uiomove to userland - hold the mutex - add p back to your buffer queue - unhold mutex However, you can of course find something better than this for situations more specific and avoid some mutex operation... Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
Hi, On Tue, Dec 22, 2009 at 2:06 PM, Jason Spiro jasonspi...@gmail.com wrote: jhell jhell at DataIX.net writes: This is what shell aliases are for and what a system admins job consist of. If it gives you that much of a problem just alias it out for your self in your .cshrc .shrc .bashrc .bash_profile etc. If you want to change something on a more per user basis figure out how to setup a skeleton directory so when a new user is created they get all the files from that skel copied into there home. If it is more of a system-wide change then the shell files in /etc will probably be of more use. PS: Applying your changes to a mailing list are not const. Using aliases would help me, but wouldn't help people elsewhere in the world who don't know what SysV killall does. Renaming FreeBSD killall would help prevent them from getting burned, perhaps on a busy production server, even once. I'm afraid that it's too late to change either parties, i.e. there would be a lot of scripts that rely on the BSD or Linux behavior, etc. Instead of making changes to killall which already diverge between open source implementation and closed source ones, it might be better off to have administrators to learn some more consistent ways to do the same task, i.e. pkill. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
On 2009/12/22 14:54, Jason A. Spiro wrote: Hi Xin, On Tue, Dec 22, 2009 at 5:34 PM, Xin LIdelp...@gmail.com wrote: I'm afraid that it's too late to change either parties, i.e. there would be a lot of scripts that rely on the BSD or Linux behavior, etc. That is why I suggested that you first show a warning message for five years, then do the renaming. killall can be used by scripts which just works in the past, and will never notice the warnings. Also, killall is not that dangerous on FreeBSD, we should ONLY give warnings when it's really necessary, otherwise users would just ignore all warnings we gave to them. On the other hand, it seems to us that warning messages won't work, no matter how long we give it, it is being ignored by a majority of users. Instead of making changes to killall which already diverge between open source implementation and closed source ones, If you rename the open source killall to fkill, then you will no longer have a killall command which differs between open source and closed source. Then users are already familiar with FreeBSD would have to learn what fkill is, and after all, having them to pay for mistakes made by commercial Unix vendors does not seem to be a fair option. it might be better off to have administrators to learn some more consistent ways to do the same task, i.e. pkill. It would be good if sysadmins learned not to use killall. But I think that most sysadmins who are already used to killall are unlikely to learn not to type the command killall unless you rename open-source killall to a different name like fkill. Well, I'd say it's too late for us to change since it's several years after we have 'killall' our way. I think it's impractical to expect all sysadmins to switch to pkill. Pkill is missing the option which displays a list onscreen of which processes were killed. I sent a feature request to the maintainer, but there is no guarantee that the maintainer will add that option. And maybe there are other pkill options which are missing from skill. pkill have '-I', at least on FreeBSD... Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
On 2009/12/22 16:21, Jason Spiro wrote: Xin LIdelphijat delphij.net writes: killall can be used by scripts which just works in the past, and will never notice the warnings. On what scripts will nobody notice the warnings? For example, AFAIK, cron job output is always mailed to root. The only scripts I can think of are scripts called by web applications like PHP, and I can't think of any concrete case where they would run killall. killall is used for instance, shutdown scripts. Yes you get the warning message on your console but not the remote ssh. [...] Then users are already familiar with FreeBSD would have to learn what fkill is, and after all, having them to pay for mistakes made by commercial Unix vendors does not seem to be a fair option. As I wrote elsewhere[1] in this thread, it seems to me the commercial vendors made no mistakes here; only Linux and FreeBSD made mistakes. I think we can hardly call it a 'mistake'. Having a command that do the same thing what shutdown(8) should do doesn't seem to be the Unix way to do things. Speaking about commercial vendor, Mac OS X have the same killall as FreeBSD have. Granted, Mac OS X is not something we consider as traditional Unix, but it's certificated as Unix operating system after all. Well, I'd say it's too late for us to change since it's several years after we have 'killall' our way. I replied to this in the last paragraph of text in [1]. It's way too late to say something a mistake after about 15 years. I think it might be reasonable to document the System V behavior and how to do the same thing on FreeBSD in killall's manual page, but I'm afraid that's all we can do nowadays, since FreeBSD users are already get used with our killall behavior, changing the behavior/semantics after ten years just make a mess, so please drop this. pkill have '-I', at least on FreeBSD... There is no such option in pkill on Linux.[2] Please talk with the authors of Linux pkill. In open source world a well written patch would say more than a thousand of sayings. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
On Mon, Dec 21, 2009 at 10:31 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Craig, and hackers, are you both willing to do this? No. killall is not part of standard, and, just because System V choose to implement that way, does not warrant that FreeBSD has to. Moreover, user can always alias /sbin/killall to 'fkill' and 'kill -15 -1' to 'killall' if they really want the System V behavior. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Regarding enabling IOAPIC on Intel Dual core processor based boards having Broadcom controller
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Ravi Shankar wrote: Hi, We are using Freebsd6.2 bases OS on our LV 5200 Series Intel Dual Core Xeon bases processor(Wolfdale-DP-ULV). In the carrier board hosting the processor we have BCM5703 controller. Currently we are using only one core in 32 bit mode and planning to use dual core where we need to enable IOAPIC. When IOAPIC is not enabled I see the bcm/bge driver is attached to IRQ10 and everything works fine, but when I enable IOAPIC I still see the boot msgs show that bge is attached to irq10 but the Broadcom controller does not come up. I found interrupt storm on irq17 ( remember without IOAPIC enable there are not IRQ assignments beyond IRQ16),looks like the controller is interrupting on 17 while driver waits on 10. When I stop and loader and assign it manually using config command set hw.pci8.9.INTA.irq=”17” , everything works fine. Would be great if some one can throw some light on this IRQ mapping when IOAPIC is enabled and possible fix ( Software or BIOS?) NOTE: Other devices ( Intel controller (em driver)) are working fine only this BCM5703 is having issues with IOAPIC Is it possible for you to use some newer FreeBSD release, i.e. 6.3 or 6.4, or 7.x even 8.x and see if that would solve your problem? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksmj5sACgkQi+vbBBjt66AJvwCeJVlT301Ulu54C+UwvdNXjTxY KCkAn19OqPOpfeifzkRdf2zooRar9UrK =i1Dc -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Anderesen, Andresen, Jason R. wrote: [...] Believe it or not, I find this pf.conf rule very effective to mitigate this type of distributed SSH botnet attack: block in quick proto tcp from any os Linux to any port ssh How does that work? Does PF do some sort of os fingerprinting on the remote side before allowing the first SYN through? Well, this would have pros and cons. pf employs a fingerprint mechanism that would passively detect the operating system based on some predefined criteria, and the Linux matches several old Linux kernel's TCP fingerprint. Note that with some tweaks to Linux's TCP parameters, or newer Linux kernels, this can be bypassed. However, if the administrator choose to do this, it's not quite likely that their boxes would be part of the botnet. Also, if you have a mix of Linux and FreeBSD boxes, presumably this would not be a great idea right? It's not just getting people who are faking it? Yes and no. Attackers would adopt to whatever defenders trying to stop them, however, for this type of attack (note that blocking Linux from being able to SSH on one system does not mean you would be more safe, it just mitigate the excessive login issue), what the attacker wanted is to have more botnet boxes, and he or she wouldn't care about having 1 more FreeBSD system be there or not, at the expense of faking or tweaking the TCP stack. From what I've seen on this attack, it looks like the hosts just send random logins to random IP addresses constantly, so adding an IP address to a blackhole list isn't as effective because you'll be getting hits from thousands of IP addresses, but only a single hit. In fact it looks like this attack is specifically designed to defeat the I'll add the attacker's IP address to a black hole list strategy, by coming in on a different address every time. Yes that's right. Since the scan is being done over a large scale of IP address space, it's possible to hide yourself by blocking Linux logins, since these boxes are usually managed by neglecting administrators and tends not to apply security updates from time to time. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrNEHkACgkQi+vbBBjt66BFxACfbfrUJnnVM9YGw6bVSo5hnfnO BwwAoKFf8DnRd3suCIYMGhZN6FqlTPrP =NwHo -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: (Ab)using rcng's features to keep rc.d-style services running should they fail.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wesley Shields wrote: On Sun, Oct 04, 2009 at 12:30:55PM -0700, Doug Barton wrote: Alex Trull wrote: Hi all, I realised that because portupgrade/portmaster don't always cleanly restart processes that have died due to being upgraded (mysqld, often!) that this was something I wanted to fix. I can't speak to portupgrade, however for portmaster there is no such facility whatsoever. The admin is expected to disable things prior to an upgrade and re-enable them when the upgrade is done. I don't feel that this is an overwhelming burden. :) There is the @stopdaemon directive in plists (which gets translated into @unexec to forcestop the script). Some ports use it and some do not. Personally I think ports doing this automatically are quite annoying, and would love to rip them all out from the ports. Something like portmaster growing support for it would be welcome provided it does not happen by default. +1 I think this feature should be user-controllable (or, the 'make install' should be 'restart'ing the rc.d script at very least). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrLyFcACgkQi+vbBBjt66DZ5QCfU3LSI+RiZwJv3huFx4wd3QNe UUsAn37vdhs30y+2eE/HLaw424CS7dMh =1FW0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel O'Connor wrote: On Sat, 3 Oct 2009, krad wrote: simplest this to do is disable password auth, and use key based. Your logs are still full of crap though. I find sshguard works well, and I am fairly sure you couldn't spoof a valid TCP connection through pf sanitising so it would be difficult (nigh-impossible?) for someone to cause you to block a legit IP. If you can, changing the port sshd runs on is by far the simplest work around. Galling as it is to have to change stuff to work around malicious assholes.. Believe it or not, I find this pf.conf rule very effective to mitigate this type of distributed SSH botnet attack: block in quick proto tcp from any os Linux to any port ssh Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrIXjsACgkQi+vbBBjt66DjhACeOJTIYbDuvAjIgYDrQ41aJcw8 +lsAoJhoUOoSL1k4Y/n/UDwqZNSUxId2 =wdkL -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Igor,
Igor Sysoev wrote:
Hi,
nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO
flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single
byte. The first aio_read() preloads the first 128K part of a file in VM cache,
however, all successive aio_read()s preload just 16K parts of the file.
This makes non-blocking sendfile() usage ineffective for files larger
than 128K.
I've created a small patch for Darwin compatible F_RDAHEAD fcntl:
fcntl(fd, F_RDAHEAD, preload_size)
There is small incompatibilty: Darwin's fcntl allows just to enable/disable
read ahead, while the proposed patch allows to set exact preload size.
Currently the preload size affects vn_read() code path only and does not
affect on sendfile() code path. However, it can be easy extended on
sendfile() part too. The preload size is still limited by sysctl vfs.read_max.
The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only.
I have ported this as a patch against -HEAD (should apply on 8.0-R but
it's too late for us to add a new feature) plus a manual page entry
documenting the feature.
I've used F_READAHEAD as the name, but reading the manual page, it looks
like we can just use F_RDAHEAD since Darwin seems to just distinguish 0
and !=0 case so that programmers won't have to use #ifdef or something
else to get code working on different platform?
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (FreeBSD)
iEYEARECAAYFAkqyt40ACgkQi+vbBBjt66AdKgCfXOo/Vn+zw0cCjS+gGJUgPo8t
WToAmgKIXaVKsKUcqVOqTwHl4eTFsbkM
=uP3m
-END PGP SIGNATURE-
Index: lib/libc/sys/fcntl.2
===
--- lib/libc/sys/fcntl.2(revision 197297)
+++ lib/libc/sys/fcntl.2(working copy)
@@ -28,7 +28,7 @@
.\ @(#)fcntl.28.2 (Berkeley) 1/12/94
.\ $FreeBSD$
.\
-.Dd March 8, 2008
+.Dd September 19, 2009
.Dt FCNTL 2
.Os
.Sh NAME
@@ -241,6 +241,14 @@
.Dv SA_RESTART
(see
.Xr sigaction 2 ) .
+.It Dv F_READAHEAD
+Set or clear the read ahead amount for sequential access to the third
+argument,
+.Fa arg ,
+which is rounded up to the nearest block size.
+A zero value in
+.Fa arg
+turns off read ahead.
.El
.Pp
When a shared lock has been set on a segment of a file,
Index: sys/kern/kern_descrip.c
===
--- sys/kern/kern_descrip.c (revision 197297)
+++ sys/kern/kern_descrip.c (working copy)
@@ -421,6 +421,7 @@
struct vnode *vp;
int error, flg, tmp;
int vfslocked;
+ uint64_t bsize;
vfslocked = 0;
error = 0;
@@ -686,6 +687,31 @@
vfslocked = 0;
fdrop(fp, td);
break;
+
+ case F_READAHEAD:
+ FILEDESC_SLOCK(fdp);
+ if ((fp = fdtofp(fd, fdp)) == NULL) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ if (fp-f_type != DTYPE_VNODE) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ fhold(fp);
+ FILEDESC_SUNLOCK(fdp);
+ if (arg) {
+ bsize = fp-f_vnode-v_mount-mnt_stat.f_iosize;
+ fp-f_seqcount = (arg + bsize - 1) / bsize;
+ fp-f_flag |= O_READAHEAD;
+ } else {
+ fp-f_flag = ~O_READAHEAD;
+ }
+ fdrop(fp, td);
+ break;
+
default:
error = EINVAL;
break;
Index: sys/kern/vfs_vnops.c
===
--- sys/kern/vfs_vnops.c(revision 197297)
+++ sys/kern/vfs_vnops.c(working copy)
@@ -312,6 +312,9 @@
sequential_heuristic(struct uio *uio, struct file *fp)
{
+ if (fp-f_flag O_READAHEAD)
+ return (fp-f_seqcount IO_SEQSHIFT);
+
/*
* Offset 0 is handled specially. open() sets f_seqcount to 1 so
* that the first I/O is normally considered to be slightly
Index: sys/sys/fcntl.h
===
--- sys/sys/fcntl.h (revision 197297)
+++ sys/sys/fcntl.h (working copy)
@@ -112,7 +112,11 @@
#if __BSD_VISIBLE
/* Attempt to bypass buffer cache */
#define O_DIRECT 0x0001
+#ifdef _KERNEL
+/* Read ahead */
+#define O_READAHEAD0x0002
#endif
+#endif
/* Defined by POSIX Extended API Set Part 2 */
#if __BSD_VISIBLE
@@ -218,6 +222,7 @@
#defineF_SETLK 12 /* set record locking
information */
#defineF_SETLKW13 /* F_SETLK; wait if blocked
Re: bsd.lib.mk question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Gábor Kövesdán wrote: Hi, I wonder if there's a conventional way of building _only_ shared libraries using bsd.lib.mk. At default, it builds static, shared and profiled libraries, which is a waste of time because I only need shared libraries, which I use as on-demand loadable modules. Adjusting _LIBS after the inclusion of bsd.lib.mk doesn't help and there are no knobs to control the behaviour. What should I do? If you define LIB= (or, not define it at all), and define both SHLIB and SHLIB_MAJOR, then only shared library is being built and installed. Example: LIB= SHLIB= test SHLIB_MAJOR=0 Would build libtest.so.0, but no libtest.a nor libtest_p.a. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpuIwEACgkQi+vbBBjt66C50gCgul420W4siZi3VBA2ZnHxNz4J UesAoMIoSzqF0rE6TzvZ5/D0vyjbTc71 =Y5xW -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tmpfs experimental?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivan Voras wrote: Hi, Are there still known problems with tmpfs? I've been using it for a while in 7-STABLE and 8-CURRENT without noticeable problems - not that there was ever serious load involved (normal /tmp activity). I've just tried it and it survived a couple of rounds of blogbench, even with virtual memory swapping. In other words, is there still reason for the highly experimental feature warning? Last time when I added the warning, it was because some data corruption issue that can be identified by fsx which I didn't got a chance to investigate further. I think tmpfs is Ok for some usual work but maybe not ready for production at that moment. alc@ and kib@ has made a lot of changes on it recently so perhaps we need to re-visit the problems, tmpfs would be a great feature for us. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko2kw8ACgkQi+vbBBjt66D8LwCgiEevv8qy5pl/b73rDhXU6oso jr0AoLKo/WGvoLOU7HrivC8KK2yidKo+ =alk6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DNS problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh M. Friedman wrote: I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is it possible to use the libthr.a file on a Redhat Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Srinivas Ganji wrote: Dear All, I have tried to use the libthr.a library for compiling an application which is working fine on Redhat system with libpthread library. However, I end up with the following errors. [...] My question is: Is it possible to use the FreeBSD libthr.a library on a Redhat Linux distribution? I don't think so. libthr depends on some features that only exists on FreeBSD, like other system libraries, they wrap FreeBSD kernel interfaces to what is more familiar to application programmers, like C and POSIX APIs, etc. It should be noted that it could be possible if you recompile your application under RedHat Linux, as the upper layer of API should be more similar. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknSr6kACgkQi+vbBBjt66AiLACePPXunI2ApOoJ3OSLZKfpZWg2 m1sAoLPrnqOavIV0ldM1+D334JMuaQCs =akOZ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Intel Integrated Raid (iir) relevance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (It would be probably good idea to redirect this discussion to -stable@, redirected) Hi, Danny, Danny Braniss wrote: It's no longer working (for me) under 7.2, and so far I am not getting any feedback, so since it seems that this particular hardware has reached EOL, I was wondering if, a) it's true, b) drop it, and replace it. c) should time be spent in getting it to work again. I'm not very sure about your problem with iir(4). A diff against RELENG_7_1 does not reveal any change on the driver itself. Are you sure that 7.1-R can have the device working? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknSy7AACgkQi+vbBBjt66AUoQCgtFiu6Bsg0LygJ7gAnKLdBBMN JKIAoKNioqTEQSA8vX621jqTpBKTaO1C =RmFa -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A patch of HPTIOP driver for 7.1-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Shaowei Wang (wsw) wrote: Hi, delphij The problem about FreeBSD-7.x-amd64's hptiop driver is solved by patching our RAID-manage software (userland utils). The hptrr driver is a soft RAID so a 32-bit compatibility ioctl structure is necessary. The hptiop is a hardware RAID controller, the firmware is 32-bit. So do we need to patch the driver at our side? My reading is that we will not need it anymore? Please feel free to let me know if you want the patch be committed. Since we are going to have 7.2-RELEASE by early May, it's important to merge stuff back early so they get more through tests, etc. I'm not so familiar with FreeBSD's development community. I'm sorry Posting the infomation here. Never mind, the PR system is just a more convenient way of tracking issues (i.e. you can check back if a problem has been resolved at a later time, etc.). On Sat, Jan 17, 2009 at 6:46 AM, Xin LI delp...@delphij.net mailto:delp...@delphij.net wrote: Hi, Shaowei, It seems that I can not apply your patch directly, I have tried to do it manually, as attached, please let me know if it's Ok. I can commit for you against -HEAD if it looks fine and take care for MFC. Note that, however, I am more or less concerned about the driver if 32-bit utility is running on amd64 platform. There seems to have three pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and found that it has defined a 32-bit compatibility ioctl structure. According to my understanding to hptiop(4), this could be a problem. PS. For faster handling it is probably a good idea to submit patch through our PR system: http://www.freebsd.org/send-pr.html Shaowei Wang (wsw) wrote: Hi, guys hptiop driver in the 7.1 release has a little bug. Because this issue the Raid-manage GUI program which we provided can NOT work anymore. So we give the patch: Index: hptiop.h === --- hptiop.h(revision 186851) +++ hptiop.h(working copy) @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) -wsw // '¶} hptiopq¨(7.1ÑLH-*ï Ù*ïüôìÐ5¡ àÕÐL ìÙúe Index: hptiop.h === --- hptiop.h(revision 186851) +++ hptiop.h(working copy) @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) -wsw ___ freebsd-hackers@freebsd.org mailto:freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org mailto:freebsd-hackers-unsubscr...@freebsd.org Index: sys/dev/hptiop/hptiop.h === - --- sys/dev/hptiop/hptiop.h （版本 187338） +++ sys/dev/hptiop/hptiop.h （工作副本） @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ - -}; +} __attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknJB5EACgkQi+vbBBjt66CPRwCeLna7weWqMVK8G/MPFcpIR5Xb z3QAn39CaWIMqTUBmj/EnAc9i09byweF =ylVm -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing libnetstat for Summer of Code 2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Cipta, Cipta H wrote: XML? I was thinking of some opaque C structures that the functions write data to, and then supply some accessor methods, just like the ones in libmemstat. Or are you thinking of a different XML? I'm not very sure but I think Rui is referring XML like the GEOM subsystem has used (perhaps to have the kernel expose the statistics data with XML and the userland part of the library parse and return the result)? On Mon, Mar 16, 2009 at 1:34 PM, Rui Paulo rpa...@freebsd.org wrote: On 16 Mar 2009, at 14:16, Cipta H wrote: 2. How much experience in C do you need to do this project? Do you need to know the FreeBSD kernel? Yes, you need to understand the C programming language well and to be able to learn how the FreeBSD kernel works. You also need to figure out a way to structure the data. I know that XML was proposed in the past, but I don't know if this is the case. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkm+orwACgkQi+vbBBjt66DyAACfZYT9/IbaPkUViBqDV6whxi2L N/8An0av6fp/EahIw5aUmd01lfNEo4el =t1WB -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing libnetstat for Summer of Code 2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Cipta, Cipta H wrote: Thanks for the reply, Xin. I'm aware of something called sysctl, and if I am accepted to work on this project, my main task is to ensure all live network data will come from sysctl, but the only XML I know of is the markup language. Perhaps someone more knowledgeable can point me to the right resource? Thanks in advance. Yes it's the markup language. I think whether or not to use XML really depends on whether you want structured data. The current approach we have used is to use kvm(3) and obtain the data directly based on knowledge of in-kernel data structure. By using XML, the structured data can be represented in a self-explaining form and known data can be easily extracted from it (of course you will need to design a schema for the data but that's fairly easy once you know what you are willing to expose). Note that you may want to contact Robert to better understand the problem that the libnetstat and friends is targeted to solve. XML is one possible approach (and we have a built-in XML parser library that can be used by userland programs) but it's not the only possible approach :) Cipta On Mon, Mar 16, 2009 at 3:04 PM, Xin LI delp...@delphij.net wrote: I'm not very sure but I think Rui is referring XML like the GEOM subsystem has used (perhaps to have the kernel expose the statistics data with XML and the userland part of the library parse and return the result)? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkm+xUcACgkQi+vbBBjt66AGRwCgpN1jErbevmhllKqlQgYxuWZt 07AAn1iycaHQCrC74h/RHkokFyBdD9RD =QUDy -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fgetc doubts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Gábor, Gábor Kövesdán wrote: Ed Schouten escribió: * Gábor Kövesdán ga...@freebsd.org wrote: Hello, I have a problem when reading files with fgetc when a 0xff character comes. In my code the reading stops at that point as if EOF had been reached, but that's not actually the case. The code is here: http://p4web.freebsd.org/@md=dcd=//c=Nsd@//depot/projects/soc2008/gabor_textproc/grep/file.c?ac=64rev1=40 And the problem occurs in grep_fgetln() when the buffers is being filled in: for (; i bufsiz !grep_feof(f); i++) binbuf[i] = grep_fgetc(f); Thanks in advance, Sign extension bug? I tried to substitute everything with int, because fgetc can return some error code afaik, but using int didn't help. Is binbuf[] an array of char or unsigned char? If it's signed char then you may want something like ch = binbufptr[0] 0xff I guess. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkm26JUACgkQi+vbBBjt66CePwCgtXlqAYcdP6G1EUUtGk0nu7vD I1sAoIJ+Hpop5mIHDdbfcXAbwMsqht2P =A8DH -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
How to change an interface?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just wanted to confirm that the following procedure to change an existing interface: - Remove the symbol in question from all previous FBSD_1.* namespaces with their corresponding Symbol.map files; - Add the new symbol into latest FBSD_1.* namespace, say, FBSD_1.1 for now, into corresponding Symbol.map files; - Create a new file containing the compatibility shims with prefix __ and suffix of something indicating its obsoleteness, e.g. _44bsd. For instance, for function foo(), the shim function would be called __foo_44bsd(); - At the tail of the shim file, add glues for the old symbols like this: __sym_compat(foo, __foo_44bsd, FBSD_1.0); - Double check to make sure that new .so would work with old binaries. Is that correct? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkml1nwACgkQi+vbBBjt66CgLwCgojrOaeSyuNHdHQyzxA0+UEMq PREAn0rFE8zpFez0WbccVAir8Nhf/AK0 =MBeo -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mel wrote: [...] I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. One comment: you may want to consider using expand_number(3) instead of rolling your own version Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmmDk0ACgkQi+vbBBjt66A1pgCghpIS/bOgflo0JKNBlKZlBzDf H0IAn21ZJNk1fT6YWDzO0e6nK4dUmJd0 =FFjB -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mel wrote: On Wednesday 25 February 2009 18:36:45 Xin LI wrote: Mel wrote: [...] I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. One comment: you may want to consider using expand_number(3) instead of rolling your own version Cool thanks, didn't know about that one and was actually considering a request for this API. Maybe strtonum/atoi/stroll and friends should .Xr this API? Maybe, perhaps also humanize_numbers... We may also want NetBSD's dehumanize_number as well... - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmmGZUACgkQi+vbBBjt66DX0ACfSge9+MA5P98MOYf4LfF+rKn8 Nq8AoLCko53l4YKQrZUQW1PJp9oUVAw4 =6ok+ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A patch of HPTIOP driver for 7.1-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Shaowei, It seems that I can not apply your patch directly, I have tried to do it manually, as attached, please let me know if it's Ok. I can commit for you against -HEAD if it looks fine and take care for MFC. Note that, however, I am more or less concerned about the driver if 32-bit utility is running on amd64 platform. There seems to have three pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and found that it has defined a 32-bit compatibility ioctl structure. According to my understanding to hptiop(4), this could be a problem. PS. For faster handling it is probably a good idea to submit patch through our PR system: http://www.freebsd.org/send-pr.html Shaowei Wang (wsw) wrote: Hi, guys hptiop driver in the 7.1 release has a little bug. Because this issue the Raid-manage GUI program which we provided can NOT work anymore. So we give the patch: Index: hptiop.h === --- hptiop.h(revision 186851) +++ hptiop.h(working copy) @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) -wsw // 大家好： hptiop的驱动在7.1发行版中有个小错误。 这个小错误导致了我们提供的阵列管理程序无法运行。 我们给出了补丁： Index: hptiop.h === --- hptiop.h(revision 186851) +++ hptiop.h(working copy) @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) -wsw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAklxDk4ACgkQi+vbBBjt66CvUQCfaAnk0XQTh3Wrn2O4Dy0pEUFW oqsAoIvlTSNGRDg71SNyGfZ5VjDh9Z93 =1xSB -END PGP SIGNATURE- Index: sys/dev/hptiop/hptiop.h === --- sys/dev/hptiop/hptiop.h ï¼çæ¬ 187338ï¼ +++ sys/dev/hptiop/hptiop.h ï¼å·¥ä½å¯æ¬ï¼ @@ -260,7 +260,7 @@ unsigned longlpOutBuffer; /* output data buffer */ u_int32_tnOutBufferSize;/* size of output data buffer */ unsigned longlpBytesReturned; /* count of HPT_U8s returned */ -}; +} __attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: td_critnest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ravi Murty wrote: Hello All, The implementation of critical_enter and critical_exit changed between freebsd 5 and freebsd 6. In the newer implemtnation, the code checks if td_critnest is 1 and if it is sets it to zero, then checks if the thread owes a preempt. If so, it increments td_critnest by 1 before grabbing a lock and then decrements it back to zero. I can't figure out why it does this. The freebsd 5 implementation seems straightforward where we check if the thread owes a preempt and if so we switch to the new thread. Can anyone help me with this? My guess is to prevent race conditions (i.e. to split the owepreempt flag into a separate variable), since this value could be changed in an interrupt context, and not only during the current thread context. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklF7lUACgkQi+vbBBjt66C0sQCeOZCFZu4VBTRk3it4/424pAbc LRoAoLfdoS09ZX2SSZ1Z/SOw+rqkrkQ0 =P2Ez -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: change to ee.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Eitan,
Eitan Adler wrote:
I changed this pursuant to a warning I got from gcc.
according to the man page This avoids the race between testing for a
file's existence and opening it for use.
Could someone on this list please tell me
a) If mkstemp is supposed to be used instead
b) if not, why not?
I tested this change and was able to spell check files (the function
which this changes).
As an aside I got an unreproducible segfault 11 when I tried to
spellcheck an empty file. When I tried again I did not get the same
error. I have the ee.core file.
--- ee.c.back 2008-11-29 22:52:28.0 -0500
+++ ee.c 2008-11-29 22:52:35.0 -0500
@@ -4386,7 +4386,7 @@
return;
}
(void)sprintf(template, /tmp/ee.);
- name = mktemp(template[0]);
+ name = mkstemp(template[0]);
fd = open(name, O_CREAT | O_EXCL | O_RDWR, 0600);
if (fd 0) {
wmove(com_win, 0, 0);
Tanks for interested in this but I'm afraid that your patch is
incorrect. mkstemp returns a file descriptor rather than a string
pointer, therefore, the subsequent open() would have undefined behavior.
It looks like that we actually want fd = mkstemp() here.
Note that we may want to bring vendor fixes before making any changes to
reduce duplicated work...
Cheers,
- --
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkkyEioACgkQi+vbBBjt66Dg8QCgw5nCU0G1WnHYtVziiNMpawqh
iPwAni7zA4yFnX9waNC0Hmj36rX6yrIG
=iJ2c
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Schenkeveld wrote: [...] utimes(2) allows non-root users to (re)set atime provided they own the file or have write permission. Having O_NOATIME follow the same rules would not break any assumed security any further than utimes(2) already does but greatfully benefit all kind of backup programs. Yes this makes sense I think. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkLR3AACgkQi+vbBBjt66BPhACfcZf6JcH0RmTpbpZHVXjdrJTq f7oAoLqQwb2UkFGrDDTy7//Ril2JWmA4 =y1zY -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Chadwick wrote: I've recently been reading about Linux's O_NOATIME flag to open(2), and I'm curious why we haven't implemented this. There seem to be a lot of good reasons to implement such a thing. Chances are it's due to lack of time/interest, which is expected, but I was wondering if there were other reasons. I realise mount's noatime trumps this, but there are lots of scenarios where atime is desired as a default, but disabled in specific cases. Em... Allowing administrators to disable NOATIME would be a good thing, but wouldn't allowing arbitrary program to decide whether atime should be changed, be a serious security disaster? Disclaimer: I'm not a big atime fan myself, actually I disable atime on a lot of my servers for performance reasons :) Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkKaooACgkQi+vbBBjt66CImQCgj51GGHXFaGhsFk4fAAWhmfV5 +s4An2Hn2TCVhqXEpzEL3xNwxy6YE84M =n7f/ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Matt, Matthew Dillon wrote: [...] /boot can be as complex as boot2 allows. There's nothing preventing it from being RAIDed if boot2 supported that, and there's nothing preventing it (once you had ZFS boot capabilities) from being ZFS using a topology supported by boot2. Having a sparate /boot allows your filesystem root to use topologues boot2 would otherwise not support. I believe that it's a good idea to separate / from the zpool for other file systems, or even use a UFS /. My experience with ZFS on my laptop shows that disk failures can be more easily fixed if there are some utilities available in the UFS /, even when ZFS is used as /. Another issue with a ZFS / is that the snapshot rollback feature generally does not work on / since it needs the mountpoint to be unmounted. One thing that I found very useful is the new GPT boot feature on 8.0, which also works on older BIOS because the protected MBR would deal with the bootstrap to the actual GPT boot. Now we have a 15-block sized gptboot that can boot FreeBSD from UFS, however this 'boot' can be in virtually any size that the BIOS supports, so we can embed more logic there. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjxHV0ACgkQi+vbBBjt66CpXgCfWstsxNc3B4xOzNTxz9/kdl3Y /WYAnjqiV5H8xQYxGgZTnwWieuG6ZZij =LH+x -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Debugging modify-after-free issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Recently I had some crashes and other issues on my laptop and I found that, among some bugs I already caught and fixed on my local tree, there is still something like this: Oct 10 01:35:53 delta kernel: Memory modified after free 0xff00a2ef9600(256) val=6438300 @ 0xff00a2ef9608 Is there any way to track this down (looks like to be wpi(4) related but still keep trying)? I can not seem to reliably trigger it so it would be helpful if such thing would trigger a panic. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjvHlAACgkQi+vbBBjt66B2YQCeMXQwUWJOOm9PdCiFnsQD7Qba exkAnAz/4VRm+ZrU83XudWeo6lLTlkHO =N2pO -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regenerate ports tree from installed ports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jordi Espasa Clofent wrote: Hi all, I suppose it's a dumb (and crazy) question, but as post subject says: ¿Is it possible to regenerate the /usr/ports tree _from_ the installed ports? As long as your ports tree is not very old, you will be able to use it in newer system but this is not always guaranteed. It is, however, possible to checkout ports tree from the date you specified with either cvsup or cvs. My personal suggestion is that when upgrading, try to build a new environment from scratch (say, everything is brand new) with ports named by 'pkg_info -qoa' on old system, and have the new environment reveal potential issues before making major updates to running system. Another possible approach is to update from time to time but this could cause you a lot of downtime. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjcCcsACgkQi+vbBBjt66D+5gCgraZv+FSEuxKFFiPNTan16Oyf HvEAoIt0OWlpSqgYwxo7Og/+7e9WBG2g =DJkP -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mercurial working copy of FreeBSD src
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Navdeep Parhar wrote: | Hello everyone, | | I'm looking for the fastest way to get a full mercurial repository of | HEAD. | | I tried using hgsvn and the tree at http://svn.freebsd.org/base/head | but it looks like the first hgpullsvn operation will take days (literally): | | $ hgimportsvn http://svn.freebsd.org/base/head | $ cd head | $ hgpullsvn === This will take a long long time | | Does anyone know of a faster way to do this? Is there a mercurial | repository out there somewhere from where I can simply hg clone my | copy? Perhaps someone should share a tarball of the hgpullsvn output, otherwise it would be a nightmare for svn.freebsd.org... Another thought would be the hg mirror provided by .fr people, which is http://hg.fr.freebsd.org/. Note that this seems to be a CVS sourced one. - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkicuekACgkQi+vbBBjt66AjNgCgqsUqGXUnIqrPgplIvt7X5Sz8 FowAoJRkW/ITN0I2UxalzK+ykYt8RLcY =fOap -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: do not strip, compile with debugging symbols
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Hello. | | What's the correct way to ensure that ports are built with '-g' | and that binaries/libraries created are not stripped? I'm assuming | the first one involves setting CFLAGS in /etc/make.conf (admittedly, | it's apparently not supported but I'm not building world with this | setting anyway). | | The second, I'm not so sure about. I thought I'd heard of a NO_STRIP | setting but if it exists, it's not documented. I think the setting is spelled as 'WITH_DEBUG=yes' which will add '-g' and remove stripping. However, it still depends on the ported software whether they will strip, most times they will obey the settings (if not then it's a bug that should have fixed anyway). - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh+lGYACgkQi+vbBBjt66C+BwCeMRzZaME1pV5b/G0PEkfmHFIY ttwAnRqb38Qgju365yitGRGAejfyj/zP =EfoP -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: do not strip, compile with debugging symbols
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | On 20080716 17:37:58, Xin LI wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | [EMAIL PROTECTED] wrote: | | Hello. | | | | What's the correct way to ensure that ports are built with '-g' | | and that binaries/libraries created are not stripped? I'm assuming | | the first one involves setting CFLAGS in /etc/make.conf (admittedly, | | it's apparently not supported but I'm not building world with this | | setting anyway). | | | | The second, I'm not so sure about. I thought I'd heard of a NO_STRIP | | setting but if it exists, it's not documented. | | I think the setting is spelled as 'WITH_DEBUG=yes' which will add '-g' | and remove stripping. However, it still depends on the ported software | whether they will strip, most times they will obey the settings (if not | then it's a bug that should have fixed anyway). | | Hi. | | Yes, that does seem to work. The only problem is that it also disables | any optimization flags (I was hoping to compile with -O2 -g as I don't | need to do in-depth debugging, just have decent stack traces). | | I tried setting CFLAGS to '-O2' but WITH_DEBUG seems to override this, | too. Maybe you want DEBUG_FLAGS='-O2 -pipe -fno-strict-aliasing -g'? - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh+mxoACgkQi+vbBBjt66B/fgCgrenfepYZBy4Hd5zLFCvXv7OF 6J4AnR6O9WqnIMegrp5INv1LdXavYjba =wyq3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: | Murty, Ravi wrote: | Hello everyone, | | | | Finally found what my last problem was. We were running top in a loop | and running some workloads that called sched_bind() to bind threads to | specific CPUs. The problem was that (and I am using ULE) sched_bind | calls a function to notify another CPU of a thread and then mi_switches | out of it. Since mi_switch sets the oncpu field of the thread to NOCPU | and given the thread is still running, calcru would come in and assert | the fact that If I am running I better no be on NOCPU.. It appears | that in other parts of the kernel (e.g. forward_signal) this is | acceptable (i.e. it is okay to be running and oncpu is NOCPU). | | | Thanks | Ravi | | Don't use ULE in 6.x, it's broken and will not be fixed. Perhaps we should mark it as broken using #error? After all the ULE changes in 7.x is amazing and we do not want to have users to obtain bad impressions from the 6.x versions... I am not sure but some explicit warning message saying ULE has been revamped in FreeBSD 7.x+ and will not be MFC'ed back to 6.x, please use SCHED_4BSD or upgrade to 7.x. seems to be better than having them to pursue the mailing list archive... Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyfjYACgkQi+vbBBjt66CdLQCfet8ls7tfg5jV5I7gSOw8QwhC maoAn2sBwjfoOBhFt6u5fELK9X6XMp0A =Bxr3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt - patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Anton wrote: [...] | I'm going to have to dig up these fixes, but presuming | I do, who should be alerted? Just file a bug? Recreation | is extremely difficult. I think Oracle is maintaining a webpage about their known bug/fixes here: http://www.oracle.com/technology/software/products/berkeley-db/db/index.html FreeBSD has applied a number of fixes IIRC, if it was a BerkeleyDB bug I'd suggest that you also give Oracle developers a headsup. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ | Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgrJq4ACgkQi+vbBBjt66CB3gCfQ/hhQXVsyItDVmbP/j4lbI4v 8k8AnRgqtHZeg7lw9aacSeXNb8uYo9Ae =dWBS -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLOCK_REALTIME undefined on my system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Franks wrote: | The manpage (http://www.freebsd.org/cgi/man.cgi?query=clock_gettimesektion=2apropos=0manpath=FreeBSD+7.0-RELEASE) | for clock_gettime() specifies the correct header as time.h, which I | am using, and I don't see any errors on clock_gettime(), but the param | I need, listed in the manpage, CLOCK_REALTIME is undefined. Any ideas | how this could be? I've recently cvsup'd standard-supfile, so you'd | think I'm up to date... | | I'm also getting an implicit declaration of isnormal(), and math.h is | clearly included... I think with #define _POSIX_C_SOURCE 199309L These will be masked... Could you please try if changing it to 200112 would work? Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgkmPIACgkQi+vbBBjt66D/bgCfd4jBteEBrPdQT272TcxY0bLF LwIAoIkcfwxlCBog7+1tyJr84Uns6jbJ =AS7o -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct #define in source to specify FBSD vs. linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Franks wrote: | Seems there is a more appropriate list for my earlier question to | freebsd-questions: | | On and on I charge porting linux engineering tools. Major pita. I | see a bunch of #ifdef __APPLE__ lines to pull in alternate headers; | what's the equiv for FreeBSD? #ifdef __FreeBSD__? - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgkmaoACgkQi+vbBBjt66C30ACeIbw6P7CuwErAIvzcUjX4d4Gk 7G0An3+S2hM9YctAkKsWDVzkEoZIMhOH =AzxS -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving Syslog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schütte wrote: | Hello, | I am taking part in this year's Google Summer of Code for NetBSD and | want to implement the upcoming IETF Syslog standards for BSD's | syslogd(8). The most important improvements will be an extended message | format, TLS network transport, and digital signatures. | | I hope these new functions will later be ported to benefit all BSD | variants (as their syslogds are similar). | So everyone interested is invited to take a look at the project pages | now and then. Naturally any feedback is welcome. | | The official project's homepage is at | http://netbsd-soc.sourceforge.net/projects/syslogd/ | and for developing I maintain a Trac at | http://barney.cs.uni-potsdam.de/trac/syslogd/ That's cool. Is there any commit-mail style stuff that we can subscribe so we can gradually incorporate your work into FreeBSD? Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgbhvUACgkQi+vbBBjt66DEnwCfZbFNXV8svbv4i31uXlJNsglS 4/EAoKogxgrOvyEKbr2DKvKncGcvh+rP =4W6A -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Some versioned storage program?
Hi, folks, I'm looking for some versioned storage program that can fulfill the following requirements: - Open source/Free Software that can run on FreeBSD, or not far (i.e. on other POSIX OS) - Support of atomic commit/rollback. - Fast checkin time (At least, when added/changed files are explicitly specified). - Fast update time (i.e. something like 'cvsup -s' that makes it possible to trust bookkeeping file rather than stat'ing every files) - Scalable for a large number of files, directories and revisions. Say, it is not acceptable for it to store a zillion of revisions as individual files within one directory. - Ideally it can support some sort of hook functions upon commit so that changes can be notified in some way such as e-mail. - Ideally it can support fast export of a snapshot for HEAD and nearby revision like HEAD - 1, etc. I think what I need is some SCM software like subversion or hg, but I do not know if there is some superior stuff that matches these requirements better. Any other suggestions? Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some versioned storage program?
Giorgos Keramidas wrote:
On Fri, 21 Mar 2008 16:10:22 -0700, Xin LI [EMAIL PROTECTED] wrote:
Hi, folks,
I'm looking for some versioned storage program that can fulfill the
following requirements:
- Open source/Free Software that can run on FreeBSD, or not far
(i.e. on other POSIX OS)
- Support of atomic commit/rollback.
- Fast checkin time (At least, when added/changed files are explicitly
specified).
- Fast update time (i.e. something like 'cvsup -s' that makes it
possible to trust bookkeeping file rather than stat'ing every files)
- Scalable for a large number of files, directories and revisions. Say,
it is not acceptable for it to store a zillion of revisions as
individual files within one directory.
- Ideally it can support some sort of hook functions upon commit so
that changes can be notified in some way such as e-mail.
- Ideally it can support fast export of a snapshot for HEAD and
nearby revision like HEAD - 1, etc.
I think what I need is some SCM software like subversion or hg, but I do
not know if there is some superior stuff that matches these requirements
better. Any other suggestions?
Before you start using Hg, Git or Subversion it may be worth
experimenting a bit with them. My apologies if you _have_ already and
the previous sentence sounds patronising. All I'm saying is that they
all have a fair share of good, not so good, or even bad aspects. So it
would be nice to have tried them all a bit and pick the one that seems
like the best fit for the job at hand :)
Ah... Ok I think I should have mentioned the purpose of the system. It
is supposed to be used in a CMS system, and the storage program will be
used as one auxiliary backend where rendered pages are being stored.
To provide a few starting points:
- Subversion, Git and Hg, all run on FreeBSD
- They support 'changesets' as the basic model of storing commits
- Commit speed varies a bit. For locally stored 'workspaces', Git and
Hg seem to be more or less equally fast, with Subversion being a close
second
- Update times tend to vary a bit too. Hg and Git will blow Subversion
away on locally stored repositories, but they might suck a bit on NFS
workspaces
- Storing individual revisions as 'a zillion directory entries in a
single tree' seem to point at Subversion. Have you already tried it,
and found that it doesn't scale for your sort of work? It is used by
many large-ish projects, so it would be surprising but not unrealistic
to have scalability issues after a few million commits
- Hooks _are_ supported by Subversion, Git and Hg (others too)
- Checkout speed (and `export' speed) is pretty fast in Git and Hg.
Subversion is a bit slower, but still usable. Changeset support is a
nice feature, because it doesn't matter if your `export' run takes 1.5
minutes instead of 20 seconds. When a given changeset is exported in
any of svn/git/hg you _never_ get a mix of file revisions from
changesets ${FOO} ... ${FOO+j} for some arbitrarily random value of
'j', because 'j+k' commits happened in the mean time.
Before you _do_ embark on the journey of using a VCS for storing a bunch
of files, it would be nice to stop for a moment and consider if you need
one. If you do, there _are_ options, and they are definitely not
limited to the three systems mentioned so far.
Thanks for all these information. I have tried svn and hg but neither
is just fit and both have good stuff and drawbacks. I have even tried
to use cvsup/cvs in a small system when I was in university and it
served them well for many years, however I think it would not work well
for larger systems.
For now I am more inclined to use hg (if not using some home grown
system as this is not exactly source code version management and a lot
of complexity can be thus just skipped) but I think I need to find out
how well it would work with 'pull+update' on large repositories, the
largest hg repository I am aware of right now, is less than 1GB and the
potential size of the repository I would use will be larger than that
and grow from time to time.
I think it's a good point that speed would vary when the repository is
being stored locally (git and hg) and remotely (svn), also speed of
synchronization between several hosts would be important as well.
Cheers,
--
Xin LI [EMAIL PROTECTED]http://www.delphij.net/
FreeBSD - The Power to Serve!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help debugging kernel dump?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carey Jones wrote: I have been getting occasional reboots on my FreeBSD 6-STABLE machine. I haven't figured out a pattern on it yet, but the most recent crash was during some pretty heavy NFS usage, and I see nfsd in the dump, so perhaps that has something to do with it. Could anyone assist in deciphering the cause of this? This is the first time it's crashed on me once I enabled debugging, so I can't say for sure whether or not this is common to all of them. Just a glance at the code, will this work? Index: nfs_srvsock.c === RCS file: /home/ncvs/src/sys/nfsserver/nfs_srvsock.c,v retrieving revision 1.94.2.3 diff -p -u -r1.94.2.3 nfs_srvsock.c - --- nfs_srvsock.c 2 Sep 2006 23:58:20 - 1.94.2.3 +++ nfs_srvsock.c 20 Feb 2008 22:02:23 - @@ -721,6 +721,7 @@ nfsrv_dorec(struct nfssvc_sock *slp, str if (nd-nd_cr != NULL) crfree(nd-nd_cr); free((caddr_t)nd, M_NFSRVDESC); + *ndp = NULL; return (error); } *ndp = nd; - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvKOYi+vbBBjt66ARAnIxAJ9MyIqcMspJLd9bI+9ikEb1WH4KvgCfSF2u OaIOdWK+kjGcm/usa/xGzhg= =3e+s -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
