From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 20:57:54 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF024106566B for ; Sun, 20 Jun 2010 20:57:54 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD178FC14 for ; Sun, 20 Jun 2010 20:57:53 +0000 (UTC) Received: by fxm7 with SMTP id 7so1911107fxm.13 for ; Sun, 20 Jun 2010 13:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=MeATj/RK9jSdIXzSfSWdgSYEU0i3NOp5oqxukLSmf/o=; b=RWKOmuvnrnlAzlrgd5Dm65FUcqK46/zzrqYgztds87PAwVLgq7cqmb/gFxmoWBWZMY ypWbUY/XM/zfgfYjnWcKoMWFhmeN5nMcf8aX/Yr7VZT1/esFTo7y4A+8xw+B5H4csXkZ WKAupA27UcenPiCzG6gmKwDS5ugrD9ONMn6BQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=usCnXBvZEjz4BF1VZ3LFlYy8QqpcDXrbcNZLMBiE5h9hevd/rKu8ZGBUCR/ZMDntMJ jbiYQpK8feU3uuHZ4SiZRNMSyPVvAI8M4WbFaB9bMXGiCa4cTelhFlZB6jMDrU5Z+JtD cUFmMaTlpizhBhekht6MbhLu89j5FS5e+pryM= MIME-Version: 1.0 Received: by 10.223.20.216 with SMTP id g24mr4163321fab.63.1277067472901; Sun, 20 Jun 2010 13:57:52 -0700 (PDT) Sender: pali.gabor@googlemail.com Received: by 10.223.104.2 with HTTP; Sun, 20 Jun 2010 13:57:52 -0700 (PDT) Date: Sun, 20 Jun 2010 22:57:52 +0200 X-Google-Sender-Auth: 2nEstN3jPT07mPmDbfp0g-Ad1QI Message-ID: From: Gabor PALI To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [RFC] Changes in stat structures X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 20:57:54 -0000 Hello, I would like to integrate my Google Summer of Code project from the last year [1]. In brief, it was about converting netstat(1) into a library and providing a relatively clean API to access various networking statistics available in the kernel. The project is far from being complete, and it needs review but I decided to split my large patch into smaller pieces and add the results continuously to the FreeBSD src/ repository, otherwise it might vanish. I do not have a src/ commit bit, thus I am also looking for a sponsor for my changes who approves or commits them. My plan of integration is simple: apply the necessary modifications to the kernel, add the sysctl export routines and data structures, add the library (called libnetstat(3)), then adapt and add applications (netstat(1), bsnmpd(1), nettop(1), etc.) to use it. This way I could get some review and continue the development of this library in an interactive style. The first piece of this set is available on my FreeBSD homepage as a separate patch [2], which technically proposes to a "standardization" for the counter values so they could be accessed from both 32-bit and 64-bit environments without problems (via kvm(3) or sysctl(3)). However, I do not know too much about the potential consequences or how such a change should be handled in the tree. For more information (and the complete patch), see the project's wiki page [3]. Any feedback is appreciated. Nothing is carved into stone, I am very open to comments :) Thank you! Cheers, :g [1] http://wiki.freebsd.org/PGJSoC2009 [2] http://people.freebsd.org/~pgj/libnetstat/libnetstat-sys.latest.diff [3] http://wiki.freebsd.org/LibNetstat From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 22:02:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F9E106566B; Sun, 20 Jun 2010 22:02:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 730418FC12; Sun, 20 Jun 2010 22:02:36 +0000 (UTC) Received: by qyk11 with SMTP id 11so1341315qyk.13 for ; Sun, 20 Jun 2010 15:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=7bbzj1J+1ueZerr0HpolNz/MPQ+hxeui7+lKDtvWB5o=; b=qQDZ64fva6DWvoUmNUMZhqEm7z4cbBK3QDddDW1ZeDgW1D5av4iZ+E1NQLlKYc42z/ ZRwj/Dg86jjkFxHyJ8P30K4PglSXZosesev3l7qWwbqjJI65AMnStUAl0P0+CeAdmune g+LjaXske1lFTBodGcmyjCzFyKrt3lT19F3uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YDlWo8yqKC8f311hm14/HcLJkQLgToXtJrGrxtMxCNZXcH65KhavHcc26NiZGxcesT LODwnwyLRFvE06wzauqyCr/L8PwyG8W6aAVJ92NXYnjHuXuRsm7j2AvKiK7tkOfPiQ+O rDG3Dq3MIj7J7/4xMlV0AjYMUYwPo5G1+4OhE= MIME-Version: 1.0 Received: by 10.224.80.65 with SMTP id s1mr2562482qak.239.1277071355773; Sun, 20 Jun 2010 15:02:35 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sun, 20 Jun 2010 15:02:35 -0700 (PDT) Date: Sun, 20 Jun 2010 15:02:35 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: standards@freebsd.org Subject: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 22:02:36 -0000 Err... I ran an mqueue test and it popped up with ENOSYS. Which makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I could be misreading the code. Another test written which tests mqueue appears to be broken as well (I'll include that in a later email if interested). I also attached the truss output and the relative code blurb for a little more analysis. Thanks, -Garrett PS I'm not guaranteeing that the code below doesn't have bugs in it as I'm not the original author and the tests were originally written and targeted towards Linux. $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: Mon Apr 26 22:45:06 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata amd64 $ truss functional/mqueues/send_rev_2.test __sysctl(0x7fffffffe130,0x2,0x7fffffffe14c,0x7fffffffe140,0x0,0x0) =3D 0 (0= x0) mmap(0x0,672,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365173760 (0x80052= f000) munmap(0x80052f000,672) =3D 0 (0x0) __sysctl(0x7fffffffe1a0,0x2,0x800639848,0x7fffffffe198,0x0,0x0) =3D 0 (0x0) mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D 34365173760 (0x80052f000) issetugid(0x800530015,0x80052a524,0x800645f50,0x800645f20,0x5af1,0x0) =3D 0= (0x0) open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' open("/var/run/ld-elf.so.hints",O_RDONLY,057) =3D 2 (0x2) read(2,"Ehnt\^A\0\0\0\M^@\0\0\0j\0\0\0\0"...,128) =3D 128 (0x80) lseek(2,0x80,SEEK_SET) =3D 128 (0x80) read(2,"/lib:/usr/lib:/usr/lib/compat:/u"...,106) =3D 106 (0x6a) close(2) =3D 0 (0x0) access("/lib/libthr.so.3",0) =3D 0 (0x0) open("/lib/libthr.so.3",O_RDONLY,030713440) =3D 2 (0x2) fstat(2,{ mode=3D-r--r--r-- ,inode=3D400430,size=3D85264,blksize=3D16384 })= =3D 0 (0x0) pread(0x2,0x800638700,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D 4096 (0x1000) mmap(0x0,1142784,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D 34366316544 (0x800646000) mmap(0x800646000,73728,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE= ,2,0x0) =3D 34366316544 (0x800646000) mmap(0x800757000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0x11000= ) =3D 34367434752 (0x800757000) mprotect(0x80075a000,12288,PROT_READ|PROT_WRITE) =3D 0 (0x0) close(2) =3D 0 (0x0) access("/lib/librt.so.1",0) ERR#2 'No such file or directory' access("/usr/lib/librt.so.1",0) =3D 0 (0x0) open("/usr/lib/librt.so.1",O_RDONLY,030713440) =3D 2 (0x2) fstat(2,{ mode=3D-r--r--r-- ,inode=3D2567883,size=3D21424,blksize=3D16384 }= ) =3D 0 (0x0) pread(0x2,0x800638700,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D 4096 (0x1000) mmap(0x0,1069056,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D 34367459328 (0x80075d000) mmap(0x80075d000,20480,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE= ,2,0x0) =3D 34367459328 (0x80075d000) mmap(0x800861000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0x4000) =3D 34368524288 (0x800861000) close(2) =3D 0 (0x0) access("/lib/libc.so.7",0) =3D 0 (0x0) open("/lib/libc.so.7",O_RDONLY,030713440) =3D 2 (0x2) fstat(2,{ mode=3D-r--r--r-- ,inode=3D400388,size=3D1156744,blksize=3D16384 = }) =3D 0 (0x0) pread(0x2,0x800638700,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D 4096 (0x1000) mmap(0x0,2281472,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D 34368528384 (0x800862000) mmap(0x800862000,995328,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCOR= E,2,0x0) =3D 34368528384 (0x800862000) mmap(0x800a54000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0xf200= 0) =3D 34370568192 (0x800a54000) mprotect(0x800a74000,110592,PROT_READ|PROT_WRITE) =3D 0 (0x0) close(2) =3D 0 (0x0) sysarch(0x81,0x7fffffffe220,0x800534188,0x0,0xffffffffffad9550,0x8080808080= 808080) =3D 0 (0x0) mmap(0x0,416,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365206528 (0x80053= 7000) munmap(0x800537000,416) =3D 0 (0x0) mmap(0x0,8064,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365206528 (0x8005= 37000) munmap(0x800537000,8064) =3D 0 (0x0) mmap(0x0,2944,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365206528 (0x8005= 37000) munmap(0x800537000,2944) =3D 0 (0x0) mmap(0x0,43296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365206528 (0x800= 537000) munmap(0x800537000,43296) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) __sysctl(0x7fffffffe1c0,0x2,0x800a7ab40,0x7fffffffe1b8,0x0,0x0) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) getpid() =3D 45130 (0xb04a) __sysctl(0x7fffffffe1b0,0x2,0x80075c3f0,0x7fffffffe1b8,0x0,0x0) =3D 0 (0x0) __sysctl(0x7fffffffe0d0,0x2,0x7fffffffe0f0,0x7fffffffe158,0x800656dc8,0xd) =3D 0 (0x0) __sysctl(0x7fffffffe0f0,0x3,0x80075b2e8,0x7fffffffe1b8,0x0,0x0) =3D 0 (0x0) __sysctl(0x7fffffffe170,0x2,0x800a7a628,0x7fffffffe168,0x0,0x0) =3D 0 (0x0) __sysctl(0x7fffffffdc60,0x2,0x7fffffffdc8c,0x7fffffffdc80,0x0,0x0) =3D 0 (0= x0) __sysctl(0x7fffffffdb50,0x2,0x7fffffffdb70,0x7fffffffdbd8,0x80094d340,0xc) =3D 0 (0x0) __sysctl(0x7fffffffdb70,0x2,0x800a7a2f0,0x7fffffffdc20,0x0,0x0) =3D 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffdc90,1024) ERR#2 'No such file or directory' issetugid(0x80094bf4f,0x7fffffffdc90,0x0,0x0,0x2,0x0) =3D 0 (0x0) break(0x800000) =3D 0 (0x0) __sysctl(0x7fffffffdcb0,0x2,0x7fffffffdccc,0x7fffffffdcc0,0x0,0x0) =3D 0 (0= x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D 34370809856 (0x800a8f000) mmap(0x800e8f000,1511424,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D 34375004160 (0x800e8f000) munmap(0x800a8f000,1511424) =3D 0 (0x0) thr_self(0x800c071c0,0x0,0x0,0x0,0x188,0x5018a8) =3D 0 (0x0) mmap(0x7fffffbff000,4096,PROT_NONE,MAP_ANON,-1,0x0) =3D 140737484156928 (0x7fffffbff000) thr_set_name(0x18a7f,0x800656e10,0x0,0x1000,0xffffffff,0x0) =3D 0 (0x0) rtprio_thread(0x0,0x18a7f,0x7fffffffe160,0x1000,0xffffffff,0x0) =3D 0 (0x0) sysarch(0x81,0x7fffffffe180,0x80075aec0,0x80075b248,0xffffffff,0x0) =3D 0 (= 0x0) sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGABRT|SIGEMT|SIGFPE|= SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTST= P|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|S= IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigaction(32,{ 0x8006511dc SA_RESTART|SA_SIGINFO ss_t },0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) kmq_open(0x401089,0x206,0x1ff,0x7fffffffe6a0,0x10,0x5018a8) ERR#78 'Function not implemented' SIGNAL 12 (SIGSYS) process exit, rval =3D 0 /* * Copyright (c) 2002, Intel Corporation. All rights reserved. * Created by: crystal.xiong REMOVE-THIS AT intel DOT com * This file is licensed under the GPL license. For the full content * of this license, see the COPYING file at the top level of this * source tree. * * 1. Two threads sending/receiving on different message queue. * 2. Set different Priority to the messages in the message queue, to * see whether the highest priority is received first. */ #include #include #include #include #include #include #include #include #include #include #include #include "posixtest.h" #define MQ_NAME_1 "/testmsg1" #define MQ_NAME_2 "/testmsg2" #define MSG_SIZE 128 #define MAX_MSG 3 const char *s_msg_ptr[] =3D {"msg test 1", "msg test 2", "msg test 3"}; char r_msg_ptr_1[MAX_MSG][MSG_SIZE]; char r_msg_ptr_2[MAX_MSG][MSG_SIZE]; pthread_t send1, send2, rev1, rev2; int * send_1(void * mq) { int i; mqd_t mq1 =3D *(mqd_t *)mq; printf("Enter into send_1 \n"); for (i =3D 0; i < MAX_MSG; i++ ) { if ( -1 =3D=3D mq_send(mq1, s_msg_ptr[i], MSG_SIZE, i)) { perror("mq_send doesn't return success \n"); pthread_exit((void *)1); } printf("[%d] send '%s' in thread send_1. \n", i+1, s_msg_ptr[i]); } pthread_exit((void *)0); } int * send_2(void * mq) { int i; mqd_t mq2 =3D *(mqd_t *)mq; printf("Enter into send_2 \n"); for (i =3D 0; i < MAX_MSG; i++ ) { if ( -1 =3D=3D mq_send(mq2, s_msg_ptr[i], MSG_SIZE, i)) { perror("mq_send doesn't return success \n"); pthread_exit((void *)1); } printf("[%d] send '%s' in thread send_2. \n", i+1, s_msg_ptr[i]); } pthread_exit((void *)0); } int * receive_1(void * mq) { int i; mqd_t mq1 =3D *(mqd_t *)mq; printf("Enter into receive_1 \n"); for (i =3D 0; i< MAX_MSG; i++) { if ( -1 =3D=3D mq_receive(mq1, r_msg_ptr_1[i], MSG_SIZE, NULL) ) { perror("mq_receive doesn't return success \n"); pthread_exit((void *)1); } printf("[%d] receive '%s' in thread receive_1. \n", i+1, r_msg_ptr_1[i]); } pthread_exit((void *)0); } int * receive_2(void * mq) { int i; mqd_t mq2 =3D *(mqd_t *)mq; printf("Enter into receive_2 \n"); for (i =3D 0; i< MAX_MSG; i++) { if ( -1 =3D=3D mq_receive(mq2, r_msg_ptr_2[i], MSG_SIZE, NULL) ) { perror("mq_receive doesn't return success \n"); pthread_exit((void *)1); } printf("[%d] receive '%s' in thread receive_2. \n", i+1, r_msg_ptr_2[i]); } pthread_exit((void *)0); } int main(int argc, char *argv[]) { =09 mqd_t mq1 =3D 0, mq2 =3D 0;=09 struct mq_attr mqstat; int oflag =3D O_CREAT|O_NONBLOCK|O_RDWR; memset(&mqstat, 0, sizeof(mqstat)); mqstat.mq_maxmsg =3D MAX_MSG; mqstat.mq_msgsize =3D MSG_SIZE; mqstat.mq_flags =3D 0; if( ((mqd_t) -1) =3D=3D (mq1 =3D mq_open(MQ_NAME_1,oflag,0777, &mqstat))= ) { printf("mq_open doesn't return success \n"); return PTS_UNRESOLVED; } if( ((mqd_t) -1) =3D=3D (mq2 =3D mq_open(MQ_NAME_2,oflag,0777, &mqstat))= ) { printf("mq_open doesn't return success \n"); return PTS_UNRESOLVED; } pthread_create(&send1, NULL, (void *)send_1, (void *)&mq1); pthread_create(&send2, NULL, (void *)send_2, (void *)&mq2); pthread_create(&rev1, NULL, (void *)receive_1, (void *)&mq1);=09 pthread_create(&rev2, NULL, (void *)receive_2, (void *)&mq2);=09 pthread_join(send1, NULL); pthread_join(send2, NULL); pthread_join(rev1, NULL); pthread_join(rev2, NULL); =09 mq_close(mq1); mq_close(mq2); mq_unlink(MQ_NAME_1); mq_unlink(MQ_NAME_2); return PTS_PASS; } From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 22:11:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BEE21065670; Sun, 20 Jun 2010 22:11:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE8918FC1A; Sun, 20 Jun 2010 22:11:42 +0000 (UTC) Received: by qyk11 with SMTP id 11so1344655qyk.13 for ; Sun, 20 Jun 2010 15:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SyJp6fYlmfihmyWeHNY52kYwKlpcYYZyBdhG9Oy4g80=; b=iyrpWUdJJY+SaJrtQ+qYatLjM9yArFr8c76We4xyO907g9svthR73pgoF1CP4yhWb2 eBjlH4GrwxK+7Uf3jTpyUhgrpqtx8vRqU4YQ9tgpRXSHXPoYtBbmKIsVbo0pKB5AZ5Qv 6j+8xgSQYGRHILLS+zXbt6wnVyQnJPVhUDz3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YCA6Q78GkMUL2suTiPBLqbX695KRgFtiuNT46J0WYVIgr6Km9o1ynRSMyrxECIJDFT Jpj4+IiU2rl3h414BeOOkv7x1BpsHP+bWHea+r5Mzvo6LJTm5tjApMztdCPshnTK8ldP D+6O/AAIPiVMtl4IuCkwYLAjX8H1ovj7m8RFY= MIME-Version: 1.0 Received: by 10.224.80.65 with SMTP id s1mr2566096qak.239.1277071901956; Sun, 20 Jun 2010 15:11:41 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sun, 20 Jun 2010 15:11:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jun 2010 15:11:41 -0700 Message-ID: From: Garrett Cooper To: Stathis Kamperis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers , standards@freebsd.org Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 22:11:43 -0000 On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis wrot= e: > 2010/6/21 Garrett Cooper : >> =A0 =A0Err... I ran an mqueue test and it popped up with ENOSYS. Which >> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I >> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I > > Hi, > > did you first load the respective kernel module (mqueuefs or something > like that) ? Duh... should have checked that first I suppose: no, it isn't loaded. However, it doesn't appear to compile with my copy of src: # make -C /sys/modules/mqueue/ all install Warning: Object directory not changed from original /usr/src/sys/modules/mq= ueue cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=3Dnocona -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error: opt_compat.h: No such file or directory *** Error code 1 Stop in /usr/src/sys/modules/mqueue. # find /usr/src/ -name opt_compat.h So I'll need to hunt down what's going on with the missing header. Thanks :), -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 22:15:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C74106566B for ; Sun, 20 Jun 2010 22:15:39 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from praag.hoster.bg (praag.hoster.bg [77.77.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 888858FC0A for ; Sun, 20 Jun 2010 22:15:38 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by praag.hoster.bg (Postfix) with ESMTP id C93378CA5B for ; Mon, 21 Jun 2010 01:15:36 +0300 (EEST) Received: from straylight.ringlet.net (middenheim.hoster.bg [77.77.142.11]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 771F15C3B8 for ; Mon, 21 Jun 2010 01:15:21 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 416008 by straylight.ringlet.net (DragonFly Mail Agent) Mon, 21 Jun 2010 01:15:15 +0300 Date: Mon, 21 Jun 2010 01:15:15 +0300 From: Peter Pentchev To: Garrett Cooper Message-ID: <20100620221515.GA2574@straylight.ringlet.net> Mail-Followup-To: Garrett Cooper , FreeBSD-Hackers , standards@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 771F15C3B8.80ACB X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-hackers@freebsd.org X-Spam-Status: No Cc: FreeBSD-Hackers , standards@freebsd.org Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 22:15:39 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 20, 2010 at 03:02:35PM -0700, Garrett Cooper wrote: > Err... I ran an mqueue test and it popped up with ENOSYS. Which > makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I > looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I > could be misreading the code. Another test written which tests mqueue > appears to be broken as well (I'll include that in a later email if > interested). I also attached the truss output and the relative code > blurb for a little more analysis. > Thanks, > -Garrett >=20 > PS I'm not guaranteeing that the code below doesn't have bugs in it as > I'm not the original author and the tests were originally written and > targeted towards Linux. Do you have the P1003_1B_MQUEUE option in your kernel config? G'luck, Peter --=20 Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJMHpLvAAoJEGUe77AlJ98TNTsQAIhNrXfKSbvyY2kkUUTazIJj LoYXFOrkDZno6VK22lXQ3pz5KjYDXDpKvTd/rD8teRZw5NjmZPbbfhLbuHFra05B wPnF0yzhbXYVqKotmeQPWY1HVotkxb++thwLm8SrWRrD5dsFoH94cvq9fyyG8JDD DwkLTlZET3aWj92w2ks+H+VkS5nD0b09S/ViqumvKGi6Mdz73LH0FzI+IuztesjV Zw7R6itJmfabQyXf06rPnjxQd7OmipgiwL84+06kGA+ym6weg6pkmi2J17g7j+6t rDHRUunqyzLEOGUXzD3QVhGRPHtvqG1s8gWaHCvZrUFQUsK4m6TBcF/ImtDdKR2G PPM0JDYFhYU84SPDk27qZTJ7ppn+QSlbKqZc+MLP/fP2XHudkIfE0KjRF/dj/lAR PL6Ht9mHrSUjKhEjHXXBRLFVe6f3FH1pe1NQegih7ajsedhEwyce7aooDh+ArZl2 xj9QjfIE4Al9RCKUIKzmDs4fYZWUqYiySNkuCXX9+eFcJVzY0dsfxUn99toHMWvt G6hn2r2O3ZwhNKR4OKx9oBLfyf/mcNp+DOAnf9tp6Y8FBi/FO4P2rLlAbJ97NwhQ aztkk0U0ZjzEAw1ufgLXwNeHhJXg4IrPBMAVCG3ReYTeZuD1c2puKHNUd7Fbfdkr iDETx78IlUMh43Unp2It =PdJ+ -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 22:29:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9F51065670; Sun, 20 Jun 2010 22:29:53 +0000 (UTC) (envelope-from ekamperi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58EC48FC13; Sun, 20 Jun 2010 22:29:52 +0000 (UTC) Received: by bwz8 with SMTP id 8so1310889bwz.13 for ; Sun, 20 Jun 2010 15:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9/a2g5yAGJ63pqFvZ+/0lwlCN/x+tDLh1n0rG2tMhE8=; b=ctZYYhC3feEu+6icnGIGKcnn+KhGv+nfhsusURlzTvHQ7UeQKq74KECBPMcU3ca/xg S5D89ihkO+JVIPTrTacnhLcuOfaj1k/W74DA205bwTjuzV3o7xecRdjiS2EY2P2yaZ37 R7p58569N6BqYFfTQJ152xDGeQ/wZVspDs+sU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XRw8l/9Cfs6LLQ5Wnt7wUaXK36JNfJdrgv+1bDMi3uSRGdEmoXgoKt5+a2i13ZtjZz ejt2GI+uJHn2dn94IxckAl/38dsWShrRO2CcWsZTShSxwMq+iAJnyX5HrahebHrFoyrF yOvqmW0FhAKblgpY6JRphtb9zql2PxfjffD4c= MIME-Version: 1.0 Received: by 10.204.83.82 with SMTP id e18mr2221291bkl.138.1277071609629; Sun, 20 Jun 2010 15:06:49 -0700 (PDT) Received: by 10.204.58.131 with HTTP; Sun, 20 Jun 2010 15:06:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 01:06:49 +0300 Message-ID: From: Stathis Kamperis To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 20 Jun 2010 23:38:42 +0000 Cc: FreeBSD-Hackers , standards@freebsd.org Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 22:29:53 -0000 2010/6/21 Garrett Cooper : > =A0 =A0Err... I ran an mqueue test and it popped up with ENOSYS. Which > makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I > looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I Hi, did you first load the respective kernel module (mqueuefs or something like that) ? Cheers, Stathis From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 20 23:41:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F02581065672 for ; Sun, 20 Jun 2010 23:41:59 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 905598FC13 for ; Sun, 20 Jun 2010 23:41:59 +0000 (UTC) Received: by vws1 with SMTP id 1so172168vws.13 for ; Sun, 20 Jun 2010 16:41:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.123.158 with SMTP id p30mr1573607vcr.133.1277077318773; Sun, 20 Jun 2010 16:41:58 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.220.72.134 with HTTP; Sun, 20 Jun 2010 16:41:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 11:41:58 +1200 X-Google-Sender-Auth: Ol-RiH-74azUJXlA6gKVut4yLic Message-ID: From: Andrew Thompson To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stathis Kamperis , standards@freebsd.org, FreeBSD-Hackers Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 23:42:00 -0000 On 21 June 2010 10:11, Garrett Cooper wrote: > On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis wr= ote: >> 2010/6/21 Garrett Cooper : >>> =A0 =A0Err... I ran an mqueue test and it popped up with ENOSYS. Which >>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I >>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I >> >> Hi, >> >> did you first load the respective kernel module (mqueuefs or something >> like that) ? > > Duh... should have checked that first I suppose: no, it isn't loaded. > However, it doesn't appear to compile with my copy of src: > > # make -C /sys/modules/mqueue/ all install > Warning: Object directory not changed from original /usr/src/sys/modules/= mqueue > cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=3Dnocona -Werror > -D_KERNEL -DKLD_MODULE -nostdinc =A0 -I. -I@ -I@/contrib/altq > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-common =A0-fno-omit-frame-pointer > -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno-sse -mno-sse2 > -mno-sse3 -mno-mmx -mno-3dnow =A0-msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions -c > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error: > opt_compat.h: No such file or directory > *** Error code 1 > > Stop in /usr/src/sys/modules/mqueue. > # find /usr/src/ -name opt_compat.h > > So I'll need to hunt down what's going on with the missing header. opt_* headers are auto-generated by the kernel config. Just add opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 00:25:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEED8106564A; Mon, 21 Jun 2010 00:25:28 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 736E88FC0C; Mon, 21 Jun 2010 00:25:28 +0000 (UTC) Received: by vws1 with SMTP id 1so206397vws.13 for ; Sun, 20 Jun 2010 17:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LkRkTEiIH0iV/SpcgTve2+Emc0r1FuOx0k6++Cj81Jg=; b=IUb3+7FTLbFA4aGJhL1kyLIwklOmT8SchMsAeKkFMMIqjWArLsRLfwVV7reWh4IEMB ZuSNu3L15kAKQhOyhlCAE+2RzHDKcGpIlspEV7lrwfAdNUz2YI+4vh26dzBvsNVbd8vJ lUZDZxG4GTHPxkQdGo6vMLVXRSlCplelF1EcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SVM39me2GwGJFe6DWE4q/sA9YQboEPPMSk6vlusSUJskyBKL6bksSUs1m6CocsHRRu R0Igs5vli/+GDngyeTH4ynMeJJKk5CiZKunmWlxoosDBPQ3N2VGqSKNxauzibd8/MCI1 aTFDkn9yZh8EdK5Lc4dJjWDl6vLh8moxRbrMw= MIME-Version: 1.0 Received: by 10.229.248.129 with SMTP id mg1mr2043269qcb.137.1277079927500; Sun, 20 Jun 2010 17:25:27 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sun, 20 Jun 2010 17:25:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jun 2010 17:25:27 -0700 Message-ID: From: Garrett Cooper To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stathis Kamperis , standards@freebsd.org, FreeBSD-Hackers Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 00:25:29 -0000 On Sun, Jun 20, 2010 at 4:41 PM, Andrew Thompson wrot= e: > On 21 June 2010 10:11, Garrett Cooper wrote: >> On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis w= rote: >>> 2010/6/21 Garrett Cooper : >>>> =A0 =A0Err... I ran an mqueue test and it popped up with ENOSYS. Which >>>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I >>>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I >>> >>> Hi, >>> >>> did you first load the respective kernel module (mqueuefs or something >>> like that) ? >> >> Duh... should have checked that first I suppose: no, it isn't loaded. >> However, it doesn't appear to compile with my copy of src: >> >> # make -C /sys/modules/mqueue/ all install >> Warning: Object directory not changed from original /usr/src/sys/modules= /mqueue >> cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=3Dnocona -Werror >> -D_KERNEL -DKLD_MODULE -nostdinc =A0 -I. -I@ -I@/contrib/altq >> -finline-limit=3D8000 --param inline-unit-growth=3D100 --param >> large-function-growth=3D1000 -fno-common =A0-fno-omit-frame-pointer >> -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno-sse -mno-sse2 >> -mno-sse3 -mno-mmx -mno-3dnow =A0-msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector >> -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign >> -fformat-extensions -c >> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c >> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error: >> opt_compat.h: No such file or directory >> *** Error code 1 >> >> Stop in /usr/src/sys/modules/mqueue. >> # find /usr/src/ -name opt_compat.h >> >> So I'll need to hunt down what's going on with the missing header. > > opt_* headers are auto-generated by the kernel config. Just add > opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h I did some reading and opt_compat is generated by options COMPAT_* in KERNC= ONF. For whatever reason my source tree wasn't prebuilt, so I reran buildkernel and everything was fine once again. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 02:45:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE520106564A for ; Mon, 21 Jun 2010 02:45:22 +0000 (UTC) (envelope-from sudakov@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4398FC0C for ; Mon, 21 Jun 2010 02:45:21 +0000 (UTC) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 13999612 for freebsd-hackers@freebsd.org; Mon, 21 Jun 2010 08:45:18 +0700 Received: from admin.sibptus.tomsk.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.tomsk.ru (8.14.3/8.14.3) with ESMTP id o5L1jH5F088637 for ; Mon, 21 Jun 2010 08:45:18 +0700 (OMSST) (envelope-from sudakov@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.14.3/8.14.3/Submit) id o5L1jHmc088636 for freebsd-hackers@freebsd.org; Mon, 21 Jun 2010 08:45:17 +0700 (OMSST) (envelope-from sudakov@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov@sibptus.tomsk.ru using -f Date: Mon, 21 Jun 2010 08:45:17 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Message-ID: <20100621014517.GA88572@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-hackers@freebsd.org References: <4B408745.3030309@andric.com> <09f445615c18768df17418f06d872a46.squirrel@www.noacks.org> <20100615022837.GB23583@admin.sibptus.tomsk.ru> <20100615131441.5b82d4eb@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc X-Mailman-Approved-At: Mon, 21 Jun 2010 02:59:48 +0000 Subject: Re: "Checksum mismatch -- will transfer entire file" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 02:45:22 -0000 Christian Weisgerber wrote: > > > csup already has a CVS mode, at least in 9-current. I don't use older > > versions of FreeBSD so I don't know whether it supports CVS there. > > It does at least down to 7.x. High time to fix this botheration, isn't it? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 08:09:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EF51065672 for ; Mon, 21 Jun 2010 08:09:43 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 457C88FC20 for ; Mon, 21 Jun 2010 08:09:42 +0000 (UTC) Received: by bwz8 with SMTP id 8so1436177bwz.13 for ; Mon, 21 Jun 2010 01:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=GjRQoep5tjC09VeH3/isET+qyi/AW3FqdjiTXwtAP4c=; b=UI1w9S9lEHN6Ax72lG+db03h0EBWii72ENwG0zYk9GWZbvVPk5NjqonUJowwSRx7f/ ihwutSZSY88ABlnopdeaIxbO5+D/KFQUQ4pVKDJwlI+gtOR4ULOpaFq8t/ftGk01xU4y hG+kqHrpjQYF0rZPsCWwZ1Pt7+fUtnrW971YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=GwGM/UGKuPIwNik3xmortiPjGMgBcpJ0iFQza30JJHwxzXZKoN7TCxnmkzYML7tA2s deoKz05vnWuY8vdbvjZ4r9IlFb4shEBJFnyk7ATvOR9JzVr/GzIxmOtNdZmvxlWYW5ha HKQ3Q0P5zfioEpEMRiRLqIDh6nRyoI+dN/s/I= Received: by 10.204.46.202 with SMTP id k10mr2598341bkf.152.1277107782017; Mon, 21 Jun 2010 01:09:42 -0700 (PDT) Received: from ernst.jennejohn.org (p578E1A33.dip.t-dialin.net [87.142.26.51]) by mx.google.com with ESMTPS id w11sm6631388bka.32.2010.06.21.01.09.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jun 2010 01:09:41 -0700 (PDT) Date: Mon, 21 Jun 2010 10:09:39 +0200 From: Gary Jennejohn To: Victor Sudakov Message-ID: <20100621100939.5c947f7e@ernst.jennejohn.org> In-Reply-To: <20100621014517.GA88572@admin.sibptus.tomsk.ru> References: <4B408745.3030309@andric.com> <09f445615c18768df17418f06d872a46.squirrel@www.noacks.org> <20100615022837.GB23583@admin.sibptus.tomsk.ru> <20100615131441.5b82d4eb@ernst.jennejohn.org> <20100621014517.GA88572@admin.sibptus.tomsk.ru> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: "Checksum mismatch -- will transfer entire file" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:09:43 -0000 On Mon, 21 Jun 2010 08:45:17 +0700 Victor Sudakov wrote: > Christian Weisgerber wrote: > > > > > csup already has a CVS mode, at least in 9-current. I don't use older > > > versions of FreeBSD so I don't know whether it supports CVS there. > > > > It does at least down to 7.x. > > High time to fix this botheration, isn't it? > This has been discussed in some mailing list (don't remember which) before. IIRC the problem is caused by the mechanism used to check commits from svn into CVS. I doubt it's easy to fix and IMO not worth the bother. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 08:17:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 051CB106566B; Mon, 21 Jun 2010 08:17:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA7D8FC23; Mon, 21 Jun 2010 08:17:52 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o5L8GZA0004707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 11:16:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o5L8GZ58093396; Mon, 21 Jun 2010 11:16:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5L8GZ6F093395; Mon, 21 Jun 2010 11:16:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jun 2010 11:16:35 +0300 From: Kostik Belousov To: Andrew Thompson Message-ID: <20100621081635.GB13238@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O1+DDjaLRatPxzPT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , standards@freebsd.org, FreeBSD-Hackers , Stathis Kamperis Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:17:54 -0000 --O1+DDjaLRatPxzPT Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 21, 2010 at 11:41:58AM +1200, Andrew Thompson wrote: > On 21 June 2010 10:11, Garrett Cooper wrote: > > On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis = wrote: > >> 2010/6/21 Garrett Cooper : > >>> =9A =9AErr... I ran an mqueue test and it popped up with ENOSYS. Which > >>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I > >>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I > >> > >> Hi, > >> > >> did you first load the respective kernel module (mqueuefs or something > >> like that) ? > > > > Duh... should have checked that first I suppose: no, it isn't loaded. > > However, it doesn't appear to compile with my copy of src: > > > > # make -C /sys/modules/mqueue/ all install > > Warning: Object directory not changed from original /usr/src/sys/module= s/mqueue > > cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=3Dnocona -Werror > > -D_KERNEL -DKLD_MODULE -nostdinc =9A -I. -I@ -I@/contrib/altq > > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > > large-function-growth=3D1000 -fno-common =9A-fno-omit-frame-pointer > > -mcmodel=3Dkernel -mno-red-zone =9A-mfpmath=3D387 -mno-sse -mno-sse2 > > -mno-sse3 -mno-mmx -mno-3dnow =9A-msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes =9A-Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual =9A-Wundef -Wno-pointer-sign > > -fformat-extensions -c > > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c > > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error: > > opt_compat.h: No such file or directory > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/mqueue. > > # find /usr/src/ -name opt_compat.h > > > > So I'll need to hunt down what's going on with the missing header. >=20 > opt_* headers are auto-generated by the kernel config. Just add > opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h Apparently, missed opt_compat.h in module Makefile is my fault. Would you, please, commit the fix ? --O1+DDjaLRatPxzPT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwfH+MACgkQC3+MBN1Mb4i5NQCfXzcCWpncbiHbPgSCXBVgr40Y g04AoJycCE73SjE8Yes8vWNcKWUj7Ldy =UeRi -----END PGP SIGNATURE----- --O1+DDjaLRatPxzPT-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 11:24:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F9D106566C for ; Mon, 21 Jun 2010 11:24:41 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBDC8FC0A for ; Mon, 21 Jun 2010 11:24:40 +0000 (UTC) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 14002214 for freebsd-hackers@freebsd.org; Mon, 21 Jun 2010 17:24:37 +0700 Received: from admin.sibptus.tomsk.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.tomsk.ru (8.14.3/8.14.3) with ESMTP id o5LAOaZd093346 for ; Mon, 21 Jun 2010 17:24:37 +0700 (OMSST) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.14.3/8.14.3/Submit) id o5LAOapM093345 for freebsd-hackers@freebsd.org; Mon, 21 Jun 2010 17:24:36 +0700 (OMSST) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Mon, 21 Jun 2010 17:24:35 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Message-ID: <20100621102435.GA93258@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-hackers@freebsd.org References: <4B408745.3030309@andric.com> <09f445615c18768df17418f06d872a46.squirrel@www.noacks.org> <20100615022837.GB23583@admin.sibptus.tomsk.ru> <20100615131441.5b82d4eb@ernst.jennejohn.org> <20100621014517.GA88572@admin.sibptus.tomsk.ru> <20100621100939.5c947f7e@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100621100939.5c947f7e@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS Subject: Re: "Checksum mismatch -- will transfer entire file" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:24:41 -0000 Gary Jennejohn wrote: > > > > > > > csup already has a CVS mode, at least in 9-current. I don't use older > > > > versions of FreeBSD so I don't know whether it supports CVS there. > > > > > > It does at least down to 7.x. > > > > High time to fix this botheration, isn't it? > > > > This has been discussed in some mailing list (don't remember which) before. > > IIRC the problem is caused by the mechanism used to check commits from svn > into CVS. simon@ holds a different view: http://lists.freebsd.org/pipermail/freebsd-hubs/2009-August/002083.html > I doubt it's easy to fix and IMO not worth the bother. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 14:39:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAFA106564A; Mon, 21 Jun 2010 14:39:12 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 442D28FC0A; Mon, 21 Jun 2010 14:39:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA23978; Mon, 21 Jun 2010 17:39:09 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C1F798C.7010204@freebsd.org> Date: Mon, 21 Jun 2010 17:39:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:39:12 -0000 I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module are zeros. This is unlike kernel itself and i386 modules. Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a certain base address and taking into account their sizes and alignment requirements. On the other hand, kgdb calculates section address as module base address plus sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the same address. This is correct only for .text which is normally the first section described in a header. DTrace situation is even worse, because don't even take into account module base address, not speaking of section relative addresses. Perhaps we should put some sh_addr values into amd64 kernel modules that would match calculations done in link_elf_load_file. Or should we replicate logic from link_elf_load_file in all places that need to map loaded module's sections to load addresses? What do you think? Thanks! P.S. As I understand CTF data includes a symbol table. What kind of symbol addresses is used there? Are they relative within a corresponding section? Or something else? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 15:43:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C2C11065675; Mon, 21 Jun 2010 15:43:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E26CD8FC08; Mon, 21 Jun 2010 15:43:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9678546B5C; Mon, 21 Jun 2010 11:43:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC9DF8A04F; Mon, 21 Jun 2010 11:43:45 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 21 Jun 2010 11:09:11 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100619154822.GA1166@a91-153-117-195.elisa-laajakaista.fi> In-Reply-To: <20100619154822.GA1166@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006211109.11653.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Jun 2010 11:43:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Jaakko Heinonen , phk@freebsd.org Subject: Re: [patch] extending alloc_unr(9) to allocate specific unit numbers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:43:47 -0000 On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: > > Hi, > > I wrote a patch to extend the kernel unit number allocator for > allocating specific unit numbers. The patch adds a new function > alloc_unr_specific() which returns the requested unit number if it is > free and -1 if the number is already allocated or out of the range. > Unlike alloc_unr(), alloc_unr_specific() may allocate memory and thus > sleep. > > The patch is here: > > http://people.freebsd.org/~jh/patches/alloc_unr_specific.diff > > I think that this functionality has been requested by some people. > Reviews/comments? > > As an example here is md(4) converted to use > alloc_unr() / alloc_unr_specific(): > > http://people.freebsd.org/~jh/patches/md-alloc_unr.diff This sounds useful to me. Perhaps ask phk@? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 15:43:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B141065672; Mon, 21 Jun 2010 15:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D9C8C8FC14; Mon, 21 Jun 2010 15:43:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8D2D846B5C; Mon, 21 Jun 2010 11:43:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A1DC68A04F; Mon, 21 Jun 2010 11:43:50 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 21 Jun 2010 11:43:26 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4C1F798C.7010204@freebsd.org> In-Reply-To: <4C1F798C.7010204@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006211143.26459.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Jun 2010 11:43:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:43:52 -0000 On Monday 21 June 2010 10:39:08 am Andriy Gapon wrote: > > I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module > are zeros. > This is unlike kernel itself and i386 modules. > > Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a > certain base address and taking into account their sizes and alignment requirements. > > On the other hand, kgdb calculates section address as module base address plus > sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the > same address. This is correct only for .text which is normally the first section > described in a header. > > DTrace situation is even worse, because don't even take into account module base > address, not speaking of section relative addresses. > > Perhaps we should put some sh_addr values into amd64 kernel modules that would > match calculations done in link_elf_load_file. > Or should we replicate logic from link_elf_load_file in all places that need to > map loaded module's sections to load addresses? > > What do you think? > Thanks! > > P.S. > As I understand CTF data includes a symbol table. > What kind of symbol addresses is used there? Are they relative within a > corresponding section? Or something else? np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 15:57:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB25106564A; Mon, 21 Jun 2010 15:57:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 44D5E8FC0A; Mon, 21 Jun 2010 15:57:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA25914; Mon, 21 Jun 2010 18:57:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C1F8BDD.9010408@freebsd.org> Date: Mon, 21 Jun 2010 18:57:17 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: John Baldwin , Navdeep Parhar References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> In-Reply-To: <201006211143.26459.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:57:20 -0000 on 21/06/2010 18:43 John Baldwin said the following: > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of > a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell script, that would set section addresses in amd64 .ko (relocatable object file) similarly to how they are set in i386 .ko (full-blown DSO)? Or is this too much useless hassle? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 19:13:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0480C106566B; Mon, 21 Jun 2010 19:13:36 +0000 (UTC) (envelope-from anjali@juniper.net) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2D18FC16; Mon, 21 Jun 2010 19:13:35 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTB+53k3cW19CvX/GCWsv81bgZ2zFnEld@postini.com; Mon, 21 Jun 2010 12:13:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 21 Jun 2010 12:09:45 -0700 From: Anjali Kulkarni To: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" Date: Mon, 21 Jun 2010 12:09:45 -0700 Thread-Topic: About Marvell Yukon drivers skgeinit and sky2 Thread-Index: AQHLEXN9uySAKNFp702lKoWf1//FKg== Message-ID: <50B3A5560BA4D74CADEC55A48B4641B23D5AD26EBF@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Anjali Kulkarni Subject: About Marvell Yukon drivers skgeinit and sky2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 19:13:36 -0000 Hi, As I understand, there are 2 flavors of the Marvel Yukon driver. One is for= Yukon-I devices, and is called skgeinit, and other is for Yukon-II devices= and called sky2 driver.=20 Looking at the release notes for 7.0, it looks like this driver which was i= n sys/dev/yukon, is now present as the msk(4) driver in sys/dev/msk and sys= /dev/sk?. I do not see a yukon under dev anymore. I see only 2 files in the= msk directory, is it really moved here?=20 Is the Yukon-II sky2 driver support present in Freebsd 6.1? How easy would = it to backport this to 6.1? If yes, then is there a way to disable the skgeinit(which seems to be the d= efault) and enable the sky2 driver? Anjali From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 19:42:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622E81065693 for ; Mon, 21 Jun 2010 19:42:07 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 25A728FC12 for ; Mon, 21 Jun 2010 19:42:06 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BD060900AD; Mon, 21 Jun 2010 19:25:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o5LJPALN092374; Mon, 21 Jun 2010 19:25:10 GMT (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 21 Jun 2010 11:09:11 -0400." <201006211109.11653.jhb@freebsd.org> Date: Mon, 21 Jun 2010 19:25:10 +0000 Message-ID: <92373.1277148310@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, Jaakko Heinonen Subject: Re: [patch] extending alloc_unr(9) to allocate specific unit numbers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 19:42:07 -0000 In message <201006211109.11653.jhb@freebsd.org>, John Baldwin writes: >On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: >> As an example here is md(4) converted to use >> alloc_unr() / alloc_unr_specific(): >> >> http://people.freebsd.org/~jh/patches/md-alloc_unr.diff > >This sounds useful to me. Perhaps ask phk@? My only worry is that if people start to use this indiscriminantly to store random collections of numbers, then it is far from the optimal data structure for it. Other than that: go for it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 20:15:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBD30106564A; Mon, 21 Jun 2010 20:15:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4C78FC12; Mon, 21 Jun 2010 20:15:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3FA7A46B5B; Mon, 21 Jun 2010 16:15:53 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A69AA8A03C; Mon, 21 Jun 2010 16:15:52 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 21 Jun 2010 16:10:45 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> In-Reply-To: <4C1F8BDD.9010408@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006211610.45811.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Jun 2010 16:15:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Navdeep Parhar , freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 20:15:53 -0000 On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > on 21/06/2010 18:43 John Baldwin said the following: > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > > patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of > > a better way to fix kgdb. > > Oh, yes, section mapping is done in common gdb code. > Perhaps kld.c shouldn't call build_section_table, but directly call > bfd_map_over_sections with a custom variant of add_to_section_table? > Can you please share the patch? It was deeper level than that, I'd have to dig it up. > Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell > script, that would set section addresses in amd64 .ko (relocatable object file) > similarly to how they are set in i386 .ko (full-blown DSO)? > Or is this too much useless hassle? No idea. If this worked and just let gdb work automatically that would be a nice fix to just put into the build process. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 20:44:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 2620C106566C; Mon, 21 Jun 2010 20:44:35 +0000 (UTC) Date: Mon, 21 Jun 2010 20:44:35 +0000 From: Navdeep Parhar To: John Baldwin Message-ID: <20100621204435.GA98177@hub.freebsd.org> Mail-Followup-To: John Baldwin , Andriy Gapon , freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006211610.45811.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, Andriy Gapon Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 20:44:35 -0000 On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: > On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > > on 21/06/2010 18:43 John Baldwin said the following: > > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > > > patched gdb internals and wasn't in a kgdb-specific place, but I'm not > sure of > > > a better way to fix kgdb. > > > > Oh, yes, section mapping is done in common gdb code. > > Perhaps kld.c shouldn't call build_section_table, but directly call > > bfd_map_over_sections with a custom variant of add_to_section_table? > > Can you please share the patch? > > It was deeper level than that, I'd have to dig it up. I'm using this patch these days: http://people.freebsd.org/~np/kgdb+kld+amd64.diff The changes to the kernel linker were not required originally. See this for why they had to be made: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html The patch is quite crude and I have no idea how it behaves on other platforms. Regards, Navdeep > > > Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell > > script, that would set section addresses in amd64 .ko (relocatable object > file) > > similarly to how they are set in i386 .ko (full-blown DSO)? > > Or is this too much useless hassle? > > No idea. If this worked and just let gdb work automatically that would be a > nice fix to just put into the build process. > > -- > John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 21:16:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F06691065672; Mon, 21 Jun 2010 21:16:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A09028FC1B; Mon, 21 Jun 2010 21:16:02 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o5LLEros086794; Mon, 21 Jun 2010 16:14:53 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o5LLEr5h086793; Mon, 21 Jun 2010 16:14:53 -0500 (CDT) (envelope-from brooks) Date: Mon, 21 Jun 2010 16:14:52 -0500 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20100621211452.GA83787@lor.one-eyed-alien.net> References: <201006211109.11653.jhb@freebsd.org> <92373.1277148310@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <92373.1277148310@critter.freebsd.dk> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 21 Jun 2010 16:14:54 -0500 (CDT) Cc: freebsd-hackers@freebsd.org, Jaakko Heinonen Subject: Re: [patch] extending alloc_unr(9) to allocate specific unit numbers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 21:16:03 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 21, 2010 at 07:25:10PM +0000, Poul-Henning Kamp wrote: > In message <201006211109.11653.jhb@freebsd.org>, John Baldwin writes: > >On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: >=20 > >> As an example here is md(4) converted to use > >> alloc_unr() / alloc_unr_specific(): > >>=20 > >> http://people.freebsd.org/~jh/patches/md-alloc_unr.diff > > > >This sounds useful to me. Perhaps ask phk@? >=20 > My only worry is that if people start to use this indiscriminantly to > store random collections of numbers, then it is far from the optimal > data structure for it. >=20 > Other than that: go for it. IIRC this is the one missing feature we need to convert if_clone to unr so I support it. -- Brooks --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFMH9ZMXY6L6fI4GtQRAll0AJ9LHnOj4/yWIzWwTAH9cwVJDBQgTACeMGEs AQmdGhCFHH+4KeQyz/GNy0U= =8lIf -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 21:34:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD9D106564A; Mon, 21 Jun 2010 21:34:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D314A8FC15; Mon, 21 Jun 2010 21:34:52 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02380; Tue, 22 Jun 2010 00:34:51 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OQodn-000Mvh-3K; Tue, 22 Jun 2010 00:34:51 +0300 Message-ID: <4C1FDAF9.3080808@freebsd.org> Date: Tue, 22 Jun 2010 00:34:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Navdeep Parhar , freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> In-Reply-To: <20100621204435.GA98177@hub.freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 21:34:54 -0000 on 21/06/2010 23:44 Navdeep Parhar said the following: > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: >>> on 21/06/2010 18:43 John Baldwin said the following: >>>> np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it >>>> patched gdb internals and wasn't in a kgdb-specific place, but I'm not >> sure of >>>> a better way to fix kgdb. >>> Oh, yes, section mapping is done in common gdb code. >>> Perhaps kld.c shouldn't call build_section_table, but directly call >>> bfd_map_over_sections with a custom variant of add_to_section_table? >>> Can you please share the patch? >> It was deeper level than that, I'd have to dig it up. > > I'm using this patch these days: > http://people.freebsd.org/~np/kgdb+kld+amd64.diff > > The changes to the kernel linker were not required originally. See this > for why they had to be made: > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html > > The patch is quite crude and I have no idea how it behaves on other > platforms. Thanks a lot! These are exact issues that I hit and the patches are what I think they should be, take or give. I don't think they are really crude. I will try to get them committed. Kernel linker change is good as is, I'd just like to move the zero size check before the switch statement. gdb change - I'd rather do it via kld_current_sos, kld_relocate_section_addresses. I'd like to avoid changing common gdb code for a variety of reasons. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 22:00:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 859DD1065670; Mon, 21 Jun 2010 22:00:35 +0000 (UTC) Date: Mon, 21 Jun 2010 22:00:35 +0000 From: Navdeep Parhar To: Andriy Gapon Message-ID: <20100621220035.GA8746@hub.freebsd.org> Mail-Followup-To: Andriy Gapon , freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, John Baldwin References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> <4C1FDAF9.3080808@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C1FDAF9.3080808@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:00:35 -0000 On Tue, Jun 22, 2010 at 12:34:49AM +0300, Andriy Gapon wrote: > on 21/06/2010 23:44 Navdeep Parhar said the following: > > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: > >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > >>> on 21/06/2010 18:43 John Baldwin said the following: > >>>> np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > >>>> patched gdb internals and wasn't in a kgdb-specific place, but I'm not > >> sure of > >>>> a better way to fix kgdb. > >>> Oh, yes, section mapping is done in common gdb code. > >>> Perhaps kld.c shouldn't call build_section_table, but directly call > >>> bfd_map_over_sections with a custom variant of add_to_section_table? > >>> Can you please share the patch? > >> It was deeper level than that, I'd have to dig it up. > > > > I'm using this patch these days: > > http://people.freebsd.org/~np/kgdb+kld+amd64.diff > > > > The changes to the kernel linker were not required originally. See this > > for why they had to be made: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html > > > > The patch is quite crude and I have no idea how it behaves on other > > platforms. > > Thanks a lot! These are exact issues that I hit and the patches are what I > think they should be, take or give. I don't think they are really crude. > I will try to get them committed. > > Kernel linker change is good as is, I'd just like to move the zero size check > before the switch statement. I'm not so sure about this. There is code inside the second switch that runs whether sh_size is 0 or not. Either all of it is pointless code (when sh_size is 0) or or you'll make sure that it still runs, right? Regards, Navdeep > > gdb change - I'd rather do it via kld_current_sos, > kld_relocate_section_addresses. I'd like to avoid changing common gdb code for > a variety of reasons. > > -- > Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 21 22:17:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38E191065670; Mon, 21 Jun 2010 22:17:18 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D3F6D8FC15; Mon, 21 Jun 2010 22:17:16 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA03191; Tue, 22 Jun 2010 01:17:15 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OQpIp-000Mxu-0y; Tue, 22 Jun 2010 01:17:15 +0300 Message-ID: <4C1FE4E9.8080400@freebsd.org> Date: Tue, 22 Jun 2010 01:17:13 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Navdeep Parhar , freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> <4C1FDAF9.3080808@freebsd.org> <20100621220035.GA8746@hub.freebsd.org> In-Reply-To: <20100621220035.GA8746@hub.freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:17:18 -0000 on 22/06/2010 01:00 Navdeep Parhar said the following: > > I'm not so sure about this. There is code inside the second switch that runs > whether sh_size is 0 or not. Either all of it is pointless code (when sh_size > is 0) or or you'll make sure that it still runs, right? It's definitely pointless. [IMHO :-)] -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 08:55:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6381065679 for ; Tue, 22 Jun 2010 08:55:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E96D8FC17 for ; Tue, 22 Jun 2010 08:55:54 +0000 (UTC) Received: by fxm7 with SMTP id 7so2724263fxm.13 for ; Tue, 22 Jun 2010 01:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hwgVGhnIxodXJxTQm20/6EJXGkk7AcWgkjsXCSpNDbU=; b=PaubhGDc3hDwy2daq0cHuKdWDY/KPPNB34gr2e+h4ukB8NCLhtRJdg29AdxyLX1dmB q6OCz2ibxucW0tYtg7v+B2NUSuPS0un/TUycayuy5iAuW9o+0mHXNyRg+umYGXIvQH3I 0OJ7mwYnLAMSZyeCb3a/xuUaoGOQs9kpYSjcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XYh9dHf6IJutfnzI/EA6q7zHG8JfuVbYQwU2UNaYCC0WCeE+3YueHVaHK3DDGjonL2 5NK/1nRZJ9WlPgS3ooJDHYp+nmBo8mo2G+bWvs6Oq52ug/pn5ah6S16u5X29xWQcHrBW OvC6EkBpsUDh8vor6Y4ucBpudaV199zyMqMTs= MIME-Version: 1.0 Received: by 10.239.181.73 with SMTP id l9mr441516hbg.139.1277196954005; Tue, 22 Jun 2010 01:55:54 -0700 (PDT) Received: by 10.239.185.1 with HTTP; Tue, 22 Jun 2010 01:55:53 -0700 (PDT) In-Reply-To: <50B3A5560BA4D74CADEC55A48B4641B23D5AD26EBF@EMBX01-HQ.jnpr.net> References: <50B3A5560BA4D74CADEC55A48B4641B23D5AD26EBF@EMBX01-HQ.jnpr.net> Date: Tue, 22 Jun 2010 09:55:53 +0100 Message-ID: From: Tom Evans To: Anjali Kulkarni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" Subject: Re: About Marvell Yukon drivers skgeinit and sky2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:55:56 -0000 On Mon, Jun 21, 2010 at 8:09 PM, Anjali Kulkarni wrote= : > Hi, > > As I understand, there are 2 flavors of the Marvel Yukon driver. One is f= or Yukon-I devices, and is called skgeinit, and other is for Yukon-II devic= es and called sky2 driver. > Looking at the release notes for 7.0, it looks like this driver which was= in sys/dev/yukon, is now present as the msk(4) driver in sys/dev/msk and s= ys/dev/sk?. I do not see a yukon under dev anymore. I see only 2 files in t= he msk directory, is it really moved here? > Is the Yukon-II sky2 driver support present in Freebsd 6.1? How easy woul= d it to backport this to 6.1? > If yes, then is there a way to disable the skgeinit(which seems to be the= default) and enable the sky2 driver? > > Anjali In linux, sure, there are two drivers for Marvel Yukon cards, called skgeinit and sky2. This is FreeBSD though, which has drivers called sk and msk. If you check the man pages for those drivers, it even tells you the history of when those drivers were added to FreeBSD. I think that the two drivers support different chipsets, so neither is 'default'. msk(4) was added in 6.3, so backport to 6.1 might be possible - have you tried taking the driver from 6.3 and compiling it on 6.1? 6.1 is no longer one of the 'supported' branches of FreeBSD, you may consider upgrading to a version that is. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 09:21:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE0E106566B; Tue, 22 Jun 2010 09:21:32 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C28E88FC16; Tue, 22 Jun 2010 09:21:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA17232; Tue, 22 Jun 2010 12:21:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OQzfc-000PcO-8F; Tue, 22 Jun 2010 12:21:28 +0300 Message-ID: <4C208096.3030602@freebsd.org> Date: Tue, 22 Jun 2010 12:21:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Navdeep Parhar , John Baldwin References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> <4C1FDAF9.3080808@freebsd.org> In-Reply-To: <4C1FDAF9.3080808@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:21:32 -0000 on 22/06/2010 00:34 Andriy Gapon said the following: > gdb change - I'd rather do it via kld_current_sos, > kld_relocate_section_addresses. I'd like to avoid changing common gdb code for > a variety of reasons. I came up with the following patch. EXEC_P and DYNAMIC flags are bfd library equivalents of ET_EXEC and ET_DYN elf flags. Absence of both of these flags means ET_REL, which is a type of our amd64 kernel modules. The code all resides in kld.c and acts only kernel modules that are either auto-loaded via kld_current_sos or explicitly added with add-kld. I used a static variable in kld_relocate_section_addresses because that function is called on each section sequentially, so current offset can not be stored on stack. The offset is reset to module's load address when see that we are called with first section. Alternative is to glimpse at previous section's end address as you did. So the code depends on sections being passed in forward sequential order. How does this look? Could you please test it? diff --git a/gnu/usr.bin/gdb/kgdb/kld.c b/gnu/usr.bin/gdb/kgdb/kld.c index 716a67c..d5ba20a 100644 --- a/gnu/usr.bin/gdb/kgdb/kld.c +++ b/gnu/usr.bin/gdb/kgdb/kld.c @@ -198,12 +198,32 @@ find_kld_address (char *arg, CORE_ADDR *address) } static void +adjust_section_address (struct section_table *sec, CORE_ADDR *curr_base) +{ + struct bfd_section *asect = sec->the_bfd_section; + bfd *abfd = sec->bfd; + + if ((abfd->flags & (EXEC_P | DYNAMIC)) != 0) { + sec->addr += *curr_base; + sec->endaddr += *curr_base; + return; + } + + *curr_base = align_power(*curr_base, + bfd_get_section_alignment(abfd, asect)); + sec->addr = *curr_base; + sec->endaddr = sec->addr + bfd_section_size(abfd, asect); + *curr_base = sec->endaddr; +} + +static void load_kld (char *path, CORE_ADDR base_addr, int from_tty) { struct section_addr_info *sap; struct section_table *sections = NULL, *sections_end = NULL, *s; struct cleanup *cleanup; bfd *bfd; + CORE_ADDR curr_addr; int i; /* Open the kld. */ @@ -224,10 +244,9 @@ load_kld (char *path, CORE_ADDR base_addr, int from_tty) if (build_section_table (bfd, §ions, §ions_end)) error("\"%s\": can't find file sections", path); cleanup = make_cleanup(xfree, sections); - for (s = sections; s < sections_end; s++) { - s->addr += base_addr; - s->endaddr += base_addr; - } + curr_addr = base_addr; + for (s = sections; s < sections_end; s++) + adjust_section_address(s, &curr_addr); /* Build a section addr info to pass to symbol_file_add(). */ sap = build_section_addr_info_from_section_table (sections, @@ -284,9 +303,12 @@ kgdb_add_kld_cmd (char *arg, int from_tty) static void kld_relocate_section_addresses (struct so_list *so, struct section_table *sec) { + static CORE_ADDR curr_addr; + + if (sec == so->sections) + curr_addr = so->lm_info->base_address; - sec->addr += so->lm_info->base_address; - sec->endaddr += so->lm_info->base_address; + adjust_section_address(sec, &curr_addr); } static void -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 19:20:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91158106564A for ; Tue, 22 Jun 2010 19:20:08 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 08B128FC16 for ; Tue, 22 Jun 2010 19:20:06 +0000 (UTC) Received: by vws14 with SMTP id 14so354527vws.13 for ; Tue, 22 Jun 2010 12:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/x/wYY3jyHlH44DtjHg3OOmW2qOFUIag/nxx2reSbvY=; b=v+DrVHhgcUlFfjRUNGDlTYTMcRvfI0fNQTRQFDjs6131/Dy9arrRwKARsQXMg6A/Ps 0P6IppLwxxsUcmqsz58VgQB0Rebaz8VVwiO/ecwVfdEoY1cAFYEKLCXwsjYAGQOqtoyp 3JN1ID+gZ8xsINRGR8ptXruguyB55iU7a1ukM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OwyPxyHayG+hKBv3PnQGSDP1pAPmplkd37j8r12fbFH6Q+lHGSwTujb0FBULduBna+ TowTCVnqnaLtU5I5fUaxSqLPIJJiwwJqFxfK1KaaosfQHZVyRrbIqWxo83WAEakrzHRP BZAGS5vaCUhI9yYNMRhad8HI8aJmf5mZS/fBM= MIME-Version: 1.0 Received: by 10.224.24.203 with SMTP id w11mr4277971qab.296.1277228752737; Tue, 22 Jun 2010 10:45:52 -0700 (PDT) Received: by 10.229.91.8 with HTTP; Tue, 22 Jun 2010 10:45:52 -0700 (PDT) Date: Tue, 22 Jun 2010 23:15:52 +0530 Message-ID: From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [DTrace][FreeBSD 6.1] Should a kernel global variable reference land up for validation in dtrace_canstore? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:20:08 -0000 I have the following simple DTrace script % cat fbt_test.d BEGIN { trace(kernel`my_kern_variable); } When I run the script I get the following error dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid kernel access in action #1 at DIF offset 4 This is a FreeBSD 6.1 base (I am attempting to get DTrace to work in a FreeBSD 6.1 cross compiler env) On limited debugging... I see this 'dtrace_dif_emulate' sets the CPU_DTRACE_KPRIV error... case DIF_OP_RLDX: if (!dtrace_canstore(regs[r1], 8, mstate, vstate)) { *flags |= CPU_DTRACE_KPRIV; *illval = regs[r1]; I tried figuring out the semantics of "dtrace_canstore", looks like it checks if the asked variable resides anywhere in the DTrace 'scratch base' or in the space of thread local variables. My query is since I marked the variable in the script with a back quote should it not consider it as a external reference? I have inlined the following lines from my debugging session (kgdb) info address my_kern_variable Symbol "my_kern_variable" is static storage at address 0xc0bd68ec. (kgdb) up #3 0xc5018967 in dtrace_dif_emulate (difo=0xc5bf38c0, mstate=0xee972b00, vstate=0xc4f59c1c, state=0xc4f59c00) (kgdb) p /x regs[1] $165 = 0xc0bd68ec <== Same as my_kern_variable, and this gets passed to dtrace_canstore as shown above (kgdb) p /x mstate->dtms_scratch_base <== Starting at 0xc6a52010 which is greater than the global my_kern_variable $166 = 0xc6a52010 (kgdb) p /x mstate->dtms_scratch_size $167 = 0xbffff0 (kgdb) p /x vstate->dtvs_dynvars.dtds_base <== Thread locals base, 0xc7652000 which is also greater than my_kern_variable $169 = 0xc7652000 (kgdb) p /x vstate->dtvs_dynvars.dtds_size $170 = 0x100000 If we look at the implementation of "dtrace_canstore" it looks very obvious to fail...with the above parameters. In a dumb way, what I am trying to figure out is whether to a reference to a kernel global which is external to the dtrace memory areas land up for validation in dtrace_canstore? Any pointers where to look, how to debug further? -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 20:11:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A88F1065678; Tue, 22 Jun 2010 20:11:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 707C38FC12; Tue, 22 Jun 2010 20:11:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=5L7go04Pwv0A:10 a=GQCbJdZ--msA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=cZiytllGAAAA:8 a=co-lk1d0aRPTRZKaQZsA:9 a=ctSAzfj0qWR95Mm0uo8A:7 a=aubw6X4oJen3x9cJAWhhvMwaHDEA:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1399275033; Tue, 22 Jun 2010 22:11:14 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, "Sergey V. Dyatko" , Ted Faber Date: Tue, 22 Jun 2010 22:08:23 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201003301510.58203.jhb@freebsd.org> <87bpe4ps9m.fsf@kobe.laptop> In-Reply-To: <87bpe4ps9m.fsf@kobe.laptop> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006222208.23271.hselasky@c2i.net> Cc: Giorgos Keramidas , Bruce Cran , freebsd-current@freebsd.org, Alexander Best Subject: Re: building world with debugging symbols [broken?] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:11:17 -0000 On Wednesday 31 March 2010 14:52:53 Giorgos Keramidas wrote: > On Tue, 30 Mar 2010 15:10:58 -0400, John Baldwin wrote: > > On Tuesday 30 March 2010 11:48:58 am Giorgos Keramidas wrote: > >> +.It Va DEBUG_FLAGS > >> +Defines a set of debugging flags that will be used to build all > >> userland +binaries under > >> +.Pa /usr/src . > >> +When > >> +.Va DEBUG_FLAGS > >> +is defined, the > >> +.Cm install > >> +and > >> +.Cm installworld > >> +targets install binaries from the current > >> +.Va MAKEOBJDIRPREFIX > >> +without stripping too, so that debugging information is retained in the > >> +installed binaries. > > > > I would drop the "too" and start 'so' on a new line (at least that is > > my interpretation of the line-break rules we use for mdoc). Other > > than that I think this looks fine. > > Fixed and committed in r205978. Thanks :) Hi, I've gotten several reports that cuse4bsd and other kernel modules built outside the kernel tree no longer load. Any clues about what is wrong? Is this a compiler issue, or has it got to do with missing/wrong symbols? For example one guy writes: On Tue, 22 Jun 2010 19:11:09 +0200 Hans Petter Selasky wrote: > On Tuesday 22 June 2010 18:06:58 Ted Faber wrote: > > FWIW, I'm seeing the same thing on 8.1-PRERELEASE csupped from > > yesterday. It's been going on foe a while, but I haven't been able > > to find the bug. > > > > (I was literally sitting down to type an e-mail about it when I saw > > this thread.) > > > > Same symptom: cuse4bsd loads but no device file appears in the /dev > > I also don't see the printfs from cuse_kern_init show up in the > > log. It seems like something's changed in the kernel module load > > path somehow. FWIW, the example in /usr/share/examples/kld/cdev/ > > doesn't work for me either. > > > > I've attached the verbose boot. Cuse4bsd is current from ports, > > recompiled after the new kernel install: > > > > $ pkg_info | grep cuse > > cuse4bsd-kmod-0.1.11 Cuse4BSD character device loopback driver for > > userspace > > > > Here's my loader.conf: > > > > $ cat /boot/loader.conf > > beastie_disable="YES" > > acpi_ibm_load="YES" > > snd_ich_load="YES" > > cuse4bsd_load="YES" > > > > The module is in the right place and seems to load: > > $ ls -l /boot/modules/ > > total 18 > > -r-xr-xr-x 1 root wheel 16505 Jun 21 19:02 cuse4bsd.ko > > $ kldstat > > Id Refs Address Size Name > > 1 36 0xc0400000 bb8ea8 kernel > > 2 1 0xc0fb9000 7224 snd_ich.ko > > 3 2 0xc0fc1000 577a4 sound.ko > > 4 1 0xc1019000 5244 acpi_ibm.ko > > 5 1 0xc101f000 4610 cuse4bsd.ko > > 6 1 0xc59c9000 8000 linprocfs.ko > > 7 1 0xc5a1d000 26000 linux.ko > > 8 1 0xc5b07000 11000 ipfw.ko > > 9 1 0xc5b18000 d000 libalias.ko > > 10 1 0xc5e2e000 2000 green_saver.ko > > 11 1 0xc5f0d000 68000 radeon.ko > > 12 1 0xc5f84000 14000 drm.ko > > > > $ uname -a > > FreeBSD praxis.lunabase.org 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE > > #38: Mon Jun 21 17:14:31 PDT 2010 > > root@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 > > > > I'm happy to try fixes or provide information. > > > > Are you sure the kernel sources are matched with your kernel. I find > this rather odd. > laptop# svn info Path: . URL: svn://svn.freebsd.by/base/head Repository Root: svn://svn.freebsd.by/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 209412 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 209408 Last Changed Date: 2010-06-22 03:26:07 +0300 (Tue, 22 Jun 2010) svn.freebsd.by - nearest svn mirror for me. [username@svn]~%crontab -l|grep svn 0 */2 * * * /usr/local/bin/svnsync sync file:///usr/local/repositories/freebsd/base/ %uname -a FreeBSD laptop.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #7 r209412M: Tue Jun 22 11:23:15 EEST 2010 root@laptop.domain:/usr/obj/usr/src/sys/b450 i386 laptop# pwd /usr/src laptop# svn st laptop# > The Cuse4BSD printout is called from a SYSINIT. If sysinits don't > work then something fundamental is wrong. Also check: > > find /boot -name "cuse4bsd*" > laptop# find /boot -name 'cuse*' /boot/modules/cuse4bsd.ko laptop# > printf("Cuse4BSD v%d.%d.%d @ /dev/cuse\n", > (CUSE_VERSION >> 16) & 0xFF, (CUSE_VERSION >> 8) & 0xFF, > (CUSE_VERSION >> 0) & 0xFF); > } > > SYSINIT(cuse_kern_init, SI_SUB_DEVFS, SI_ORDER_ANY, cuse_kern_init, > 0); > --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 20:39:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44E2F106566B; Tue, 22 Jun 2010 20:39:19 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFCF8FC12; Tue, 22 Jun 2010 20:39:18 +0000 (UTC) Received: by ewy22 with SMTP id 22so294225ewy.13 for ; Tue, 22 Jun 2010 13:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PZuo2Balgps3qu0i+qebpWyf34VcoRd1aleAb++jQ7g=; b=leGdtdkraWW3RdVcm/rfi07RZzUyYpWCUITkC+9NNwhJp2HyHYHg1lIC0Yuo3hhkFc bp2C23ZPeF9eTu4TY3SgiOU0w8lTIJBJ13CBfa0UCA7cI2o4F7ShO+cNl8xVTkteJkoh ALgi8CIaaVZ1Z4rQEfKFV5NsZoLF9lHLerkgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CUICRvGxcMXsD5Cr7lAu0oChdogOx3AouWjeTIslJA3Vr8n0l7C9E51k6zMNLe5ftR oqXWKohYbYHeqd8pdDjEITIapLIo5eStLXsGaRK3rISqb9+w4Rerk82g7Sieahs+l4de WCoYORHdVY7txrcUMkotJob8OrXA00pZ2b8dA= MIME-Version: 1.0 Received: by 10.213.31.132 with SMTP id y4mr1891437ebc.51.1277239157248; Tue, 22 Jun 2010 13:39:17 -0700 (PDT) Received: by 10.213.10.131 with HTTP; Tue, 22 Jun 2010 13:39:17 -0700 (PDT) In-Reply-To: <201006222208.23271.hselasky@c2i.net> References: <201003301510.58203.jhb@freebsd.org> <87bpe4ps9m.fsf@kobe.laptop> <201006222208.23271.hselasky@c2i.net> Date: Tue, 22 Jun 2010 16:39:17 -0400 Message-ID: From: Ryan Stone To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , "Sergey V. Dyatko" , freebsd-hackers@freebsd.org, Alexander Best , freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: building world with debugging symbols [broken?] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:39:19 -0000 I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 21:32:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DD5A106564A for ; Tue, 22 Jun 2010 21:32:17 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 002478FC21 for ; Tue, 22 Jun 2010 21:32:16 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5ML7N8r021850; Tue, 22 Jun 2010 14:07:23 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5ML7LGU021849; Tue, 22 Jun 2010 14:07:21 -0700 (PDT) (envelope-from faber) Date: Tue, 22 Jun 2010 14:07:21 -0700 From: Ted Faber To: Ryan Stone Message-ID: <20100622210721.GC18012@zod.isi.edu> References: <201003301510.58203.jhb@freebsd.org> <87bpe4ps9m.fsf@kobe.laptop> <201006222208.23271.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c3bfwLpm8qysLVxt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: Bruce Cran , "Sergey V. Dyatko" , freebsd-hackers@freebsd.org, Hans Petter Selasky , Alexander Best , freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: building world with debugging symbols [broken?] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:32:17 -0000 --c3bfwLpm8qysLVxt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: > I saw similar behaviour a couple of years ago when I switched from > using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. > The problem ended up being a change in the linker script used by GNU > ld for linking kernel modules. It used to always put some magic > symbols used by the linker to implement things like sysinits into the > module. It was changed to only provide those symbols, which > apparently means that the linker would discard those symbols if > nothing referenced them(and nothing did reference them). I had to > work around it by adding the following to my link line: >=20 > -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > -u __stop_set_sysctl_set -u __stop_set_modmetadata_set HPS: I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.000000000 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.000000000 -0700 @@ -30,4 +30,10 @@ KMOD=3D cuse4bsd SRCS=3D cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h =20 +LDFLAGS +=3D -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:0000275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:00002758 r __set_sysuninit_set_sym_cuse_kern_unin= it_sys_uninit /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys =2E/cuse4bsd.ko:000028cc r __set_sysinit_set_sym_cuse_kern_init_sys_init =2E/cuse4bsd.ko:000028c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uni= nit =2E/cuse4bsd.ko: U __start_set_sysctl_set =2E/cuse4bsd.ko:000028cc A __start_set_sysinit_set =2E/cuse4bsd.ko:000028c8 A __start_set_sysuninit_set =2E/cuse4bsd.ko: U __stop_set_sysctl_set =2E/cuse4bsd.ko:000028d0 A __stop_set_sysinit_set =2E/cuse4bsd.ko:000028cc A __stop_set_sysuninit_set =2E/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init =2E/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --c3bfwLpm8qysLVxt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwhJgkACgkQaUz3f+Zf+XsIHQCg01pjgmyQMtRhCxX5Vcecfmh6 oAEAoMjEQJnq4qzA5nrwpptyHFNnnJ+T =tM4z -----END PGP SIGNATURE----- --c3bfwLpm8qysLVxt-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 21:41:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2935106564A for ; Tue, 22 Jun 2010 21:41:38 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 369CE8FC17 for ; Tue, 22 Jun 2010 21:41:36 +0000 (UTC) Received: by vws14 with SMTP id 14so514831vws.13 for ; Tue, 22 Jun 2010 14:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qjlEa0mRrpa1GJi2yL+bp0Ohn43S9mf4J03cpwOjy6U=; b=uA6y+qsle2GAyOX04tRV8pkobojG+30hlwJGUykWsyNUuWNVH124YuBLu2BbIYkawz XNrMa8KUMlKAQbYdglcrT9QN8pqwPXPDr8KlpK2Eb2MO1ocBQxjdKKLdjEurRnOqt95T arMa8RX0M2gwkQxRhMXn97IPQt+tapHp7giYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CqhO9wgS6aQQqJcA/MVG9IxcrJBn62dCFkBXPSr2aQ8lQxNZ4bFzjXnIUKgilTft+C f+UjN1zM9v7sxhOyPUlByjqOKrCUh37yGvwPbdrHzhFRKiEofuNqMTTsqTWGH1et8Db9 Y+LBLw1Q53k61Nt0icSJlTl3YNh8OHB0Hx7Ds= MIME-Version: 1.0 Received: by 10.220.124.66 with SMTP id t2mr3423202vcr.186.1277237596981; Tue, 22 Jun 2010 13:13:16 -0700 (PDT) Received: by 10.220.188.76 with HTTP; Tue, 22 Jun 2010 13:13:16 -0700 (PDT) Date: Tue, 22 Jun 2010 16:13:16 -0400 Message-ID: From: grarpamp To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 22 Jun 2010 21:45:58 +0000 Subject: msdosfs exit status, failures: chmod, touch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:41:39 -0000 This exit should not be 0, regardless of msdosfs or not. Same for if the '.' dir entries do in fact have B/M/A/C times, operations on those entries should update those times accordingly, as subdirs do. RELENG_8. Thanks. # newfs_msdos /dev/fd0 /dev/fd0: 2829 sectors in 2829 FAT12 clusters (512 bytes/cluster) BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=2880 Media=0xf0 FATsecs=9 SecPerTrack=18 Heads=2 HiddenSecs=0 # mount_msdosfs /dev/fd0 /mnt # ls -alt /mnt total 18 drwxr-xr-x 22 root wheel 512 Jun 8 17:00 .. drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . # chmod 1777 /mnt ; echo $? 0 # touch /mnt ; echo $? 0 # ls -alt /mnt total 18 drwxr-xr-x 22 root wheel 512 Jun 8 17:00 .. drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 00:41:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD67E1065670; Wed, 23 Jun 2010 00:41:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id DDE838FC13; Wed, 23 Jun 2010 00:40:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zy2FLL-uPcA:10 a=yQWWgrYGNuUA:10 a=kj9zAlcOel0A:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=IGmblQ1dLY3wUGMpuGUA:9 a=EPc1bLlpiiolXB59LsWQj2YinIsA:4 a=CjuIK1q_8ugA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1368958191; Wed, 23 Jun 2010 02:40:58 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 23 Jun 2010 02:38:06 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?utf-8?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?utf-8?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7CoTlKM?= =?utf-8?q?usi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201006230238.06831.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 00:41:00 -0000 Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: > I saw similar behaviour a couple of years ago when I switched from > using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. > The problem ended up being a change in the linker script used by GNU > ld for linking kernel modules. It used to always put some magic > symbols used by the linker to implement things like sysinits into the > module. It was changed to only provide those symbols, which > apparently means that the linker would discard those symbols if > nothing referenced them(and nothing did reference them). I had to > work around it by adding the following to my link line: > > -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.000000000 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.000000000 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:0000275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:00002758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:000028cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:000028c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:000028cc A __start_set_sysinit_set ./cuse4bsd.ko:000028c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:000028d0 A __stop_set_sysinit_set ./cuse4bsd.ko:000028cc A __stop_set_sysuninit_set ./cuse4bsd.ko:00003194 d cuse_kern_init_sys_init ./cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 04:07:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619731065670; Wed, 23 Jun 2010 04:07:01 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 4518E8FC0A; Wed, 23 Jun 2010 04:07:00 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5N46v9T025900; Tue, 22 Jun 2010 21:06:57 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5N46uIs025899; Tue, 22 Jun 2010 21:06:56 -0700 (PDT) (envelope-from faber) Date: Tue, 22 Jun 2010 21:06:56 -0700 From: Ted Faber To: Hans Petter Selasky Message-ID: <20100623040656.GC23023@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: <201006230238.06831.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 04:07:01 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2010 at 02:38:06AM +0200, Hans Petter Selasky wrote: > It appears many kmods are broken because the linker is stripping away sta= tic=20 > data declared with the section attribute in FreeBSD 8.1-RC1. >=20 > >=20 > I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port > made the module and the result loads and creates the /dev/cuse file. Hi. I'm the fellow in Hans's .... If someone's looking into this, it's worth mentioning that the sample cdev kmodule in /usr/share/examples/kld/cdev/ also exhibits the behavior. On my 8.1-PRERELEASE system that module does not create the /dev/cedv device, but if you add the line=20 LDFLAGS +=3D -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set right before the=20 =2Einclude in /usr/share/examples/kld/cdev/module/Makefile and remake everything, the module creates the /dev/cdev file when it's loaded. That magical line was suggested by Ryan Stone in another thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D120718+0+current/freebsd-hac= kers Happy hunting, and I'm happy to test patches or provide more information. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwhiGAACgkQaUz3f+Zf+XvhngCgm+78NGZnUFXI4z9hJu8fe+H3 CzEAn31VtQ6ByJMglAxKmRIDk/7SUqpF =LPYM -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 06:18:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2AA51065670 for ; Wed, 23 Jun 2010 06:18:44 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC1F8FC0A for ; Wed, 23 Jun 2010 06:18:44 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5N6JRV7046281 for ; Tue, 22 Jun 2010 23:19:27 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C21A743.6040306@mahan.org> Date: Tue, 22 Jun 2010 23:18:43 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:18:44 -0000 I have the following senerio - We need to build the kernel and world for multiple platforms architectures (amd64, mips, ppc, etc). Initially we had a set of shell scripts for the following: -kernel-toolchain.sh -kernel64.sh -world64.sh -bldpkg.sh Which set the correct environment variables before invoking the FreeBSD makefile under src/. As part of an effort to setup nightly builds and to make it easier for people to build the kernels they needed, I created a top-level makefile that goes something like - all: src-kern-tools src-kernel src-world src-package src-kern-tools: cd src; ./-kernel-toolchain.sh 2>&1 | tee src-kernel: src-kern-tools cd src; ./-kernel64.sh 2>&1 | tee .... and so on. My issue is that if there is a build failure at any point, the status does not seem to be propagated upward. For example, if the kernel fails to build due to incorrect code, the script -kernel64.sh stops (verifable by examining the logfile), however, the make will continue to the next target, src-world, and continue building. How do I propagate the status up to the top-level make? I've read through the PMake document but nothing jumped out at me... Any pointers would be appreciated. The build miser wants me to create status dot files that he then verifies before moving on (yuck!). Thanks for listening, Patrick From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 06:47:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA9FE1065670; Wed, 23 Jun 2010 06:47:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE808FC0C; Wed, 23 Jun 2010 06:47:58 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA14089; Wed, 23 Jun 2010 09:47:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ORJkX-0003DI-WF; Wed, 23 Jun 2010 09:47:54 +0300 Message-ID: <4C21AE18.4050400@icyb.net.ua> Date: Wed, 23 Jun 2010 09:47:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Hans Petter Selasky References: <201006230238.06831.hselasky@c2i.net> In-Reply-To: <201006230238.06831.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:47:59 -0000 on 23/06/2010 03:38 Hans Petter Selasky said the following: > Hi, > > I'm creating a new thread on this issue. > > On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: >> I saw similar behaviour a couple of years ago when I switched from >> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. >> The problem ended up being a change in the linker script used by GNU >> ld for linking kernel modules. It used to always put some magic >> symbols used by the linker to implement things like sysinits into the >> module. It was changed to only provide those symbols, which >> apparently means that the linker would discard those symbols if >> nothing referenced them(and nothing did reference them). I had to >> work around it by adding the following to my link line: >> >> -u __start_set_sysinit_set -u __start_set_sysuninit_set \ >> -u __start_set_sysctl_set -u __start_set_modmetadata_set \ >> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ >> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set > > It appears many kmods are broken because the linker is stripping away static > data declared with the section attribute in FreeBSD 8.1-RC1. > > > > I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port > made the module and the result loads and creates the /dev/cuse file. > > Here's a diff relative to > /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so > it's clear what I did. > > > --- Makefile.kmod.orig 2010-02-11 03:28:02.000000000 -0800 > +++ Makefile.kmod 2010-06-22 14:02:52.000000000 -0700 > @@ -30,4 +30,10 @@ > KMOD= cuse4bsd > SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h > > +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set > + > + > .include > > Running nm -o on the two modules, the difference seems to be that the -u > results in some additional absolute symbols being defined: > > Bad module: > $ nm -o /boot/modules/cuse4bsd.ko| grep sys > /boot/modules/cuse4bsd.ko:0000275c r > __set_sysinit_set_sym_cuse_kern_init_sys_init > /boot/modules/cuse4bsd.ko:00002758 r > __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit > /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init > /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit I am not sure if this analysis is correct. I tested on head and stable/8 and my nm output is exactly like above ("bad module"), still the module loads fine and creates /dev/cuse. I don't think there were any recent changes related to build infrastructure or linker in 8.1. Please consider other possibilities. > Good module: > > $ nm -o ./cuse4bsd.ko | grep sys > ./cuse4bsd.ko:000028cc r __set_sysinit_set_sym_cuse_kern_init_sys_init > ./cuse4bsd.ko:000028c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit > ./cuse4bsd.ko: U __start_set_sysctl_set > ./cuse4bsd.ko:000028cc A __start_set_sysinit_set > ./cuse4bsd.ko:000028c8 A __start_set_sysuninit_set > ./cuse4bsd.ko: U __stop_set_sysctl_set > ./cuse4bsd.ko:000028d0 A __stop_set_sysinit_set > ./cuse4bsd.ko:000028cc A __stop_set_sysuninit_set > ./cuse4bsd.ko:00003194 d cuse_kern_init_sys_init > ./cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit > > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 06:55:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4961E106566C; Wed, 23 Jun 2010 06:55:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 710DA8FC1A; Wed, 23 Jun 2010 06:55:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nXlDabneoW0A:10 a=uEzv4HemXiYA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Czt-lxB3K3gCxCdIjiAA:9 a=doJ4I_PN3phXl2CbSDgA:7 a=cNb5hjClQZjlamADw7sB3-yCQ_MA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1369002294; Wed, 23 Jun 2010 08:55:18 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 23 Jun 2010 08:52:26 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> In-Reply-To: <4C21AE18.4050400@icyb.net.ua> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006230852.26536.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:55:21 -0000 On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote: > on 23/06/2010 03:38 Hans Petter Selasky said the following: > > Hi, > > > > I'm creating a new thread on this issue. > > > > On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: > >> I saw similar behaviour a couple of years ago when I switched from > >> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. > >> The problem ended up being a change in the linker script used by GNU > >> ld for linking kernel modules. It used to always put some magic > >> symbols used by the linker to implement things like sysinits into the > >> module. It was changed to only provide those symbols, which > >> apparently means that the linker would discard those symbols if > >> nothing referenced them(and nothing did reference them). I had to > >> work around it by adding the following to my link line: > >> > >> -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > >> -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > >> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > >> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set > > > > It appears many kmods are broken because the linker is stripping away > > static data declared with the section attribute in FreeBSD 8.1-RC1. > > > > > > > > I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port > > made the module and the result loads and creates the /dev/cuse file. > > > > Here's a diff relative to > > /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so > > it's clear what I did. > > > > > > --- Makefile.kmod.orig 2010-02-11 03:28:02.000000000 -0800 > > +++ Makefile.kmod 2010-06-22 14:02:52.000000000 -0700 > > @@ -30,4 +30,10 @@ > > KMOD= cuse4bsd > > SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h > > > > +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > > + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > > + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > > + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set > > + > > + > > .include > > > > Running nm -o on the two modules, the difference seems to be that the -u > > results in some additional absolute symbols being defined: > > > > Bad module: > > $ nm -o /boot/modules/cuse4bsd.ko| grep sys > > /boot/modules/cuse4bsd.ko:0000275c r > > __set_sysinit_set_sym_cuse_kern_init_sys_init > > /boot/modules/cuse4bsd.ko:00002758 r > > __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit > > /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init > > /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit > > I am not sure if this analysis is correct. > I tested on head and stable/8 and my nm output is exactly like above ("bad > module"), still the module loads fine and creates /dev/cuse. > > I don't think there were any recent changes related to build infrastructure > or linker in 8.1. > > Please consider other possibilities. I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken. Andriy, make sure that you re-make the toolchain before building the module in question. Also I think you have to: cd /usr/src ; make buildenv TARGET_ARCH=xxx_target Then you cd to the module directory and type make. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 07:02:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B66106564A; Wed, 23 Jun 2010 07:02:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B30078FC15; Wed, 23 Jun 2010 07:02:12 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA14342; Wed, 23 Jun 2010 10:02:09 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ORJyK-0003EY-KN; Wed, 23 Jun 2010 10:02:08 +0300 Message-ID: <4C21B170.2030903@icyb.net.ua> Date: Wed, 23 Jun 2010 10:02:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Hans Petter Selasky References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> In-Reply-To: <201006230852.26536.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 07:02:13 -0000 on 23/06/2010 09:52 Hans Petter Selasky said the following: > On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote: >> on 23/06/2010 03:38 Hans Petter Selasky said the following: >>> Hi, >>> >>> I'm creating a new thread on this issue. >>> >>> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: >>>> I saw similar behaviour a couple of years ago when I switched from >>>> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. >>>> The problem ended up being a change in the linker script used by GNU >>>> ld for linking kernel modules. It used to always put some magic >>>> symbols used by the linker to implement things like sysinits into the >>>> module. It was changed to only provide those symbols, which >>>> apparently means that the linker would discard those symbols if >>>> nothing referenced them(and nothing did reference them). I had to >>>> work around it by adding the following to my link line: >>>> >>>> -u __start_set_sysinit_set -u __start_set_sysuninit_set \ >>>> -u __start_set_sysctl_set -u __start_set_modmetadata_set \ >>>> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ >>>> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set >>> It appears many kmods are broken because the linker is stripping away >>> static data declared with the section attribute in FreeBSD 8.1-RC1. >>> >>> >>> >>> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port >>> made the module and the result loads and creates the /dev/cuse file. >>> >>> Here's a diff relative to >>> /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so >>> it's clear what I did. >>> >>> >>> --- Makefile.kmod.orig 2010-02-11 03:28:02.000000000 -0800 >>> +++ Makefile.kmod 2010-06-22 14:02:52.000000000 -0700 >>> @@ -30,4 +30,10 @@ >>> KMOD= cuse4bsd >>> SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h >>> >>> +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ >>> + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ >>> + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ >>> + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set >>> + >>> + >>> .include >>> >>> Running nm -o on the two modules, the difference seems to be that the -u >>> results in some additional absolute symbols being defined: >>> >>> Bad module: >>> $ nm -o /boot/modules/cuse4bsd.ko| grep sys >>> /boot/modules/cuse4bsd.ko:0000275c r >>> __set_sysinit_set_sym_cuse_kern_init_sys_init >>> /boot/modules/cuse4bsd.ko:00002758 r >>> __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit >>> /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init >>> /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit >> I am not sure if this analysis is correct. >> I tested on head and stable/8 and my nm output is exactly like above ("bad >> module"), still the module loads fine and creates /dev/cuse. >> >> I don't think there were any recent changes related to build infrastructure >> or linker in 8.1. >> >> Please consider other possibilities. > > I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken. I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. > Andriy, > make sure that you re-make the toolchain before building the module in > question. Also I think you have to: > > cd /usr/src ; make buildenv TARGET_ARCH=xxx_target > > Then you cd to the module directory and type make. I don't think that this is needed when _not_ cross-building for a different architecture. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 07:11:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B17691065676; Wed, 23 Jun 2010 07:11:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A51C48FC08; Wed, 23 Jun 2010 07:11:04 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA14541; Wed, 23 Jun 2010 10:11:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ORK6u-0003FL-If; Wed, 23 Jun 2010 10:11:00 +0300 Message-ID: <4C21B383.2000602@icyb.net.ua> Date: Wed, 23 Jun 2010 10:10:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Hans Petter Selasky References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> In-Reply-To: <4C21B170.2030903@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 07:11:05 -0000 on 23/06/2010 10:02 Andriy Gapon said the following: > I don't dispute that it is found broken in particular environments, I just think > that the analysis could be incorrect. Which also brings the question - what arch(s) is affected? I tested on amd64. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 07:32:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17DFA106567D; Wed, 23 Jun 2010 07:32:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 70F028FC28; Wed, 23 Jun 2010 07:32:22 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nXlDabneoW0A:10 a=uEzv4HemXiYA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=mSBxGRa38I5jodgpOH8A:9 a=I6Cbr6VEyAYYEzE6qtglDhQepVEA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1418686487; Wed, 23 Jun 2010 09:32:21 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 23 Jun 2010 09:29:30 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201006230238.06831.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> In-Reply-To: <4C21B383.2000602@icyb.net.ua> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006230929.30410.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 07:32:24 -0000 On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote: > on 23/06/2010 10:02 Andriy Gapon said the following: > > I don't dispute that it is found broken in particular environments, I > > just think that the analysis could be incorrect. Ok. > > Which also brings the question - what arch(s) is affected? > I tested on amd64. > I tested on i386. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 09:32:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852A8106566B for ; Wed, 23 Jun 2010 09:32:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 473898FC2F for ; Wed, 23 Jun 2010 09:32:56 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7B07B1FFC34; Wed, 23 Jun 2010 09:32:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C19158454A; Wed, 23 Jun 2010 11:30:43 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Patrick Mahan References: <4C21A743.6040306@mahan.org> Date: Wed, 23 Jun 2010 11:30:43 +0200 In-Reply-To: <4C21A743.6040306@mahan.org> (Patrick Mahan's message of "Tue, 22 Jun 2010 23:18:43 -0700") Message-ID: <86hbkujdto.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 09:32:56 -0000 Patrick Mahan writes: > My issue is that if there is a build failure at any point, the > status does not seem to be propagated upward. For example, if > the kernel fails to build due to incorrect code, the script > -kernel64.sh stops (verifable by examining the logfile), > however, the make will continue to the next target, src-world, > and continue building. How do I propagate the status up to the > top-level make? Your shell script needs to exit with a non-zero status if it fails. There are several ways to do this. For instance, if your shell script looks like this: #!/bin/sh make TARGET=3Damd64 kernel-toolchain you can: - prefix "make" with "exec": sh will exec make instead of running it in a subshell, and the exit status will be whatever make returns. - add the following line at the bottom: exit $? which causes the shell script to exit with the same exit status as the last command it ran, in this case make. - append "|| exit 1" to the the "make" command line; this will cause the script to exit immediately with status 1 if make fails, otherwise it will continue (in case you want to do something else if make succeeds) - wrap the make command line in an if statement, which allows you do additional work depending on the outcome, and end the failure case with "exit 1" or similar - insert the following line at any point between the shebang and the make command line: set -e this will cause sh to terminate the script immediately with a non-zero exit status if any command after the "set" line fails. However, I don't see the point of using shell scripts in the first place... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 09:56:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86811065673 for ; Wed, 23 Jun 2010 09:56:18 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5758FC13 for ; Wed, 23 Jun 2010 09:56:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ORMgn-0001NG-FQ for freebsd-hackers@freebsd.org; Wed, 23 Jun 2010 11:56:13 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jun 2010 11:56:13 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jun 2010 11:56:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 23 Jun 2010 11:56:10 +0200 Lines: 6 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 09:56:18 -0000 On 06/21/10 02:25, Garrett Cooper wrote: > For whatever reason my source tree wasn't prebuilt, so I reran > buildkernel and everything was fine once again. So, do the tests pass now? :) From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 15:01:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA261065674; Wed, 23 Jun 2010 15:01:10 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id B02A28FC1A; Wed, 23 Jun 2010 15:01:10 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5NF16oL031766; Wed, 23 Jun 2010 08:01:06 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5NF15M2031765; Wed, 23 Jun 2010 08:01:05 -0700 (PDT) (envelope-from faber) Date: Wed, 23 Jun 2010 08:01:05 -0700 From: Ted Faber To: Andriy Gapon Message-ID: <20100623150105.GA31578@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <4C21B383.2000602@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:01:10 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote: > on 23/06/2010 10:02 Andriy Gapon said the following: > > I don't dispute that it is found broken in particular environments, I j= ust think > > that the analysis could be incorrect. >=20 > Which also brings the question - what arch(s) is affected? > I tested on amd64. Right. I'm i386 and I have the problem. Good point! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwiIbEACgkQaUz3f+Zf+Xvi7ACfc2Zo1cR7TxJ+GcNW+sE0zcG0 sWcAoJ2pKpJ5jd1vBqSErY/oSRDOLUCj =9Swq -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 15:03:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0EB1065675; Wed, 23 Jun 2010 15:03:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id A67A08FC14; Wed, 23 Jun 2010 15:03:46 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so426869eya.9 for ; Wed, 23 Jun 2010 08:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kS5qWBKNlUi/Cq6inyK4bZ3ozNVp33lDveAPWAJGns8=; b=P+DmexcM8JQXoXwYzsVfDXycOg/k8JizvVc74eIB8OsDyd/RVfjyhhJVv0mIzthx8V tldLp9Tac5K8Z/s1TU+JeykDb5VFG4rS6EMKGH+cUtGjlCjrD1nIejuwc0Rh6TqumoUj 6SkkFTq8lw1UTZ0riPzTJU/VuBOE/uO0cwkho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n5exZO6RkY9njU/QOhyWckZDrRhQAKvWi5laXU/Q16HeQakvluTvW1ptTcK/KqwU1M peSOMlZltdfIbcKi9D6u3PLC97BjdK6BFUh5PcmA+HDxTGzw4mytpzj44pKwMk63uCIw +x8NCZuNgqcaECApNQDsIBS/h7qOhW2gRCG/g= MIME-Version: 1.0 Received: by 10.213.32.136 with SMTP id c8mr1796601ebd.38.1277305425285; Wed, 23 Jun 2010 08:03:45 -0700 (PDT) Received: by 10.213.10.131 with HTTP; Wed, 23 Jun 2010 08:03:45 -0700 (PDT) In-Reply-To: <4C21B383.2000602@icyb.net.ua> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> Date: Wed, 23 Jun 2010 11:03:45 -0400 Message-ID: From: Ryan Stone To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:03:47 -0000 On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote: > > Which also brings the question - what arch(s) is affected? > I tested on amd64. This should explain it. It looks to me like i386 uses kern/link_elf.c as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can only find the sections containing the sysinits(and some related things) via the magic symbols. link_elf_obj.c seems to understand ELF objects much better and doesn't need those symbols to be present. It just looks up the section that contains the sysinits directly via the ELF metadata that is already present. As far as I can tell, amd64 is the only arch in the tree that uses link_elf_obj.c, so all other arches may be affected. I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). The link line that I gave was a hack. The proper solution is to use a linker script that unconditionally puts the magic symbols in. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 15:32:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92F11065672; Wed, 23 Jun 2010 15:32:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4838FC12; Wed, 23 Jun 2010 15:32:14 +0000 (UTC) Received: by qwg8 with SMTP id 8so355588qwg.13 for ; Wed, 23 Jun 2010 08:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Lg6mJSjlWu5SF/pKT6qu/5W6dXjnS35GtJvuwYwJ9gk=; b=gFSZvdni/qDgWRlVRLahEi/kdAWYlkpoCkTOGzz3QUHPItdh6QLIhdazniXgUH5RgD q4YKAzZy8HYBOcZSeNDetJHNpu+O3+yi9CfxQiyHwC4GLTiTxcT5Mbe8/2w/Ll4FaQrx nIz07n+2Ple9g8USrf5DfqX32amO73Cq6QRxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k3E8pptA6gMkMFO1ft1KrPGzhfF/X/L5KZEDgh0o3S7wX5YfgZ9rmBVXWRn9sHEfsx mNd8/vxlos6eCTQcplyeglAq8zQm4Ku4JRSGI+S5yWhs+AZag0EvaDRXfq7GfHUEvsw5 uKPOB+Dv/HEUxY/V9dMBAww3JmIJzSqe/JNDg= MIME-Version: 1.0 Received: by 10.224.26.156 with SMTP id e28mr5068018qac.134.1277307133493; Wed, 23 Jun 2010 08:32:13 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Wed, 23 Jun 2010 08:32:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jun 2010 08:32:13 -0700 Message-ID: From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Are POSIX mqueues supposed to be functional on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:32:14 -0000 On Wed, Jun 23, 2010 at 2:56 AM, Ivan Voras wrote: > On 06/21/10 02:25, Garrett Cooper wrote: > >> For whatever reason my source tree wasn't prebuilt, so I reran >> buildkernel and everything was fine once again. > > So, do the tests pass now? :) Not 100%, but that might be a problem with the tests :(... Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 15:40:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC72106566C; Wed, 23 Jun 2010 15:40:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 485D68FC14; Wed, 23 Jun 2010 15:40:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28330; Wed, 23 Jun 2010 18:40:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C222AED.2070802@icyb.net.ua> Date: Wed, 23 Jun 2010 18:40:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Ryan Stone References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:40:46 -0000 on 23/06/2010 18:03 Ryan Stone said the following: > On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote: >> Which also brings the question - what arch(s) is affected? >> I tested on amd64. > > This should explain it. It looks to me like i386 uses kern/link_elf.c > as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can > only find the sections containing the sysinits(and some related > things) via the magic symbols. link_elf_obj.c seems to understand ELF > objects much better and doesn't need those symbols to be present. It > just looks up the section that contains the sysinits directly via the > ELF metadata that is already present. Yes, you are absolutely correct. This comes from the fact that amd64 uses simple objects files (aka .o) as kernel modules and i386 uses full-blow dso. > As far as I can tell, amd64 is the only arch in the tree that uses > link_elf_obj.c, so all other arches may be affected. > > I have to admit that I'm more than a little surprised that this > problem does not affect modules that in src, but maybe that's because > I don't know all that much about FreeBSD's build infrastructure. Are > the src modules being linked with a linker script that is not being > used for out-of-src modules? No, we don't have any special linker script for modules. > Are the people affected by this not > using the base compiler to build ports?(I see that this affects PC-BSD > as well, and I'd be a little surprised to learn that it wasn't using > the base compiler). I think that even out-of-base modules still use the same module build infrastructure (bsd.kmod.mk). At least this is the case for cuse4bsd. > The link line that I gave was a hack. The proper solution is to use a > linker script that unconditionally puts the magic symbols in. Module link process on i386 is like this (simplified): 1) combine object files into a single object file mod.kld ld -r -o mod.kld 1.o 2.o 2) convert it to dso ld -Bshareable -d -warn-common -o mod.ko mod.kld I believe that __start/__stop symbols for sections should be automatically added at step 2 by linker. Reference: http://sourceware.org/binutils/docs/ld/Orphan-Sections.html#Orphan-Sections -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 15:45:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2521065679; Wed, 23 Jun 2010 15:45:35 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 29A088FC0A; Wed, 23 Jun 2010 15:45:34 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5NFjVAW032385; Wed, 23 Jun 2010 08:45:31 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5NFjVq2032384; Wed, 23 Jun 2010 08:45:31 -0700 (PDT) (envelope-from faber) Date: Wed, 23 Jun 2010 08:45:31 -0700 From: Ted Faber To: Ryan Stone Message-ID: <20100623154531.GB31578@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon , Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:45:35 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: > I have to admit that I'm more than a little surprised that this > problem does not affect modules that in src, but maybe that's because > I don't know all that much about FreeBSD's build infrastructure. Are > the src modules being linked with a linker script that is not being > used for out-of-src modules? Are the people affected by this not > using the base compiler to build ports?(I see that this affects PC-BSD > as well, and I'd be a little surprised to learn that it wasn't using > the base compiler). I had the problem on i386, base compiler. It also affects the sample module in /usr/share/examples/kld/cdev/ which also uses the base compiler, if you want a case w/o th eports infrastructure. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwiLBsACgkQaUz3f+Zf+XuPygCg40gyhhu/+2i+s0SYz/0aKmJ5 hCwAoMRjg6s0ViTgHUa2lDLIzYXhYKgl =bMIb -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 16:03:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7820B106564A for ; Wed, 23 Jun 2010 16:03:35 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 090298FC14 for ; Wed, 23 Jun 2010 16:03:34 +0000 (UTC) Received: by bwz17 with SMTP id 17so403122bwz.13 for ; Wed, 23 Jun 2010 09:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:x-mailer; bh=68LlfBo7suv22kiBLZYb+uolCcWMpOSgC7njcU1jbXE=; b=YdY2XPsZcJD7ZbKpsU4I66jQZuvLwXI/yOKKQP/Tamc7n4eBbYzz3G8C8ja2kRfyPK gtBZDha4M6F3C/ZvAJ36lOs2vGcXWC9CkznHO3I3XuiOuzSDqLWByXXnwqn/4+O+TQmX K4fXlqgkSPd/aAs117Hidh4BufAmzERZNesEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:x-mailer; b=wJo05xqlBxVAIPOxhmTR3lMVzKh0pibg9/ifvKm+6k5g2hGz6x2flbXAY1VRuO/Xln o2Yob7uydN0JerZ//6szrPRGFe5HliHhXynkFYXySp03gNL9PVDBTgtr46//Qj7hPR0D Mnswt8vmgIxFS6/XGBmhu4sTG/+7KXsdxA++I= Received: by 10.204.47.11 with SMTP id l11mr5822942bkf.96.1277309012195; Wed, 23 Jun 2010 09:03:32 -0700 (PDT) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id jq1sm12935102bkb.35.2010.06.23.09.03.29 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 09:03:31 -0700 (PDT) Message-ID: <20100623.160330.281.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Wed, 23 Jun 2010 18:03:30 +0200 X-Mailer: POP Peeper (3.6.0.0) Subject: loader prompt: list / on other device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:03:35 -0000 I've escaped to loader prompt: Current device is disk0s3a, from which this loader is running. My USB stick is device1 and device1s2a is UFS /, on which I would like to reach some file or simply list directory. Syntax? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 16:52:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FA21065673 for ; Wed, 23 Jun 2010 16:52:11 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id D86B28FC0A for ; Wed, 23 Jun 2010 16:52:10 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id o5NGGgfK002371; Wed, 23 Jun 2010 23:16:43 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4C22336A.9040205@grosbein.pp.ru> Date: Wed, 23 Jun 2010 23:16:42 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: rank1seeker@gmail.com References: <20100623.160330.281.1@DEV> In-Reply-To: <20100623.160330.281.1@DEV> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: loader prompt: list / on other device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:52:12 -0000 On 23.06.2010 23:03, rank1seeker@gmail.com wrote: > I've escaped to loader prompt: > Current device is disk0s3a, from which this loader is running. > > My USB stick is device1 and device1s2a is UFS /, on which I would like to > reach some file or simply list directory. > > Syntax? I guess, you have to change 'currdev' variable to point to right diskX Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 17:07:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 846011065672 for ; Wed, 23 Jun 2010 17:07:13 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by mx1.freebsd.org (Postfix) with ESMTP id E5AD48FC08 for ; Wed, 23 Jun 2010 17:07:11 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTCI/PhbZ6N/kK9c4pOvfVFsVnpetSkL2@postini.com; Wed, 23 Jun 2010 10:07:13 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 23 Jun 2010 10:03:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 23 Jun 2010 13:03:46 -0400 From: Andrew Duane To: "rank1seeker@gmail.com" , "freebsd-hackers@freebsd.org" Date: Wed, 23 Jun 2010 13:03:44 -0400 Thread-Topic: loader prompt: list / on other device Thread-Index: AcsS7a3h1mEVLbLwQTusjLe9tnDEmQACDIBA Message-ID: References: <20100623.160330.281.1@DEV> In-Reply-To: <20100623.160330.281.1@DEV> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: loader prompt: list / on other device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:07:13 -0000 You *should* be able to use device1s2a:/ as a syntax, but I noticed a bug = in our old loader code that parses devicenames like that where it wouldn't = work correctly with unit numbers. I don't know if that bug is still around,= but setting currdev did work around it. /Andrew =20 =20 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org=20 > [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of=20 > rank1seeker@gmail.com > Sent: Wednesday, June 23, 2010 12:04 PM > To: freebsd-hackers@freebsd.org > Subject: loader prompt: list / on other device >=20 > I've escaped to loader prompt: > Current device is disk0s3a, from which this loader is running. >=20 > My USB stick is device1 and device1s2a is UFS /, on which I=20 > would like to reach some file or simply list directory. >=20 > Syntax?=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to=20 > "freebsd-hackers-unsubscribe@freebsd.org" > = From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 17:16:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF80106566B for ; Wed, 23 Jun 2010 17:16:17 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 94F6B8FC08 for ; Wed, 23 Jun 2010 17:16:17 +0000 (UTC) Received: by qyk10 with SMTP id 10so192306qyk.13 for ; Wed, 23 Jun 2010 10:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=CwFeiPh71TmGqpk5TfNFTMMz/mKl1p3GxqztmNxY7Rw=; b=Ta1XaP826MM7+lWl6YQNsEHsQp5ldIr2k/GpVLQarngJWmCfM21QzWObYyadYHOT87 p95bN152olNuK9fKOpL/QVNGAhqNuuMMY6iRGsUBHRcLrPkM0F6cLU4CUeVeHK14jlLE miKrJD3m+W7Gc/s38w4Q9CCbIh+trVVelP29I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=cx8YVF2tH9GN9uGNb6NiFE7CHEwx7eGYv9Buqn9C0U1J9aC2Nu6DI6ripgtpK3voa9 W0Y4H3smOd93w57i6JMJxSNnC67z+sVCtjinYZ8h4ZDLdVko4rRvqru+xNy09CB1z9ZJ 6O2wXUdIF53f53wXIyzzIsRkPMc85FJEsFE9k= MIME-Version: 1.0 Received: by 10.224.65.77 with SMTP id h13mr5271427qai.196.1277311536763; Wed, 23 Jun 2010 09:45:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.224.28.79 with HTTP; Wed, 23 Jun 2010 09:45:36 -0700 (PDT) In-Reply-To: <20100623.160330.281.1@DEV> References: <20100623.160330.281.1@DEV> Date: Wed, 23 Jun 2010 09:45:36 -0700 X-Google-Sender-Auth: 4zu1VtNCbCS7ODIE6uLu2kYTVWc Message-ID: From: mdf@FreeBSD.org To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: loader prompt: list / on other device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:16:17 -0000 On Wed, Jun 23, 2010 at 9:03 AM, wrote: > I've escaped to loader prompt: > Current device is disk0s3a, from which this loader is running. > > My USB stick is device1 and device1s2a is UFS /, on which I would like to > reach some file or simply list directory. IIRC, there is no way to do this (but my memory is based on stable/7). I extended some Isilon stuff to add a 'bootdev' command to the loader that would allow for selecting alternate boot disks. I can see about dusting that off and making a patch against CURRENT, if there is no current way to do what you ask. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 17:16:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 673411065749 for ; Wed, 23 Jun 2010 17:16:34 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id C61AA8FC18 for ; Wed, 23 Jun 2010 17:16:33 +0000 (UTC) Received: by wwb24 with SMTP id 24so886181wwb.13 for ; Wed, 23 Jun 2010 10:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jizf13mBzb0Qk2RL4DX0ZYDAe7528kMTH6+NfVJEigc=; b=LFTnW5KyuDrl3zi7DPhcf+5nUOvGccf2ziLg0FKNBxO8S7R7WoILKuTfBRLmpVlWli aAYpfc0XAFCEaYPXWWE1uptiTtahqZsovJjvoLIh49I1lgsXr33K7wYjg/UIuJK5Mr41 lYmYZbnPOUS30fpeTUGujvPwoogHNA3GYmF4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QWol/3IEvWEpIvIwveayfOJG5d+qghb+w1PsM48N5WSMWIDuOzPxagKEgW3VWnHh00 5x8U05X8he6LloA2bxg2hMP8sShQWYDQYQzinOUtAF1S55tkCQUkxiyOx3UYc+mxnllU orYdZmdtumbUoPQvWiNuuW2FPBZq3OGj5/n5Q= MIME-Version: 1.0 Received: by 10.216.93.73 with SMTP id k51mr189663wef.97.1277313392583; Wed, 23 Jun 2010 10:16:32 -0700 (PDT) Received: by 10.216.230.160 with HTTP; Wed, 23 Jun 2010 10:16:32 -0700 (PDT) In-Reply-To: <4C22336A.9040205@grosbein.pp.ru> References: <20100623.160330.281.1@DEV> <4C22336A.9040205@grosbein.pp.ru> Date: Wed, 23 Jun 2010 19:16:32 +0200 Message-ID: From: "Domagoj S." To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, Eugene Grosbein Subject: Re: loader prompt: list / on other device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:16:34 -0000 2010/6/23 Eugene Grosbein : > On 23.06.2010 23:03, rank1seeker@gmail.com wrote: >> I've escaped to loader prompt: >> Current device is disk0s3a, from which this loader is running. >> >> My USB stick is device1 and device1s2a is UFS /, on which I would like t= o >> reach some file or simply list directory. >> >> Syntax? > > I guess, you have to change 'currdev' variable to point to right diskX > > Eugene Grosbein Thanks Eugene! It worked. ;) I've booted ad4s3a and escaped to loader prompt. currdev was disk0s3a USB stick was disk1s2a, which mounted, appears as da0s2a I used "more /etc/fstab" in order to get hostname HDD_hostanme Then at loader prompt: "set currdev=3Ddisk1s2a" Then again, I used "more /etc/fstab" in order to get hostname: USB_hostanme On Wed, Jun 23, 2010 at 6:45 PM, wrote: > On Wed, Jun 23, 2010 at 9:03 AM, wrote: >> I've escaped to loader prompt: >> Current device is disk0s3a, from which this loader is running. >> >> My USB stick is device1 and device1s2a is UFS /, on which I would like t= o >> reach some file or simply list directory. > > IIRC, there is no way to do this (but my memory is based on stable/7). > I extended some Isilon stuff to add a 'bootdev' command to the loader > that would allow for selecting alternate boot disks. I can see about > dusting that off and making a patch against CURRENT, if there is no > current way to do what you ask. > > Cheers, > matthew Well, looks like it is working on 8.0 RELEASE. On Wed, Jun 23, 2010 at 7:03 PM, Andrew Duane wrote: > You *should* be able to use device1s2a:/ as a syntax, but I noticed a bu= g in our old loader code that parses devicenames like that where it wouldn'= t work correctly with unit numbers. I don't know if that bug is still aroun= d, but setting currdev did work around it. > > /Andrew Thx! I'll try it... From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 21:10:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F741065670 for ; Wed, 23 Jun 2010 21:10:10 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 968728FC15 for ; Wed, 23 Jun 2010 21:10:06 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id AC46AD480E9; Wed, 23 Jun 2010 23:10:00 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 828E933CD8; Wed, 23 Jun 2010 21:09:59 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 72E2EA1274; Wed, 23 Jun 2010 21:09:59 +0000 (UTC) Date: Wed, 23 Jun 2010 23:09:59 +0200 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20100623210959.GA21260@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: Avoiding sysctl at program startup using ELF aux vector (was: concurrent sysctl implementation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 21:10:10 -0000 Hi Kostik, This patch seems to have faded out from memory. Is it possible to go forward and commit it? Thanks, Regards. On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > Below is the prototype that seems to work for me both with patched and > old rtld on i386. Patch also contains bits for amd64 that I did not > tested yet. All other arches are not buildable for now. > > Patch completely eliminates sysctl syscalls from the rtld and libc > startup. Without the patch, a single run of /bin/ls did 6 sysctls, > with the patch, no sysctls is queried at all. > > diff --git a/lib/libc/gen/__getosreldate.c b/lib/libc/gen/__getosreldate.c > index 69aac07..6a4e5ea 100644 > --- a/lib/libc/gen/__getosreldate.c > +++ b/lib/libc/gen/__getosreldate.c > @@ -29,6 +29,8 @@ __FBSDID("$FreeBSD$"); > > #include > #include > +#include > +#include > > /* > * This is private to libc. It is intended for wrapping syscall stubs in order > @@ -49,7 +51,15 @@ __getosreldate(void) > > if (osreldate != 0) > return (osreldate); > - > + > + if (_rtld_aux_info != NULL) > + error = _rtld_aux_info(AT_OSRELDATE, &osreldate, > + sizeof(osreldate)); > + else > + error = ENOSYS; > + if (error == 0 && osreldate != 0) > + return (osreldate); > + > oid[0] = CTL_KERN; > oid[1] = KERN_OSRELDATE; > osrel = 0; > diff --git a/lib/libc/gen/getpagesize.c b/lib/libc/gen/getpagesize.c > index d796b9d..b8f0ec1 100644 > --- a/lib/libc/gen/getpagesize.c > +++ b/lib/libc/gen/getpagesize.c > @@ -36,6 +36,8 @@ __FBSDID("$FreeBSD$"); > #include > #include > > +#include > +#include > #include > > /* > @@ -52,13 +54,23 @@ getpagesize() > int mib[2]; > static int value; > size_t size; > + int error; > + > + if (value != 0) > + return (value); > + > + if (_rtld_aux_info != NULL) > + error = _rtld_aux_info(AT_PAGESZ, &value, sizeof(value)); > + else > + error = ENOSYS; > + if (error == 0 && value != 0) > + return (value); > + > + mib[0] = CTL_HW; > + mib[1] = HW_PAGESIZE; > + size = sizeof value; > + if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) > + return (-1); > > - if (!value) { > - mib[0] = CTL_HW; > - mib[1] = HW_PAGESIZE; > - size = sizeof value; > - if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) > - return (-1); > - } > return (value); > } > diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c > index 270d641..e479abe 100644 > --- a/lib/libc/stdlib/malloc.c > +++ b/lib/libc/stdlib/malloc.c > @@ -179,6 +179,7 @@ __FBSDID("$FreeBSD$"); > > #include > #include > +#include > #include > #include > #include > @@ -4769,7 +4770,10 @@ malloc_init_hard(void) > unsigned i; > int linklen; > char buf[PATH_MAX + 1]; > + int mib[2]; > + size_t len; > const char *opts; > + int error; > > malloc_mutex_lock(&init_lock); > if (malloc_initialized) { > @@ -4782,10 +4786,11 @@ malloc_init_hard(void) > } > > /* Get number of CPUs. */ > - { > - int mib[2]; > - size_t len; > - > + if (_rtld_aux_info != NULL) > + error = _rtld_aux_info(AT_NCPUS, &ncpus, sizeof(ncpus)); > + else > + error = ENOSYS; > + if (error != 0 || ncpus == 0) { > mib[0] = CTL_HW; > mib[1] = HW_NCPU; > len = sizeof(ncpus); > diff --git a/lib/libc/sys/stack_protector.c b/lib/libc/sys/stack_protector.c > index 63beebc..571f63c 100644 > --- a/lib/libc/sys/stack_protector.c > +++ b/lib/libc/sys/stack_protector.c > @@ -34,6 +34,8 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -54,9 +56,17 @@ __guard_setup(void) > { > int mib[2]; > size_t len; > + int error; > > if (__stack_chk_guard[0] != 0) > return; > + if (_rtld_aux_info != NULL) > + error = _rtld_aux_info(AT_CANARY, __stack_chk_guard, > + sizeof(__stack_chk_guard)); > + else > + error = ENOSYS; > + if (error == 0 && __stack_chk_guard[0] != 0) > + return; > > mib[0] = CTL_KERN; > mib[1] = KERN_ARND; > diff --git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map > index ce1e3e5..f45f955 100644 > --- a/libexec/rtld-elf/Symbol.map > +++ b/libexec/rtld-elf/Symbol.map > @@ -24,4 +24,5 @@ FBSDprivate_1.0 { > _rtld_free_tls; > _rtld_atfork_pre; > _rtld_atfork_post; > + _rtld_aux_info; > }; > diff --git a/libexec/rtld-elf/amd64/reloc.c b/libexec/rtld-elf/amd64/reloc.c > index 8a32adf..a510884 100644 > --- a/libexec/rtld-elf/amd64/reloc.c > +++ b/libexec/rtld-elf/amd64/reloc.c > @@ -113,7 +113,7 @@ init_pltgot(Obj_Entry *obj) > > /* Process the non-PLT relocations. */ > int > -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) > +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) > { > const Elf_Rela *relalim; > const Elf_Rela *rela; > @@ -125,9 +125,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) > * The dynamic loader may be called from a thread, we have > * limited amounts of stack available so we cannot use alloca(). > */ > - cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > - if (cache == MAP_FAILED) > + if (early) > cache = NULL; > + else { > + cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > + if (cache == MAP_FAILED) > + cache = NULL; > + } > > relalim = (const Elf_Rela *) ((caddr_t) obj->rela + obj->relasize); > for (rela = obj->rela; rela < relalim; rela++) { > diff --git a/libexec/rtld-elf/i386/reloc.c b/libexec/rtld-elf/i386/reloc.c > index ec83bff..2913d78 100644 > --- a/libexec/rtld-elf/i386/reloc.c > +++ b/libexec/rtld-elf/i386/reloc.c > @@ -114,7 +114,7 @@ init_pltgot(Obj_Entry *obj) > > /* Process the non-PLT relocations. */ > int > -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) > +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) > { > const Elf_Rel *rellim; > const Elf_Rel *rel; > @@ -126,9 +126,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) > * The dynamic loader may be called from a thread, we have > * limited amounts of stack available so we cannot use alloca(). > */ > - cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > - if (cache == MAP_FAILED) > + if (early) > cache = NULL; > + else { > + cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > + if (cache == MAP_FAILED) > + cache = NULL; > + } > > rellim = (const Elf_Rel *) ((caddr_t) obj->rel + obj->relsize); > for (rel = obj->rel; rel < rellim; rel++) { > diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c > index 721fe89..75a1c69 100644 > --- a/libexec/rtld-elf/rtld.c > +++ b/libexec/rtld-elf/rtld.c > @@ -40,6 +40,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -84,6 +85,9 @@ typedef struct Struct_DoneList { > */ > static const char *basename(const char *); > static void die(void) __dead2; > +static void digest_dynamic1(Obj_Entry *, int, const Elf_Dyn **, > + const Elf_Dyn **); > +static void digest_dynamic2(Obj_Entry *, const Elf_Dyn *, const Elf_Dyn *); > static void digest_dynamic(Obj_Entry *, int); > static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *); > static Obj_Entry *dlcheck(void *); > @@ -97,7 +101,7 @@ static char *find_library(const char *, const Obj_Entry *); > static const char *gethints(void); > static void init_dag(Obj_Entry *); > static void init_dag1(Obj_Entry *, Obj_Entry *, DoneList *); > -static void init_rtld(caddr_t); > +static void init_rtld(caddr_t, Elf_Auxinfo **); > static void initlist_add_neededs(Needed_Entry *, Objlist *); > static void initlist_add_objects(Obj_Entry *, Obj_Entry **, Objlist *); > static bool is_exported(const Elf_Sym *); > @@ -116,7 +120,7 @@ static void objlist_push_head(Objlist *, Obj_Entry *); > static void objlist_push_tail(Objlist *, Obj_Entry *); > static void objlist_remove(Objlist *, Obj_Entry *); > static void *path_enumerate(const char *, path_enum_proc, void *); > -static int relocate_objects(Obj_Entry *, bool, Obj_Entry *); > +static int relocate_objects(Obj_Entry *, bool, Obj_Entry *, bool early); > static int rtld_dirname(const char *, char *); > static int rtld_dirname_abs(const char *, char *); > static void rtld_exit(void); > @@ -188,6 +192,9 @@ extern Elf_Dyn _DYNAMIC; > #define RTLD_IS_DYNAMIC() (&_DYNAMIC != NULL) > #endif > > +static int pagesize, osreldate, canary_len, ncpus; > +static char *canary; > + > /* > * These are the functions the dynamic linker exports to application > * programs. They are the only symbols the dynamic linker is willing > @@ -214,6 +221,7 @@ static func_ptr_type exports[] = { > (func_ptr_type) &dl_iterate_phdr, > (func_ptr_type) &_rtld_atfork_pre, > (func_ptr_type) &_rtld_atfork_post, > + (func_ptr_type) &_rtld_aux_info, > NULL > }; > > @@ -350,7 +358,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry **objp) > > /* Initialize and relocate ourselves. */ > assert(aux_info[AT_BASE] != NULL); > - init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr); > + init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); > > __progname = obj_rtld.path; > argv0 = argv[0] != NULL ? argv[0] : "(null)"; > @@ -519,7 +527,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry **objp) > allocate_initial_tls(obj_list); > > if (relocate_objects(obj_main, > - ld_bind_now != NULL && *ld_bind_now != '\0', &obj_rtld) == -1) > + ld_bind_now != NULL && *ld_bind_now != '\0', &obj_rtld, false) == -1) > die(); > > dbg("doing copy relocations"); > @@ -736,14 +744,16 @@ die(void) > * information in its Obj_Entry structure. > */ > static void > -digest_dynamic(Obj_Entry *obj, int early) > +digest_dynamic1(Obj_Entry *obj, int early, const Elf_Dyn **dyn_rpath, > + const Elf_Dyn **dyn_soname) > { > const Elf_Dyn *dynp; > Needed_Entry **needed_tail = &obj->needed; > - const Elf_Dyn *dyn_rpath = NULL; > - const Elf_Dyn *dyn_soname = NULL; > int plttype = DT_REL; > > + *dyn_rpath = NULL; > + *dyn_soname = NULL; > + > obj->bind_now = false; > for (dynp = obj->dynamic; dynp->d_tag != DT_NULL; dynp++) { > switch (dynp->d_tag) { > @@ -867,11 +877,11 @@ digest_dynamic(Obj_Entry *obj, int early) > * We have to wait until later to process this, because we > * might not have gotten the address of the string table yet. > */ > - dyn_rpath = dynp; > + *dyn_rpath = dynp; > break; > > case DT_SONAME: > - dyn_soname = dynp; > + *dyn_soname = dynp; > break; > > case DT_INIT: > @@ -958,6 +968,12 @@ digest_dynamic(Obj_Entry *obj, int early) > obj->pltrelasize = obj->pltrelsize; > obj->pltrelsize = 0; > } > +} > + > +static void > +digest_dynamic2(Obj_Entry *obj, const Elf_Dyn *dyn_rpath, > + const Elf_Dyn *dyn_soname) > +{ > > if (obj->z_origin && obj->origin_path == NULL) { > obj->origin_path = xmalloc(PATH_MAX); > @@ -975,6 +991,16 @@ digest_dynamic(Obj_Entry *obj, int early) > object_add_name(obj, obj->strtab + dyn_soname->d_un.d_val); > } > > +static void > +digest_dynamic(Obj_Entry *obj, int early) > +{ > + const Elf_Dyn *dyn_rpath; > + const Elf_Dyn *dyn_soname; > + > + digest_dynamic1(obj, early, &dyn_rpath, &dyn_soname); > + digest_dynamic2(obj, dyn_rpath, dyn_soname); > +} > + > /* > * Process a shared object's program header. This is used only for the > * main program, when the kernel has already loaded the main program > @@ -1301,9 +1327,11 @@ init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList *dlp) > * this function is to relocate the dynamic linker. > */ > static void > -init_rtld(caddr_t mapbase) > +init_rtld(caddr_t mapbase, Elf_Auxinfo **aux_info) > { > Obj_Entry objtmp; /* Temporary rtld object */ > + const Elf_Dyn *dyn_rpath; > + const Elf_Dyn *dyn_soname; > > /* > * Conjure up an Obj_Entry structure for the dynamic linker. > @@ -1320,27 +1348,38 @@ init_rtld(caddr_t mapbase) > #endif > if (RTLD_IS_DYNAMIC()) { > objtmp.dynamic = rtld_dynamic(&objtmp); > - digest_dynamic(&objtmp, 1); > + digest_dynamic1(&objtmp, 1, &dyn_rpath, &dyn_soname); > assert(objtmp.needed == NULL); > #if !defined(__mips__) > /* MIPS and SH{3,5} have a bogus DT_TEXTREL. */ > assert(!objtmp.textrel); > #endif > - > /* > * Temporarily put the dynamic linker entry into the object list, so > * that symbols can be found. > */ > > - relocate_objects(&objtmp, true, &objtmp); > + relocate_objects(&objtmp, true, &objtmp, true); > } > - > /* Initialize the object list. */ > obj_tail = &obj_list; > > /* Now that non-local variables can be accesses, copy out obj_rtld. */ > memcpy(&obj_rtld, &objtmp, sizeof(obj_rtld)); > > + if (aux_info[AT_PAGESZ] != NULL) > + pagesize = aux_info[AT_PAGESZ]->a_un.a_val; > + if (aux_info[AT_OSRELDATE] != NULL) > + osreldate = aux_info[AT_OSRELDATE]->a_un.a_val; > + if (aux_info[AT_CANARY] != NULL && aux_info[AT_CANARYLEN] != NULL) { > + canary = aux_info[AT_CANARY]->a_un.a_ptr; > + canary_len = aux_info[AT_CANARYLEN]->a_un.a_val; > + } > + if (aux_info[AT_NCPUS] != NULL) > + ncpus = aux_info[AT_NCPUS]->a_un.a_val; > + > + digest_dynamic2(&obj_rtld, dyn_rpath, dyn_soname); > + > /* Replace the path with a dynamically allocated copy. */ > obj_rtld.path = xstrdup(PATH_RTLD); > > @@ -1745,7 +1784,8 @@ objlist_remove(Objlist *list, Obj_Entry *obj) > * or -1 on failure. > */ > static int > -relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj) > +relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj, > + bool early) > { > Obj_Entry *obj; > > @@ -1770,7 +1810,7 @@ relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj) > } > > /* Process the non-PLT relocations. */ > - if (reloc_non_plt(obj, rtldobj)) > + if (reloc_non_plt(obj, rtldobj, early)) > return -1; > > if (obj->textrel) { /* Re-protected the text segment. */ > @@ -2022,7 +2062,8 @@ dlopen(const char *name, int mode) > if (result != -1 && ld_tracing) > goto trace; > if (result == -1 || > - (relocate_objects(obj, mode == RTLD_NOW, &obj_rtld)) == -1) { > + (relocate_objects(obj, mode == RTLD_NOW, &obj_rtld, false)) > + == -1) { > obj->dl_refcount--; > unref_dag(obj); > if (obj->refcount == 0) > @@ -3611,3 +3652,110 @@ fetch_ventry(const Obj_Entry *obj, unsigned long symnum) > } > return NULL; > } > + > +static int > +__getosreldate(void) > +{ > + static int osreldate; > + size_t len; > + int oid[2]; > + int error, osrel; > + > + oid[0] = CTL_KERN; > + oid[1] = KERN_OSRELDATE; > + osrel = 0; > + len = sizeof(osrel); > + error = sysctl(oid, 2, &osrel, &len, NULL, 0); > + if (error == 0 && osrel > 0 && len == sizeof(osrel)) > + osreldate = osrel; > + return (osreldate); > +} > + > +static int > +__getpagesize(void) > +{ > + int mib[2]; > + static int value; > + size_t size; > + > + mib[0] = CTL_HW; > + mib[1] = HW_PAGESIZE; > + size = sizeof value; > + if (sysctl(mib, 2, &value, &size, NULL, 0) == -1) > + return (-1); > + > + return (value); > +} > + > +static int > +__getncpus(void) > +{ > + int mib[2]; > + size_t len; > + int n; > + > + mib[0] = CTL_HW; > + mib[1] = HW_NCPU; > + len = sizeof(ncpus); > + if (sysctl(mib, 2, &n, &len, (void *) 0, 0) == -1) > + n = 1; > + return (n); > +} > + > +int > +_rtld_aux_info(int aux, void *buf, int buflen) > +{ > + int res; > + > + switch (aux) { > + case AT_CANARY: > + if (canary != NULL && canary_len >= buflen) { > + memcpy(buf, canary, buflen); > + memset(canary, 0, canary_len); > + canary = NULL; > + res = 0; > + } else > + res = ENOENT; > + break; > + case AT_PAGESZ: > + if (buflen == sizeof(int)) { > + if (pagesize == 0) > + pagesize = __getpagesize(); > + if (pagesize != 0) { > + *(int *)buf = pagesize; > + res = 0; > + } else > + res = ENOENT; > + } else > + res = EINVAL; > + break; > + case AT_OSRELDATE: > + if (buflen == sizeof(int)) { > + if (osreldate == 0) > + osreldate = __getosreldate(); > + if (osreldate != 0) { > + *(int *)buf = osreldate; > + res = 0; > + } else > + res = ENOENT; > + } else > + res = EINVAL; > + break; > + case AT_NCPUS: > + if (buflen == sizeof(int)) { > + if (ncpus == 0) > + ncpus = __getncpus(); > + if (ncpus != 0) { > + *(int *)buf = ncpus; > + res = 0; > + } else > + res = ENOENT; > + } else > + res = EINVAL; > + break; > + default: > + res = ENOENT; > + break; > + } > + return (res); > +} > diff --git a/libexec/rtld-elf/rtld.h b/libexec/rtld-elf/rtld.h > index 06086b4..928e3ed 100644 > --- a/libexec/rtld-elf/rtld.h > +++ b/libexec/rtld-elf/rtld.h > @@ -286,7 +286,7 @@ const Ver_Entry *fetch_ventry(const Obj_Entry *obj, unsigned long); > * MD function declarations. > */ > int do_copy_relocations(Obj_Entry *); > -int reloc_non_plt(Obj_Entry *, Obj_Entry *); > +int reloc_non_plt(Obj_Entry *, Obj_Entry *, bool); > int reloc_plt(Obj_Entry *); > int reloc_jmpslots(Obj_Entry *); > void allocate_initial_tls(Obj_Entry *); > diff --git a/sys/amd64/include/elf.h b/sys/amd64/include/elf.h > index e5c95f7..d541b9e 100644 > --- a/sys/amd64/include/elf.h > +++ b/sys/amd64/include/elf.h > @@ -87,8 +87,12 @@ __ElfType(Auxinfo); > #define AT_GID 13 /* Real gid. */ > #define AT_EGID 14 /* Effective gid. */ > #define AT_EXECPATH 15 /* Path to the executable. */ > +#define AT_CANARY 16 /* Canary for SSP */ > +#define AT_CANARYLEN 17 /* Length of the canary. */ > +#define AT_OSRELDATE 18 /* OSRELDATE. */ > +#define AT_NCPUS 19 /* Number of CPUs. */ > > -#define AT_COUNT 16 /* Count of defined aux entry types. */ > +#define AT_COUNT 20 /* Count of defined aux entry types. */ > > /* > * Relocation types. > diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c > index af8168e..acf2c34 100644 > --- a/sys/compat/ia32/ia32_sysvec.c > +++ b/sys/compat/ia32/ia32_sysvec.c > @@ -191,6 +191,7 @@ ia32_copyout_strings(struct image_params *imgp) > struct freebsd32_ps_strings *arginfo; > size_t execpath_len; > int szsigcode; > + char canary[sizeof(long) * 8]; > > /* > * Calculate string base and vector table pointers. > @@ -203,8 +204,9 @@ ia32_copyout_strings(struct image_params *imgp) > arginfo = (struct freebsd32_ps_strings *)FREEBSD32_PS_STRINGS; > szsigcode = *(imgp->proc->p_sysent->sv_szsigcode); > destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - > - roundup(execpath_len, sizeof(char *)) - > - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); > + roundup(execpath_len, sizeof(char *)) - > + roundup(sizeof(canary), sizeof(char *)) - > + roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); > > /* > * install sigcode > @@ -223,6 +225,14 @@ ia32_copyout_strings(struct image_params *imgp) > } > > /* > + * Prepare the canary for SSP. > + */ > + arc4rand(canary, sizeof(canary), 0); > + imgp->canary = (uintptr_t)arginfo - szsigcode - execpath_len - > + sizeof(canary); > + copyout(canary, (void *)imgp->canary, sizeof(canary)); > + > + /* > * If we have a valid auxargs ptr, prepare some room > * on the stack. > */ > @@ -239,8 +249,8 @@ ia32_copyout_strings(struct image_params *imgp) > * for argument of Runtime loader. > */ > vectp = (u_int32_t *) (destp - (imgp->args->argc + > - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * > - sizeof(u_int32_t)); > + imgp->args->envc + 2 + imgp->auxarg_size) > + * sizeof(u_int32_t)); > } else > /* > * The '+ 2' is for the null pointers at the end of each of > diff --git a/sys/i386/include/elf.h b/sys/i386/include/elf.h > index af71ab8..a959e68 100644 > --- a/sys/i386/include/elf.h > +++ b/sys/i386/include/elf.h > @@ -90,8 +90,12 @@ __ElfType(Auxinfo); > #define AT_GID 13 /* Real gid. */ > #define AT_EGID 14 /* Effective gid. */ > #define AT_EXECPATH 15 /* Path to the executable. */ > +#define AT_CANARY 16 /* Canary for SSP. */ > +#define AT_CANARYLEN 17 /* Length of the canary. */ > +#define AT_OSRELDATE 18 /* OSRELDATE. */ > +#define AT_NCPUS 19 /* Number of CPUs. */ > > -#define AT_COUNT 16 /* Count of defined aux entry types. */ > +#define AT_COUNT 20 /* Count of defined aux entry types. */ > > /* > * Relocation types. > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > index e2c0a12..b2c1d45 100644 > --- a/sys/kern/imgact_elf.c > +++ b/sys/kern/imgact_elf.c > @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -887,6 +888,12 @@ __elfN(freebsd_fixup)(register_t **stack_base, struct image_params *imgp) > AUXARGS_ENTRY(pos, AT_BASE, args->base); > if (imgp->execpathp != 0) > AUXARGS_ENTRY(pos, AT_EXECPATH, imgp->execpathp); > + AUXARGS_ENTRY(pos, AT_OSRELDATE, imgp->proc->p_osrel); > + if (imgp->canary != 0) { > + AUXARGS_ENTRY(pos, AT_CANARY, imgp->canary); > + AUXARGS_ENTRY(pos, AT_CANARYLEN, imgp->canarylen); > + } > + AUXARGS_ENTRY(pos, AT_NCPUS, mp_ncpus); > AUXARGS_ENTRY(pos, AT_NULL, 0); > > free(imgp->auxargs, M_TEMP); > diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c > index 3f36658..6bed93f 100644 > --- a/sys/kern/kern_exec.c > +++ b/sys/kern/kern_exec.c > @@ -380,6 +380,8 @@ do_execve(td, args, mac_p) > imgp->args = args; > imgp->execpath = imgp->freepath = NULL; > imgp->execpathp = 0; > + imgp->canary = 0; > + imgp->canarylen = 0; > > #ifdef MAC > error = mac_execve_enter(imgp, mac_p); > @@ -1175,6 +1177,7 @@ exec_copyout_strings(imgp) > struct proc *p; > size_t execpath_len; > int szsigcode; > + char canary[sizeof(long) * 8]; > > /* > * Calculate string base and vector table pointers. > @@ -1191,6 +1194,7 @@ exec_copyout_strings(imgp) > szsigcode = *(p->p_sysent->sv_szsigcode); > destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - > roundup(execpath_len, sizeof(char *)) - > + roundup(sizeof(canary), sizeof(char *)) - > roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); > > /* > @@ -1210,6 +1214,15 @@ exec_copyout_strings(imgp) > } > > /* > + * Prepare the canary for SSP. > + */ > + arc4rand(canary, sizeof(canary), 0); > + imgp->canary = (uintptr_t)arginfo - szsigcode - execpath_len - > + sizeof(canary); > + copyout(canary, (void *)imgp->canary, sizeof(canary)); > + imgp->canarylen = sizeof(canary); > + > + /* > * If we have a valid auxargs ptr, prepare some room > * on the stack. > */ > @@ -1226,8 +1239,8 @@ exec_copyout_strings(imgp) > * for argument of Runtime loader. > */ > vectp = (char **)(destp - (imgp->args->argc + > - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * > - sizeof(char *)); > + imgp->args->envc + 2 + imgp->auxarg_size) > + * sizeof(char *)); > } else { > /* > * The '+ 2' is for the null pointers at the end of each of > diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h > index e6acc00..8acd184 100644 > --- a/sys/sys/imgact.h > +++ b/sys/sys/imgact.h > @@ -69,6 +69,8 @@ struct image_params { > char *execpath; > unsigned long execpathp; > char *freepath; > + unsigned long canary; > + int canarylen; > }; > > #ifdef _KERNEL > diff --git a/sys/sys/link_elf.h b/sys/sys/link_elf.h > index 98840a5..30f3d75 100644 > --- a/sys/sys/link_elf.h > +++ b/sys/sys/link_elf.h > @@ -92,6 +92,10 @@ __BEGIN_DECLS > > typedef int (*__dl_iterate_hdr_callback)(struct dl_phdr_info *, size_t, void *); > extern int dl_iterate_phdr(__dl_iterate_hdr_callback, void *); > +extern int _rtld_aux_info(int, void *, int); > +#ifndef IN_RTLD > +#pragma weak _rtld_aux_info > +#endif > > __END_DECLS > -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 01:15:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8FE61065672; Thu, 24 Jun 2010 01:15:14 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA038FC0A; Thu, 24 Jun 2010 01:15:14 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5O1FAUT038142; Wed, 23 Jun 2010 18:15:10 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5O1F95A038141; Wed, 23 Jun 2010 18:15:09 -0700 (PDT) (envelope-from faber) Date: Wed, 23 Jun 2010 18:15:09 -0700 From: Ted Faber To: Ryan Stone Message-ID: <20100624011509.GI31578@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dp9QYJgVRVEW2bsm" Content-Disposition: inline In-Reply-To: <20100623154531.GB31578@zod.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon , Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 01:15:14 -0000 --dp9QYJgVRVEW2bsm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote: > On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: > > I have to admit that I'm more than a little surprised that this > > problem does not affect modules that in src, but maybe that's because > > I don't know all that much about FreeBSD's build infrastructure. Are > > the src modules being linked with a linker script that is not being > > used for out-of-src modules? Are the people affected by this not > > using the base compiler to build ports?(I see that this affects PC-BSD > > as well, and I'd be a little surprised to learn that it wasn't using > > the base compiler). >=20 > I had the problem on i386, base compiler. It also affects the sample > module in /usr/share/examples/kld/cdev/ which also uses the base > compiler, if you want a case w/o the ports infrastructure. Just so it gets into Google: Andriy Gapon went a few rounds of debugging with me and it turns out that the problem was that the binutils port had installed a loader in /usr/local/bin/ld that was incompatible with the module system. (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) Basically if the linker you're using to compile isn't /usr/bin/ld you may have problems building kernel modules. The easiest way to detect this is to get the -v output (version number) from the linker in use and compare it against /usr/bin/ld . I was able to do that by adding LDFLAGS +=3D -v to the Makefile in question. Thanks Andriy! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --dp9QYJgVRVEW2bsm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwisZ0ACgkQaUz3f+Zf+Xs5SQCgxZaxZsOwnaWgUBtmXj2qcclK vnQAoKEzudwhmeqM4zGw8DQc58il68xd =ht3Z -----END PGP SIGNATURE----- --dp9QYJgVRVEW2bsm-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 01:36:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD071106564A for ; Thu, 24 Jun 2010 01:36:22 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 397CC8FC13 for ; Thu, 24 Jun 2010 01:36:21 +0000 (UTC) Received: by wyb33 with SMTP id 33so5889344wyb.13 for ; Wed, 23 Jun 2010 18:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=X5SpNat18Q1kKLu4bLwAyh6YP9gvizkSmJOj96JmJXs=; b=cbG4cxNMDNif5456VUkQ7KrAaQaKbvSuWSu/8eodMoz1+yXRtp42qSCq+TIuE2oouQ ZVTnVHHinqSS54ZoC18AqDOf0PvK+cvTNAaL3rYZRXqUWbLW3wv7qUVOaX1uWFwVgo5z IOF8KWqGTOikaRxJKj8cTY04gtbckZ3Oi3hm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SVn8ZJKdby2PqPKxJpdt8efGsRzanZj5310sNv8SaI9w2YiwyTZ83OGlNK0CHrENM5 0zZ2rByC72PHqIs1I3QLMiaD5Q4kM13f67QkP3k+im+spTOU0eq5di7hUBkqpXoNRDlC Zwj4mYg5o1YoCJKP3fYzXdH531nG6u21u2Cuo= MIME-Version: 1.0 Received: by 10.216.160.70 with SMTP id t48mr3208318wek.82.1277343381040; Wed, 23 Jun 2010 18:36:21 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.216.52.145 with HTTP; Wed, 23 Jun 2010 18:36:20 -0700 (PDT) In-Reply-To: <20100612100006.000073fa@unknown> References: <20100612100006.000073fa@unknown> Date: Thu, 24 Jun 2010 04:36:20 +0300 X-Google-Sender-Auth: 47B02MGKjlsAQDkr6y-bWgzuzVg Message-ID: From: Mohammed Farrag To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Chargen , freebsd-hackers@freebsd.org, Matt Thyer , freebsd-current@freebsd.org, Mohammed@freebsd.org Subject: Re: I need reply in Embedded FreeBSD Kernel Theme X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 01:36:22 -0000 hi sorry for being late in reply but I had some problems in the last week. I hope u still remeber what I was talking about :) @chargen Thanx for ur reply. Embedded computer systems permeate all aspects of our daily lives. Alarm clocks, coffee makers, digital watches, cell phones, and automobiles are just a few of the devices that make use of embedded systems. The design and development of such systems is unique, because the design constraints are different for each system. I supposed a new design for reducing the size of the kernel to be able to work in such an environment which has some constraints make it does not have the ability to get large memory, large storage devices or others. ///////////////////////////// as far as your document goes: "We will unload all the drivers that indicated with zeros in the module metadata file. That would make the OS to be a few of Megabytes." unload? what is the logic here? I'm sorry but what is the real gain here, ////////////////////// The configuration file is dependent on the kernel (which is included as a compiled kernel). If I unload these unneeded drivers, I decrease the size of the compiled kernel So it will have the ability to work in more constrained environment and that is suitable to work for Operating Systems for small chips for embedded systems. As the Internet grew, the requirements of embedded systems also began to grow in complexity. In addition to solving classic embedded systems problems, system designers were required to add connectivity for sending and receiving data or providing an automated method for software upgrades. Rather than increase the development effort, system designers have moved toward using third-party hardware and evaluating open source software. Thanx Chargen @ andrew Thanx for your reply. I appreciate your effort to download the document. Regarding the uploading of the document to that site, I am sorry for that but I tried to attach it with the email but it was refused because its size was too large. I did not send it in the text part because the text format and tables will be lost. I am sorry for that. ///////////////////////////////////////////////////////// After a couple of quick readings, I'm not sure I correctly understand what you plan to achieve. It sounds like you are trying to achive something like hardware specific dynamic module loading (like in Solaris, for example), but then it also sounds like you are trying to build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. Are you compiling a kernel at some point rather than just generating a loader.conf for modules in order to minimise the running size? //////////////////////////////////////////////////////// This approach will combine the two both. It will build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. It also will use hardware specific dynamic module loading because I don't have to load all the drivers for devices connected to the machine. I will use this dynamic module loading at the start-up only not at the run time because some considerations of the embedded systems for chips not being to load modules and change how to work at run time. that would make power problems. //////////////////////////////////////////////////////// I was most confused by We will unload all the drivers that indicated with zeros in the > module metadata file. That would make the OS to be a > few of Megabytes. > Whether you are compiling a kernel for the (chosen) hardware based on a generated kernel or loader config, I don't see a sensible case in which you would ever need to "unload" any driver. /////////////////////////////////////////////////////////////// yeah I know it is not sensible but I wrote it as a result of what I supposed before so it has no meaning. just a result to clarify what I reduced here. Thanx for ur sympathy and I will be glad to send you my next file to get ur comments about. //////////////////////////////////////////////////////////////// As much fun as it is spending hours manually tweaking and testing a kernel config for each system and deciding what modules to use, I like the idea of a one time guided process based on accurately identified hardware to build an optimal kernel, so I hope that's what you're proposing. ////////////////////////////////////////////////////////////////// Actually, I am deciding many time guided process based on accurately identified hardware to build an optimal kernel because I think this is more dynamic for considerations of changing the purpose of the embedded system. I mean sometimes u may need to perform deterministic operation in this boot so u do not have to load all drivers which there will be a lot of unneeded drivers of them at this boot process. I will determine the dependencies to provide optimal kernel. Thanx Andrew @ Matt Thanx for ur reply Matt. ///////////////////////////////////////////////////// FreeBSD is already a very modular system and the traditional way (a traditional way) to build for embedded systems is to follow the NanoBSD build method (tools included in the source tree) with a stripped down kernel in which you only load the modules your hardware requires using the FreeBSD loader (or after the initial boot). //////////////////////////////////////////////////// yeah I read about that. My mentor suggested that before and my idea is very close to NanoBSD but I don't know if the freebsd loader will load the moduls based on the hardware requirements or user requirements. I will be glad to reply me. //////////////////////////////////////////////// However my Soekris net4801 board still takes about 2.5 minutes to boot and I think time could be saved by parallel probing of hardware where possible. //////////////////////////////////////////////////// I think parallel probing is not providing in many boards. It's supported for the new borders only (correct me if I am wrong). I have to develop something which can be used in most of embedded systems. /////////////////////////////////////////////////// I'd vote for more work on FreeBSD's existing boot method rather than an entirely new implementation. What problem are you trying to solve Mohammed ? ////////////////////////////// I am not going to change in the main boot process. I am only changing the how of including the kernel in the configuration file. that is it and everything will be done as it is in the current freebsd. no more. That would save space and that is what I need to reduce the size of kernel in memory. @ bruce Thanx for ur reply. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 07:23:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525AA1065674; Thu, 24 Jun 2010 07:23:42 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id A5AE88FC0A; Thu, 24 Jun 2010 07:23:41 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1366885fga.13 for ; Thu, 24 Jun 2010 00:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=Q2iSCSQC9mSdOqAwFZbZlxA4ONqUc/1iUsV1QipqdEY=; b=MfYmk7bp+RRanpfyjxX/LCWVV2ZkYNQNiNEMly1QaxxzmenONP84piBCdYWd2vS7PY yuZKBkeR8m1WbT3faB1iUybpMEPfXsuJsa+KsF/fV69meexTGVwn2kFkQvc1cwnT0ui0 O103XeZggIqml0g61WEeBZw+lx4nhdMdf525E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=WaxrrIPGXu9C24ix1OTc3dLWQM5KwqZWSafLv7VkGKt+/n6uNu2wL/tI/VGekBBXgZ PjFGWjcxJrd25l1lRL8xRNZcSjzexyl2ohOvvvFaazSjV87rpSd2WQ1SjPHyzoHAkC8k OUAPtWAlpABMfE/yIpXI3wJK0HEziEmQPy5WI= Received: by 10.87.70.19 with SMTP id x19mr14931955fgk.14.1277364220283; Thu, 24 Jun 2010 00:23:40 -0700 (PDT) Received: from ernst.jennejohn.org (p578E35A0.dip.t-dialin.net [87.142.53.160]) by mx.google.com with ESMTPS id 18sm14769353fks.35.2010.06.24.00.23.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 00:23:39 -0700 (PDT) Date: Thu, 24 Jun 2010 09:23:37 +0200 From: Gary Jennejohn To: Ted Faber Message-ID: <20100624092337.6bed1f45@ernst.jennejohn.org> In-Reply-To: <20100624011509.GI31578@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:23:42 -0000 On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber wrote: > (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr > commands from cupsd, though it's evidently a bit of a dangerous idea.) > [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 08:38:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968FF106566C; Thu, 24 Jun 2010 08:38:43 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E7F1D8FC08; Thu, 24 Jun 2010 08:38:42 +0000 (UTC) Received: by fxm7 with SMTP id 7so4224021fxm.13 for ; Thu, 24 Jun 2010 01:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=ho6qVI2+3uWqYx5NAlOR2f6c+yRbWbK6p9vpCQ5BSs8=; b=kAsArPprJi2AgSVV5y7pp+kc55oOCoXSaCmr7mabXuXuP9KJkX8tJkvY4Xc4yuhpuC T86fF6Q1oA6POfqfuyIqcweSaL/nEpnY6bhxfUFCT/Qbg6tSACFx8ChxxOm5MB2vfVBv Eh52K8pYmSk2HEdkDrVYtTXeTqRGW3Uhg6LsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=PauUETJ7LYXYpAAfdeUSBFFYMvxI29n80aX0//4iWIJilWCog25oM3nGBiqsn/YwA8 XNqsRFaMPrhNqnK5jvZEzvSx9PTOegQt+6P32cEZ4qeiJzKCIDnJ58bliSGdp59TcqWO wi398KxvUtH9oA9XUb1SYtWDXxxT0mKpCZzuA= Received: by 10.87.2.15 with SMTP id e15mr14897944fgi.23.1277368721734; Thu, 24 Jun 2010 01:38:41 -0700 (PDT) Received: from ernst.jennejohn.org (p578E35A0.dip.t-dialin.net [87.142.53.160]) by mx.google.com with ESMTPS id k29sm14900412fkk.45.2010.06.24.01.38.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 01:38:41 -0700 (PDT) Date: Thu, 24 Jun 2010 10:38:39 +0200 From: Gary Jennejohn To: Alban Hertroys Message-ID: <20100624103839.56d77563@ernst.jennejohn.org> In-Reply-To: <6E6E5D74-018C-4E65-80BD-BC9E5A71D4F8@solfertje.student.utwente.nl> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <6E6E5D74-018C-4E65-80BD-BC9E5A71D4F8@solfertje.student.utwente.nl> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 08:38:43 -0000 On Thu, 24 Jun 2010 10:30:26 +0200 Alban Hertroys wrote: > On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: > > > On Wed, 23 Jun 2010 18:15:09 -0700 > > Ted Faber wrote: > > > >> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr > >> commands from cupsd, though it's evidently a bit of a dangerous idea.) > >> > > [trimmed Cc] > > > > I use cupsd and have these settings to get around using the base system > > lp stuff: > > > > in /etc/src.conf - WITHOUT_LPR=yes > > > > and these symbolic links in /usr/bin > > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> /usr/local/bin/lp > > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> /usr/local/bin/lpq > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> /usr/local/bin/lpr > > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> /usr/local/bin/lprm > > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> /usr/local/bin/lpstat > > > > and /usr/bin is _before_ /usr/local/bin in my PATH. > > > Wouldn't it be easier to alias those commands instead of physically replacing them? > In my .tcshrc I have: > > alias lp /usr/local/bin/lp > alias lpq /usr/local/bin/lpq > alias lpr /usr/local/bin/lpr > alias lprm /usr/local/bin/lprm > > I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. > That's a valid option, of course. My thought was that the base lp isn't being installed anyway so it's just as simple to use symbolic links. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 08:40:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A65C21065686; Thu, 24 Jun 2010 08:40:02 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id F3EBB8FC17; Thu, 24 Jun 2010 08:40:01 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1410655fgb.13 for ; Thu, 24 Jun 2010 01:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rI+CN0Xvf0lLktdVKBc1hEm21c0Gd2+laUl3GG2tf9M=; b=mX49cMipIqU+uBQQj3CY7k/nzzlUJsRH+9gJ01/m5tXOqNH3ITEqroF0xU05vEH3SN +XyS2bQjAtCwDc9STYYJLT8+yPd0jgCBRxpuAMGvrnmCnRhG5n+Qn4gEQ+xzNfPuNLt8 cARCwFtmJ05MvT6quUTC4Xr6okEvA/dqeV67o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OJSQRCJ7VOh8iDSa0JDfrWnR7yXrlAqtFOexgh2pBgfApdYx3iHNROjntHNt+MiMGp WFHTDjxViG+eMrHJO3giOhEaUGTmhhPPieWzmIpxap9wkphsk8AiDVKzdvjB7LLnvKOn AgWqYPdFk6fHZxyL0wvRoTl2o2kA5SAXwKUsw= MIME-Version: 1.0 Received: by 10.239.192.74 with SMTP id d10mr685595hbi.74.1277368800631; Thu, 24 Jun 2010 01:40:00 -0700 (PDT) Received: by 10.239.185.1 with HTTP; Thu, 24 Jun 2010 01:40:00 -0700 (PDT) In-Reply-To: <20100624092337.6bed1f45@ernst.jennejohn.org> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> Date: Thu, 24 Jun 2010 09:40:00 +0100 Message-ID: From: Tom Evans To: gljennjohn@googlemail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 08:40:02 -0000 On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn wrote: > On Wed, 23 Jun 2010 18:15:09 -0700 > Ted Faber wrote: > >> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr >> commands from cupsd, though it's evidently a bit of a dangerous idea.) >> > [trimmed Cc] > > I use cupsd and have these settings to get around using the base system > lp stuff: > > in /etc/src.conf - WITHOUT_LPR=3Dyes > > and these symbolic links in /usr/bin > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A017 Mar 18 =C2=A02= 009 /usr/bin/lp -> /usr/local/bin/lp > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A024 Mar 18 =C2=A02= 009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A018 Mar 18 =C2=A02= 009 /usr/bin/lpq -> /usr/local/bin/lpq > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A018 Mar 18 =C2=A02= 009 /usr/bin/lpr -> /usr/local/bin/lpr > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A019 Mar 18 =C2=A02= 009 /usr/bin/lprm -> /usr/local/bin/lprm > lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A021 Mar 18 =C2=A02= 009 /usr/bin/lpstat -> /usr/local/bin/lpstat > > and /usr/bin is _before_ /usr/local/bin in my PATH. > > =C2=A0--- > Gary Jennejohn I also have this in make.conf: CUPS_OVERWRITE_BASE=3Dyes WITHOUT_LPR=3Dyes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 08:51:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89790106564A; Thu, 24 Jun 2010 08:51:09 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 45A168FC18; Thu, 24 Jun 2010 08:51:08 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3E9D11FFC33; Thu, 24 Jun 2010 08:51:08 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 6D46F845D8; Thu, 24 Jun 2010 10:48:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <4C222AED.2070802@icyb.net.ua> Date: Thu, 24 Jun 2010 10:48:57 +0200 In-Reply-To: <4C222AED.2070802@icyb.net.ua> (Andriy Gapon's message of "Wed, 23 Jun 2010 18:40:29 +0300") Message-ID: <86zkykak92.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ryan Stone , Hans Petter Selasky Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 08:51:09 -0000 Andriy Gapon writes: > Yes, you are absolutely correct. This comes from the fact that amd64 use= s simple > objects files (aka .o) as kernel modules and i386 uses full-blow dso. The obvious question is: since, as I understand, amd64's solution is superior, what would it take to switch to .o on other platforms? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 09:32:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D93C9106564A; Thu, 24 Jun 2010 09:32:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3958FC13; Thu, 24 Jun 2010 09:32:55 +0000 (UTC) Received: by fxm7 with SMTP id 7so4270498fxm.13 for ; Thu, 24 Jun 2010 02:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YWYDR/Btt1npoaO286toFqRz2vPujAfzeJ7K0KfP4AE=; b=IbHnv9cH1eMoc2cejlj7Oy8a5K0eJMEiKdodbouYv4pKXht8mw8feNyA12DzdNz+S4 umcuiqrbzeScYxpBVbMIrHeRf9+/m4+Vwlbsab0ZzKyuAKrCz08VIGNOBYtc+E8WMy1i P0sXfBE/E5kJRWIfC6ACe8skLgCseHgZMNm5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Zyf2c21M3n41lHV4oXbVi4M+9bc5OsgWb1UNb7m7B62kAwTc7NF+RL1YXkMUYIixrm cmLndmCmRcyhFauCpbdaNPXxn4O9CYK7eeAdYbJNx9oIzST2S1wom6umrH2q/aPRuXrG Xa+oVSCVf4+ASOuxAuJcVqCjzkcHAWbPiLnXM= MIME-Version: 1.0 Received: by 10.239.189.133 with SMTP id t5mr663989hbh.4.1277371974985; Thu, 24 Jun 2010 02:32:54 -0700 (PDT) Received: by 10.239.185.1 with HTTP; Thu, 24 Jun 2010 02:32:54 -0700 (PDT) In-Reply-To: <20100624092148.GA6948@duncan.reilly.home> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> Date: Thu, 24 Jun 2010 10:32:54 +0100 Message-ID: From: Tom Evans To: Andrew Reilly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:32:57 -0000 On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly wr= ote: > On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: >> in /etc/src.conf - WITHOUT_LPR=3Dyes >> >> and these symbolic links in /usr/bin >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A017 Mar 18 =C2=A0= 2009 /usr/bin/lp -> /usr/local/bin/lp >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A024 Mar 18 =C2=A0= 2009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A018 Mar 18 =C2=A0= 2009 /usr/bin/lpq -> /usr/local/bin/lpq >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A018 Mar 18 =C2=A0= 2009 /usr/bin/lpr -> /usr/local/bin/lpr >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A019 Mar 18 =C2=A0= 2009 /usr/bin/lprm -> /usr/local/bin/lprm >> lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A021 Mar 18 =C2=A0= 2009 /usr/bin/lpstat -> /usr/local/bin/lpstat >> >> and /usr/bin is _before_ /usr/local/bin in my PATH. > > Since you have /usr/local/bin in your path, why bother with > the symlinks at all? =C2=A0Your shell will find them in their new > locations just fine. =C2=A0You'll want to remove the old ones from > /usr/bin, but make delete-old will probably do that nicely > anyway. > > Cheers, > > -- > Andrew make delete-old removes old deprecated files, not files that weren't built because of src.conf options. It definitely will not remove the lpr binaries from /usr/bin if they exist there. There already is a proper solution for this: if you want to have LPR from CUPS, and don't want to use LPR from base, then you set these settings in make.conf: CUPS_OVERWRITE_BASE=3Dyes WITHOUT_LPR=3Dyes With these, lpr in base will not be built, and print/cups-base will deactivate any base system lpr binaries that are installed. It's documented in the FreeBSD CUPS article here: http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORT= S-KNOBS Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 09:45:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6250E106564A for ; Thu, 24 Jun 2010 09:45:52 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 9451C8FC21 for ; Thu, 24 Jun 2010 09:45:51 +0000 (UTC) Received: (qmail 87398 invoked from network); 24 Jun 2010 09:45:50 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 24 Jun 2010 09:45:50 -0000 Message-ID: <4C23294E.1050100@FreeBSD.org> Date: Thu, 24 Jun 2010 11:45:50 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Tom Evans References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Andrew Reilly Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:45:52 -0000 Tom Evans ha scritto: > make delete-old removes old deprecated files, not files that weren't > built because of src.conf options. I think you are wrong: http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 -- Alex Dupre From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 09:59:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E421106564A; Thu, 24 Jun 2010 09:59:27 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 6F57B8FC0A; Thu, 24 Jun 2010 09:59:26 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1435620fgb.13 for ; Thu, 24 Jun 2010 02:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OETNN9oAMS9L6PAu25StahjezZCuzdaQv/FKCxxjyUg=; b=eFgQBlHICak79e+h9RI9SP2cy9Pszv/TQI+Ed6ygJAomw/izIW2HEzohhgTFwEJzj4 z1vL2+ZXU3CbJ6qU2cvDwL0wYlDBdfHYKz82pwAvjxJ/olRRFwecUaGMQUf0irTkdUHb 9e0Pdo5g0c2WbIrxrm7spU4Kw/O7soxjXIKGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WfNFx8MIgoAqL6I6RLkhNfW9y3OabvLwpj4lvEOW3dWoK0+KYIf7n/pqnh4rOzRl95 R8mMoR7bis3NxFPsnsZoOMtChfJ9/lxTDt+StXd8R+a+xHAYdprX8aFkseehfHfi4jaM +WeVmV9dzxyPQzkdthnC5+co68tOdvCWBIMeQ= MIME-Version: 1.0 Received: by 10.239.168.68 with SMTP id j4mr611820hbe.187.1277373565138; Thu, 24 Jun 2010 02:59:25 -0700 (PDT) Received: by 10.239.185.1 with HTTP; Thu, 24 Jun 2010 02:59:25 -0700 (PDT) In-Reply-To: <4C23294E.1050100@FreeBSD.org> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> <4C23294E.1050100@FreeBSD.org> Date: Thu, 24 Jun 2010 10:59:25 +0100 Message-ID: From: Tom Evans To: Alex Dupre Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Andrew Reilly Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:59:27 -0000 On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre wrote: > Tom Evans ha scritto: >> make delete-old removes old deprecated files, not files that weren't >> built because of src.conf options. > > I think you are wrong: > http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 > > -- > Alex Dupre > Meh, OK. It didn't used to, there was a discussion about this about 6 months ago, and yes, check the history of that file. This support was added in February, nothing in /usr/src/UPDATING about it.. Still, besides the point. There is one supported way to get cups-base lpr used instead of base lpr, and it's got not much to do with 'make delete-old'. http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 08:49:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B0E106566B for ; Thu, 24 Jun 2010 08:49:06 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 32DFE8FC0C for ; Thu, 24 Jun 2010 08:49:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id DFADE8065 for ; Thu, 24 Jun 2010 10:30:48 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 591D78061; Thu, 24 Jun 2010 10:30:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: <20100624092337.6bed1f45@ernst.jennejohn.org> Date: Thu, 24 Jun 2010 10:30:26 +0200 Content-Transfer-Encoding: 8bit Message-Id: <6E6E5D74-018C-4E65-80BD-BC9E5A71D4F8@solfertje.student.utwente.nl> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> To: gljennjohn@googlemail.com X-Mailer: Apple Mail (2.1081) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jun 24 10:30:48 2010 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 1111,4c2317b8286214077543485 X-DSPAM-Factors: 27, References*<201006230852.26536.hselasky, 0.40000, using+the, 0.40000, /usr/local/bin, 0.40000, From*Alban, 0.40000, 09+0700, 0.40000, system+>, 0.40000, References*c2i.net>+<4C21B170.2030903, 0.40000, Subject*FreeBSD+8.1, 0.40000, Mime-Version*Message, 0.40000, 18+Mar, 0.40000, 18+Mar, 0.40000, an, 0.40000, Cc*isi.edu>, 0.40000, from, 0.40000, I+guess, 0.40000, easier, 0.40000, of, 0.40000, of, 0.40000, References*icyb.net.ua>, 0.40000, References*icyb.net.ua>, 0.40000, though+it's, 0.40000, Message-Id*80BD, 0.40000, Subject*RC1+(solved)], 0.40000, Received*ESMTP, 0.40000, system+(7, 0.40000, them?, 0.40000, preceeds, 0.40000 X-Mailman-Approved-At: Thu, 24 Jun 2010 11:06:29 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 08:49:06 -0000 On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: > On Wed, 23 Jun 2010 18:15:09 -0700 > Ted Faber wrote: > >> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr >> commands from cupsd, though it's evidently a bit of a dangerous idea.) >> > [trimmed Cc] > > I use cupsd and have these settings to get around using the base system > lp stuff: > > in /etc/src.conf - WITHOUT_LPR=yes > > and these symbolic links in /usr/bin > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> /usr/local/bin/lp > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> /usr/local/bin/lpq > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> /usr/local/bin/lpr > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> /usr/local/bin/lprm > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> /usr/local/bin/lpstat > > and /usr/bin is _before_ /usr/local/bin in my PATH. Wouldn't it be easier to alias those commands instead of physically replacing them? In my .tcshrc I have: alias lp /usr/local/bin/lp alias lpq /usr/local/bin/lpq alias lpr /usr/local/bin/lpr alias lprm /usr/local/bin/lprm I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:1111,4c2317b8286214077543485! From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 11:18:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F401065674 for ; Thu, 24 Jun 2010 11:18:53 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id E72658FC1A for ; Thu, 24 Jun 2010 11:18:52 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20100624092149.XUCB12312.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Thu, 24 Jun 2010 09:21:49 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100624092148.DWEN2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Thu, 24 Jun 2010 09:21:48 +0000 Date: Thu, 24 Jun 2010 19:21:48 +1000 From: Andrew Reilly To: Gary Jennejohn Message-ID: <20100624092148.GA6948@duncan.reilly.home> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100624092337.6bed1f45@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Thu, 24 Jun 2010 09:21:48 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090208.4C2323AD.0081,ss=1,fgs=0 X-SIH-MSG-ID: qR40ENL9TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHK+ZRu8u4xDxIJhqMNGMhaajtTY3Rs9mK X-Mailman-Approved-At: Thu, 24 Jun 2010 12:01:54 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:18:53 -0000 On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: > in /etc/src.conf - WITHOUT_LPR=yes > > and these symbolic links in /usr/bin > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> /usr/local/bin/lp > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> /usr/local/bin/lpoptions > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> /usr/local/bin/lpq > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> /usr/local/bin/lpr > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> /usr/local/bin/lprm > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> /usr/local/bin/lpstat > > and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 13:21:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5B21065675; Thu, 24 Jun 2010 13:21:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2001:4dd0:ff41::b23f:aa]) by mx1.freebsd.org (Postfix) with ESMTP id D8A7F8FC0A; Thu, 24 Jun 2010 13:21:54 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 257A32A28CD4; Thu, 24 Jun 2010 15:21:54 +0200 (CEST) Date: Thu, 24 Jun 2010 15:21:54 +0200 From: Ed Schouten To: Andrew Reilly Message-ID: <20100624132154.GT2179@hoeg.nl> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2tWkrNKppd65XSnD" Content-Disposition: inline In-Reply-To: <20100624092148.GA6948@duncan.reilly.home> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 13:21:55 -0000 --2tWkrNKppd65XSnD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andrew Reilly wrote: > On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: > > in /etc/src.conf - WITHOUT_LPR=3Dyes > >=20 > > and these symbolic links in /usr/bin > > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> /usr/loca= l/bin/lp > > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> /u= sr/local/bin/lpoptions > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> /usr/loc= al/bin/lpq > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> /usr/loc= al/bin/lpr > > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> /usr/lo= cal/bin/lprm > > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> /usr/= local/bin/lpstat > >=20 > > and /usr/bin is _before_ /usr/local/bin in my PATH. >=20 > Since you have /usr/local/bin in your path, why bother with > the symlinks at all? Your shell will find them in their new > locations just fine. You'll want to remove the old ones from > /usr/bin, but make delete-old will probably do that nicely > anyway. In theory, yes. In practice, no. Just for fun, remove your /usr/sbin/sendmail while having Postfix's /usr/local/sbin/sendmail installed. It simply won't work. If I remember correctly, you won't even receive the periodic(8) emails. Nowadays it's probably better, but I remember in the old days GNOME would always print through /usr/bin/lpr, even when CUPS is installed. --=20 Ed Schouten WWW: http://80386.nl/ --2tWkrNKppd65XSnD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkwjW/IACgkQ52SDGA2eCwWhnwCeOZsoyNCKkpXCQNkmHuIYDbdo UpMAnRevo7UfWpC6p3puyYUqsKbAYZGE =lUUd -----END PGP SIGNATURE----- --2tWkrNKppd65XSnD-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 13:45:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7857106568C; Thu, 24 Jun 2010 13:45:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2001:4dd0:ff41::b23f:aa]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6188FC1D; Thu, 24 Jun 2010 13:45:51 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id AA91B2A28CD4; Thu, 24 Jun 2010 15:45:50 +0200 (CEST) Date: Thu, 24 Jun 2010 15:45:50 +0200 From: Ed Schouten To: Mike Meyer Message-ID: <20100624134550.GU2179@hoeg.nl> References: <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> <20100624132154.GT2179@hoeg.nl> <20100624094408.68d13c41@bhuda.mired.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKOZ/JADkehwFk9I" Content-Disposition: inline In-Reply-To: <20100624094408.68d13c41@bhuda.mired.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Andrew Reilly Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 13:45:51 -0000 --HKOZ/JADkehwFk9I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Mike Meyer wrote: > Maybe it's time for /usr/sbin/lpwrapper, to do the same thing for > print systems? In my opinion, we should just rename mailwrapper to whateverwrapper and list the lpr programs in there as well. --=20 Ed Schouten WWW: http://80386.nl/ --HKOZ/JADkehwFk9I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkwjYY4ACgkQ52SDGA2eCwVbWQCeP8v27W35CiH6navZhCjk4DZs VXkAmgNZ7hANskD+PO/r96YKxgslQdFz =8jPV -----END PGP SIGNATURE----- --HKOZ/JADkehwFk9I-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 13:59:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E264A1065670; Thu, 24 Jun 2010 13:59:08 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE438FC16; Thu, 24 Jun 2010 13:59:08 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 89AA41FFC33; Thu, 24 Jun 2010 13:59:07 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B266B8452D; Thu, 24 Jun 2010 15:56:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ed Schouten References: <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> <20100624132154.GT2179@hoeg.nl> <20100624094408.68d13c41@bhuda.mired.org> <20100624134550.GU2179@hoeg.nl> Date: Thu, 24 Jun 2010 15:56:56 +0200 In-Reply-To: <20100624134550.GU2179@hoeg.nl> (Ed Schouten's message of "Thu, 24 Jun 2010 15:45:50 +0200") Message-ID: <86pqzg8rfb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Mike Meyer , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 13:59:09 -0000 Ed Schouten writes: > In my opinion, we should just rename mailwrapper to whateverwrapper > and list the lpr programs in there as well. Take a look at /etc/alternatives in any Debian-based Linux distro... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 15:30:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA0EB106567B; Thu, 24 Jun 2010 15:30:18 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8AEAC8FC14; Thu, 24 Jun 2010 15:30:18 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5OFTv9a046629; Thu, 24 Jun 2010 08:30:17 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5OFTvCM046628; Thu, 24 Jun 2010 08:29:57 -0700 (PDT) (envelope-from faber) Date: Thu, 24 Jun 2010 08:29:57 -0700 From: Ted Faber To: Tom Evans Message-ID: <20100624152957.GA46600@zod.isi.edu> References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 15:30:18 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: > I also have this in make.conf: > CUPS_OVERWRITE_BASE=3Dyes > WITHOUT_LPR=3Dyes >=20 > which print/cups-base uses to do make any lpr related binaries in > /usr/bin non-executable, so they are skipped over and the cups > specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just > stops LPR being built by buildworld. The clear winner, and one I was unaware of. Thanks, Tom. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwjefUACgkQaUz3f+Zf+XtTkACffwzLDDbJSJDS9rCVq9tokT+j PLwAn2VYDIHaPus7s7w/6wphOSWPbbjZ =+UKw -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 15:46:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4724106566B for ; Thu, 24 Jun 2010 15:46:23 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from praag.hoster.bg (praag.hoster.bg [77.77.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 552608FC08 for ; Thu, 24 Jun 2010 15:46:22 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by praag.hoster.bg (Postfix) with ESMTP id 51F428CA5F for ; Thu, 24 Jun 2010 18:46:20 +0300 (EEST) Received: from straylight.ringlet.net (office.hoster.bg [78.90.131.77]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 2F4855C53A for ; Thu, 24 Jun 2010 18:46:17 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 41600c by straylight.ringlet.net (DragonFly Mail Agent) Thu, 24 Jun 2010 18:46:10 +0300 Date: Thu, 24 Jun 2010 18:46:10 +0300 From: Peter Pentchev To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20100624154610.GC18189@straylight.ringlet.net> Mail-Followup-To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , Ed Schouten , freebsd-hackers@freebsd.org, Mike Meyer , Andrew Reilly , freebsd-current@freebsd.org References: <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624092148.GA6948@duncan.reilly.home> <20100624132154.GT2179@hoeg.nl> <20100624094408.68d13c41@bhuda.mired.org> <20100624134550.GU2179@hoeg.nl> <86pqzg8rfb.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline In-Reply-To: <86pqzg8rfb.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 2F4855C53A.7E2A1 X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-hackers@freebsd.org X-Spam-Status: No Cc: Ed Schouten , Mike Meyer , freebsd-current@freebsd.org, Andrew Reilly , freebsd-hackers@freebsd.org Subject: Re: using cupsd instead of base lpr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 15:46:24 -0000 --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 24, 2010 at 03:56:56PM +0200, Dag-Erling Sm=C3=B8rgrav wrote: > Ed Schouten writes: > > In my opinion, we should just rename mailwrapper to whateverwrapper > > and list the lpr programs in there as well. >=20 > Take a look at /etc/alternatives in any Debian-based Linux distro... Yeah, that's actually something I've long wondered about implementing; shouldn't be too hard, really. Never found the tuits, though :) For those who don't know what the idea is: /usr/bin/ftp is a symlink to /etc/alternatives/ftp, which in its turn is a symlink to /usr/bin/tnftp. The /etc/alternatives/ links are maintained by the update-alternatives utility which knows about priorities, defaults, slave symlinks (e.g. if the ftp(1) utility's symlink changes, it would be best to also change the ftp.1.gz manpage symlink, wouldn't it?), and a whole lot more. =46rom a user's standpoint, all you have to do is install a package that declares a higher-priority alternative, and update-alternatives switches the symlink behind the scenes (unless you have explicitly specified one of the choices). If you don't like that, run update-alternatives by hand, and your choice is honored even if later a package with an even higher priority is installed. G'luck, Peter --=20 Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJMI33CAAoJEGUe77AlJ98TFusP/iN2zNk/bj5DJGwaQKgYfEqq oaLi6cUd/5P5bJPNm+8freXHgU9Hg5VangGOYGyvyXhGDZ9nthCEU+rga1SA5IYR y97XooViSQGS+x8BqqXKuBG/zv4TZ7y4zZOWb6Kaz3QwiwdyG1GO1/OLqG93Sru/ 1i0eWK+oOZUhuQavWu+e83DiDUW0DT3etzTB+GumkXt35z8jAC++xDXZR1IB2bBl 29pLunPrLWz2/u9Pax9EPVUNnEuosgDYAP7qHLjohk+zgClCDQSb23QfFJ50sGE6 SXeEcSQpLIp8BSnffdkGnqBJRpc8g6EcP/KjKf2imHMZFzgaJkM4dLL3cQSx2U2b XR6qemE7kEfeu6zRc7dSOF93+/EZ/siFieLK8nbWGfjVks9kwa9gvIRXS5KTPfHr 8PsB4WKNbpoIUEBTILog7bCZjNKO2klwXT3VbJo0F5UNO8LUab3ZK7tqkeLwEp3j RUeUVkPWdmSi/qhh22E2fECLE6iJgFsu75HeHq6O/F+DvF3ey7TYi5W9EO6m2YYO Tz20U0/tQhXqNi540Du6GoOHKP4XGl5CuD5Kn6/W3MnEZW6DAiSq5OuWDAve5vnh wIJHz40tVCxQEFCyykxsCv3zi7kTnDiEWD33N2HzGuo6Z7fdrZktAW8fa4Q/eKaN S7zFn/85EgtzJotFIxjS =o9DP -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 24 16:54:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 813C31065672; Thu, 24 Jun 2010 16:54:46 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 445E58FC0C; Thu, 24 Jun 2010 16:54:46 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id o5OGsjhO047921; Thu, 24 Jun 2010 09:54:45 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.4/8.14.4/Submit) id o5OGsj0V047920; Thu, 24 Jun 2010 09:54:45 -0700 (PDT) (envelope-from faber) Date: Thu, 24 Jun 2010 09:54:45 -0700 From: Ted Faber To: Tom Evans Message-ID: <20100624165445.GF46600@zod.isi.edu> References: <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624152957.GA46600@zod.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IvGM3kKqwtniy32b" Content-Disposition: inline In-Reply-To: <20100624152957.GA46600@zod.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:54:46 -0000 --IvGM3kKqwtniy32b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote: > On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: > > I also have this in make.conf: > > CUPS_OVERWRITE_BASE=3Dyes > > WITHOUT_LPR=3Dyes > >=20 > > which print/cups-base uses to do make any lpr related binaries in > > /usr/bin non-executable, so they are skipped over and the cups > > specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just > > stops LPR being built by buildworld. >=20 > The clear winner, and one I was unaware of. >=20 > Thanks, Tom. CUPS_OVERWRITE_BASE seems to do an odd thing. It doesn't install the cups binaries in /usr/bin, but it does do a chmod 0000 on everything it replaces in /usr/bin . For example praxis:~$ ls -l /usr/bin/lpr -r-sr-sr-x 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr # portupgrade -f cups-base-1.4.3 praxis:~$ ls -l /usr/bin/lpr ---------- 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr I'll still use it, but interesting behavior. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --IvGM3kKqwtniy32b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwjjdUACgkQaUz3f+Zf+Xvc8ACg1aGz3iIceO379NTqQzlvwXCO QvAAoIrqfiDzNbX2wSfG8eNfzCSJlyt4 =IMWC -----END PGP SIGNATURE----- --IvGM3kKqwtniy32b-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 08:46:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D2F1065675; Fri, 25 Jun 2010 08:46:12 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 16B998FC17; Fri, 25 Jun 2010 08:46:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA20190; Fri, 25 Jun 2010 11:46:09 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OS4Y5-000C5E-6S; Fri, 25 Jun 2010 11:46:09 +0300 Message-ID: <4C246CD0.3020606@freebsd.org> Date: Fri, 25 Jun 2010 11:46:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , Navdeep Parhar , Peter Wemm Subject: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 08:46:12 -0000 Proposed patch skips zero sized sections without going into trouble of allocating section entry (progtab), doing zero-sized memory allocs and copies. I observe that sometimes zero-sized set_pcpu sections are produced in module objects, maybe when a module doesn't create any per cpu data of its one, but references external pcpu data. Not sure. Main goal of this patch is to play nice with external debugging tools (e.g. kgdb) which ignore zero-sized sections outright. Current code effectively ignores but may apply their alignment to the next non-zero section if its required alignment is smaller. So the patch should get rid of that side effect as well as do some very tiny resource conservation. This work is based on np@'s investigation and original patch: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html diff --git a/sys/boot/common/load_elf_obj.c b/sys/boot/common/load_elf_obj.c index 4b3aaea..6f3b349 100644 --- a/sys/boot/common/load_elf_obj.c +++ b/sys/boot/common/load_elf_obj.c @@ -221,6 +221,8 @@ __elfN(obj_loadimage)(struct preloaded_file *fp, elf_file_t ef, u_int64_t off) for (i = 0; i < hdr->e_shnum; i++) shdr[i].sh_addr = 0; for (i = 0; i < hdr->e_shnum; i++) { + if (shdr[i].sh_size == 0) + continue; switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c index a337fd0..b0df57d 100644 --- a/sys/kern/link_elf_obj.c +++ b/sys/kern/link_elf_obj.c @@ -555,6 +555,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, symtabindex = -1; symstrindex = -1; for (i = 0; i < hdr->e_shnum; i++) { + if (shdr[i].sh_size == 0) + continue; switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: @@ -677,6 +679,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, /* Size up code/data(progbits) and bss(nobits). */ alignmask = 0; for (i = 0; i < hdr->e_shnum; i++) { + if (shdr[i].sh_size == 0) + continue; switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: @@ -737,6 +741,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, ra = 0; alignmask = 0; for (i = 0; i < hdr->e_shnum; i++) { + if (shdr[i].sh_size == 0) + continue; switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 09:03:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD31A1065670; Fri, 25 Jun 2010 09:03:44 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 077128FC1D; Fri, 25 Jun 2010 09:03:43 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so24733eya.9 for ; Fri, 25 Jun 2010 02:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=ElNIEfTefmijEC+63lM1FK7XvUTM/ay0STMGI+/t3PU=; b=mHUksa4OImj2Z52hfH8IVnbXzqtjSG3i+M7nFuaXYzmVQFdlIBAsh+1ZzM2yXEMjCL S9anukIedCrti+1qCr6IrKGduLvbBFFdXj6SEuSYUtVaDPOpRLhBi+1l1VcRMHHiMDvQ XFf4Y8hNPPc9UYf/GmkxpeqByHQSLH1rPh+go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=p7GfP4eyL2Tq0VbsdcRA/8tzkG61t0NfFgjKDCC2It9RgOM08NSOIhBQgX26BQBb0e muThGKLovCwmzMuAKp+wpPHFp3bQ8CReUTcj3k4XBwZq1rSy4KdQmuNZwB5vh6na+/ON Dj67Ipkb8ylLfB6cfM0HfrEEEnVOyWhcwGXqE= Received: by 10.102.13.11 with SMTP id 11mr85852mum.74.1277456622671; Fri, 25 Jun 2010 02:03:42 -0700 (PDT) Received: from ernst.jennejohn.org (p578E2768.dip.t-dialin.net [87.142.39.104]) by mx.google.com with ESMTPS id j10sm13264298muh.58.2010.06.25.02.03.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 02:03:41 -0700 (PDT) Date: Fri, 25 Jun 2010 11:03:39 +0200 From: Gary Jennejohn To: Ted Faber Message-ID: <20100625110339.398a5006@ernst.jennejohn.org> In-Reply-To: <20100624165445.GF46600@zod.isi.edu> References: <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624152957.GA46600@zod.isi.edu> <20100624165445.GF46600@zod.isi.edu> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tom Evans , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 09:03:44 -0000 On Thu, 24 Jun 2010 09:54:45 -0700 Ted Faber wrote: > On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote: > > On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: > > > I also have this in make.conf: > > > CUPS_OVERWRITE_BASE=yes > > > WITHOUT_LPR=yes > > > > > > which print/cups-base uses to do make any lpr related binaries in > > > /usr/bin non-executable, so they are skipped over and the cups > > > specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just > > > stops LPR being built by buildworld. > > > > The clear winner, and one I was unaware of. > > > > Thanks, Tom. > > CUPS_OVERWRITE_BASE seems to do an odd thing. It doesn't install the > cups binaries in /usr/bin, but it does do a chmod 0000 on everything it > replaces in /usr/bin . For example > > praxis:~$ ls -l /usr/bin/lpr > -r-sr-sr-x 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr > # portupgrade -f cups-base-1.4.3 > praxis:~$ ls -l /usr/bin/lpr > ---------- 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr > > I'll still use it, but interesting behavior. > IMO if you're going to make the binaries in base non-executable you might just as well delete them. But CUPS_OVERWRITE_BASE does have the advantage that it works without (active) user intervention. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 09:28:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565961065670; Fri, 25 Jun 2010 09:28:09 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9169B8FC13; Fri, 25 Jun 2010 09:28:07 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA21258; Fri, 25 Jun 2010 12:28:04 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OS5Cc-000C90-Ny; Fri, 25 Jun 2010 12:28:02 +0300 Message-ID: <4C2476A1.1080307@freebsd.org> Date: Fri, 25 Jun 2010 12:28:01 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> <4C1FDAF9.3080808@freebsd.org> <4C208096.3030602@freebsd.org> In-Reply-To: <4C208096.3030602@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Navdeep Parhar Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 09:28:09 -0000 Here's a patch that is supposed to do the right thing for dtrace. Perhaps I should have put the new code under __amd64__, but I decided to go more "generic" and check for module's ELF type (ET_REL). Reviews and testing are welcome! diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h index 6bcc5bc..a712d24 100644 --- a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h @@ -137,6 +137,7 @@ typedef struct dt_module { dt_idhash_t *dm_extern; /* external symbol definitions */ #if !defined(sun) caddr_t dm_reloc_offset; /* Symbol relocation offset. */ + uintptr_t *dm_sec_offsets; #endif } dt_module_t; diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c index af17501..d33fb95 100644 --- a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c @@ -83,6 +83,14 @@ dt_module_syminit32(dt_module_t *dmp) uint_t i, n = dmp->dm_nsymelems; uint_t asrsv = 0; +#if defined(__FreeBSD__) + GElf_Ehdr ehdr; + int is_elf_obj; + + gelf_getehdr(dmp->dm_elf, &ehdr); + is_elf_obj = (ehdr.e_type == ET_REL); +#endif + for (i = 0; i < n; i++, sym++) { const char *name = base + sym->st_name; uchar_t type = ELF32_ST_TYPE(sym->st_info); @@ -97,8 +105,12 @@ dt_module_syminit32(dt_module_t *dmp) (ELF32_ST_BIND(sym->st_info) != STB_LOCAL || sym->st_size)) { asrsv++; /* reserve space in the address map */ -#if !defined(sun) +#if defined(__FreeBSD__) sym->st_value += (Elf_Addr) dmp->dm_reloc_offset; + if (is_elf_obj && sym->st_shndx != SHN_UNDEF && + sym->st_shndx < ehdr.e_shnum) + sym->st_value += + dmp->dm_sec_offsets[sym->st_shndx]; #endif } @@ -117,6 +129,14 @@ dt_module_syminit64(dt_module_t *dmp) uint_t i, n = dmp->dm_nsymelems; uint_t asrsv = 0; +#if defined(__FreeBSD__) + GElf_Ehdr ehdr; + int is_elf_obj; + + gelf_getehdr(dmp->dm_elf, &ehdr); + is_elf_obj = (ehdr.e_type == ET_REL); +#endif + for (i = 0; i < n; i++, sym++) { const char *name = base + sym->st_name; uchar_t type = ELF64_ST_TYPE(sym->st_info); @@ -130,9 +150,12 @@ dt_module_syminit64(dt_module_t *dmp) if (sym->st_value != 0 && (ELF64_ST_BIND(sym->st_info) != STB_LOCAL || sym->st_size)) { asrsv++; /* reserve space in the address map */ - -#if !defined(sun) +#if defined(__FreeBSD__) sym->st_value += (Elf_Addr) dmp->dm_reloc_offset; + if (is_elf_obj && sym->st_shndx != SHN_UNDEF && + sym->st_shndx < ehdr.e_shnum) + sym->st_value += + dmp->dm_sec_offsets[sym->st_shndx]; #endif } @@ -722,7 +745,12 @@ dt_module_unload(dtrace_hdl_t *dtp, dt_module_t *dmp) free(dmp->dm_asmap); dmp->dm_asmap = NULL; } - +#if defined(__FreeBSD__) + if (dmp->dm_sec_offsets != NULL) { + free(dmp->dm_sec_offsets); + dmp->dm_sec_offsets = NULL; + } +#endif dmp->dm_symfree = 0; dmp->dm_nsymbuckets = 0; dmp->dm_nsymelems = 0; @@ -846,9 +874,12 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat) (void) snprintf(fname, sizeof (fname), "%s/%s/object", OBJFS_ROOT, name); #else + GElf_Ehdr ehdr; GElf_Phdr ph; char name[MAXPATHLEN]; + uintptr_t mapbase, alignmask; int i = 0; + int is_elf_obj; (void) strlcpy(name, k_stat->name, sizeof(name)); (void) strlcpy(fname, k_stat->pathname, sizeof(fname)); @@ -893,7 +924,20 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat) dt_module_destroy(dtp, dmp); return; } - +#if defined(__FreeBSD__) + mapbase = (uintptr_t)k_stat->address; + gelf_getehdr(dmp->dm_elf, &ehdr); + is_elf_obj = (ehdr.e_type == ET_REL); + if (is_elf_obj) { + dmp->dm_sec_offsets = + malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); + if (dmp->dm_sec_offsets == NULL) { + dt_dprintf("failed to allocate memory\n"); + dt_module_destroy(dtp, dmp); + return; + } + } +#endif /* * Iterate over the section headers locating various sections of * interest and use their attributes to flesh out the dt_module_t. @@ -902,7 +946,19 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat) if (gelf_getshdr(sp, &sh) == NULL || sh.sh_type == SHT_NULL || (s = elf_strptr(dmp->dm_elf, shstrs, sh.sh_name)) == NULL) continue; /* skip any malformed sections */ - +#if defined(__FreeBSD__) + if (sh.sh_size == 0) + continue; + if (is_elf_obj && (sh.sh_type == SHT_PROGBITS || + sh.sh_type == SHT_NOBITS)) { + alignmask = sh.sh_addralign - 1; + mapbase += alignmask; + mapbase &= ~alignmask; + sh.sh_addr = mapbase; + dmp->dm_sec_offsets[elf_ndxscn(sp)] = sh.sh_addr; + mapbase += sh.sh_size; + } +#endif if (strcmp(s, ".text") == 0) { dmp->dm_text_size = sh.sh_size; dmp->dm_text_va = sh.sh_addr; @@ -927,6 +983,13 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat) #if defined(sun) dmp->dm_modid = (int)OBJFS_MODID(st.st_ino); #else + /* + * Include .rodata and special sections into .text. + * This depends on default section layout produced by GNU ld + * for ELF objects and libraries: + * [Text][R/O data][R/W data][Dynamic][BSS][Non loadable] + */ + dmp->dm_text_size = dmp->dm_data_va - dmp->dm_text_va; #if defined(__i386__) /* * Find the first load section and figure out the relocation -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 09:46:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B45106566C for ; Fri, 25 Jun 2010 09:46:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5EEBF8FC13 for ; Fri, 25 Jun 2010 09:46:16 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OS5UE-0009U8-LY for freebsd-hackers@freebsd.org; Fri, 25 Jun 2010 12:46:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jun 2010 12:46:14 +0300 From: Daniel Braniss Message-ID: Subject: hg convert stopped working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 09:46:16 -0000 Hi, probably wrong place to ask, but I great minds lurk here :-) I have been mirroing FreeBSD via svn since last summer, svnsync sync file:///cs/svn/freebsd/base then converting to mercurial hg convert ... file:///cs/svn/freebsd/base ${HG_HOME}/bsd/stable/8 ... since I can better track local changes, all worked nice till someone - probably me, while upgrading firefox, screwed up svn - it happens :-) So I upgraded svn, and now my svnsync worked again, but mercurial stopped working, so upgarded mercurial, but it's still not working: Traceback (most recent call last): File "/usr/local/lib/python2.6/site-packages/hgext/convert/hg.py", line 223, in __init__ self.repo = hg.repository(self.ui, path) File "/usr/local/lib/python2.6/site-packages/mercurial/hg.py", line 82, in repository repo = _lookup(path).instance(ui, path, create) File "/usr/local/lib/python2.6/site-packages/mercurial/localrepo.py", line 2223, in instance return localrepository(ui, util.drop_scheme('file', path), create) File "/usr/local/lib/python2.6/site-packages/mercurial/localrepo.py", line 62, in __init__ raise error.RepoError(_("repository %s not found") % path) RepoError: repository /cs/svn/freebsd/base not found but /cs/svn/freebsd/base is ok: ls -lsd /cs/svn/freebsd/base 4 drwxr-xr-x 6 svn svn 4096 Jun 7 2008 /cs/svn/freebsd/base any help will be much appreciated, thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 12:57:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A84CE106566B for ; Fri, 25 Jun 2010 12:57:31 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF498FC16 for ; Fri, 25 Jun 2010 12:57:31 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5PCwO9I063785; Fri, 25 Jun 2010 05:58:25 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C24A7B4.5050301@mahan.org> Date: Fri, 25 Jun 2010 05:57:24 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> In-Reply-To: <86hbkujdto.fsf@ds4.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 12:57:31 -0000 Dag-Erling, I am using option 3 below. I have the following in my shell: amd64-kernel.sh #!/bin/sh trap "exit 1" 1 2 3 15 export SRCROOT=3D`pwd -P` export MAKEOBJDIRPREFIX=3D$SRCROOT/../amd64/obj export SRCCONF=3D$SRCROOT/src.conf # Use our private copy export SECKNOB=3D"-DPRIVATE" KERNCONF=3DTCONF make NO_CLEAN=3Dyes NO_PROFILE=3Dyes NO_MODULES=3Dyes KERNCONF=3D$KERNCON= F buildkernel ||=20 exit 1 =2E.. In the top-level makefile I have the following label: src-kernel: src-kernel-tools cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log If there is a build failure with the kernel, it can be seen in the file 'build_amd64_kernel.log'. However, the top-level make file just continues on to the next label as if no error occurs. The reason we are using shell scripts is because of the environment variables that need to be defined and some other house-keeping stuff that I did not include in the above example. Also, I wanted scripts so the developer could just build individual "groups" without resorting to building everything. Thanks, Patrick Dag-Erling Sm=C3=B8rgrav wrote: > Patrick Mahan writes: >> My issue is that if there is a build failure at any point, the >> status does not seem to be propagated upward. For example, if >> the kernel fails to build due to incorrect code, the script >> -kernel64.sh stops (verifable by examining the logfile), >> however, the make will continue to the next target, src-world, >> and continue building. How do I propagate the status up to the >> top-level make? >=20 > Your shell script needs to exit with a non-zero status if it fails. > There are several ways to do this. For instance, if your shell script > looks like this: >=20 > #!/bin/sh > make TARGET=3Damd64 kernel-toolchain >=20 > you can: >=20 > - prefix "make" with "exec": sh will exec make instead of running it i= n > a subshell, and the exit status will be whatever make returns. >=20 > - add the following line at the bottom: >=20 > exit $? >=20 > which causes the shell script to exit with the same exit status as > the last command it ran, in this case make. >=20 > - append "|| exit 1" to the the "make" command line; this will cause > the script to exit immediately with status 1 if make fails, otherwis= e > it will continue (in case you want to do something else if make > succeeds) >=20 > - wrap the make command line in an if statement, which allows you do > additional work depending on the outcome, and end the failure case > with "exit 1" or similar >=20 > - insert the following line at any point between the shebang and the > make command line: >=20 > set -e >=20 > this will cause sh to terminate the script immediately with a > non-zero exit status if any command after the "set" line fails. >=20 > However, I don't see the point of using shell scripts in the first > place... >=20 > DES From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 13:17:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D2FC1065675 for ; Fri, 25 Jun 2010 13:17:29 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 200148FC14 for ; Fri, 25 Jun 2010 13:17:28 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0951B1FFC33; Fri, 25 Jun 2010 13:17:27 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EDBB68452A; Fri, 25 Jun 2010 15:15:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Patrick Mahan References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> <4C24A7B4.5050301@mahan.org> Date: Fri, 25 Jun 2010 15:15:16 +0200 In-Reply-To: <4C24A7B4.5050301@mahan.org> (Patrick Mahan's message of "Fri, 25 Jun 2010 05:57:24 -0700") Message-ID: <86mxujdziz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 13:17:29 -0000 Patrick Mahan writes: > In the top-level makefile I have the following label: > > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log > > If there is a build failure with the kernel, it can be seen in the > file 'build_amd64_kernel.log'. However, the top-level make file just > continues on to the next label as if no error occurs. Make looks at tee's exit status, not the script's. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 13:30:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F751106566B for ; Fri, 25 Jun 2010 13:30:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 4597C8FC24 for ; Fri, 25 Jun 2010 13:30:58 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id BA5C335A85B; Fri, 25 Jun 2010 15:30:56 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id A984A172DB; Fri, 25 Jun 2010 15:30:56 +0200 (CEST) Date: Fri, 25 Jun 2010 15:30:56 +0200 From: Jilles Tjoelker To: Patrick Mahan Message-ID: <20100625133056.GA97679@stack.nl> References: <4C21A743.6040306@mahan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C21A743.6040306@mahan.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 13:30:58 -0000 On Tue, Jun 22, 2010 at 11:18:43PM -0700, Patrick Mahan wrote: > src-kern-tools: > cd src; ./-kernel-toolchain.sh 2>&1 | tee The pipeline will return the status of 'tee' which is almost always 0. The exit status of the build script is ignored. A simple fix is store the status in a file and refer to that afterwards. Another fix uses a separate file descriptor to pass through the status, like { st=$( { { ./kernel-toolchain.sh 2>&1 3>&- 4>&-; echo $? >&3; } | tee logfile >&4 } 3>&1) } 4>&1 but this is fairly complicated. The issue can be sidestepped entirely by sending the output to a file only; a developer can use tail -f to follow the build if necessary. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 14:18:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D15106566B for ; Fri, 25 Jun 2010 14:18:09 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 168B98FC17 for ; Fri, 25 Jun 2010 14:18:08 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5PEHsSS053531 for ; Fri, 25 Jun 2010 07:17:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:content-type:date:message-id: mime-version:x-mailer:content-transfer-encoding; b=VxHUGCUGk464gvB9R8rpHUnqKGsn9jhHA6IdjBD5WuVpgZ2CmoIMm/wIkIC5OPpt From: Sean Bruno To: freebsd-hackers Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Jun 2010 07:17:54 -0700 Message-ID: <1277475474.2411.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: What is the exected behavior with the NMI button? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 14:18:09 -0000 While trying to get a deadlock sorted out in the GPROF code, I attempted to use this fancy shmancy NMI button on my Dell server. I noted that, not unlike the goggles, it did nothing once the system was deadlocked. I noted that when the system was running normally, an NMI log message would be spewed to the console. What is supposed to happen in these two cases when we toggle the NMI button? Sean From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 14:50:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE3BC1065672; Fri, 25 Jun 2010 14:50:32 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5AA8FC13; Fri, 25 Jun 2010 14:50:31 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5PEmw6i029651; Fri, 25 Jun 2010 07:48:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ypHv3Dp2/3trAc7kPG0+hDqGLWRRPy7I0SawpzFR5CgOBqdwQHxF2CHcsLzSv177 From: Sean Bruno To: "sbruno@freebsd.org" In-Reply-To: <1277475474.2411.4.camel@localhost.localdomain> References: <1277475474.2411.4.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Jun 2010 07:48:58 -0700 Message-ID: <1277477338.2411.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: What is the exected behavior with the NMI button? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 14:50:32 -0000 On Fri, 2010-06-25 at 07:17 -0700, Sean Bruno wrote: > While trying to get a deadlock sorted out in the GPROF code, I attempted > to use this fancy shmancy NMI button on my Dell server. > > I noted that, not unlike the goggles, it did nothing once the system was > deadlocked. I noted that when the system was running normally, an NMI > log message would be spewed to the console. In the event you don't get the goggles reference. http://www.youtube.com/watch?v=OqfOxm_1BE0 Sean From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 16:30:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409C9106564A for ; Fri, 25 Jun 2010 16:30:58 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1C93F8FC08 for ; Fri, 25 Jun 2010 16:30:57 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5PGVqB9064940; Fri, 25 Jun 2010 09:31:56 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C24D9BC.7030008@mahan.org> Date: Fri, 25 Jun 2010 09:30:52 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> <4C24A7B4.5050301@mahan.org> <86mxujdziz.fsf@ds4.des.no> In-Reply-To: <86mxujdziz.fsf@ds4.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:30:58 -0000 Oy vey! Good point! Not something I had considered (but should have). Is there a way to propogate that status through the pipe? I am using 'tee' so that the master build (which invokes the top-level make) can also see the make output. But going back and reading the man page on 'sh' shows me that on a pipline, the status is the status of the *last* command. Maybe I should do this instead? src-kernel: src-kernel-tools cd src; ./amd64-kernel.sh 2>&1 > build_amd64_kernel.log; \ tail -f build_amd64_kernel.log It is not too clear if the status is the last one in a compound command. I will give that a try. Thanks, Patrick Dag-Erling Sm=C3=B8rgrav wrote: > Patrick Mahan writes: >> In the top-level makefile I have the following label: >> >> src-kernel: src-kernel-tools >> cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log >> >> If there is a build failure with the kernel, it can be seen in the >> file 'build_amd64_kernel.log'. However, the top-level make file just >> continues on to the next label as if no error occurs. >=20 > Make looks at tee's exit status, not the script's. >=20 > DES From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 16:35:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47277106564A for ; Fri, 25 Jun 2010 16:35:53 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 22CEA8FC1B for ; Fri, 25 Jun 2010 16:35:52 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5PGaqA4064990; Fri, 25 Jun 2010 09:36:53 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C24DAE7.1020809@mahan.org> Date: Fri, 25 Jun 2010 09:35:51 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Jilles Tjoelker References: <4C21A743.6040306@mahan.org> <20100625133056.GA97679@stack.nl> In-Reply-To: <20100625133056.GA97679@stack.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:35:53 -0000 Jilles, Thanks for the more complicated example. I am always interested in shell hacks like these, especially when they involve interesting uses of file I/O redirection. The tee is there so that the master build package (a perl script) that builds not only my groups sources but other sources as well is required to provide make 'output' for the master build log. How is the status handled on compound commands? ./amd64-kernel.sh 2>&1 > build.log; tail -f build.log would that obscure the exit status of the shell script as well? The man page is not really clear on this. Thanks, Patrick Jilles Tjoelker wrote: > On Tue, Jun 22, 2010 at 11:18:43PM -0700, Patrick Mahan wrote: >> src-kern-tools: >> cd src; ./-kernel-toolchain.sh 2>&1 | tee > > The pipeline will return the status of 'tee' which is almost always 0. > The exit status of the build script is ignored. > > A simple fix is store the status in a file and refer to that afterwards. > Another fix uses a separate file descriptor to pass through the status, > like > { st=$( > { > { ./kernel-toolchain.sh 2>&1 3>&- 4>&-; echo $? >&3; } | tee logfile >&4 > } 3>&1) > } 4>&1 > but this is fairly complicated. > > The issue can be sidestepped entirely by sending the output to a file > only; a developer can use tail -f to follow the build if necessary. > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 16:52:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A257E106566B for ; Fri, 25 Jun 2010 16:52:30 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFFE8FC14 for ; Fri, 25 Jun 2010 16:52:29 +0000 (UTC) Received: by wyf22 with SMTP id 22so1536298wyf.13 for ; Fri, 25 Jun 2010 09:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=OdIhbkl0eY0F6/iMzmDz6JovcG4wbo0TIHR7S+Vh3Bk=; b=Sr7JXwN/E1+Yt0ejSNk6tEaNxivSaYUC1l3iAx+twlyAr1FiGFSfD7TjuPYnIOcuCP d0sgAuazUMuxYfvKAp8DZouqO5YMoK58UuhiKUuQ82xF9RWqFIE0KAF+WZ3W2DZ8lpOD AwhCE7OZUywFIqi4zCf8e25VdS4tXL1J4atRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=c8YgGSrI1sUp/WfLvZEipWytvMFW9tmhmlvOZ4q/BzgGG+u1K9NrSiDghsqbcg4OyR aC0XWJ8iylRaKUoWcWbWdTrLKTMIifFKrKQd6LEaEj0/mOV1zC/CLLwfEsDtJUqjtC6e Blb4cMJWpdRi5kWAjopq+Y7syH176xSfibm1g= Received: by 10.216.153.149 with SMTP id f21mr5345190wek.2.1277484749056; Fri, 25 Jun 2010 09:52:29 -0700 (PDT) Received: from dragon.dg (41-132-24-150.dsl.mweb.co.za [41.132.24.150]) by mx.google.com with ESMTPS id l46sm2523202wed.10.2010.06.25.09.52.24 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 09:52:28 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-hackers@freebsd.org Date: Fri, 25 Jun 2010 18:52:26 +0200 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart42614793.5JcOpxEqdd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006251852.30302.naylor.b.david@gmail.com> Subject: [RFC] mtree improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:52:30 -0000 --nextPart42614793.5JcOpxEqdd Content-Type: multipart/mixed; boundary="Boundary-01=_K7NJM4EmdaaEL6R" Content-Transfer-Encoding: 7bit --Boundary-01=_K7NJM4EmdaaEL6R Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've created a patch that increases the performance of mtree. This is of=20 particular use during a port install. In an extreme case I have experience= d a=20 ~20% increase [1]. =20 =46or a full discussion see PR bin/143732. This arose out of [2] where I=20 experienced the increase. =20 =46or your convenience I have attached the patch. =20 Please review this patch and if it is acceptable, commit it. =20 Regards, David 1] http://markmail.org/message/iju3l6hyv7s7emrb 2] http://markmail.org/message/gfztjpszl5dozzii --Boundary-01=_K7NJM4EmdaaEL6R Content-Type: text/x-patch; charset="ISO-8859-1"; name="mtree.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mtree.diff" =2D-- /usr/src/usr.sbin/mtree/verify.c 2010-02-07 15:07:28.000000000 +0200 +++ verify.c 2010-02-07 15:04:10.000000000 +0200 @@ -50,17 +50,23 @@ static NODE *root; static char path[MAXPATHLEN]; =20 =2Dstatic void miss(NODE *, char *); +static int miss(NODE *, char *); +static int check(NODE *, char *); static int vwalk(void); =20 int mtree_verifyspec(FILE *fi) { =2D int rval; + int rval =3D 0; =20 root =3D mtree_readspec(fi); =2D rval =3D vwalk(); =2D miss(root, path); + /* + * No need to walk entire tree if we are only updating the structure + * and extra files are ignored. + */ + if (!(uflag && eflag)) + rval =3D vwalk(); + rval |=3D miss(root, path); return (rval); } =20 @@ -155,15 +161,47 @@ return (rval); } =20 =2Dstatic void +static int +check(NODE *p, char *tail) +{ + FTSENT fts; + struct stat fts_stat; + + strcpy(tail, p->name); + + /* + * It is assumed that compare() only requires fts_accpath and fts_statp + * fields in the FTSENT structure. + */ + fts.fts_accpath =3D path; + fts.fts_statp =3D &fts_stat; + + if (stat(path, fts.fts_statp)) + return (0); + + p->flags |=3D F_VISIT; + if ((p->flags & F_NOCHANGE) =3D=3D 0 && compare(p->name, p, &fts)) + return (MISMATCHEXIT); + else + return (0); + + /* + * tail is not restored to '\0' as the next time tail (or path) is used + * is with a strcpy (thus overriding the '\0'). See +19 lines below. + */ +} + +static int miss(NODE *p, char *tail) { int create; char *tp; const char *type, *what; =2D int serr; + int serr, rval =3D 0; =20 for (; p; p =3D p->next) { + if (uflag && eflag) + rval |=3D check(p, tail); if (p->flags & F_OPT && !(p->flags & F_VISIT)) continue; if (p->type !=3D F_DIR && (dflag || p->flags & F_VISIT)) @@ -256,4 +294,5 @@ (void)printf("%s: file flags not set: %s\n", path, strerror(errno)); } + return (rval); } --Boundary-01=_K7NJM4EmdaaEL6R-- --nextPart42614793.5JcOpxEqdd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkwk3s4ACgkQUaaFgP9pFrLcYQCfaS+oZhomdmcQBGZLHNnR+e12 uVkAoIBLLnexJ0tjEgsxSnvF/ooToQMQ =57B8 -----END PGP SIGNATURE----- --nextPart42614793.5JcOpxEqdd-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 18:01:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F5F1065692 for ; Fri, 25 Jun 2010 18:01:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 210388FC19 for ; Fri, 25 Jun 2010 18:01:42 +0000 (UTC) Received: by gyh20 with SMTP id 20so6567238gyh.13 for ; Fri, 25 Jun 2010 11:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FpSlM0vefHp94Z1cl2SdH1FWogKLwPE4yNaR4I1i67w=; b=pntZKILe2VC51GbBDIb5mXUqt8568B//nxkscoxWcSBNlOIv6J/RPgi8ptGNKv8PfA YVeIWUVB9bfIzXJskIAVHQI1EzPEFN9R/CcMZZ9Id8ttdm+UoAOTFBdgHICei8jA7lY2 5H5evOweQ/VHcMwezY8u9wpTiYh6gprEA6QAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=I4MkdWH9KoQatL3EAVPDeFjENTNOMc6zSdBiGQCjZ4XkqhTr64mjzLrBe5yiu42ffj YPQJgZsg4qC6I1MzCi5TzM9+nlE9RwmFzLayufQYPn9dKYAeNQ6DpUP0KnZVsV3R+Tp+ 0xn96ZqeZJrCFquSwPVmcj+ALHEmrvxtuMabE= MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr744117qcb.18.1277488902209; Fri, 25 Jun 2010 11:01:42 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Fri, 25 Jun 2010 11:01:42 -0700 (PDT) In-Reply-To: <201006251852.30302.naylor.b.david@gmail.com> References: <201006251852.30302.naylor.b.david@gmail.com> Date: Fri, 25 Jun 2010 11:01:42 -0700 Message-ID: From: Garrett Cooper To: David Naylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] mtree improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:01:43 -0000 On Fri, Jun 25, 2010 at 9:52 AM, David Naylor wr= ote: > Hi, > > I've created a patch that increases the performance of mtree. =A0This is = of > particular use during a port install. =A0In an extreme case I have experi= enced a > ~20% increase [1]. > > For a full discussion see PR bin/143732. =A0This arose out of [2] where I > experienced the increase. > > For your convenience I have attached the patch. > > Please review this patch and if it is acceptable, commit it. > > Regards, > > David > > 1] http://markmail.org/message/iju3l6hyv7s7emrb > 2] http://markmail.org/message/gfztjpszl5dozzii Hmm... this has other interesting applications other than just ports, but unfortunately pkg_install won't really feel as much of a performance boost (because it uses mtree -e -U when +MTREE exists in the package). Comments follow. Thanks! -Garrett --- /usr/src/usr.sbin/mtree/verify.c 2010-02-07 15:07:28.000000000 +0200 +++ verify.c 2010-02-07 15:04:10.000000000 +0200 @@ -50,17 +50,23 @@ static NODE *root; static char path[MAXPATHLEN]; -static void miss(NODE *, char *); +static int miss(NODE *, char *); +static int check(NODE *, char *); static int vwalk(void); int mtree_verifyspec(FILE *fi) { - int rval; + int rval =3D 0; root =3D mtree_readspec(fi); - rval =3D vwalk(); - miss(root, path); + /* + * No need to walk entire tree if we are only updating the structure + * and extra files are ignored. + */ + if (!(uflag && eflag)) + rval =3D vwalk(); gcooper> This is where the performance boost is coming from as you're not walking the directory tree, correct? + rval |=3D miss(root, path); return (rval); } @@ -155,15 +161,47 @@ return (rval); } -static void +static int +check(NODE *p, char *tail) +{ + FTSENT fts; + struct stat fts_stat; + + strcpy(tail, p->name); gcooper> Dangerous. Please use strlcpy with appropriate bounds. + /* + * It is assumed that compare() only requires fts_accpath and fts_statp + * fields in the FTSENT structure. + */ + fts.fts_accpath =3D path; + fts.fts_statp =3D &fts_stat; + + if (stat(path, fts.fts_statp)) + return (0); gcooper> What about symlink functionality? lstat(2)? + p->flags |=3D F_VISIT; + if ((p->flags & F_NOCHANGE) =3D=3D 0 && compare(p->name, p, &fts)) + return (MISMATCHEXIT); + else + return (0); + + /* + * tail is not restored to '\0' as the next time tail (or path) is used + * is with a strcpy (thus overriding the '\0'). See +19 lines below. + */ +} + +static int miss(NODE *p, char *tail) { int create; char *tp; const char *type, *what; - int serr; + int serr, rval =3D 0; gcooper> This isn't correct as per-style(9). Please do: gcooper> gcooper> int rval =3D 0; gcooper> int serr; gcooper> gcooper> This reduces diff churn and is more style(9)-istically correct. for (; p; p =3D p->next) { + if (uflag && eflag) + rval |=3D check(p, tail); if (p->flags & F_OPT && !(p->flags & F_VISIT)) continue; if (p->type !=3D F_DIR && (dflag || p->flags & F_VISIT)) @@ -256,4 +294,5 @@ (void)printf("%s: file flags not set: %s\n", path, strerror(errno)); } + return (rval); } From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 18:01:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFAB1065676 for ; Fri, 25 Jun 2010 18:01:19 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4354E8FC15 for ; Fri, 25 Jun 2010 18:01:18 +0000 (UTC) Received: by gxk26 with SMTP id 26so327425gxk.13 for ; Fri, 25 Jun 2010 11:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.221.134 with SMTP id ic6mr713604qcb.65.1277487111314; Fri, 25 Jun 2010 10:31:51 -0700 (PDT) Received: by 10.229.225.142 with HTTP; Fri, 25 Jun 2010 10:31:51 -0700 (PDT) X-Originating-IP: [139.181.0.34] Date: Fri, 25 Jun 2010 10:31:51 -0700 Message-ID: From: Christopher Bowman To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Fri, 25 Jun 2010 18:35:14 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: PCI Express and drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:01:19 -0000 I have a Xilinx PCI Express board that has an on board PCIe interface macro. I intend to have an address space with memory and another with my devices control registers. I wish to program this board under FreeBSD. It would seem to me that the way to do this would be to write a driver that would allow me to map these two address spaces into a user process which could then directly interact with the device. In my case my board doesn't really support multiple users, and it doesn't really seem to make sense to me to put a lot of code in the kernel to create some sort of interface to allow multiple processes to interact with my device via some sort of syscall which would impose a lot of overhead in any case. By mapping the address ranges into a user process I can write user programs to drive the board without having to recompile and reboot the kernel each time I make a change, plus if I do something stupid and crash my user space process it shouldn't bring down the whole kernel. Am I thinking about this wrong? Is there some place I can go to read up on what I should be doing? If I am thinking about this correctly, then how does one map device memory into a user space process? How does one make sure that only one process has such a mapping? Thanks Christopher From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 18:56:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4282106566B for ; Fri, 25 Jun 2010 18:56:40 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 765378FC18 for ; Fri, 25 Jun 2010 18:56:40 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8C1421FFC33; Fri, 25 Jun 2010 18:56:39 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A53FE8452A; Fri, 25 Jun 2010 20:54:28 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Patrick Mahan References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> <4C24A7B4.5050301@mahan.org> <86mxujdziz.fsf@ds4.des.no> <4C24D9BC.7030008@mahan.org> Date: Fri, 25 Jun 2010 20:54:28 +0200 In-Reply-To: <4C24D9BC.7030008@mahan.org> (Patrick Mahan's message of "Fri, 25 Jun 2010 09:30:52 -0700") Message-ID: <86iq57djtn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:56:40 -0000 Patrick Mahan writes: > Maybe I should do this instead? > > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 > build_amd64_kernel.log; \ > tail -f build_amd64_kernel.log > > It is not too clear if the status is the last one in a compound > command. This won't work, because tail won't start until the build is done. You should just pass the file name as an argument to your script and handle it there. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 20:23:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17301106566B for ; Fri, 25 Jun 2010 20:23:29 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7D28FC0A for ; Fri, 25 Jun 2010 20:23:28 +0000 (UTC) Received: by wyf22 with SMTP id 22so1693549wyf.13 for ; Fri, 25 Jun 2010 13:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=p9U3lgbtw39FOjRik3jZLz3TDsU/8M43u3vygK0spgU=; b=srFK7PaPkV4+LTFh3qcS9lTm1eQaElwJ0+J02ZK1hcJaK5MeEmqDUJufXertpUFq2b 8bDkXumZriyWLwbfBYbDeDpl+5Xf39yy908+KppDessEK3ogV1h8PuAPYqj1clzQW7a/ aBWjuA7IreoqF/E8Vwft+v04+ojrrNsk5gw4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=p1D3Wl/4As8hwSWWP1ooeBEeZNXW2r6j3z0oaEszDl+pteiPY4QstcQYuJk7WVJ6Kp OQDTlynd6sM4TPWDY95gq/R3bLkJqKmRWFifNnv+HD/ixiheIaZFn84/U6jjE3okcyzu 1ud1Z1Jh4CuM2Rirry9FUZh5omZHM40ajVayA= Received: by 10.216.90.18 with SMTP id d18mr5483153wef.79.1277496769665; Fri, 25 Jun 2010 13:12:49 -0700 (PDT) Received: from dragon.dg (41-132-24-150.dsl.mweb.co.za [41.132.24.150]) by mx.google.com with ESMTPS id u81sm1059214wei.4.2010.06.25.13.12.42 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 13:12:48 -0700 (PDT) From: David Naylor Organization: Private To: Garrett Cooper Date: Fri, 25 Jun 2010 22:12:42 +0200 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) References: <201006251852.30302.naylor.b.david@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1715099.4f37riSuJ6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006252212.46301.naylor.b.david@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] mtree improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 20:23:29 -0000 --nextPart1715099.4f37riSuJ6 Content-Type: multipart/mixed; boundary="Boundary-01=_62QJMEjqHFP9f2f" Content-Transfer-Encoding: 7bit --Boundary-01=_62QJMEjqHFP9f2f Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 25 June 2010 20:01:42 Garrett Cooper wrote: > On Fri, Jun 25, 2010 at 9:52 AM, David Naylor = =20 wrote: > > Hi, > >=20 > > I've created a patch that increases the performance of mtree. This is = of > > particular use during a port install. In an extreme case I have > > experienced a ~20% increase [1]. > >=20 > > For a full discussion see PR bin/143732. This arose out of [2] where I > > experienced the increase. > >=20 > > For your convenience I have attached the patch. > >=20 > > Please review this patch and if it is acceptable, commit it. > >=20 > > Regards, > >=20 > > David > >=20 > > 1] http://markmail.org/message/iju3l6hyv7s7emrb > > 2] http://markmail.org/message/gfztjpszl5dozzii >=20 > Hmm... this has other interesting applications other than just ports, > but unfortunately pkg_install won't really feel as much of a > performance boost (because it uses mtree -e -U when +MTREE exists in > the package). >=20 > Comments follow. > Thanks! > -Garrett I've included some more changes. I do not think -[uU] needs to be set when= =20 skipping vwalk. I also move sflag so it will get called even if eflag is s= et=20 (bug in my patch). =20 I'm not sure sflag will produce the same results as check() and vwalk() may= =20 call compare() in different orders? Will this impact on crc? > --- /usr/src/usr.sbin/mtree/verify.c 2010-02-07 15:07:28.000000000 +0200 > +++ verify.c 2010-02-07 15:04:10.000000000 +0200 > @@ -50,17 +50,23 @@ > static NODE *root; > static char path[MAXPATHLEN]; >=20 > -static void miss(NODE *, char *); > +static int miss(NODE *, char *); > +static int check(NODE *, char *); > static int vwalk(void); >=20 > int > mtree_verifyspec(FILE *fi) > { > - int rval; > + int rval =3D 0; >=20 > root =3D mtree_readspec(fi); > - rval =3D vwalk(); > - miss(root, path); > + /* > + * No need to walk entire tree if we are only updating the structure > + * and extra files are ignored. > + */ > + if (!(uflag && eflag)) > + rval =3D vwalk(); >=20 > gcooper> This is where the performance boost is coming from as you're > not walking the directory tree, correct? Yes, if an update is requested without reporting extra files. In some case= s=20 with a well populated /usr/local (and a slowish HDD) it could take some tim= e. =20 I think it is possible to even use this optimisation if uflag is not set? = =20 > + rval |=3D miss(root, path); > return (rval); > } >=20 > @@ -155,15 +161,47 @@ > return (rval); > } >=20 > -static void > +static int > +check(NODE *p, char *tail) > +{ > + FTSENT fts; > + struct stat fts_stat; > + > + strcpy(tail, p->name); >=20 > gcooper> Dangerous. Please use strlcpy with appropriate bounds. This is the same code used in miss.c:171. =20 It appears the code assumes that a path a mtree file describes will not exc= eed=20 MAXPATHLEN and does not check to see if the buffer overflows. I could crea= te a=20 patch to fix that. Perhaps a separate patch? > + /* > + * It is assumed that compare() only requires fts_accpath and fts_statp > + * fields in the FTSENT structure. > + */ > + fts.fts_accpath =3D path; > + fts.fts_statp =3D &fts_stat; > + > + if (stat(path, fts.fts_statp)) > + return (0); >=20 > gcooper> What about symlink functionality? lstat(2)? =46ixed. This should now be consistent with fts_read. =20 > + p->flags |=3D F_VISIT; > + if ((p->flags & F_NOCHANGE) =3D=3D 0 && compare(p->name, p, &fts)) > + return (MISMATCHEXIT); > + else > + return (0); > + > + /* > + * tail is not restored to '\0' as the next time tail (or path) is used > + * is with a strcpy (thus overriding the '\0'). See +19 lines below. > + */ > +} > + > +static int > miss(NODE *p, char *tail) > { > int create; > char *tp; > const char *type, *what; > - int serr; > + int serr, rval =3D 0; >=20 > gcooper> This isn't correct as per-style(9). Please do: > gcooper> > gcooper> int rval =3D 0; > gcooper> int serr; > gcooper> > gcooper> This reduces diff churn and is more style(9)-istically correct. I didn't know that. Good point. =20 > for (; p; p =3D p->next) { > + if (uflag && eflag) > + rval |=3D check(p, tail); > if (p->flags & F_OPT && !(p->flags & F_VISIT)) > continue; > if (p->type !=3D F_DIR && (dflag || p->flags & F_VISIT)) > @@ -256,4 +294,5 @@ > (void)printf("%s: file flags not set: %s\n", > path, strerror(errno)); > } > + return (rval); > } --Boundary-01=_62QJMEjqHFP9f2f Content-Type: text/x-patch; charset="ISO-8859-1"; name="mtree.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mtree.diff" =2D-- mtree/verify.c 2010-05-27 13:47:20.000000000 +0200 +++ verify.c 2010-06-25 22:04:40.000000000 +0200 @@ -50,17 +50,25 @@ static NODE *root; static char path[MAXPATHLEN]; =20 =2Dstatic void miss(NODE *, char *); +static int miss(NODE *, char *); +static int check(NODE *, char *); static int vwalk(void); =20 int mtree_verifyspec(FILE *fi) { =2D int rval; + int rval =3D 0; =20 root =3D mtree_readspec(fi); =2D rval =3D vwalk(); =2D miss(root, path); + /* No need to walk tree if we are ignoring extra files. */ + if (!eflag) + rval =3D vwalk(); + rval |=3D miss(root, path); + + /* Called here to make sure vwalk() and check() have been called */ + if (sflag) + warnx("%s checksum: %lu", fullpath, (unsigned long)crc_total); + return (rval); } =20 @@ -135,35 +143,72 @@ if (ep) continue; extra: =2D if (!eflag) { =2D (void)printf("%s extra", RP(p)); =2D if (rflag) { =2D if ((S_ISDIR(p->fts_statp->st_mode) =2D ? rmdir : unlink)(p->fts_accpath)) { =2D (void)printf(", not removed: %s", =2D strerror(errno)); =2D } else =2D (void)printf(", removed"); =2D } =2D (void)putchar('\n'); + (void)printf("%s extra", RP(p)); + if (rflag) { + if ((S_ISDIR(p->fts_statp->st_mode) + ? rmdir : unlink)(p->fts_accpath)) { + (void)printf(", not removed: %s", + strerror(errno)); + } else + (void)printf(", removed"); } + (void)putchar('\n'); (void)fts_set(t, p, FTS_SKIP); } (void)fts_close(t); =2D if (sflag) =2D warnx("%s checksum: %lu", fullpath, (unsigned long)crc_total); return (rval); } =20 =2Dstatic void +static int +check(NODE *p, char *tail) +{ + FTSENT fts; + struct stat fts_stat; + + strcpy(tail, p->name); + + /* + * It is assumed that compare() only requires fts_accpath and fts_statp + * fields in the FTSENT structure. + */ + fts.fts_accpath =3D path; + fts.fts_statp =3D &fts_stat; + + if (ftsoptions & FTS_LOGICAL) { + if (stat(path, fts.fts_statp) || lstat(path, fts.fts_statp)) + return (0); + } else if (lstat(path, fts.fts_statp)) + return (0); + + p->flags |=3D F_VISIT; + if ((p->flags & F_NOCHANGE) =3D=3D 0 && compare(p->name, p, &fts)) + return (MISMATCHEXIT); + else + return (0); + + /* + * tail is not restored to '\0' as the next time tail (or path) is used + * is with a strcpy (thus overriding the '\0'). See +25 lines below. + */ +} + +static int miss(NODE *p, char *tail) { int create; char *tp; const char *type, *what; + int rval =3D 0; int serr; =20 for (; p; p =3D p->next) { + /* + * If check() needs to be called (eflag set) and dflag is set=20 + * then only call for directories (as we are ignoring=20 + * everything else) otherwise always call. + */ + if (eflag && (!dflag || (p->type =3D=3D F_DIR))) + rval |=3D check(p, tail); if (p->flags & F_OPT && !(p->flags & F_VISIT)) continue; if (p->type !=3D F_DIR && (dflag || p->flags & F_VISIT)) @@ -256,4 +301,5 @@ (void)printf("%s: file flags not set: %s\n", path, strerror(errno)); } + return (rval); } --Boundary-01=_62QJMEjqHFP9f2f-- --nextPart1715099.4f37riSuJ6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkwlDb4ACgkQUaaFgP9pFrK33wCffHn+OJ7hDXbjdTIkP85c9I5s djgAnjQnvYi2h5yooO2Pe/NeHOFqvTPa =4b6w -----END PGP SIGNATURE----- --nextPart1715099.4f37riSuJ6-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 25 22:48:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EACD10656CD for ; Fri, 25 Jun 2010 22:48:02 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECB028FC1E for ; Fri, 25 Jun 2010 22:48:01 +0000 (UTC) Received: by wwb24 with SMTP id 24so3132202wwb.13 for ; Fri, 25 Jun 2010 15:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=yWhe9V+jO6ClQUSpNYe1iSKZiy25vwvxZ+BuNN0zKRw=; b=B9sRPpd4W71YrAuQ8jY9JkYyHXfupGzxjVoD8TNvgV9dIgEhFkRhAlPYWpaq9ACLMH GebeJ0jSz4pQ3IlPu8gQ/EL8jJAmtxWMIqwH39yMaS+LvoduloSka4mJzvmcK9abV3/A uDnOpUgmmrUaBNXYYstoI0ygiT4tOwL0OpcSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Gj7gCznXw+akPMNU4eQjFLzaXR9M3fCL1hI7xaxUnLXRjEtZK7IG57KomoeLAYGIke Z6xBFvq2Haq7/VMpDZymK6PWsloLP2A1Woayqkd8+Uk13B0bPA7M5Roln3XpXaCo1uXf yliOV3UGkW9Zdt4YgVR3fRSsZV/WBlHDpAaMo= MIME-Version: 1.0 Received: by 10.216.165.82 with SMTP id d60mr5611476wel.40.1277506080979; Fri, 25 Jun 2010 15:48:00 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.216.5.66 with HTTP; Fri, 25 Jun 2010 15:48:00 -0700 (PDT) In-Reply-To: <20100612100006.000073fa@unknown> References: <20100612100006.000073fa@unknown> Date: Sat, 26 Jun 2010 01:48:00 +0300 X-Google-Sender-Auth: D84md6Pq8h07mRW5KhlewHoEkRk Message-ID: From: Mohammed Farrag To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Chargen , freebsd-hackers@freebsd.org, Matt Thyer , freebsd-current@freebsd.org Subject: Re: I need reply in Embedded FreeBSD Kernel Theme X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 22:48:02 -0000 hi sorry for being late in reply but I had some problems in the last week. I hope u still remeber what I was talking about :) @chargen Thanx for ur reply. Embedded computer systems permeate all aspects of our daily lives. Alarm clocks, coffee makers, digital watches, cell phones, and automobiles are just a few of the devices that make use of embedded systems. The design and development of such systems is unique, because the design constraints are different for each system. I supposed a new design for reducing the size of the kernel to be able to work in such an environment which has some constraints make it does not have the ability to get large memory, large storage devices or others. ///////////////////////////// as far as your document goes: "We will unload all the drivers that indicated with zeros in the module metadata file. That would make the OS to be a few of Megabytes." unload? what is the logic here? I'm sorry but what is the real gain here, ////////////////////// The configuration file is dependent on the kernel (which is included as a compiled kernel). If I unload these unneeded drivers, I decrease the size of the compiled kernel So it will have the ability to work in more constrained environment and that is suitable to work for Operating Systems for small chips for embedded systems. As the Internet grew, the requirements of embedded systems also began to grow in complexity. In addition to solving classic embedded systems problems, system designers were required to add connectivity for sending and receiving data or providing an automated method for software upgrades. Rather than increase the development effort, system designers have moved toward using third-party hardware and evaluating open source software. Thanx Chargen @ andrew Thanx for your reply. I appreciate your effort to download the document. Regarding the uploading of the document to that site, I am sorry for that but I tried to attach it with the email but it was refused because its size was too large. I did not send it in the text part because the text format and tables will be lost. I am sorry for that. ////////////////////////////// /////////////////////////// After a couple of quick readings, I'm not sure I correctly understand what you plan to achieve. It sounds like you are trying to achive something like hardware specific dynamic module loading (like in Solaris, for example), but then it also sounds like you are trying to build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. Are you compiling a kernel at some point rather than just generating a loader.conf for modules in order to minimise the running size? //////////////////////////////////////////////////////// This approach will combine the two both. It will build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. It also will use hardware specific dynamic module loading because I don't have to load all the drivers for devices connected to the machine. I will use this dynamic module loading at the start-up only not at the run time because some considerations of the embedded systems for chips not being to load modules and change how to work at run time. that would make power problems. //////////////////////////////////////////////////////// I was most confused by We will unload all the drivers that indicated with zeros in the > module metadata file. That would make the OS to be a > few of Megabytes. > Whether you are compiling a kernel for the (chosen) hardware based on a generated kernel or loader config, I don't see a sensible case in which you would ever need to "unload" any driver. /////////////////////////////////////////////////////////////// yeah I know it is not sensible but I wrote it as a result of what I supposed before so it has no meaning. just a result to clarify what I reduced here. Thanx for ur sympathy and I will be glad to send you my next file to get ur comments about. //////////////////////////////////////////////////////////////// As much fun as it is spending hours manually tweaking and testing a kernel config for each system and deciding what modules to use, I like the idea of a one time guided process based on accurately identified hardware to build an optimal kernel, so I hope that's what you're proposing. ////////////////////////////////////////////////////////////////// Actually, I am deciding many time guided process based on accurately identified hardware to build an optimal kernel because I think this is more dynamic for considerations of changing the purpose of the embedded system. I mean sometimes u may need to perform deterministic operation in this boot so u do not have to load all drivers which there will be a lot of unneeded drivers of them at this boot process. I will determine the dependencies to provide optimal kernel. Thanx Andrew @ Matt Thanx for ur reply Matt. ///////////////////////////////////////////////////// FreeBSD is already a very modular system and the traditional way (a traditional way) to build for embedded systems is to follow the NanoBSD build method (tools included in the source tree) with a stripped down kernel in which you only load the modules your hardware requires using the FreeBSD loader (or after the initial boot). //////////////////////////////////////////////////// yeah I read about that. My mentor suggested that before and my idea is very close to NanoBSD but I don't know if the freebsd loader will load the moduls based on the hardware requirements or user requirements. I will be glad to reply me. //////////////////////////////////////////////// However my Soekris net4801 board still takes about 2.5 minutes to boot and I think time could be saved by parallel probing of hardware where possible. //////////////////////////////////////////////////// I think parallel probing is not providing in many boards. It's supported for the new borders only (correct me if I am wrong). I have to develop something which can be used in most of embedded systems. /////////////////////////////////////////////////// I'd vote for more work on FreeBSD's existing boot method rather than an entirely new implementation. What problem are you trying to solve Mohammed ? ////////////////////////////// I am not going to change in the main boot process. I am only changing the how of including the kernel in the configuration file. that is it and everything will be done as it is in the current freebsd. no more. That would save space and that is what I need to reduce the size of kernel in memory. @ bruce Thanx for ur reply. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 03:19:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C498B106566B for ; Sat, 26 Jun 2010 03:19:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 303708FC08 for ; Sat, 26 Jun 2010 03:19:11 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o5Q3Iwwq058012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Jun 2010 12:49:04 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sat, 26 Jun 2010 12:48:57 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> References: To: Christopher Bowman X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI Express and drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 03:19:12 -0000 On 26/06/2010, at 3:01, Christopher Bowman wrote: > I have a Xilinx PCI Express board that has an on board PCIe interface > macro. I intend to have an address space with memory and another with = my > devices control registers. I wish to program this board under = FreeBSD. It > would seem to me that the way to do this would be to write a driver = that > would allow me to map these two address spaces into a user process = which > could then directly interact with the device. In my case my board = doesn't > really support multiple users, and it doesn't really seem to make = sense to > me to put a lot of code in the kernel to create some sort of interface = to > allow multiple processes to interact with my device via some sort of = syscall > which would impose a lot of overhead in any case. By mapping the = address > ranges into a user process I can write user programs to drive the = board > without having to recompile and reboot the kernel each time I make a = change, > plus if I do something stupid and crash my user space process it = shouldn't > bring down the whole kernel. Am I thinking about this wrong? Is = there some > place I can go to read up on what I should be doing? If I am thinking = about > this correctly, then how does one map device memory into a user space > process? How does one make sure that only one process has such a = mapping? You could use mmap() I think, For a driver I maintain I did the following -> /* Magic sauce stolen from src/sys/pci/xrpu.c via phk * = http://www.mail-archive.com/freebsd-hackers%40freebsd.org/msg11729.html */ *paddr =3D rman_get_start(sc->g_membase.reshandle) + offset; =20 g_membase is.. struct resource *reshandle; /* Resource handle */ bus_space_tag_t sc_st; /* bus space tag */ bus_space_handle_t sc_sh; /* bus space handle */ PS what board are you using? :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 03:00:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA1C0106564A; Sat, 26 Jun 2010 03:00:03 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF4A8FC1C; Sat, 26 Jun 2010 03:00:02 +0000 (UTC) Received: by vws13 with SMTP id 13so5059066vws.13 for ; Fri, 25 Jun 2010 20:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nyYcgDJRx44CWX9GK44olfB1JgWJGoLM9bSIb9AG1PU=; b=FmKmHG5secRW11VyBFDaj1hV9MKae7nACLhPOeNwZlihj/mxSTBEZnwGa4C3N6frIv MQ4LJ4w09fxaAo0xCPzP/Z0h9pjq2e0uH0kp2yzmKQyPU9W9luwP8kdGmZ/ycBYvPJEd VYc0+9p0XcxsFqMfNOW7/53gP2NnbM83IITZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EctMIZ8HY8dsicAcm9ViywwvBi6mtZV3PxVgLicRRLOGtNEQWAzu0VY4w7UyNCUN+v DXM17KX8XftUIuLZiX8qL5yI7pCxJzsGWrpjzdOB3fsuV7CRUI49ZustSJZ5YaZh2BsG 6Lde6I5eVJbZieqTQM9CEgs8zXSZa7+UjWNMY= MIME-Version: 1.0 Received: by 10.220.161.201 with SMTP id s9mr957184vcx.137.1277521202196; Fri, 25 Jun 2010 20:00:02 -0700 (PDT) Received: by 10.220.180.204 with HTTP; Fri, 25 Jun 2010 20:00:02 -0700 (PDT) In-Reply-To: References: <20100612100006.000073fa@unknown> Date: Sat, 26 Jun 2010 12:30:02 +0930 Message-ID: From: Matt Thyer To: Mohammed Farrag Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 26 Jun 2010 04:23:03 +0000 Cc: Bruce Cran , Chargen , freebsd-current@freebsd.org, Mohammed@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: I need reply in Embedded FreeBSD Kernel Theme X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 03:00:04 -0000 On 24 June 2010 11:06, Mohammed Farrag wrote: > @ Matt > Thanx for ur reply Matt. > ///////////////////////////////////////////////////// > FreeBSD is already a very modular system and the traditional way (a > traditional way) to build for embedded systems is to follow the > NanoBSD build method (tools included in the source tree) with a > stripped down kernel in which you only load the modules your hardware > requires using the FreeBSD loader (or after the initial boot). > //////////////////////////////////////////////////// > yeah I read about that. My mentor suggested that before and my idea is very > close to NanoBSD but I don't know if the freebsd loader will load the moduls > based on the hardware requirements or user requirements. I will be glad to > reply me. Modules are loaded by the user adding entries to /boot/loader.conf. e.g. if_sis_load="YES". That example will load the "sis" driver for the Silicon Image network interfaces on my Soekris net4801 board as I have removed almost everything in my kernel and just load the modules I require. Some modules will automatically load when another driver requires them. FreeBSD does not try to discover and reconfigure your hardware at boot time like the "kudzu" utility in Linux. Instead it will attach to the hardware for which you have drivers in your kernel or for which you have told the loader to load modules for. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 06:51:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537AA106564A for ; Sat, 26 Jun 2010 06:51:01 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0A298FC0A for ; Sat, 26 Jun 2010 06:50:58 +0000 (UTC) Received: by fxm13 with SMTP id 13so306850fxm.13 for ; Fri, 25 Jun 2010 23:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=wTjFrgqQkWkfPuLhe4gt/11ghJiY+HJ2dqY/BQ6+hZY=; b=lvwn9lPrIx7DUY7C6oo40hn35O4K9Y3OWa57m1/2WGD5v6zzL3TiPN/pRUYPZ55Ubr 8StfNBw9ZTmp0czYkqkG8P4WTGumeHTdi2LrZuAwYhLmAq07dsbJFB3z65Ygt1zJDyRX LrCCviQauU9eSDXAdCgZ+5mCrGmDvCL1Off4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=EbjOwCCTfDQKmGC/13z6P7cUDPITHjwVZAZLPQNvA/zEq9vD+XoFOm7EvRFcdLsac/ S6mSmW8FFqX5bVmD445iU5D8dyJZDw//KlAtryOd1lFZ8R7NF5Ja8FE7tCoJyPgt6ZEj tl8QS2t/Ifj8fnO7XVsTG2atWYUg+MrTuScuU= Received: by 10.223.50.68 with SMTP id y4mr1384157faf.51.1277535057772; Fri, 25 Jun 2010 23:50:57 -0700 (PDT) Received: from viper.internal.network (dsl78-143-224-50.in-addr.fast.co.uk [78.143.224.50]) by mx.google.com with ESMTPS id a3sm39732883fak.40.2010.06.25.23.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Jun 2010 23:50:57 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 4C1A64AC0A; Sat, 26 Jun 2010 06:50:56 +0000 (UTC) Date: Sat, 26 Jun 2010 06:50:56 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20100626065056.GA897@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 32 bit DRI on amd64 - possible bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 06:51:01 -0000 Hi. I've had two people tell me that this is supposed to be working these days (8.0-RELEASE-p2) but I'm not having much luck. I have a 32 bit chroot, built with "make buildworld TARGET=i386" and have built a pile of ports in that jail (i386 libGL, i386 dri, etc, etc). I've tried running the chroot as both a jail and an ordinary chroot and in both cases, any program that tries to use DRI behaves erratically and usually (but not always) segfaults immediately: i386-jail$ LIBGL_DEBUG=verbose glxinfo name of display: 10.1.3.1:0.0 libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) DRM_IOCTL_VERSION: Bad address Segmentation fault: 11 i386-jail$ LIBGL_DEBUG=verbose glxinfo name of display: 10.1.3.1:0.0 libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) Segmentation fault: 11 i386-jail$ LIBGL_DEBUG=verbose glxinfo name of display: 10.1.3.1:0.0 libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci:0000:06:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports (null) drmOpenDevice: node name is /dev/dri/card1 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card2 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card3 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card4 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card5 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card6 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card7 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card8 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card9 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card10 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card11 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card12 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card13 drmOpenByBusid: drmOpenMinor returns -1003 drmOpenDevice: node name is /dev/dri/card14 drmOpenByBusid: drmOpenMinor returns -1003 libGL error: drmOpenOnce failed (Operation not permitted) libGL error: reverting to software direct rendering libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so display: 10.1.3.1:0 screen: 0 direct rendering: Yes Note the lack of a segfault in the third invocation. The glxinfo program runs to completion about one in every six invocations. Programs such as glxdemo sometimes manage to open a window and process a few events before crashing (it's pretty much over before anything's visible onscreen - less than half a second): i386-chroot$ glxdemo Segmentation fault: 11 (core dumped) i386-chroot$ glxdemo Segmentation fault: 11 (core dumped) i386-chroot$ glxdemo Resize event Resize event Redraw event Segmentation fault: 11 (core dumped) It doesn't work outside of the chroot either (just using LD_32_LIBRARY_PATH to allow the binaries to find their libraries): $ LD_32_LIBRARY_PATH=/jail/i386/usr/local/lib \ LIBGL_DEBUG=verbose \ LIBGL_DRIVERS_PATH=/jail/i386/usr/local/lib/dri \ /jail/i386/usr/local/bin/glxinfo 2>&1 name of display: :0.0 libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /jail/wine/usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) Segmentation fault (core dumped) A ktrace shows nothing particular interesting in any case. Sometimes an ioctl() will fail with EFAULT but usually, things just crash: 75860 initial thread RET stat 0 75860 initial thread CALL open(0xffffd0f4,O_RDWR,0) 75860 initial thread NAMI "/dev/dri/card0" 75860 initial thread RET open 6 75860 initial thread CALL write(0x2,0xffffcaf0,0x26) 75860 initial thread GIO fd 2 wrote 38 bytes "drmOpenDevice: open result is 6, (OK) " 75860 initial thread RET write 38/0x26 75860 initial thread CALL ioctl(0x6,0xc0246400 ,0x28414100) 75860 initial thread RET ioctl 0 75860 initial thread CALL ioctl(0x6,0xc0246400 ,0x28414100) 75860 initial thread RET ioctl 0 75860 initial thread PSIG SIGSEGV SIG_DFL 75860 initial thread NAMI "glxinfo.core" The "operation not permitted" error is confusing too as permissions on /dev/dri/card0 are fine: i386$ id uid=11001(m0) gid=11001(m0) groups=11001(m0),11003(devel),11012(usb),11013(video) i386$ ls -alF /dev/dri/card0 crw-rw---- 1 root video 0, 37 May 26 10:29 /dev/dri/card0 Needless to say, DRI works flawlessly on the host. The package versions on the host and in the chroot match. Is this a bug? I'm mystified as I seem to be the only person having this problem. host: FreeBSD 8.0-RELEASE-p2 amd64 jail: FreeBSD 8.0-RELEASE-p2 i386 packages: dri-7.4.4,2 xf86-video-ati-6.12.4_1 libGL-7.4.4 Device is an ATI Radeon x1950. Any help would be seriously appreciated! Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 07:40:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E45106566B for ; Sat, 26 Jun 2010 07:40:59 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7B58FC08 for ; Sat, 26 Jun 2010 07:40:59 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o5Q7ewoK052518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 00:40:59 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o5Q7ewWf052517; Sat, 26 Jun 2010 00:40:58 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01360; Sat, 26 Jun 10 00:34:44 PDT Date: Sat, 26 Jun 2010 00:31:01 -0700 From: perryh@pluto.rain.com To: mahan@mahan.org Message-Id: <4c25acb5.bmIH6XsQ0VuWcjmY%perryh@pluto.rain.com> References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> <4C24A7B4.5050301@mahan.org> <86mxujdziz.fsf@ds4.des.no> <4C24D9BC.7030008@mahan.org> In-Reply-To: <4C24D9BC.7030008@mahan.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 07:40:59 -0000 Patrick Mahan wrote: > Maybe I should do this instead? > > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 > build_amd64_kernel.log; \ > tail -f build_amd64_kernel.log > > It is not too clear if the status is the last one in a compound > command. Someone already noted that this will not run tail until after the build finishes; then you'll see the last 10 lines of the log and make will stop until something (like kill) causes tail to exit. Another problem arises from the order of the redirections: only the script's normal output will go to the logfile; errors will go to make's standard output. This should do more or less what I think you're trying for: src-kernel: src-kernel-tools touch src/build_amd64_kernel.log tail -f src/build_amd64_kernel.log & cd src; ./amd64-kernel.sh > build_amd64_kernel.log 2>&1 IOW start tail in the background, after ensuring that the logfile exists so tail doesn't immediately exit with an error. Note that this does not solve the problem of somehow getting rid of the tail process after the build finishes. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 07:41:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F61106566C; Sat, 26 Jun 2010 07:41:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id E401E8FC13; Sat, 26 Jun 2010 07:40:59 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o5Q7exBx052523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 00:40:59 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o5Q7exP3052522; Sat, 26 Jun 2010 00:40:59 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01374; Sat, 26 Jun 10 00:34:55 PDT Date: Sat, 26 Jun 2010 00:31:12 -0700 From: perryh@pluto.rain.com To: faber@isi.edu, gljennjohn@googlemail.com Message-Id: <4c25acc0.Iv6wSe8/bzgSDqFQ%perryh@pluto.rain.com> References: <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> <4C21B170.2030903@icyb.net.ua> <4C21B383.2000602@icyb.net.ua> <20100623154531.GB31578@zod.isi.edu> <20100624011509.GI31578@zod.isi.edu> <20100624092337.6bed1f45@ernst.jennejohn.org> <20100624152957.GA46600@zod.isi.edu> <20100624165445.GF46600@zod.isi.edu> <20100625110339.398a5006@ernst.jennejohn.org> In-Reply-To: <20100625110339.398a5006@ernst.jennejohn.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tevans.uk@googlemail.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 07:41:00 -0000 Gary Jennejohn wrote: > IMO if you're going to make the binaries in base non-executable > you might just as well delete them. The chmod is reversible without having to recover the base binaries from somewhere. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 05:21:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B981065670 for ; Sat, 26 Jun 2010 05:21:00 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DEF718FC08 for ; Sat, 26 Jun 2010 05:20:59 +0000 (UTC) Received: by qwg5 with SMTP id 5so982376qwg.13 for ; Fri, 25 Jun 2010 22:20:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.250.81 with SMTP id mn17mr1095895qcb.182.1277529658255; Fri, 25 Jun 2010 22:20:58 -0700 (PDT) Received: by 10.229.225.142 with HTTP; Fri, 25 Jun 2010 22:20:58 -0700 (PDT) X-Originating-IP: [139.181.0.34] In-Reply-To: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> References: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> Date: Fri, 25 Jun 2010 22:20:58 -0700 Message-ID: From: Christopher Bowman To: "Daniel O'Connor" X-Mailman-Approved-At: Sat, 26 Jun 2010 11:02:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI Express and drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 05:21:00 -0000 On Fri, Jun 25, 2010 at 8:18 PM, Daniel O'Connor wrote: > > On 26/06/2010, at 3:01, Christopher Bowman wrote: > > I have a Xilinx PCI Express board that has an on board PCIe interface > > macro. I intend to have an address space with memory and another with my > > devices control registers. I wish to program this board under FreeBSD. > It > > would seem to me that the way to do this would be to write a driver that > > would allow me to map these two address spaces into a user process which > > could then directly interact with the device. In my case my board > doesn't > > really support multiple users, and it doesn't really seem to make sense > to > > me to put a lot of code in the kernel to create some sort of interface to > > allow multiple processes to interact with my device via some sort of > syscall > > which would impose a lot of overhead in any case. By mapping the address > > ranges into a user process I can write user programs to drive the board > > without having to recompile and reboot the kernel each time I make a > change, > > plus if I do something stupid and crash my user space process it > shouldn't > > bring down the whole kernel. Am I thinking about this wrong? Is there > some > > place I can go to read up on what I should be doing? If I am thinking > about > > this correctly, then how does one map device memory into a user space > > process? How does one make sure that only one process has such a > mapping? > > You could use mmap() I think, > > For a driver I maintain I did the following -> > /* Magic sauce stolen from src/sys/pci/xrpu.c via phk > * http://www.mail-archive.com/freebsd-hackers%40freebsd.org/msg11729.html > */ > *paddr = rman_get_start(sc->g_membase.reshandle) + offset; > > g_membase is.. > struct resource *reshandle; /* Resource handle */ > bus_space_tag_t sc_st; /* bus space tag */ > bus_space_handle_t sc_sh; /* bus space handle */ > > PS what board are you using? :) > > Daniel, Cool, that looks like what I am looking for. I'll go and read up on it, thanks very much. I am using the Xilinx SP605 http://www.xilinx.com/products/devkits/EK-S6-SP605-G.htm perfect for playing with hardware for a frame buffer device or graphics device. It comes with a full license for the synthesis and PCIe IP for the device on that board which is a great deal. Christopher -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 15:12:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD50B1065679 for ; Sat, 26 Jun 2010 15:12:07 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD588FC20 for ; Sat, 26 Jun 2010 15:12:05 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o5QFBr2F097395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jun 2010 00:41:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sun, 27 Jun 2010 00:41:52 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> To: Christopher Bowman X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI Express and drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 15:12:07 -0000 On 26/06/2010, at 14:50, Christopher Bowman wrote: >> PS what board are you using? :) >>=20 > Cool, that looks like what I am looking for. I'll go and read up = on it, thanks very much. I am using the Xilinx SP605 = http://www.xilinx.com/products/devkits/EK-S6-SP605-G.htm > perfect for playing with hardware for a frame buffer device or = graphics device. It comes with a full license for the synthesis and = PCIe IP for the device on that board which is a great deal. Ahh, it does look like a fun toy :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 20:53:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06371065670; Sat, 26 Jun 2010 20:53:25 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 400B98FC15; Sat, 26 Jun 2010 20:53:25 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 6D3A418F39B; Sat, 26 Jun 2010 15:32:00 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id N0S35NBA68I9; Sat, 26 Jun 2010 15:31:58 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4C2476A1.1080307@freebsd.org> Date: Sat, 26 Jun 2010 21:31:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99843999-233B-4E07-B815-9808B85B599A@freebsd.org> References: <4C1F798C.7010204@freebsd.org> <201006211143.26459.jhb@freebsd.org> <4C1F8BDD.9010408@freebsd.org> <201006211610.45811.jhb@freebsd.org> <20100621204435.GA98177@hub.freebsd.org> <4C1FDAF9.3080808@freebsd.org> <4C208096.3030602@freebsd.org> <4C2476A1.1080307@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-hackers@freebsd.org, Navdeep Parhar , freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 20:53:25 -0000 On 25 Jun 2010, at 10:28, Andriy Gapon wrote: >=20 > Here's a patch that is supposed to do the right thing for dtrace. > Perhaps I should have put the new code under __amd64__, but I decided = to go more > "generic" and check for module's ELF type (ET_REL). >=20 > Reviews and testing are welcome! I believe this is good to go. Regards, -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 21:14:43 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF6E41065674; Sat, 26 Jun 2010 21:14:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D49F8FC1E; Sat, 26 Jun 2010 21:14:42 +0000 (UTC) Received: by qwg5 with SMTP id 5so1296153qwg.13 for ; Sat, 26 Jun 2010 14:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=P+8tD23pbxCJQUKDp0eVX2afAr2EHwhTuxQ3PuCjbjY=; b=G0fbKK98g10WKJ0njx2jBVWvEVIvnBtgRFQ+1cGv3fz/4OU4imKzSeM9P4zw0yOoQl A0pG/EJUMSfQUsIWVJrH88rVXcBVnmiIAhPryezsEGaAuwAki8MczeWbF+NqNe/3k5wy xAgHeLhhV6oGyXafu9ihDfkkK2nvdbRztbkzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Xi9+8p/4KBBz6Jx3hi4zcGqKix2pZg/CvNTYIlmY55yzXlQBXzFUFLKixG6hPYzByC 7xmo2dz/vfcwCEkQ+9ayzVy95tESLEYlmBq2G9JLFMjaH9EWH30lTGf46tfaq1zlXG5z ctJR+XEckAGFdFh6u8yWq3423HzQj+MNKRrqU= MIME-Version: 1.0 Received: by 10.224.65.103 with SMTP id h39mr1780366qai.288.1277586882523; Sat, 26 Jun 2010 14:14:42 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sat, 26 Jun 2010 14:14:42 -0700 (PDT) Date: Sat, 26 Jun 2010 14:14:42 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: multipart/mixed; boundary=00c09f83a3bc4d745d0489f56076 Cc: Warner Losh , Dag-Erling Smorgrav Subject: [PATCH] Build error with buildworld and -j1 on a memory backed /usr/obj X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:14:43 -0000 --00c09f83a3bc4d745d0489f56076 Content-Type: text/plain; charset=ISO-8859-1 The build for r209530 failed with a clean workspace and a clean /usr/obj/scratch. I was building with a memory-disk backed /usr/obj. Here's the error: ===> usr.bin/ar (depend) lex -t /scratch/freebsd/current/usr.bin/ar/acplex.l > acplex.c yacc -d /scratch/freebsd/current/usr.bin/ar/acpyacc.y cp y.tab.c acpyacc.c rm -f .depend mkdep -f .depend -a -I. -I/scratch/freebsd/current/usr.bin/ar /scratch/freebsd/current/usr.bin/ar/ar.c acplex.c acpyacc.c /scratch/freebsd/current/usr.bin/ar/read.c /scratch/freebsd/current/usr.bin/ar/util.c /scratch/freebsd/current/usr.bin/ar/write.c /scratch/freebsd/current/usr.bin/ar/ar.c:66:21: error: archive.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/acpyacc.y:35:21: error: archive.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/acpyacc.y:36:27: error: archive_entry.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/read.c:33:21: error: archive.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/read.c:34:27: error: archive_entry.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/write.c:34:21: error: archive.h: No such file or directory /scratch/freebsd/current/usr.bin/ar/write.c:35:27: error: archive_entry.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /scratch/freebsd/current/usr.bin/ar. *** Error code 1 Stop in /scratch/freebsd/current/usr.bin. *** Error code 1 Stop in /scratch/freebsd/current. *** Error code 1 Stop in /scratch/freebsd/current. *** Error code 1 Stop in /scratch/freebsd/current. I think this is due to dependency issues with libarchive. I had some changes in my p4 workspace to address the libarchive dependency for libpkg (for work that's incoming in the next couple of months) that Warner helped me out with, and once I applied the change things worked. The patch is attached. Thanks, -Garrett PS This might also resolve some other outstanding issues related to build dependencies with libarchive, like with the ia64 lzma issue that DES and a few other folks have been munging over for a while now. --00c09f83a3bc4d745d0489f56076 Content-Type: application/octet-stream; name="fix-libarchive-dependencies.diff" Content-Disposition: attachment; filename="fix-libarchive-dependencies.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gaww4n3j0 LS0tIE1ha2VmaWxlLmluYzEJMjAxMC0wNi0yNSAyMToxMzozNS4wMDAwMDAwMDAgLTA3MDAKKysr IC4uL3BlcmZvcmNlL3BrZ19pbnN0YWxsLWVuaGFuY2VtZW50cy9NYWtlZmlsZS5pbmMxCTIwMTAt MDYtMjYgMTM6MTE6MDIuMDAwMDAwMDAwIC0wNzAwCkBAIC0xLDUgKzEsNSBAQAogIwotIyAkRnJl ZUJTRCQKKyMgJEZyZWVCU0Q6IHNyYy9NYWtlZmlsZS5pbmMxLHYgMS42NTYgMjAxMC8wNi8yNCAx Nzo1MzoyNSBpbXAgRXhwICQKICMKICMgTWFrZSBjb21tYW5kIGxpbmUgb3B0aW9uczoKICMJLURO T19DTEVBTkRJUiBydW4gJHtNQUtFfSBjbGVhbiwgaW5zdGVhZCBvZiAke01BS0V9IGNsZWFuZGly CkBAIC0xMDE3LDEwICsxMDE3LDYgQEAKIF9yZXNjdWU9IHJlc2N1ZS9yZXNjdWUKIC5lbmRpZgog Ci0uaWYgJHtNS19TWVNJTlNUQUxMfSAhPSAibm8iCi1fc3lzaW5zdGFsbD0JCXVzci5zYmluL3N5 c2luc3RhbGwKLS5lbmRpZgotCiBidWlsZC10b29sczoKIC5mb3IgX3Rvb2wgaW4gXAogICAgIGJp bi9jc2ggXApAQCAtMTAzMiw3ICsxMDI4LDcgQEAKICAgICAke19haWNhc219IFwKICAgICB1c3Iu YmluL2F3ayBcCiAgICAgbGliL2xpYm1hZ2ljIFwKLSAgICAke19zeXNpbnN0YWxsfQorICAgIHVz ci5zYmluL3N5c2luc3RhbGwKIAkke18rX31AJHtFQ0hPRElSfSAiPT09PiAke190b29sfSAob2Jq LGJ1aWxkLXRvb2xzKSI7IFwKIAkJY2QgJHsuQ1VSRElSfS8ke190b29sfTsgXAogCQkke01BS0V9 IERJUlBSRlg9JHtfdG9vbH0vIG9iajsgXApAQCAtMTEyNSwxNiArMTEyMSwxNSBAQAogX3ByZWJ1 aWxkX2xpYnM9CSR7X2tlcmJlcm9zNV9saWJfbGliYXNuMX0gJHtfa2VyYmVyb3M1X2xpYl9saWJo ZWltbnRsbX0gXAogCQkke19rZXJiZXJvczVfbGliX2xpYmh4NTA5fSAke19rZXJiZXJvczVfbGli X2xpYmtyYjV9IFwKIAkJJHtfa2VyYmVyb3M1X2xpYl9saWJyb2tlbn0gXAotCQlsaWIvbGliYnoy IGxpYi9saWJjb21fZXJyIGxpYi9saWJjcnlwdCBcCi0JCWxpYi9saWJleHBhdCBsaWIvbGliZmV0 Y2ggXAotCQkke19saWJfbGliZ3NzYXBpfSAke19saWJfbGliaXB4fSBcCisJCWxpYi9saWJhcmNo aXZlIGxpYi9saWJiejIgbGliL2xpYmNvbV9lcnIgbGliL2xpYmNyeXB0IFwKKwkJbGliL2xpYmV4 cGF0IGxpYi9saWJmZXRjaCAke19saWJfbGliZ3NzYXBpfSAke19saWJfbGliaXB4fSBcCiAJCWxp Yi9saWJraWNvbnYgbGliL2xpYmt2bSBsaWIvbGlibHptYSBsaWIvbGlibWQgXAogCQlsaWIvbmN1 cnNlcy9uY3Vyc2VzIGxpYi9uY3Vyc2VzL25jdXJzZXN3IFwKLQkJbGliL2xpYm9waWUgbGliL2xp YnBhbSAke19saWJfbGlidGhyfSBcCisJCWxpYi9saWJvcGllIGxpYi9saWJwYW0gJHtfbGliX2xp YnBrZ30gJHtfbGliX2xpYnRocn0gXAogCQlsaWIvbGlicmFkaXVzIGxpYi9saWJzYnVmIGxpYi9s aWJ0YWNwbHVzIFwKIAkJbGliL2xpYnV0aWwgJHtfbGliX2xpYnlwY2xudH0gbGliL2xpYnogbGli L21zdW4gXAogCQkke19zZWN1cmVfbGliX2xpYmNyeXB0b30gJHtfc2VjdXJlX2xpYl9saWJzc2h9 IFwKLQkJJHtfc2VjdXJlX2xpYl9saWJzc2x9CisJCSR7X3NlY3VyZV9saWJfbGlic3NsfSBcCiAK IC5pZiAke01LX0xJQlRIUn0gIT0gIm5vIgogX2xpYl9saWJ0aHI9CWxpYi9saWJ0aHIKQEAgLTEx NDIsNiArMTEzNywxMyBAQAogCiBfZ2VuZXJpY19saWJzPQkke19jZGRsX2xpYn0gZ251L2xpYiAk e19rZXJiZXJvczVfbGlifSBsaWIgJHtfc2VjdXJlX2xpYn0gdXNyLmJpbi9sZXgvbGliCiAKKy5p ZiAke01LX0NSWVBUfSA9PSBubworbGliL2xpYmFyY2hpdmVfX0w6IGxpYi9saWJiejJfX0wgbGli L2xpYmx6bWFfX0wgbGliL2xpYm1kX19MIGxpYi9saWJ6X19MCisuZWxzZQorbGliL2xpYmFyY2hp dmVfX0w6IGxpYi9saWJiejJfX0wgbGliL2xpYmx6bWFfX0wgbGliL2xpYm1kX19MIGxpYi9saWJ6 X19MIFwKKwkJICAgc2VjdXJlL2xpYi9saWJjcnlwdG9fX0wKKy5lbmRpZgorCiBsaWIvbGlib3Bp ZV9fTCBsaWIvbGlidGFjcGx1c19fTDogbGliL2xpYm1kX19MCiAKIC5pZiAke01LX0NEREx9ICE9 ICJubyIKQEAgLTExOTIsNiArMTE5NCwxMiBAQAogbGliL2xpYmZldGNoX19MIGxpYi9saWJyYWRp dXNfX0w6IGxpYi9saWJtZF9fTAogLmVuZGlmCiAKKy5pZiAke01LX1BLR1RPT0xTfSAhPSAibm8i CitfbGliX2xpYnBrZz0JbGliL2xpYnBrZworIyBPbmx5IGxpc3RpbmcgZGlyZWN0IGRlcGVuZGVu Y2llcyBvZiBsaWJwa2cuCitsaWIvbGlicGtnX19MOiBsaWIvbGliYXJjaGl2ZV9fTCBsaWIvbGli ZmV0Y2hfX0wgbGliL2xpYm1kX19MIGxpYi9saWJ1dGlsX19MCisuZW5kaWYKKwogLmZvciBfbGli IGluICR7X3ByZXJlcV9saWJzfQogJHtfbGlifV9fUEw6IC5QSE9OWQogLmlmIGV4aXN0cygkey5D VVJESVJ9LyR7X2xpYn0pCg== --00c09f83a3bc4d745d0489f56076-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 26 21:43:22 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A32641065672; Sat, 26 Jun 2010 21:43:22 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2839B8FC0A; Sat, 26 Jun 2010 21:43:21 +0000 (UTC) Received: by qyk12 with SMTP id 12so80851qyk.13 for ; Sat, 26 Jun 2010 14:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yDlXKeSlLgYz09DV7mHSjRcWBPcd0N1IyVxMycmthkc=; b=YUbJvzl94eZWokqFhMAzXmmCb9A/Khc6nKYN0Ceff866GBMh/xbOMMMKHOS1ih00eQ ySQNwhPowUHa1FdGk9bMXwuJQEsQU84MgPzz7Fa99Cc5JVz1q/eyDGFhEW1KXdSqhDH1 jUpESD7c2aQ2ESDeKVvtXdFaC78s6Exq/euI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rrWs8crcmidHneN/GUPsejTwwWydT3K11uLHz2JfyryXSeAhx120nFb+GJSAabaRgN MGN1o+SrvyV9vcz70tPHcmSgNOaY7Aw7WGqj2HgmVoxi/ElrxQpUWL+N2SV8yg3sKSJq gB4xojYVrg9YHIqIMhkHXEWaiDOZbKwIg4cCs= MIME-Version: 1.0 Received: by 10.229.182.16 with SMTP id ca16mr1514024qcb.88.1277588601242; Sat, 26 Jun 2010 14:43:21 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sat, 26 Jun 2010 14:43:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Jun 2010 14:43:21 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: multipart/mixed; boundary=0016363101cbbf047d0489f5c63f Cc: Warner Losh , Dag-Erling Smorgrav Subject: Re: [PATCH] Build error with buildworld and -j1 on a memory backed /usr/obj X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:43:22 -0000 --0016363101cbbf047d0489f5c63f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 26, 2010 at 2:14 PM, Garrett Cooper wrote: > =A0 =A0The build for r209530 failed with a clean workspace and a clean > /usr/obj/scratch. I was building with a memory-disk backed /usr/obj. > Here's the error: > > =3D=3D=3D> usr.bin/ar (depend) > lex -t =A0/scratch/freebsd/current/usr.bin/ar/acplex.l > acplex.c > yacc -d /scratch/freebsd/current/usr.bin/ar/acpyacc.y > cp y.tab.c acpyacc.c > rm -f .depend > mkdep -f .depend -a =A0 =A0-I. -I/scratch/freebsd/current/usr.bin/ar > /scratch/freebsd/current/usr.bin/ar/ar.c acplex.c acpyacc.c > /scratch/freebsd/current/usr.bin/ar/read.c > /scratch/freebsd/current/usr.bin/ar/util.c > /scratch/freebsd/current/usr.bin/ar/write.c > /scratch/freebsd/current/usr.bin/ar/ar.c:66:21: error: archive.h: No > such file or directory > /scratch/freebsd/current/usr.bin/ar/acpyacc.y:35:21: error: archive.h: > No such file or directory > /scratch/freebsd/current/usr.bin/ar/acpyacc.y:36:27: error: > archive_entry.h: No such file or directory > /scratch/freebsd/current/usr.bin/ar/read.c:33:21: error: archive.h: No > such file or directory > /scratch/freebsd/current/usr.bin/ar/read.c:34:27: error: > archive_entry.h: No such file or directory > /scratch/freebsd/current/usr.bin/ar/write.c:34:21: error: archive.h: > No such file or directory > /scratch/freebsd/current/usr.bin/ar/write.c:35:27: error: > archive_entry.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /scratch/freebsd/current/usr.bin/ar. > *** Error code 1 > > Stop in /scratch/freebsd/current/usr.bin. > *** Error code 1 > > Stop in /scratch/freebsd/current. > *** Error code 1 > > Stop in /scratch/freebsd/current. > *** Error code 1 > > Stop in /scratch/freebsd/current. > > =A0 =A0I think this is due to dependency issues with libarchive. I had > some changes in my p4 workspace to address the libarchive dependency > for libpkg (for work that's incoming in the next couple of months) > that Warner helped me out with, and once I applied the change things > worked. The patch is attached. > > Thanks, > -Garrett > > PS This might also resolve some other outstanding issues related to > build dependencies with libarchive, like with the ia64 lzma issue that > DES and a few other folks have been munging over for a while now. Sorry. The old patch contained some noise from other changes I was testing out earlier. This cleans it up. Thanks, -Garrett --0016363101cbbf047d0489f5c63f Content-Type: application/octet-stream; name="fix-libarchive-dependencies.diff" Content-Disposition: attachment; filename="fix-libarchive-dependencies.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gawz73vx1 SW5kZXg6IE1ha2VmaWxlLmluYzEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFrZWZpbGUuaW5jMQkocmV2aXNp b24gMjA5NTMwKQorKysgTWFrZWZpbGUuaW5jMQkod29ya2luZyBjb3B5KQpAQCAtMTEyMSwxNiAr MTEyMSwxNSBAQAogX3ByZWJ1aWxkX2xpYnM9CSR7X2tlcmJlcm9zNV9saWJfbGliYXNuMX0gJHtf a2VyYmVyb3M1X2xpYl9saWJoZWltbnRsbX0gXAogCQkke19rZXJiZXJvczVfbGliX2xpYmh4NTA5 fSAke19rZXJiZXJvczVfbGliX2xpYmtyYjV9IFwKIAkJJHtfa2VyYmVyb3M1X2xpYl9saWJyb2tl bn0gXAotCQlsaWIvbGliYnoyIGxpYi9saWJjb21fZXJyIGxpYi9saWJjcnlwdCBcCi0JCWxpYi9s aWJleHBhdCBsaWIvbGliZmV0Y2ggXAotCQkke19saWJfbGliZ3NzYXBpfSAke19saWJfbGliaXB4 fSBcCisJCWxpYi9saWJhcmNoaXZlIGxpYi9saWJiejIgbGliL2xpYmNvbV9lcnIgbGliL2xpYmNy eXB0IFwKKwkJbGliL2xpYmV4cGF0IGxpYi9saWJmZXRjaCAke19saWJfbGliZ3NzYXBpfSAke19s aWJfbGliaXB4fSBcCiAJCWxpYi9saWJraWNvbnYgbGliL2xpYmt2bSBsaWIvbGlibHptYSBsaWIv bGlibWQgXAogCQlsaWIvbmN1cnNlcy9uY3Vyc2VzIGxpYi9uY3Vyc2VzL25jdXJzZXN3IFwKLQkJ bGliL2xpYm9waWUgbGliL2xpYnBhbSAke19saWJfbGlidGhyfSBcCisJCWxpYi9saWJvcGllIGxp Yi9saWJwYW0gJHtfbGliX2xpYnBrZ30gJHtfbGliX2xpYnRocn0gXAogCQlsaWIvbGlicmFkaXVz IGxpYi9saWJzYnVmIGxpYi9saWJ0YWNwbHVzIFwKIAkJbGliL2xpYnV0aWwgJHtfbGliX2xpYnlw Y2xudH0gbGliL2xpYnogbGliL21zdW4gXAogCQkke19zZWN1cmVfbGliX2xpYmNyeXB0b30gJHtf c2VjdXJlX2xpYl9saWJzc2h9IFwKLQkJJHtfc2VjdXJlX2xpYl9saWJzc2x9CisJCSR7X3NlY3Vy ZV9saWJfbGlic3NsfSBcCiAKIC5pZiAke01LX0xJQlRIUn0gIT0gIm5vIgogX2xpYl9saWJ0aHI9 CWxpYi9saWJ0aHIKQEAgLTExMzgsNiArMTEzNywxMyBAQAogCiBfZ2VuZXJpY19saWJzPQkke19j ZGRsX2xpYn0gZ251L2xpYiAke19rZXJiZXJvczVfbGlifSBsaWIgJHtfc2VjdXJlX2xpYn0gdXNy LmJpbi9sZXgvbGliCiAKKy5pZiAke01LX0NSWVBUfSA9PSBubworbGliL2xpYmFyY2hpdmVfX0w6 IGxpYi9saWJiejJfX0wgbGliL2xpYmx6bWFfX0wgbGliL2xpYm1kX19MIGxpYi9saWJ6X19MCisu ZWxzZQorbGliL2xpYmFyY2hpdmVfX0w6IGxpYi9saWJiejJfX0wgbGliL2xpYmx6bWFfX0wgbGli L2xpYm1kX19MIGxpYi9saWJ6X19MIFwKKwkJICAgc2VjdXJlL2xpYi9saWJjcnlwdG9fX0wKKy5l bmRpZgorCiBsaWIvbGlib3BpZV9fTCBsaWIvbGlidGFjcGx1c19fTDogbGliL2xpYm1kX19MCiAK IC5pZiAke01LX0NEREx9ICE9ICJubyIKQEAgLTExODgsNiArMTE5NCwxMiBAQAogbGliL2xpYmZl dGNoX19MIGxpYi9saWJyYWRpdXNfX0w6IGxpYi9saWJtZF9fTAogLmVuZGlmCiAKKy5pZiAke01L X1BLR1RPT0xTfSAhPSAibm8iCitfbGliX2xpYnBrZz0JbGliL2xpYnBrZworIyBPbmx5IGxpc3Rp bmcgZGlyZWN0IGRlcGVuZGVuY2llcyBvZiBsaWJwa2cuCitsaWIvbGlicGtnX19MOiBsaWIvbGli YXJjaGl2ZV9fTCBsaWIvbGliZmV0Y2hfX0wgbGliL2xpYm1kX19MIGxpYi9saWJ1dGlsX19MCisu ZW5kaWYKKwogLmZvciBfbGliIGluICR7X3ByZXJlcV9saWJzfQogJHtfbGlifV9fUEw6IC5QSE9O WQogLmlmIGV4aXN0cygkey5DVVJESVJ9LyR7X2xpYn0pCg== --0016363101cbbf047d0489f5c63f--